– DRAFT –
Open UI

<masonf> github-bot, take up openui/open-ui#1142

[meta] Should we have an OpenUI account on new socials?

<github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1142.

<lwarlow> Proposed Resolution: Setup BlueSky and/or Mastodon account for OpenUI

<keithamus> +1

<masonf> +1

<Penny> +1

RESOLUTION: Setup BlueSky and/or Mastodon account for OpenUI

<masonf> github-bot, take up openui/open-ui#1179

[menu] Menu elements proposal

<github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1179.

dom: di and i are working on the menu elements proposal

dom: some of yall have already looked at the google doc

dom: *shows presentation*

<Di> https://docs.google.com/presentation/d/1vPTQm6mV5DcgNHCWm1NStA0n2DYuaWNPW2kaDAlAqZk/edit#slide=id.p

<masonf> Proposed resolution: OpenUI will incubate the "menu" concept, and we can land an explainer.

lwarlow: is there anyone who objects to us incubating a menu idea? we can probably resolve thats a good idea

lwarlow: its been discussed before, popover is a primitive and that we want to use these patterns on top of that

lwarlow: this is a great examlpe of one we should tackle

lwarlow: i think we should just say yes

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

lwarlow: when doing the explainer it would be good to say this is this pattern, it needs to be separate for this reason

dom: youre saying to distinguish which two cases?

lwarlow: the google docs screenshot it has bits at the top

lwarlow: is the in page bit is that the format tools etc. bit?

dom: yes

lwarlow: the bit to the right hand side of the thing, the toolbar is a slightly different pattern

lwarlow: the bold italic, underline stuff, thats a different pattern

lwarlow: might be good to explain why thats a different pattern

dom: there is a separate aria page for that editor toolbar as well, we should do a better job of distinguishing those

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

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

scott: toolbar at the bottom can be buttons, form controls, even links

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

scott: a toolbar may contain a button to invoke a submenu, but a toolbar is not a menubar

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

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

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

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

dom: the fieldset is a generic container for form controls but it doesn't have exclusivity, and we would be changing that

masonf: is the suggestion to create a new grouping element?

dom: we could do that. whats currently proposed in the doc is just fieldset, checkable=multiple or something

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

dom: maybe the way forms are now is weird

lwarlow: one of the difference is navigation

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

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

dom: i like the idea of the parent grouping, i would prefer to not do fieldset

dom: i do like the proposal, its clean and looks nice

sorvell: do you want the discussion on the issue or the google doc?

masonf: use github issues

sorvell: use cases are critically imporant to nail down

sorvell: i think scott could be better for this

sorvell: navigation is a deep can of worms, people have strong opinions about navigations and menus

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

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

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

sorvell: navigation example is something that seems similar, whether you would actually want the arrow keys to navigate around these

sorvell: you could have a bunch of text in there too

sorvell: is this the same thing? i dont know

sorvell: this thing is entirely a navigation menu bar

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

sorvell: theres a lot of nuance around the specific issues here

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

sorvell: maybe we can think of that as a list and provide those as separate primitives

sorvell: things like submenu positioning, dismissal, opening, anything related to how a submenu would display

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

sorvell: theres arrow navigation, we dont have a good primitive for that

sorvell: the more that a browser can do for me the happier i am

sorvell: and this is independent from a11y or use case related issues

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

masonf: openable is another one of those that might work

masonf: the other thing that i heard is that the explainer needs to talk in detail about all of the cases

masonf: navigation menu, context menu, etc.

masonf: even if the proposal doesn't tackle those things, saying which things are or aren't handled

masonf: we should think about all of those use cases

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

masonf: hopefully those pieces can be used in either case

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?

masonf: where are the menu item contents etc

scott: im going to talk about navigation use case

scott: that is one thats on the apg and is the most contentious

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

scott: theyre meant to be used in forms mode. arrow key navigtaion. maybe some typeahead

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

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

scott: everythings either a menu tooltip or dialog because those are the only words we have

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

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

scott: in the apg its just a bar of menuitems, theres no functional difference other than its used for navigation purposes

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

