Meeting minutes
set the topic: Agenda for April 24: https://lists.w3.org/Archives/Public/public-open-ui/2020Apr/0005.html
Topic Agenda for April 24: https://lists.w3.org/Archives/Public/public-open-ui/2020Apr/0005.html
set the topic: Agenda for April 24 https://lists.w3.org/Archives/Public/public-open-ui/2020Apr/0002.html
Interactive elements within a select
https://github.com/WICG/open-ui/issues/74
<Levi> Greg: Due to ARIA guidelines, we should not allow interactive elements inside the option elements
<Levi> Confirming, we would still allow for styling a checkbox appearance inside the option, as in the linked github issue, we just won't allow keyboard interaction and focusable elements within the option element?
<Levi> Greg/Chris: Confirmed and agreed
<Levi> Levi: What about combo box and searchable lists? Do they allow interactive elements in the searchable part? Such as a list of active items.
<Levi> Greg: Out of scope for current select proposal
<Levi> Chris: Not a reason to overload select with combo box behavior.
Resolution: Do not allow interactive elements within an option
Select anatomy
https://github.com/WICG/open-ui/issues/73
Levi: there is a top part or a bottom part, can they search them or not. They all seem to be functional changes but the concept is a top and bottom parts
Levi: Speaking from the component teams we'll need to be able to have the tags to represent the states in the bottom options
<Levi> Greg: Technically, the platform select element does support these things it is just difficult to use and not clear. This is probably a WHATWG conversation.
Action: gregwhitworth to open a new issue for the anatomy for button to allow for tag type selection
Levi: normally the design docs will have the sub-parts in the design specs
gregwhitworth: that's good to know because it's hard to decipher them from code
Levi: there currently aren't any implementations of a design system with listbox so I'm hesitant to agree with this.
gregwhitworth: that's a valid point, but the ones that have menu are technically for items and I primarily want to expose this container. If this was a dropdown I'd agree with the menu
chrisdholt: I'm curious what role/behavior comes into account when naming. They visually may be the same, function and semantics are very different. So I'd wonder, how do we hold tension between visual and function
Levi: yes, I can kind of see this. I'll go over the research and it may be missing something
Action: Levi to review research and provide feedback on PR
Levi: it would be good to understand if we should include native usage in the research
chrisdholt: I wouldn't want to throw out content because people use native
Levi: Ant is very interesting, the props and the parts in HTML are conflicting for example. All of their text refers to it as a menu
chrisdholt: it would be good to understand how to weight the content, is the HTML more important or are the props/api surface?
chrisdholt: sometimes it's compat, they desire to change but can't
Levi: we ran into this as well, when people are talking about it they may refer to it in a different way
Levi: yeah they use item and option as well as in other areas
chrisdholt: the platform doesn't have the same restrictions so I end up having to contain numerous other things due to having to recreate them
chrisdholt: so this may lead to convulution of naming
Action: Levi to add in naming support for subparts similar to specimens