18:02:32 RRSAgent has joined #openui 18:02:37 logging to https://www.w3.org/2026/07/09-openui-irc 18:02:38 Zakim, start meeting 18:02:38 RRSAgent, make logs Public 18:02:40 please title this meeting ("meeting: ..."), keithamus 18:02:55 meeting: Open UI 18:03:15 jarhar has joined #openui 18:04:13 Present+ 18:04:23 Present+ 18:04:28 github-bot, take up https://github.com/openui/open-ui/issues/226 18:04:29 Topic: Token feature, or something like that. 18:04:29 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/226 18:04:29 sarah has joined #openui 18:04:36 present+ 18:04:39 present+ 18:04:41 bkardell has joined #openui 18:04:43 present+ 18:04:54 present+ 18:05:05 present+ 18:05:13 I vote we close this issue. 18:05:20 keithamus: *presents issue* 18:06:06 bkardell: i think we should close this 18:06:15 +1 18:06:16 proposed resolution: close this issue for now 18:06:37 q+ 18:06:47 gregwhitworth: theres no champion, but not sure if we should close this 18:06:55 gregwhitworth: i dont want it to look like openui doesnt think we should do this 18:07:18 proposed resolution: We don't have a current champion, so we'll close this as not planned. 18:07:25 +1 18:07:27 +1 18:07:28 RESOLVED: We don't have a current champion, so we'll close this as not planned. 18:07:57 lwarlow: i dont know if this is something that openui wants to take up. a token or chip or various different name for it, they dont seem to me like they have semantic meaning 18:08:02 lwarlow: maybe they have use cases we should go after 18:08:09 lwarlow: generally arent they just spans with maybe a button? 18:08:17 gregwhitworth: can we debate this when it has a champion? 18:08:18 it is the kind of thing a champion would need to provide which is why I suggested closing it 18:08:26 gregwhitworth: i will happily debate you on this 18:08:42 this sounds like greg is weakly championing it :) 18:08:46 keithamus: we can park it and figure out when anyone wishes to resurface it 18:08:49 github-bot, take up https://github.com/openui/open-ui/issues/1118 18:08:50 Topic: select: provide a way for authors to define the string value of rich options 18:08:50 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1118 18:09:47 jarhar: I think this would be cool, I just don't know how to put this in HTML markup in a way which works with WHATWG. 18:09:54 q+ 18:10:03 sarah: the feature is a thing that in fluent we need to be able to use it, but yeah idk what the best way to mark this up is 18:10:28 sarah: in the past we threw around - the label attribute. repurpose label in stylable select and combobox because its an attribute that already exists and its useless 18:10:31 q+ 18:10:41 sarah: but its already an attribute and already does a thing 18:11:06 sarah: to go over why its needed: stylable select in the dropdown of options you have a rich set of stuff and the actual name which is the thing you care about but theres more information like the email, status, office number, etc 18:11:21 sarah: so that could show up in the select menu but when you select something you only want the name to show up 18:11:40 jarhar: you mention you want it to show up in the button 18:11:41 sarah: yes 18:11:43 q+ 18:11:49 jarhar: in the dropdown? Not when it's rendered in the button 18:11:51 sarah: generally 18:12:20 sarah: what's rendered in the button can be customised. But especially when we move to filterable/comboboxes we need more than a simple string - when you filter you want to define "this is the string that mathces" 18:12:32 sarah: you only want that to match based on the relevant string, the rest is ancilliary. 18:13:13 jarhar: sounds like "typeahead", e.g. type to focus an option, "text" used for matching for filtering, then there's what's rendered in the option in the dropdown and what's rendered in the button. Those 4 right? 18:13:30 sarah: typeahead and type to filter are conceptually the same, just whether or not there's an input or you're just hitting keys. 18:13:36 lwarlow: i think 18:13:53 lwarlow: ideally label would be the attribute for this, but it currently already replaces the rendered thing 18:14:03 lwarlow: thats already a behavior that someone somewhere is going to be relying on 18:14:13 lwarlow: i think a new attribute that we'll name "bruce" for now which takes a string seems like the way to do it 18:14:19 lwarlow: an attribute on the option seems fine here 18:14:30 lwarlow: its deliberately only meant to be a string, so it doesnt matter if its an attribute 18:14:37 lwarlow: i think attribute values can contain unicode characters 18:14:46 +1 for label, just posted in the issue 18:14:49 lwarlow: so youll at least get non ascii stuff in there for internationalization 18:15:04 gregwhitworth: ironically sarah just wanted to go back to what we propsoed in 2024 18:15:07 Jacques has joined #openui 18:15:12 gregwhitworth: i feel like we could come up with solutions on the call all day 18:15:30 gregwhitworth: luke even with the combobox proposal, you could still caveat that because were going to introduce a new "foo" that works on x elements, lets pick on select 18:15:36 gregwhitworth: you could add the search or bruce attribute 18:15:42 gregwhitworth: at that point, you can leverage the labels that are already there 18:15:48 gregwhitworth: and thus you dont actually dont have a compat issue 18:16:06 gregwhitworth: ironically yesterday in focusgroup channel, brought up wanting to do this for file explorer and typing ahead it changes focus 18:16:15 gregwhitworth: theres some overlap but not all at the same time 18:16:27 gregwhitworth: i dont think were going to get consensus until someone puts forward a concrete proposal 18:16:28 +1 18:16:30 what's wrong with bruce? 18:16:34 q? 18:16:36 ack lwarlow 18:16:39 keithamus: i think thats reasonable 18:16:43 ack gregwhitworth 18:16:55 ack jarhar 18:16:59 gregwhitworth: maybe we could set up with a working session or two and jam on an explainer real quick and make sure it doesnt collide with focusgroup 18:17:10 sarah: yeah with menus too 18:17:54 lwarlow: one thing that might be worth trying to do now is getting a use counter for label on options in base appearance mode 18:17:58 0 18:18:20 q+ 18:18:35 +1 18:19:00 dandclark: we talked about this in issue number ??? 18:19:23 sarah: we talked about changing label for stylable select. in theory i think that was discussed, could we repurpose label 18:19:24 s/???/1115 18:19:26 s/???/https://github.com/openui/open-ui/issues/1115 18:19:36 I mean customizable select is still relatively low in adoption right now: https://chromestatus.com/metrics/webfeature/timeline/popularity/342 18:21:07 sarah: i have no personal preference for label. i thought from before that maybe whatwg people would dislike more attributes 18:22:22 jarhar: probably can't change it for auto, but can for base appearance. Be surprised if there was a result otherwise. 18:22:35 jarhar: adding a use counter is effectively free, if it's useful 18:22:41 sbender has joined #openui 18:23:06 q? 18:23:25 proposed resolution: Workshop a concrete design for this, meanwhile investigate adding a use counter for label. 18:23:31 lwarlow: worth looking at optgroups 18:23:39 lwarlow: would be interesting if you could filter by the group name and it filters 18:23:50 lwarlow: optgroups can have a legend that isnt just plain text, so we might want to account for it there too 18:24:04 +1 18:24:10 lwarlow: optgroups also already have a label attribute, although idk what happens when you have both label and legend 18:24:15 +1 18:24:17 +1 18:24:18 RESOLVED: Workshop a concrete design for this, meanwhile investigate adding a use counter for label. 18:24:29 github-bot, take up https://github.com/openui/open-ui/issues/1189 18:24:29 Topic: [menu] How should we group checkboxes and radios, and how should we decide if they are checkboxes or radios? 18:24:29 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1189 18:24:50 dbaron: *introduces issue* 18:25:20 dbaron: this drew objections from whatwg meeting 18:27:34 q+ 18:28:01 q+ 18:29:06 sarah: in favor of fieldset at least being an option, its really helpful to have a nice way to add a visible name sometimes to a group of related items 18:29:13 sarah: especially for checkboxes and radios 18:29:25 sarah: if you can do that with styles, you should be able to do it with semantic grouping 18:29:33 sarah: if we have an option for that it might as well be a happy path 18:29:34 ack me 18:29:42 dbaron: yeah the ability to label is something i should write in 18:29:54 dbaron: im a little confused about how much we want to go into this is a visible label vs just a11y tree 18:30:12 sarah: if you have a grouping that can have a visible label and you just want it to be a11y then you can hide with css or use aria-label 18:30:28 sarah: for that you need a grouping element to define the grouping semantic around those menu items 18:30:43 dbaron: i hadnt previously thought about using the fieldset to group non checkbox or radio items but that sounds reasonable 18:30:47 sarah: we have use cases for that 18:31:14 lwarlow: +1 to sticking with the container element. like you say we can have the discussion about fieldset vs a new element. i think that fieldset makes sense 18:31:35 ack lwarlow 18:31:54 +1 to type being evil 18:32:10 lwarlow: i think if we dont want the containing element, the argument for doing option 3 with type in name is fairly weak. type attributes are a bad design, people dont like input, and the name attr specifically it makes sense for inputs in a form because of form submission, but it has no extra meaning here, so containing element makes sense. if we 18:32:10 dont do a containing element, then i think new tag names for each role is good 18:32:31 lwarlow: focusing on containing element or attributes is probably enough to move the conversation forwards. if we decide to go with the attribute approach, then we can decide on the specifics 18:32:49 dbaron: im trying to push naming stuff out of the stage 2 discussion. 18:33:25 gregwhitworth: +1 the containing element. the thing to watch out for, which doesnt impact stage 3 or 4, i do like the design of elements that match the roles, since i think thats the path html should go 18:33:38 gregwhitworth: the other question is, why are we introducing checkable instead of just doing check? 18:33:45 dbaron: on the fieldset? 18:33:56 gregwhitworth: either. i can follow up offline in the github issue 18:34:19 gregwhitworth: grouping container totally 100% on board. i dont want us to box ourselves in where we want a radiogroup element but then thats fieldset + radio 18:34:28 gregwhitworth: im concerned this may have ripple effects down the road 18:34:44 dbaron: checkable right now is to distinguish fieldsets that make radios vs checkboxes 18:34:56 dbaron: as sarah points out we would have omitting that creates neither, its just menuitems in a labeled group 18:34:58 ack gregwhitworth 18:35:52 lwarlow: in this case new elements for the roles isnt great. largely i agree, but if you create a different element for a radio vs checkbox, then you can mix and match them and then the browser has to decide what its going to do. but if you have a containing element that says which one it is, then the browser can force it to be one or the other, 18:35:52 and you cant do the bad authoring practice 18:35:57 solid argument 18:35:59 lwarlow: if you go with aria roles and js then you can do what you want 18:36:11 lwarlow: its forcing you into the nice path. so i think in that case it makes sense to not do the separate elements 18:36:22 gregwhitworth: my caveat was outside of menu elements 18:36:41 resolved 18:36:44 dbaron: i dont know that i need a resolution, other than maybe i should document the rationales for the grouping elemnet approach 18:36:48 gregwhitworth: we have your back 18:36:57 lwarlow: should we resolve on using fieldset for non checkable? 18:37:00 dbaron: yeah i think that makes sense 18:37:07 dbaron: it indeed isnt in the current proposal 18:37:23 Proposed 1: David to document rationales for fieldset approach in explainer 18:37:30 +1 18:37:39 Proposed 2: Also allow

