17:54:28 RRSAgent has joined #openui 17:54:32 logging to https://www.w3.org/2025/03/20-openui-irc 17:54:32 Zakim, start meeting 17:54:33 RRSAgent, make logs Public 17:54:34 please title this meeting ("meeting: ..."), masonf 17:54:36 meeting: Open UI 17:54:55 github-bot, take up https://github.com/openui/open-ui/issues/1142 17:54:55 Topic: [meta] Should we have an OpenUI account on new socials? 17:54:55 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1142. 17:59:43 frehner has joined #openui 18:01:49 jarhar has joined #openui 18:02:33 flackr has joined #openui 18:02:39 present+ 18:02:40 Di has joined #openui 18:02:42 present+ 18:02:54 lwarlow has joined #openui 18:03:02 Penny has joined #openui 18:03:11 scribenick: jarhar 18:05:05 Proposed Resolution: Setup BlueSky and/or Mastodon account for OpenUI 18:05:08 +1 18:05:13 +1 18:05:21 +1 18:05:22 RESOLVED: Setup BlueSky and/or Mastodon account for OpenUI 18:05:47 github-bot, take up https://github.com/openui/open-ui/issues/1179 18:05:47 Topic: [menu] Menu elements proposal 18:05:47 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1179. 18:06:37 scott has joined #openui 18:06:43 present+ 18:06:55 dom: di and i are working on the menu elements proposal 18:07:06 dom: some of yall have already looked at the google doc 18:07:15 sorvell has joined #openui 18:07:46 dom: *shows presentation* 18:08:58 https://docs.google.com/presentation/d/1vPTQm6mV5DcgNHCWm1NStA0n2DYuaWNPW2kaDAlAqZk/edit#slide=id.p 18:12:29 q+ 18:14:34 q+ 18:16:05 ack lwarlow 18:16:14 Proposed resolution: OpenUI will incubate the "menu" concept, and we can land an explainer. 18:16:18 lwarlow: is there anyone who objects to us incubating a menu idea? we can probably resolve thats a good idea 18:16:26 q+ 18:16:32 lwarlow: its been discussed before, popover is a primitive and that we want to use these patterns on top of that 18:16:40 lwarlow: this is a great examlpe of one we should tackle 18:16:44 lwarlow: i think we should just say yes 18:17:00 domfarolino has joined #openui 18:17:12 q+ 18:17:13 lwarlow: the details of it: i think one thing is the in-page bit, some in the doc, it was unclear to me what the disction between that an the toolbar would be 18:17:25 lwarlow: when doing the explainer it would be good to say this is this pattern, it needs to be separate for this reason 18:17:34 dom: youre saying to distinguish which two cases? 18:17:42 lwarlow: the google docs screenshot it has bits at the top 18:17:50 lwarlow: is the in page bit is that the format tools etc. bit? 18:17:53 dom: yes 18:18:05 lwarlow: the bit to the right hand side of the thing, the toolbar is a slightly different pattern 18:18:14 lwarlow: the bold italic, underline stuff, thats a different pattern 18:18:20 lwarlow: might be good to explain why thats a different pattern 18:18:34 dom: there is a separate aria page for that editor toolbar as well, we should do a better job of distinguishing those 18:18:50 scott: yeah this was one of the comments i brought up. the top bar is a menu bar, and below that is a toolbar, and they are distinct 18:19:07 scott: ? bar is a list of menu items that invoke other sub menus. this pattern is taken from the platform, windows apple they both have this 18:19:15 scott: toolbar at the bottom can be buttons, form controls, even links 18:19:44 scott: toolbar pattern is important because ? dont allow for quick navigation. toolbars do allow this. if someone wants to jump to a thing they can do that. if theyre all menu items then they cant jump 18:19:55 scott: a toolbar may contain a button to invoke a submenu, but a toolbar is not a menubar 18:20:31 lwarlow: the two other bits: one about the grouping of the menuitemcheckbox and menuitem radio, i quite like scotts idea of doing that based on the container element. i think that solves many of the problems, otherwise you can mix and match and the browser has to decide what to do 18:20:45 lwarlow: if you get one marked up as a radio or vice versa, if we do it based on the parent it eliminates that problem 18:21:09 dom: the only point i have there is that we dont do wthat with forms. fieldset doens't determine if anything es exclusive or not, it just draws a line, and then the input type determines that 18:21:25 dom: i would have the same question, what if you mix and match things in a form, well the form just works based on other semantics 18:21:42 dom: the fieldset is a generic container for form controls but it doesn't have exclusivity, and we would be changing that 18:21:50 masonf: is the suggestion to create a new grouping element? 18:22:01 dom: we could do that. whats currently proposed in the doc is just fieldset, checkable=multiple or something 18:22:16 dom: im just noting i think that would give a real behavior difference in menu elements for normal forms, might want to do another element 18:22:27 dom: maybe the way forms are now is weird 18:22:35 lwarlow: one of the difference is navigation 18:22:50 lwarlow: in a form you use tab, whereas here you use arrow keys as your navigation, and having them mix and match there makes it more confusing 18:23:17 lwarlow: the other thing is that if we were designing form controls now, we probably would do it so that you have a radio group element and radio buttons inside, and likewise would have a checkbox group, to handle the indeterminate state for checkbox group 18:23:28 dom: i like the idea of the parent grouping, i would prefer to not do fieldset 18:23:40 dom: i do like the proposal, its clean and looks nice 18:23:57 ack sorvell 18:24:06 sorvell: do you want the discussion on the issue or the google doc? 18:24:19 masonf: use github issues 18:24:33 sorvell: use cases are critically imporant to nail down 18:24:39 sorvell: i think scott could be better for this 18:24:51 sorvell: navigation is a deep can of worms, people have strong opinions about navigations and menus 18:25:08 sorvell: i cant represent it very well. theres two points i want to make: we should respect it but shouldn't shy away from use cases involved 18:25:24 sorvell: from my perspective, if its not good, we shouldn't do it, but if it is good and its hard, then we should do it 18:26:07 sorvell: around a menu, theres a number of behaviors that are intended to be regularized, like application menus on OSes always look and behave the same way. this is the intent with whats on the screen here, and that has implications for the amount of customization 18:26:27 sorvell: navigation example is something that seems similar, whether you would actually want the arrow keys to navigate around these 18:26:32 sorvell: you could have a bunch of text in there too 18:26:36 sorvell: is this the same thing? i dont know 18:26:41 sorvell: this thing is entirely a navigation menu bar 18:27:04 sorvell: in google docs, in the help menu, most of the things are specific actions which are very menuey, but there are links in the help thing that navigates to a different page 18:27:10 sorvell: theres a lot of nuance around the specific issues here 18:27:30 sorvell: from the developer perspective, theres a number of annoying difficult to get right features that i want this thing nto do for me that are otherwise annoying 18:27:37 q+ 18:27:41 sorvell: maybe we can think of that as a list and provide those as separate primitives 18:27:53 sorvell: things like submenu positioning, dismissal, opening, anything related to how a submenu would display 18:28:17 sorvell: theres crazy things people do where theres a magical triangle where parent menu doesn't close submenu which mimics os behavior, theres keyboard activation behavor and hotkeys that match the platform 18:28:26 sorvell: theres arrow navigation, we dont have a good primitive for that 18:28:31 sorvell: the more that a browser can do for me the happier i am 18:28:39 sorvell: and this is independent from a11y or use case related issues 18:28:43 q? 18:28:46 ack mason 18:29:14 masonf: there are some concepts that we have shipped. triggering is one of them, popover itself, we should make sure we're reusing those concepts 18:29:19 masonf: openable is another one of those that might work 18:29:32 q+ 18:29:33 masonf: the other thing that i heard is that the explainer needs to talk in detail about all of the cases 18:29:38 masonf: navigation menu, context menu, etc. 18:29:48 masonf: even if the proposal doesn't tackle those things, saying which things are or aren't handled 18:29:52 masonf: we should think about all of those use cases 18:30:06 masonf: i would hope that a menu item does work in a navigation menu and a regular menu even if the parent element is only for one of those 18:30:15 masonf: hopefully those pieces can be used in either case 18:30:36 masonf: another helpful section for the explainer, there are code snippets, but full examples would be good. a fully built code sample. where does the word "file" go? 18:30:39 scott has joined #openui 18:30:42 masonf: where are the menu item contents etc 18:30:45 q? 18:30:48 ack scott 18:31:01 scott: im going to talk about navigation use case 18:31:10 scott: that is one thats on the apg and is the most contentious 18:31:53 scott: one of the reasons that navigation use case is not preferred is that menuitems are not navigable using screenreaders. theyre meant to be treated like navigation to menus in macos windows etc 18:32:04 scott: theyre meant to be used in forms mode. arrow key navigtaion. maybe some typeahead 18:32:29 scott: as far how theyre used on the web and used for navigation purporses, they can make finding what youre looking for harder for screenreader users because you cant just bring up a list of hyperlink 18:32:47 scott: what were looking at on screen here is probably a very good example of a mega menu, and you might hear the word menu there 18:32:58 scott: everythings either a menu tooltip or dialog because those are the only words we have 18:33:16 scott: if the navigation menubar is to go forward, we would need to do work thats never been done before to make this a thing that is not just another way of saying menu 18:33:40 scott: one of my comments in the google doc is that in order to have type=nav, that would mean that there is going to be something that is different than a regulra menu, but according to the platform there is no difference 18:33:52 scott: in the apg its just a bar of menuitems, theres no functional difference other than its used for navigation purposes 18:34:14 scott: there are some use cases, app driven - google docs for instance, the whole top bar you could have submenus that do commands or bring you to anotehr page 18:34:21 scott: maybe theres an indication there that it opens a new page 18:34:45 scott: if a nav version is going to be seriously proposed, then it should support the href attribute on it. there would need to be specific directionsn about what can or cannot go into such menus 18:34:58 scott: in these mega menus, people put in headings or descriptions about the content, those dont belong in menus 18:35:11 scott: in customziable select, anything can go in there so we have the dialog fallback 18:35:23 q+ 18:35:24 scott: i dont want us to start off with were just going to make this messy by default 18:35:36 scott: i am not opposed to it moving forward, but theres a lot of work moving forward 18:35:50 scott: if its just going to be menu but it has type=nav but no actual difference then we havent helped anyone 18:36:25 masonf: it sounds like theres more work to be done on the a11y side to do this correctly. if we carve this out as something we aren't going to do, do we know enough about that work that we could design the rest of the api or is it too nebulous? 18:36:36 scott: theres a lot of other people who have a lot of thoughts on this 18:36:43 scott: probably even more critical or supportive than me 18:36:57 scott: im just trying to relay this and warn that there is a landmine here, if you want to step on it you bettter have some solid shoes 18:37:02 q? 18:37:02 masonf: we should file an issue about this 18:37:19 dom: thanks, i understand why its a big deviation 18:37:24 ack lwarlow 18:37:53 lwarlow: regarding contextmenu, to provide some context on that, i find that people make custom context menus because they want to change the styling, and then you just lose all the benefits of the browser provided one 18:38:08 lwarlow: the browser provides a lot of useful stuff in there, and i usually want access to it. i want to right click and inspect element 18:38:18 lwarlow: google docs doesn't let me do that, but its all canvas based anyway 18:38:31 lwarlow: im not completely against the idea of you should be able to build a context menu 18:38:47 lwarlow: we should be able to build it using the system just because there should be some js method to open a menu, and you can do that via contextmenu and popover works there and thats fine 18:39:10 lwarlow: it would be interesting to look at what the actual use cases are. why do people build context menus? if its just styling, then maybe you should be able to style the context menu 18:39:31 lwarlow: the other thing is, at least when ive looked at this in the past, ive wanted one or two custom commands, and it would be nice to be able to add those to the native context menu 18:39:34 q? 18:39:37 qq+ 18:39:39 lwarlow: web extensions can already do that, my password manager can do that 18:39:47 lwarlow: i dont see why we cant let websites do that 18:40:05 lwarlow: if we can do it in such a way where the full custom menu is an escape hatch and not your only option then i would feel more ok with it 18:40:28 masonf: i think you should - contextmenu is only different from a menu because you invoke it with a different gesture and the other aspect is that the browser provides useful stuff in there 18:40:46 masonf: explainer should have something in there, but should not try to tackle that. those are good things to tackle but not in this context 18:40:56 dom: are we even in control of that? since you can just make your own now 18:40:59 masonf: yeah, keep it separate 18:41:10 ack mason 18:41:10 masonf, you wanted to react to lwarlow 18:41:23 lwarlow: im not saying this should magically not work there. i think theres a separate discussion about how to make contextmenu a non cancelable event, like firefox lets you do it with shift right click 18:41:31 lwarlow: if devleopers want to that they already can 18:41:36 dom: we shouldn't design with that use case in mind? 18:41:38 lwarlow: yes 18:41:41 masonf: youll get it for free 18:41:42 ack keith 18:41:57 keithamus: firefox used to ahve this feature where you could add stuff to context menus 18:42:09 q+ 18:42:12 keithamus: steve had a comment about the safety triangles, and the idea that we should expose more of these 18:42:28 keithamus: i believe we talked about safety triangles in interesttarget, if it exists in two places maybe worth investigating 18:43:06 keithamus: im a linux enjoyer, and one of the features of menu systems on these OSes is you can hold down the mouse button to traverse the menu, and when you release it select its. click and drag. i find it very useful, i would like to see that explored as a pattern here as well. 18:43:23 I think macOS has that too right? And we added that for custom select 18:43:25 keithamus: i dont think its reasonable to put it as a primitive, but i and other users would be pleased to see this. it never works on the web 18:43:30 ack sorvell 18:43:54 sorvell: first i think that - i feel pretty strongly that we should decide the use cases 18:44:04 sorvell: we need to really explore this space before we decide what we do 18:44:12 sorvell: scoping it to a number of phases 18:44:42 sorvell: slight pushback to what scott said. maybe we are forging a new path here, and if thats important and useful then maybe we should carefully. theres a tension where theres a set of behavior where everyone agrees is canonical, but its annoying to implement. basic menuing 18:45:06 sorvell: its mostly canonical, theres something you only get on linux, but most of this stuff is the same across platform. google docs is doing that. making that easier is something i desparately want 18:45:18 sorvell: part of this is around forging expressiveness on the web 18:45:44 sorvell: it is very hard to actually make a butterknife, but i also want a steak knife. if you only give me a butterknife, but i need a steak knife, then i might throw away the butterknife 18:45:57 sorvell: we should make it expressive enough for other use cases 18:46:11 sorvell: if all the rage is radio menus and we cant do radio menus, and people dont use it then that would be unfortunate 18:46:33 sorvell: theres no right answer, and we need to respect the dificulty, but we should allow expressiveness to allow new things and push boundaries 18:46:42 i'm not sure where the pushback is? 18:46:53 sorvell: if we can bake in at least the keyboard works the right way then we have a huge win 18:47:11 ack lwarlow 18:47:36 lwarlow: it would be really good to have a demonstration of what does menuitemcheckbox do? whats an example of where thats used? maybe its the view options in chrome? 18:47:42 lwarlow: unclear to me what the radio equivalent would be? 18:48:08 dom: the code examples of one of the aria pages has a toolbar but inside the options, group of three options, theres different font sizes so you can only select one of them, only one of the group 18:48:21 masonf: google docs format menu has line and paragraph spacing with exclusive options 18:48:32 lwarlow: its not in the macos things for chrome so i couldn't see an example 18:48:41 lwarlow: we need to really think about the activation behavior for each of these 18:49:01 lwarlow: i think the checkbox ones they according to the spec, if you enter it checks and closes, and space checks but doesn't close, important that we get those details right 18:49:22 lwarlow: even the activation - on macos if i activate a menu item - if i focus it with the keyboard then it immediately activates that menu 18:49:28 lwarlow: using google docs i have to manually open the submenus 18:49:36 that activation behavior isn't really standardized - so this could be a good way to introduce that. but, i would also assume exact behavior will be left up to the platform 18:49:41 lwarlow: it would be different to see if platforms are consistent there? shoul dwe leave that up to the UA? 18:49:49 lwarlow: customizable select activation stuff is somewhat platform dependent in the spec 18:50:08 lwarlow: the mouse activation. on macos its hover and it triggers it, which is the case in google docs 18:50:24 lwarlow: it would be intersting from scotts perspectove, maybe focus on activate, other cases where thats bad 18:50:33 q? 18:50:38 lwarlow: as steve said its a pain to implement this yourself 18:50:46 lwarlow: every feature where i dont need to remake focusgroups myself is great 18:50:58 dom: which example did you give where it activates on hover but not anything else? 18:51:15 q+ 18:51:16 lwarlow: in google docs if you hover a submenu, click format and then text, it opens a submenu, but if you activate using your keyboard then you have to use your arrow key 18:51:24 lwarlow: with macos native menu if you select text it activates the submenui 18:51:47 scott: we can do an issue to talk about this stuff 18:52:01 Zakim, close queue 18:52:01 ok, masonf, the speaker queue is closed 18:52:03 q? 18:52:11 scott: theres a whole subtopic of how do you select more than one item from a series of checkboxes? platform behavior is that it clsoes, but then you have to open it a check again 18:52:36 scott: if you stray away from that, how do you close it? escape might mean you don't commit the change. is it enter or space key? 18:52:43 scott: its gotta come down to the platforms 18:52:57 ack sorvell 18:53:08 sorvell: what keith said what luke said made me concerned around platform differences 18:53:22 sorvell: we gotta be really careful because i want to avoid a behavior where we have with focusing where its completely different on mac 18:53:31 sorvell: theres all sorts of options, and its confusing 18:53:32 q+ 18:54:11 keithamus: i think theres a philosophical thing whether you consider the browser and web to be consistent with your os or consistent with itself 18:54:32 +1 to incubating, lets get the ball rolling! 18:54:36 dom: we will go through all the minutes and pull out the interesting things and start filing issues 18:55:32 dom: people can file issues, but if i go through then i might not capture full context if i go through 18:55:35 dom: i can also just do that 18:55:47 i will continue to provide lots of comments / critical feedback - but i want to make it clear that i am very glad that this proposal was brought forward, and i appreciate the work y'all did on writing this up 18:55:47 Proposed resolution: OpenUI will incubate the "menu" concept, and we can land an explainer. 18:55:49 masonf: too much feedback is a great problem to have 18:55:56 +1 18:55:59 +1 18:56:03 +1 18:56:05 RESOLVED: OpenUI will incubate the "menu" concept, and we can land an explainer. 18:56:06 +1 18:56:07 +1 18:56:08 +1 18:56:53 Zakim, end meeting 18:56:53 As of this point the attendees have been flackr, masonf, lwarlow 18:56:54 RRSAgent, please draft minutes 18:56:56 I have made the request to generate https://www.w3.org/2025/03/20-openui-minutes.html Zakim 18:57:03 I am happy to have been of service, masonf; please remember to excuse RRSAgent. Goodbye 18:57:03 Zakim has left #openui 19:54:08 flackr1 has joined #openui