17:49:36 <RRSAgent> RRSAgent has joined #openui
17:49:36 <RRSAgent> logging to https://www.w3.org/2021/06/03-openui-irc
17:50:26 <gregwhitworth> gregwhitworth has changed the topic to: Open UI Telecon: https://github.com/openui/open-ui/blob/main/meetings/telecon/2021-06-03.md
17:56:12 <chrisdholt> chrisdholt has joined #openui
17:57:51 <gregwhitworth> Zakim, start the meeting
17:57:51 <Zakim> RRSAgent, make logs Public
17:57:52 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
17:57:59 <gregwhitworth> meeting: Open UI Telecon
17:58:03 <gregwhitworth> chair: Greg Whitworth
17:59:18 <flackr> flackr has joined #openui
18:00:03 <neovalk> neovalk has joined #openui
18:01:19 <flackr> present+
18:01:22 <chrisdholt> present+
18:01:28 <miriam> present+
18:01:29 <gregwhitworth> present+
18:01:56 <una> una has joined #openui
18:02:02 <masonf> masonf has joined #openui
18:02:02 <una> present+
18:02:05 <masonf> present+
18:02:10 <dandclark> present+
18:02:10 <masonf> (because I forgot)
18:02:21 <brodym> brodym has joined #openui
18:02:23 <brodym> present+
18:03:30 <gregwhitworth> scribenick: melanierichards
18:03:53 <melanierichards> present+
18:03:56 <neovalk> present+
18:04:06 <melanierichards> una: anchor pos explainer is out! Take a look
18:04:29 <tantek> regrets+
18:04:40 <una> https://github.com/openui/open-ui/blob/main/meetings/telecon/2021-06-03.md
18:04:44 <davatron5000> davatron5000 has joined #openui
18:04:49 <una> https://github.com/openui/open-ui/issues/251#issuecomment-839330098
18:04:51 <davatron5000> present+
18:04:57 <melanierichards> topic: #251
18:05:14 <andrico_> andrico_ has joined #openui
18:05:50 <una> Here's that explainer to take a look at later: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
18:07:02 <melanierichards> leo: started researching radio buttons, thought it would be as simple as a checkbox. Radio buttons, they work kind of like select boxes. Allow us to choose one option from a set of options. While the checkboxes only allow us to set a bool value for one input. The radio buttons, they are mostly a different layout for a select box. They allow us to choose from several options, only one. Main diff being layout allows us to decide where
18:07:02 <melanierichards> we want to make the info readily available for user to see, or maybe we want to compress every option in a single line (select box)
18:07:33 <bkardell_> present+
18:07:54 <bkardell_> bkardell_ has joined #openui
18:08:25 <melanierichards> leo: radio buttons have quirks that select box doesn't have. Radio buttons could have a similar structure than select box. Could have a tag for a radio button group, and a different tag for every option in the group, a label for the options, much like select box. Could slap an attr to a select box and have it behave visually like a radio group, logic is so similar. However, would lose flexibility radio buttons give us. Could break
18:08:25 <melanierichards> the component apart, place the radio buttons all over the page and have them bound together by the name attr, even though they are visually apart
18:08:39 <gregwhitworth> q+
18:09:13 <chrisdholt> q+
18:10:19 <melanierichards> leo: if we tried to change the structure of the HTML of a radio button group to like a select box, we would lose this flexibility. Radio button grouping is a little weird. When we talk about labels, every input field has its own label. Could bind w/ for attr. When we're talking about the radio buttons, we're not talking about the group, we're talking about each option. It's like we have a select box and label each option. We don't
18:10:19 <melanierichards> have label for the group. Would need fieldset w/ legend. While this is ok, this is a diff use for the fieldset. Grouping a single input result instead of different inputs. All part of a single possible choice.
18:10:26 <bkardell_> present+
18:12:33 <melanierichards> leo: wouldn't be a big problem but there are some cases where we can make semantic differential scale, can build a table with a question in each row, each column has a radio button that represents an answer to that question. If we actually use tables, we don't have anywhere to put the fieldset. Would have to make the whole table a fieldset. But if we need a single table w/ all the inputs, then we miss a place to put a fieldset for
18:12:33 <melanierichards> the radio buttons. This is kind of an edge case but we see this type of layout a lot, presume other situations where we have to retain the flexibility of the radio button groups, we have to make an HTML structure that would actually allow us to group them not with fieldsets. Need something other than just the name attr. And maybe this would make it less repetitive. Maybe wouldn't need to repeat the value for every instance of the
18:12:33 <melanierichards> input field
18:12:50 <una> q?
18:13:38 <bkardell_> I think x-forms was like this
18:16:14 <melanierichards> leo: [presenting] could have a structure similiar to select box, but that would limit flexibility. Can't use fieldsets for each row because we'd break the table apart. Need some binding to group the table as a whole. Table cell with question and inputs with labels bound by name attr, the only thing that binds them with the question is the [table semantics] Could have special tag for group label that has an attr that binds it to the
18:16:14 <melanierichards> name attr of all the radio buttons. Or we could have, as suggested on the issue, maybe have only one input field that represents the selected choice. The radio button would actually be the question. The value of the whole group would be set on this input. The answers would be a use for the <option> element. Bound to input by attr. This would allow us to always try to target the input tag to get the value.
18:16:17 <gregwhitworth> q-
18:16:27 <gregwhitworth> q+
18:16:57 <bkardell_> q+
18:17:03 <melanierichards> leo: question we have is, if we're creating components for it, should we have a rigid structure like <radioGroup> (like select box), or retain flexibility and propose another way to bind a label to the actual input group.
18:17:16 <melanierichards> leo: Greg said maybe we can have both
18:19:07 <una> ack chrisdholt
18:19:08 <melanierichards> chrisdholt: great, ton of research. One thing that stands out to me, I think this is a complicated issue but things like the name attr would work well for binding inputs together, but then we'd have to consider impl from ARIA and ARIA radios. We associate ARIA radios under a radiogroup component because of our requirements. Those end up being different, unique bit is we can't bind with the name...throwing a little bit of gasoline on
18:19:08 <melanierichards> this, but it's something tha needs to be addressed. Came up with checkbox, input type checkbox and ARIA checkbox, they're different beasts in some sense. Holistic solution needs to be flexible
18:19:22 <melanierichards> gregwhitworth: how do his options don't fit into what you outlined?
18:19:35 <neovalk> q+
18:20:14 <melanierichards> chrisdholt: ARIA spec says that ARIA radio needs to be child of radiogroup. AT expects direct descendent. The platform obfuscated some of the pain of association. Associating using w/ name attr. Platform has special magic we don't get to use that causes this problem
18:20:17 <una> ack gregwhitworth
18:21:08 <melanierichards> gregwhitworth: the reason I said I recommend both, I agree w/ flexibility aspect that you'd outlined, need a grouping mechanism that provides flexibility that allows authors to sprinkle things in a DOM structure that's not strict. That said, large/common paradigm of radio groups that could be a common component
18:21:17 <eugene> eugene has joined #openui
18:22:06 <melanierichards> gregwhitworth: why  is name not necessarily still sufficient for cross dom structure binding?
18:22:18 <melanierichards> chrisdholt: it's not an actual input, it's an ARIA radio
18:22:32 <melanierichards> gregwhitworth: so the binding doesn't magically happen for you
18:23:04 <una> ack bkardell_
18:23:05 <melanierichards> chrisdholt: yeah...we have some requirements that pushed us into the ARIA direction. Both implementations exist and are valid, one has benefits the other doesn't?
18:23:26 <melanierichards> q+
18:24:09 <melanierichards> bkardell_: if you were trying to do this with ARIA in a table, the label you can do with an ARIA attr, but the grouping is the million dollar question
18:24:41 <melanierichards> chrisdholt: from AT standpoint, each direct child of radiogroup would have a role of radio. We're blocked by this scenario because we're not inputs
18:25:01 <una> ack neovalk
18:25:04 <gregwhitworth> chrisdholt do you have a public bug on that blocking issue?
18:25:07 <melanierichards> leo: wasn't thinking about ARIA but that makes the problem a little bit bigger
18:26:33 <melanierichards> leo: was looking at consistency aspect, labels and fieldsets are used in an inconsistent way when we're talking about radio buttons. This doesn't click with me very well. We could have ARIA work w/o a parent HTML tag. Wouldn't have solution for the whole group. This is the basic problem we have here. Implementation is outside of the scope of my work. IDK how to do this.
18:26:53 <melanierichards> bkardell_: this is a problem for a lot of controls, right?
18:27:00 <melanierichards> gregwhitworth: yeah binding comes up everywhere
18:27:37 <melanierichards> gregwhitworth: it seems like the crux here is the binding is only available on an input. The labeling aspect is a different question, whether rigid or flexible, I imagine group would agree we generally want flexibility
18:27:45 <gregwhitworth> ack una
18:27:52 <gregwhitworth> ack melanierichards
18:28:04 <gregwhitworth> melanierichards: I was curious to see
18:28:12 <gregwhitworth> melanierichards: this is just a subset of the problems we're trying to solve
18:28:22 <gregwhitworth> melanierichards: is there a different way to solve the root problem?
18:28:39 <gregwhitworth> melanierichards: chrisdholt you said you have reqs that require you to reach for aria-role rather than the HTML input?
18:28:54 <gregwhitworth> melanierichards: maybe we unblock that rather than making name= work on everything?
18:29:06 <gregwhitworth> melanierichards: we'd want to have something aria specific solution
18:29:25 <gregwhitworth> chrisdholt: yeah it's just frustrating because the platform just handles it with input radios
18:29:32 <gregwhitworth> chrisdholt: there's a disconnect with custom elements
18:29:50 <gregwhitworth> chrisdholt: I would love some way to logically group things that aren't direct descendants in the DOM
18:30:02 <gregwhitworth> chrisdholt: I can handle keyboarding, form association, etc
18:30:20 <gregwhitworth> chrisdholt: but the minute that role of radio is not a direct descendant of radio group a11y is out the window and nothing I can do
18:30:25 <gregwhitworth> chrisdholt: use input that is native
18:30:29 <gregwhitworth> chrisdholt: that's not an option for us
18:30:33 <gregwhitworth> chrisdholt: tough
18:31:23 <melanierichards> gregwhitworth: would be cool to have that blocking use case somewhere, ultimately it is that grouping mechanism we want to solve
18:31:51 <una> q+
18:31:58 <gregwhitworth> ack una
18:32:44 <gregwhitworth> +1 to that una
18:33:14 <melanierichards> una: really good points, I do think a part of what we are trying to solve is building accessibility in. Ways we can work around this with some kind of binding tag, maybe not inside in the radiogroup  but in sibling elements...this is not a new pattern to have this tag, we can provide that here. Maybe best practices. Tag maybe not the primary option because it would add complexity for other use cases
18:33:47 <melanierichards> gregwhitworth: agree, should do both. Thing I want to make sure is captured, Chris is blocked in some other way and maybe it needs a new issue or Chris can pile on this issue.
18:34:05 <melanierichards> una: good next step would be a proposal of what these both look like
18:34:05 <chrisdholt> It's noted in the issue (very early on) - I can add more if need be
18:34:41 <chrisdholt> Unfortunately I've got to drop for an internal sync. Thanks all! This is a tough problem but agree it's definitely solveable, especially with this group.
18:35:21 <chrisdholt> On the CSS note - if I need these represented *in* the table, that loses the semantics needed to represent for AT as well.
18:35:23 <chrisdholt> OK, that's all!
18:35:25 <chrisdholt> Thanks!
18:35:48 <melanierichards> leo: there are some advantages to radioGroup tag. Could set a lot of attrs to radioGroup to have it laid out in a different way. We could maybe do all of this with CSS. Hmm. I'm not sure. The way some of the design systems use this kind of structure, options work like radio buttons, maybe larger, smaller, vertical, horizontal, but the way they've abstracted it, that could be achievable in CSS. So this one just makes the grouping
18:35:48 <melanierichards> simpler
18:36:38 <melanierichards> gregwhitworth: that would be why we'd go do this. Just have people reach for radiogroup. Understand limitations, they're probably majority use case though. Technically we could achieve layouts like the one you've shown w/o table.
18:37:27 <melanierichards> gregwhitworth: checkbox group could work the same way, very prevalent, but there's no binding mechanism in any meaningful way other than rolling yourself. I think this is technically the proposal for the anatomy if you presume the group mechanism exists.
18:38:27 <melanierichards> una: I think the grouping is fine, what we're not seeing yet is the solution for the disjoint radios. Not as much an a11y problem as a a declaration problem. How to declaratively have non-sibling radios a part of the same grouping. How do we tell the DOM this is a group, don't let more than one be selected?
18:39:27 <melanierichards> leo: this proposal of Sergei's, I could see...we have an input, and the <option>s would work like radio and label at the same time. Clicking on them would populate the value of the input.
18:39:39 <melanierichards> leo: we could maybe have this implemented in an accessible way
18:40:35 <melanierichards> leo: the fact that this is on input could make it easier to handle with JS, only one place to look at for options. So I actually like this one. Radio input is the main Q, and the options are handles for this input field.
18:41:19 <melanierichards> leo: I have no idea how this would translate to HTML, would need new HTML
18:41:26 <melanierichards> una: yeah that new HTML is what we should think about next
18:41:57 <bkardell_> q+
18:42:07 <melanierichards> gregwhitworth: how complicated would it be to say, "name attr binds any element that has the same name"
18:42:39 <melanierichards> gregwhitworth: would potentially come back w/ spec text and maybe start by saying I would make name work with any element, and how the browser knows what to bind is based on that model that already exists.
18:44:14 <melanierichards> gregwhitworth: re-spec'ing how name binding works for radios today, but with any element
18:44:34 <melanierichards> una: next steps to spec out a solution
18:44:43 <una> ack bkardell_
18:44:43 <melanierichards> gregwhitworth: leo, ping me on Discord, I'm happy to help
18:45:23 <melanierichards> bkardell_: what does it mean to bind in this case? There's form value/submission, there's key bindings, role bindings...it would be great if you had a shorthand for this that didn't require you to bolt on a thousand ARIA things.
18:45:40 <melanierichards> present?
18:47:10 <gregwhitworth> Zakim, end meeting
18:47:10 <Zakim> As of this point the attendees have been flackr, chrisdholt, miriam, gregwhitworth, una, masonf, dandclark, brodym, melanierichards, neovalk, davatron, bkardell_
18:47:13 <Zakim> RRSAgent, please draft minutes
18:47:13 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/03-openui-minutes.html Zakim
18:47:14 <melanierichards> rrsagent, make minutes
18:47:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/03-openui-minutes.html melanierichards
18:47:16 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
18:47:20 <Zakim> Zakim has left #openui
18:47:34 <bkardell_> doh I was going to add something to clarify for the minutes - I'll add them to the issue
18:48:46 <bkardell_> basically just that ^ by this I mean for example that if you do all of these things without talking about the patterns that make radio buttons in the sequential focus order and arrow keys and things, even still you have to resort to js too - that would be really sad too
19:59:53 <gregwhitworth> RRSAgent, please re-generate minutes v2
19:59:53 <RRSAgent> I'm logging. I don't understand 'please re-generate minutes v2', gregwhitworth.  Try /msg RRSAgent help
21:18:29 <gregwhitworth> RRSAgent, please make minutes public
21:18:29 <RRSAgent> I'm logging. I don't understand 'please make minutes public', gregwhitworth.  Try /msg RRSAgent help
21:18:38 <gregwhitworth> RRSAgent, please make logs world-visible
21:32:07 <gregwhitworth> RRSAgent, please generate the minutes
21:32:07 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/03-openui-minutes.html gregwhitworth