as a grouping element for non-radio/checkbox menuitems. 18:37:39 +1 18:37:42 +2 18:37:45 +1 18:37:52 +1 (both) 18:37:56 +12 18:37:58 +1 +2 18:38:09 +21 even 18:38:19 Resolveds 18:38:34 RESOLVED: David to document rationales for fieldset approach in explainer 18:38:39 RESOLVED: Also allow

as a grouping element for non-radio/checkbox menuitems. 18:38:53 github-bot, take up https://github.com/openui/open-ui/issues/1220 18:38:53 Topic: [command invokers] scroll command 18:38:53 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1220 18:40:07 flackr: i believe we have an implementation in chrome. i forget who was going to write a spec for it. i think we should be able to move forward with it 18:40:21 keithamus: should we close this one if youre taking it to whatwg? is there a whatwg issue? is it worth us closing this one now? 18:40:26 flackr: i dont recall if there is an issue yet 18:40:34 maybe whatwg and whatnot... .why not 18:40:48 keithamus: im going to close this and say we are tracking it in whatwg 18:41:25 github-bot, take up https://github.com/openui/open-ui/issues/1227 18:41:26 Topic: How should `interestfor` work on a disabled button 18:41:26 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1227 18:42:04 q? 18:42:22 q+ 18:42:24 bkardell: it seems like recent discussion agrees with what we said 18:42:30 bkardell: lukes proposal is reasonable 18:42:38 keithamus: the big problem with disabled buttons is theyre not focusable 18:42:50 keithamus: unless we can force them to be focusable via interestfor, the only reasonable choice is to make it not work 18:43:16 lwarlow: some other discussions with toolbars and menu items, a concept of a soft disabled. it seemed like the conclusion there is disabled is disabled, and if we want soft disabled then we should add a new attr for that 18:43:41 lwarlow: if we have that where its aria-disabled but focusable then it should work. in the case that its disabled, then it just shouldnt work. if you need the explanation, then the button shouldnt be disabled 18:43:48 keithamus: lets make a proposed resolution then 18:43:55 q? 18:44:06 PROPOSED RESOLUTION: `interestfor` should not work for `disabled` buttons 18:44:10 FWIW in https://github.com/openui/open-ui/issues/1274#issuecomment-4433923848 the only platform I found that does soft disabling of menuitems was Windows. (Not a minor platform, though!) 18:44:27 vmpstr: my understanding is that the interest button is not focusable due to the ability for the ua to indicate interest in another way 18:44:42 vmpstr: are we setting up a way for the button to not be focusable and theres also an interest button? 18:44:54 lwarlow: thats what im saying you wouldnt do. you can generate an interest button for a disabled button 18:45:00 vmpstr: so if its disabled then it hides the interest button? 18:45:02 lwarlow: yes 18:45:15 lwarlow: if you have an element without an href, then its not focusable then it doesnt partake in interest stuff 18:45:18 We should do two resolutions here 18:45:22 lwarlow: if it generates an interest button then thats a browser bug 18:45:53 keithamus: so it will change layout if its disabled? 18:46:12 keithamus: its much less common to change the href attribute - there are lots of forms which will toggle disabled based on whether its valid 18:46:13 q+ 18:46:19 ack vmpstr 18:46:26 keithamus: if this now creates a weird flashing of layout, that could be confusing 18:46:43 lwarlow: maybe we gneerate the thing but it doesnt do anything? we could give it disabled styles. imo we should just get rid of the thing 18:46:57 sarah: my expectation is similar to the last person who commented. i would expect it to still render but not do anything 18:47:12 sarah: when ive created the manual equivalent thats what it does, its still generated but doesnt do anything anymore 18:47:16 ack sarah 18:47:20 q+ 18:47:33 sarah: children of disabled controls dont go away, they just stop doing things 18:47:57 bkardell: it does seem valuable in recommending that they be distinct visually, but there are lots of ways you could imagine doing that. you could make it continue to reserve space and gray it out so that its obviously disabled 18:48:08 bkardell: it would make sense to break this into two resolution 18:48:33 PROPOSED RESOLUTION: Interestfor should not work on disabled elements, with some kind of UA styling tbd. 18:48:36 +1 to the first resolution 18:48:44 +1 18:48:50 what I said is also just my gut feeling, I could be convinced otherwise 18:48:55 by people who have thought more about this :D 18:48:56 lwarlow: the styling question depends on the opt in vs opt out question which i dont think is answered 18:49:04 lwarlow: i cant get interest button to show up currently so i cant test it 18:49:10 lwarlow: i would imagine that currently it hides the interest button 18:49:30 keithamus: are we going back to the first proposed resolution that it shouldnt work on disabled elements or should we think more about the ua styling 18:49:54 lwarlow: maybe proposed resolution that it doesnt work on disabled elements and then action to figure out what that means 18:49:57 +1 for assigning things to mason :) 18:50:02 PROPOSED RESOLUTION: Interestfor should not work on disabled elements. Further exploration on what we do about the ::interest-button pseudo; UA styles or do not generate. 18:50:17 +1 18:50:20 +1 18:50:21 +1 18:50:24 +1 18:50:33 RESOLVED: Interestfor should not work on disabled elements. Further exploration on what we do about the ::interest-button pseudo; UA styles or do not generate. 18:51:42 github-bot, take up https://github.com/openui/open-ui/issues/1465 18:51:42 Topic: Keyboard behaviour of custom select options 18:51:42 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1465 18:52:50 q+ 18:52:52 jarhar: there are two issues here; 1. should chrome implement the safari behavior, where right = down and left = up. 2nd issue is how do you make this work nicely in grid. 18:53:05 jarhar: should have double checked safari's right=down/left=up 18:53:12 jarhar: maybe we can resolve on that? 18:53:13 My inclination is that maybe you want the default behavior of the different arrows to depend on direction and writing-mode 18:53:38 jarhar: appearance:auto right and left don't do anything... though maybe in vertical writing mode? 18:54:03 q? 18:54:08 ack bkardell 18:54:50 lwarlow: safari behavior is right same as down and left is up; essentially focusgroup where axes is both 18:55:07 lwarlow: on topic of focusgroup, ??? listbox constrained. This is a listbox. 18:55:17 lwarlow: ultimately i think keyboard stuff is impl defined, so fine either way 18:55:17 q+ 18:55:42 lwarlow: we need to solve problem of what you do when styles change layout; need to solve for focusgroup and select. A larger thing to do rather than take an action on select specifically. 18:56:02 lwarlow: from my perspective: chromium doesn't need to change immediately, more research on 2d focusgroup and grid focusgroup 18:56:17 lwarlow: maybe a way to apply that to select. Maybe solution is to add focusgroup to select. 18:56:18 I'll be spending time on 2D focusgroup immenently. 18:56:31 gregwhitworth: agree with your proposal, completely disagree on listbox being vertical 18:56:50 gregwhitworth: I like the examples posted - like a game, but select, but horitonzal, left/right makes complete sense to do 18:57:04 gregwhitworth: simple, all directions make sense. 18:57:17 gregwhitworth: figuring it out holistically, with a bunch of demos 18:58:13 dbaron: one other thought: intuition for i18n is possibly that- ignoring potentially dealing with 2d better- it makes sense to have defaults for which arrows do what be a function of writing mode, e.g horitontal rtl vs vertical rl 18:58:42 lwarlow: something we want to check with i18n people. Discussed for focusgroup, visual doesn't mean it impacts directionality of keys 18:58:51 dbaron: seems most weird for vertical rl 18:59:11 dbaron: select by default starts at right with each option to left, seems weird for left and right to do the opposite of that. 18:59:34 jarhar: left goes forwards and right goes backwards - so different between writing modes, want to post on the issue to highlight exact browser differences 18:59:40 ack dbaron 18:59:44 ack gregwhitworth 19:00:38 resolved: there will be no resolution 19:00:41 good job everybody 19:00:43 🍻 19:01:37 Zakim: end meeting 19:01:44 Zakim, end meting 19:01:44 I don't understand 'end meting', keithamus 19:01:51 Zakim, please leave 19:01:51 leaving. As of this point the attendees have been dbaron, gregwhitworth, sarah, flackr, vmpstr, bkardell, lwarlow 19:01:51 Zakim has left #openui 19:01:56 RRSAgent, make minutes 19:01:58 I have made the request to generate https://www.w3.org/2026/07/09-openui-minutes.html keithamus 19:02:26 github-bot, take up foo 19:02:26 keithamus, I can't comment on that because it doesn't look like a github issue to me. 19:02:51 dbaron: do you happen to recall how I can get github-bot to post on the last issue? 19:03:01 I forget the invocation required 19:03:33 github-bot, end topic 19:03:46 found it! 19:09:57 I think "Zakim, end meeting" would also have worked if you'd spelled "meeting" correctly