17:55:39 RRSAgent has joined #openui 17:55:43 logging to https://www.w3.org/2025/09/04-openui-irc 17:55:43 Zakim, start meeting 17:55:43 RRSAgent, make logs Public 17:55:44 please title this meeting ("meeting: ..."), masonf 17:55:47 meeting: Open UI 17:59:40 lwarlow has joined #openui 17:59:43 present+ 18:00:08 present+ 18:00:26 present+ 18:02:23 flackr has joined #openui 18:02:29 present+ 18:03:49 grk has joined #openui 18:04:27 github-bot, take up https://github.com/openui/open-ui/issues/1220 18:04:27 Topic: [command invokers] scroll command 18:04:27 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1220. 18:04:34 jarhar has joined #openui 18:04:34 scribe+ 18:04:48 masonf: first issue is command invokers scroll command. flackr to present? 18:05:11 lwarlow: I added this to the agenda, but some time has passes so I wanted to keep the ball rolling on it 18:05:19 masonf: can one of you remind us of the proposal 18:06:02 masonf: there was talk of a functional microsyntax but that's not the direction? 18:06:06 flackr: right 18:06:23 q+ 18:06:27 flackr: we should bikeshed the names of the values but they are the 4 physical & 4 logical directions. 18:06:33 scott has joined #openui 18:06:43 Leo4 has joined #openui 18:06:43 bkardell: I wanted to clarify, it's paging right? One whole scroll port 18:06:44 q+ 18:06:46 flackr: yes 18:06:54 bkardell: maybe page is better 18:07:02 flackr: we can start with page. 18:07:06 masonf: Like page down? 18:07:17 flackr: yes those make sense. page-block-end maybe less so. 18:07:22 exit, stage left, chased by a bear 18:07:24 masonf: it's descriptive. 18:07:31 ack bkardell 18:07:33 ack lwarlow 18:08:06 lwarlow: this works with scroll-snap and scroll containers. I assume - how do things like page up page down buttons work with scroll snap? The container? 18:08:21 Jacques has joined #openui 18:08:25 flackr: It's complicated. Well defined, this would mimic that. You scroll by about a page and find a snap point near that destination 18:08:46 flackr: the reason you dont want to go to the next snap item is you might have a set of small snap items, and so moving a page might trap you in those snap items 18:08:58 masonf: the behaviour of the page up and page down keys is expressed in the spec? 18:09:12 flackr: it's hand wavey but we have tests and such. This would hook into the same mechanism. 18:09:33 masonf: Are there other questions? Naming aside. Other questions to be answered? 18:09:42 lwarlow: I guess - is it ready to just propose to whatwg? 18:09:53 lwarlow: bikeshedding doesn't need to happen here. 18:10:09 flackr: i guess so. The target needs to be the scroll container, there's no magic "find the nearest scroll container". 18:10:26 lwarlow: there is an issue in whatwg to handle that, it could piggy back that if there was anything we could come up with 18:10:34 masonf: auto targeting based on ancestor chain? 18:10:56 lwarlow: yeah. It's up for discussion what shape it would take. But for something like this it would probably be the nearest scroll ancestor. 18:11:03 masonf: that's separate and more general anyway 18:11:18 masonf: one plan is to take it to whatwg but another is to prototype this, right? 18:11:30 q? 18:11:32 flackr: yeah probably not too hard to prototype, I assume adding commands isn't difficult 18:12:26 keithamus: the spec has a handle invoke step, which is awkward, but implementations are easy 18:12:29 lwarlow: not too difficult 18:12:40 flackr: maybe that's the plan, write a rough explainer, prototype, bring to wg. 18:12:58 masonf: sounds like it has 2 champions, lwarlow and flackr? Presumably one of you will do this? 18:13:21 lwarlow: I am fine to work on the html spec parts. Implementation wise I can help with the command stuff, but not the scrolling bits 18:13:44 flackr: I know about those bits so I can handle those. I'll reach out 18:14:08 PROPOSED RESOLUTION: page as common command name, 4 physical and logical directions, no functional microsyntax. 18:14:18 +1 18:14:19 +1 18:14:26 RESOLVED: page as common command name, 4 physical and logical directions, no functional microsyntax. 18:14:40 github-bot, take up https://github.com/openui/open-ui/issues/1265 18:14:40 Topic: Open a11y questions for overflow/carousels 18:14:40 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1265. 18:15:04 masonf: a11y questions for overflow/carousels... scott? sarah? 18:15:31 github-bot, take up https://github.com/openui/open-ui/issues/1260 18:15:31 Topic: Scoped focusgroup explainer 18:15:31 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1260. 18:15:55 Jacques: *introductions* 18:17:10 Jacques: *pitches explainer8 18:17:12 q+ 18:17:22 masonf: you can't key off of.... so the.... 18:17:48 Jacques: when you make the focus group you specify an aria-role, from there we can infer the value. So it's scoped for specific scenarios. 18:18:27 Jacques: so you cant make a div with no role... the old focus group explainer made it required, this one flips the script and says it supplies it. 18:18:34 q+ 18:18:48 Jacques: the latest comment about aria making semantic changes is a conversation I want to have. But this is what I'm working with 18:18:49 ack lwarlow 18:19:17 lwarlow: specified role within focusgroup and role within role attribute, which one wins? 18:19:26 Jacques: aria-role. Authors can do whatever they want in the end 18:19:34 lwarlow: if you have an html element?... 18:19:41 nmn has joined #openui 18:19:58 Jacques: in that case, it would take the... I don't think I specified this but it would take the one supplied by focus group. I could be convinced otherwise. 18:20:07 q+ 18:20:08 Jacques: I think I would say the focusgroup supplied aria role would win 18:20:19 lwarlow: it has to in some circumstances, if you put it on a div for e.g. 18:20:40 ack scott 18:20:43 Jacques: I am trying to think of scenarios where you'd want the opposite but I think you'd want focusgroup overriding the implicit role. 18:20:48 scott: 2 things: 18:21:43 scott: 1. one way to move forward with this is to call out that - reading the explainer - I think it could be better explained that while the values given to the focusgroup attribute defines the behaviour, that align with the specific roles, it's not using ARIA. ARIA would be if you provided the ARIA role on it. 18:22:05 scott: the direction you've gone now solves the problem, but you're not using aria roles, they just happen to align. 18:22:07 q+ 18:22:24 scott: so the argument of "you're using aria the wrong way" is wrong if you pay attention to what happened. 18:23:09 scott: 2. The way this is trying to force or overwrite implicit ARIA roles for HTML elements. Say someone used it on a div that contained all the options of the customised select, and you put grid as the focusgroup behavior. 18:23:35 scott: what una was looking to do with how to navigate a visual grid of options... so what does that do? Change all the children to grid cell roles? That wouldn't be appropriate 18:23:46 scott: we still have the potential to really break things if we don't scope it down 18:24:14 Jacques: I still think this should be scoped to a subset of aria roles. Not any aria role could be used as the behavior, but a subset. Or am I misunderstanding? 18:25:10 scott: if I understood the explainer, it was saying if you put radiogroup for the focusgroup attribute, divs inside of it would get the role=radio implicit role. If someone were to have a div focusgroup=grid and had options inside of it, they're trying to get bidirectional arrow key behaviour but may inadvertently undo the actual role that's 18:25:10 necessary for those options. 18:25:19 scott: but that's not what this thing is at all 18:25:45 q+ 18:25:47 Jacques: I see what you're getting at, the child override is a little messy. Some span from not useful to harmful, as you pointed out 18:26:07 Jacques: at risk of making this more complex I think we'll need to supply more for this. 18:26:26 q- 18:26:52 scott: that's not a bad idea to pursue. The other thing is that we stipulate it doesn't override any roles, except generic. It becomes more behavioural. Potential mappings provided so for a focusgroup of options are bidirectional. more about behavior less about roles. 18:27:14 q+ 18:27:24 scott: but a focusgroup on a series of divs... like a mapping on html-aam, if it's just divs we can say this might be a grid lets give them grid roles, otherwise we might not know what they've create.d 18:27:39 Jacques: I need to think on this more but overriding only generic is a great first step 18:27:49 scott: thanks, I think you're pushing it in the right direction 18:28:29 masonf: I had the same comment about re-using role values exactly. There's a value describing the bheaviour you want, and it just happens to align to role 18:28:32 Jacques: exactly 18:28:59 masonf: you might want to sidestep the argument by creating a list of words that then map to roles, if they're different words that's fine. 18:29:29 masonf: changing of native roles that come from elements, there is push back about attributes changing semantics. That's kind of whats happening here so I think there will be pushback 18:30:09 masonf: but there is a concept of a minimum role. e.g. popover. If the element has a strong role, e.g. option in select, you dont change it. If the element is a div it can have a minimum role of - whatever- so you're not overriding defaults that come from elements 18:30:18 ack mason 18:30:20 ack nmn 18:31:36 q+ 18:31:40 nmn: I would say there should be no a11y overrides even in the generic case. Thinking hard I wonder if the entire value can be simplified to what it does for focus and nothing else. 2 things I can think of is either focus trapping, or unify multiple focusable elements as a single tabstop, arrow keys switching between them. Unify or contain, wrap or 18:31:40 no wrap, horizontal and vertical, as the three axes of this. 18:32:06 Jacques: that was the original explainer. The problem is we now need to expose this to a screen reader which is not going to understand how to communicate how to navigate through this. 18:32:22 Jacques: doing all this and asking screen readers to adapt to it means it has no future 18:32:50 Jacques: whereas mapping these to roles, we can tell the screen reader for example that this maps to a radiogroup. No new platform APIs, no causing trouble. 18:33:18 nmn: another possibility - can we have a value that says mirror what the role is? So you don't repeat focusgroup=grid but role=grid focusgroup=? 18:33:22 q- 18:33:40 Jacques: original proposal was that focusgroup requires a specified role, but this then became aria defining behaviour which people don't want. 18:33:51 nmn: I'd argue its focusgroup defining the behaviour 18:34:19 Jacques: we really want to make sure that focusgroup requires a behaviour, and if it's defined by aria role then that's determining if focusgroup can be used 18:34:23 nmn: whats the invalid value? 18:34:29 Jacques: focus group would not function 18:34:31 ack lwarlow 18:34:36 +1 for things breaking and making devs have to pay attention to their mistakes :) 18:34:40 lwarlow: few comments. 18:35:20 lwarlow: combining grid and wrap in the same attribute might make things more confusing. i.e. reflection, if you had a predefined list of valid values it might be nice to have that as a reflected enum. So maybe wrap is a separate attribute. 18:35:53 lwarlow: I'd like to understand the value proposition this provides, rather than implementing the elements in html. Toolbar, for example, doesn't provide that much in the ARIA space, it's a role, essentially. 18:36:05 ...and we're working on ``: https://open-ui.org/components/menu.explainer/ 18:36:11 q+ 18:36:15 lwarlow: I'm curious if we have focusgroup=toolbar what is different to specifying as an element 18:36:38 lwarlow: custom elements come up a lot but we can give them some additional behaviour to opt in to this 18:36:57 lwarlow: if you have a composite widget, like select, if we didnt have focusgroup and we had these other mechanisms, perhaps thats better? 18:37:47 q+ 18:37:47 Jacques: what you mentioned, the custom element scenario and the flexibility. Adding or a new element to the html spec is going to be a process. It's going to take time. focusgroup is something we could get to having this. That enum of behaviours is more flexible than adding a new html element. 18:38:23 Jacques: with that, I think ideally no one would use divs it would be native elements but reality is folks do interesting things. Adding the attribute means they dont have to write their own focus management and it scopes them into something standardised. 18:38:37 Jacques: keyboard user will do the same thing and screen readers get the right information 18:38:46 q+ 18:38:56 Jacques: in the ideal world everyone would use native elements and the ideal element would already exist but we're not there yet 18:38:59 ack bkardell 18:39:41 bkardell: I have a split between these two. I see the value in something potentially like this but I see greater value to get people to not use this at all - so if we had native or native elements this could replace, the markup gets a lot simpler. 18:39:48 bkardell: the ability to use it becomes incredibly simple 18:40:03 bkardell: and the ability to use it wrong becomes harder. Almost no markup means hard to mess up 18:40:39 bkardell: so I'd like to see - I assume the idea you have is internally if we made new native elements with these concerns they'd use these mechanisms themselves - so maybe a native element to go through at the same time? 18:40:55 bkardell: I dont know if its a true statement to say one can be done faster than the other? 18:41:06 bkardell: we've done stuff since the original proposal 18:41:08 ack lwarlow 18:41:44 lwarlow: in terms of use cases, I've written code before that has the comment "we can remove all of this when focusgroup ships". But the scoped nature... we have customisable select, that's select done. 18:41:53 lwarlow: menu element is in some form of progress 18:42:09 lwarlow: toolbar element feels quite simple to propose and add. It seems to be this essentially. 18:42:24 lwarlow: then leftover you've got combobox, in the input datalist sense? And tabs. 18:42:39 lwarlow: tabs is a big thing, if we wanted a native element... 18:42:43 nah, tabs is trivial, just ship it 18:42:43 +1 18:42:44 :-) 18:43:00 lwarlow: but they also have more than just focusgroup, you cant slap focusgroup on it and call it tabs, you still have to go write the rest. 18:43:17 +1 was meant in reply to "you can't just slap this on tabs" 18:43:22 lwarlow: then theres grid. Maybe the most interesting part. Can't necessarily inherantly replace with an element, number of different forms it can take 18:43:28 nmn has joined #openui 18:43:38 lwarlow: specifically a future thing, interesting to solve. 18:43:47 q+ 18:44:07 lwarlow: if we get behaviour for toolbar though, it would e nice to get the element. If we propose toolbar and we've got select then we can specify the keyboard navigation, then you get half of focusgoup for free. 18:44:16 q- 18:44:25 sorvell has joined #openui 18:44:35 q+ 18:44:45 q+ 18:44:45 q+ 18:44:55 Jacques: I agree authors should prefer native. But there will be cases where they want to use a div with aria role, and focusgroup will at least give them consistent behaviour and give them a correct mapping. We live in a world where button exists, but so does role=button 18:45:16 Jacques: I agree native elements where it makes sense but developers are also potentially not going to use them. This is a stop gap to encourage consistency. 18:45:30 masonf: lukes list was a long one! 18:45:33 ack scott 18:46:08 q- 18:46:09 scott: I am in the middle of this. If we could ship the elements, great, but it does help for people who want to reinvent things like button, custom elements, etc. 18:46:59 scott: there are components that don't have good representation in html or aria, even new things we haven't figured out yet. I think this is similar to popover, where we - in an ideal world wouldnt need popover - but it definitely helped, e.g. customisable select, dialog, you might need a popover dialog, that's a new concept we wouldn't have had 18:46:59 before 18:47:42 scott: is there a benefit to using focusgroup to make a toolbar when you can use a toolbar element? Probably not but absolutely interfaces out there where people have done this and those places can slowly refactor which might be easier than completely rewriting html 18:47:57 scott: so I think theres 2 pathways forward here. 18:48:46 scott: really the only thing toolbar does at this point is that certain screen readers will go into forms mode which allows them to use them without the screen reader overriding them. Hopefully in the future we will have enumeration of how many items are in the toolbar soon - so that'll be another difference. 18:48:53 ack bkardell 18:49:48 bkardell: while I would like to see us do both at the same time - one thing that might come out of that is there is a different way to handle this, like an element mixin or something. Maybe people will have less objection than attributes? e.g. elementinternals.type = 'toolbar' 18:49:55 ack sorvell 18:49:56 masonf: another one to add to the list of as-yet shipped things 18:50:25 sorvell: going to push back on criticisms of it being powerful and not tied to aria. I think this is good to add to the platform. 18:50:43 sorvell: concern around ARIA being semantic only apply regardless of aria attribute or not. 18:50:59 sorvell: if you're going to use names that are close to aria you're still using it non semantically 18:51:34 sorvell: the thing we have to face is that the criticism levied was people could do bad things with this behavior. People _are_ doing bad things now, keyboard navigation grouping is widely used. 18:51:35 q+ 18:52:08 sorvell: making this canonical in the platform only makes it better. Today you can mess it up in 27 million different ways, if we can fix a couple million on those that's much better 18:52:38 ack scott 18:52:40 sorvell: the point on elementinternals, i think that's not appropriate, there are tons of frameworks - not just customelements. So I think those all do this and need the same functionality. 18:52:45 vehemently agree with sorvell! 18:52:57 scott: you said you came in late but maybe review minutes, we discussed the aria pushback 18:53:22 scott: generally, the intent with what was updated was to untie with aria and have it as behaviours that just happen to map to aria roles 18:53:42 scott: there probably needs similarity because people need to know what they're trying to create 18:54:16 q+ 18:54:16 scott: the problem with the stuff now without implicit aria semantics is it doesnt make sense with AT. The experience is broken now 18:54:35 masonf: this is a PR right now to add an explainer. Are we okay with just landing this? 18:54:43 q- 18:54:46 Jacques: that would be great, once landed I'll still be making updates. 18:55:07 masonf: since it lands in parallel to the other explainer it might be good to add a link from the old to the new one 18:55:11 Jacques: sounds good to me 18:55:28 masonf: any objections to land the explainer? 18:55:32 +1 to landing the explainers. it can continue to evolve 18:55:46 bkardell: if you land this, it wont replace the other one? 18:56:01 masonf: the current PR is a new document. So the website will have 2 explainers next to each other. 18:56:21 masonf: how much of the new explainer is new new? 18:56:40 Jacques: it started from a copy paste, but through a filter. Some sections might be word for word, but a good amount are new. 18:56:45 q+ 18:57:26 masonf: my only comment, I'd want to have both pointing to the other, and context on both. The reason I think it's valuable to keep both is to help decipher the scoped vs broader thing 18:57:50 keithamus: I'd like to replace the old one with the new one, or push the old one further away. Maybe to "legacy/unmaintained"? 18:58:03 keithamus: it is that way now, so maybe ok. 18:58:30 keithamus: I'd lobby to remove the old one. We have git history. 18:58:34 ack keithamus 18:58:59 masonf: counterpoint is that it says we have decided to go with this scoped approach. Have we concluded that? 18:59:23 nmn: in non-active it's fine, if anyone wants to update it we can have another discussion 18:59:29 masonf: a PR to delete it later is easy 18:59:58 Zakim, please leave 18:59:58 leaving. As of this point the attendees have been lwarlow, bkardell, masonf, flackr 18:59:58 Zakim has left #openui 19:00:12 > Zakim, please leave. <-- does that work? 19:00:17 I guess so 19:00:28 Whats the RRS one...? 19:00:37 RRS? 19:00:58 RRSAgent, please draft minutes 19:01:00 I have made the request to generate https://www.w3.org/2025/09/04-openui-minutes.html keithamus 19:01:07 ahh