scott: maybe theres an indication there that it opens a new page

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

scott: in these mega menus, people put in headings or descriptions about the content, those dont belong in menus

scott: in customziable select, anything can go in there so we have the dialog fallback

scott: i dont want us to start off with were just going to make this messy by default

scott: i am not opposed to it moving forward, but theres a lot of work moving forward

scott: if its just going to be menu but it has type=nav but no actual difference then we havent helped anyone

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?

scott: theres a lot of other people who have a lot of thoughts on this

scott: probably even more critical or supportive than me

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

masonf: we should file an issue about this

dom: thanks, i understand why its a big deviation

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

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

lwarlow: google docs doesn't let me do that, but its all canvas based anyway

lwarlow: im not completely against the idea of you should be able to build a context menu

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

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

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

lwarlow: web extensions can already do that, my password manager can do that

lwarlow: i dont see why we cant let websites do that

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

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

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

dom: are we even in control of that? since you can just make your own now

masonf: yeah, keep it separate

<Zakim> masonf, you wanted to react to lwarlow

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

lwarlow: if devleopers want to that they already can

dom: we shouldn't design with that use case in mind?

lwarlow: yes

masonf: youll get it for free

keithamus: firefox used to ahve this feature where you could add stuff to context menus

keithamus: steve had a comment about the safety triangles, and the idea that we should expose more of these

keithamus: i believe we talked about safety triangles in interesttarget, if it exists in two places maybe worth investigating

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.

<lwarlow> I think macOS has that too right? And we added that for custom select

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

sorvell: first i think that - i feel pretty strongly that we should decide the use cases

sorvell: we need to really explore this space before we decide what we do

sorvell: scoping it to a number of phases

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

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

sorvell: part of this is around forging expressiveness on the web

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

sorvell: we should make it expressive enough for other use cases

sorvell: if all the rage is radio menus and we cant do radio menus, and people dont use it then that would be unfortunate

sorvell: theres no right answer, and we need to respect the dificulty, but we should allow expressiveness to allow new things and push boundaries

<scott> i'm not sure where the pushback is?

sorvell: if we can bake in at least the keyboard works the right way then we have a huge win

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?

lwarlow: unclear to me what the radio equivalent would be?

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

masonf: google docs format menu has line and paragraph spacing with exclusive options

lwarlow: its not in the macos things for chrome so i couldn't see an example

lwarlow: we need to really think about the activation behavior for each of these

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

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

lwarlow: using google docs i have to manually open the submenus

<scott> 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

lwarlow: it would be different to see if platforms are consistent there? shoul dwe leave that up to the UA?

lwarlow: customizable select activation stuff is somewhat platform dependent in the spec

lwarlow: the mouse activation. on macos its hover and it triggers it, which is the case in google docs

lwarlow: it would be intersting from scotts perspectove, maybe focus on activate, other cases where thats bad

lwarlow: as steve said its a pain to implement this yourself

lwarlow: every feature where i dont need to remake focusgroups myself is great

dom: which example did you give where it activates on hover but not anything else?

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

lwarlow: with macos native menu if you select text it activates the submenui

scott: we can do an issue to talk about this stuff

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

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?

scott: its gotta come down to the platforms

sorvell: what keith said what luke said made me concerned around platform differences

sorvell: we gotta be really careful because i want to avoid a behavior where we have with focusing where its completely different on mac

sorvell: theres all sorts of options, and its confusing

keithamus: i think theres a philosophical thing whether you consider the browser and web to be consistent with your os or consistent with itself

<lwarlow> +1 to incubating, lets get the ball rolling!

dom: we will go through all the minutes and pull out the interesting things and start filing issues

dom: people can file issues, but if i go through then i might not capture full context if i go through

dom: i can also just do that

<scott> 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

<masonf> Proposed resolution: OpenUI will incubate the "menu" concept, and we can land an explainer.

masonf: too much feedback is a great problem to have

<lwarlow> +1

<jarhar> +1

<frehner> +1

RESOLUTION: OpenUI will incubate the "menu" concept, and we can land an explainer.

<scott> +1

<sorvell> +1

<keithamus> +1