Meeting minutes
<gregwhitworth> github-bot, take up openui/
Consider "toggle" (e.g., show/hide - expand/collapse) button or attribute
<github-bot> OK, I'll post this discussion to https://
lwarlow: there are many things on the web that show and hide the content in them. currently theres not necessarily a great way of implementing that without javascript but also like to implement it nicely, can be difficult
lwarlow: the details element, which is perfect in some situations, but its got some rough edges to it, and it also just isnt the correct solution in all cases
lwarlow: even with the new styling stuff, which is great, its still problematic for certain things
lwarlow: it would be nice if we had some sort of thing that could do that in a more generic way
lwarlow: comand invokers could be the summary equivalent thing which is a button that triggers this
lwarlow: i put a comment with some questions
lwarlow: i dont have answers to all of these, but thats the gist of it
lwarlow: the latest proposal is to have an attriubute called bruce. that would turn the elemnt into a showy hidy thing
lwarlow: some questions: would this add js apis? yes, like popover does
lwarlow: what theyre called, we can decide, but expand collapse and toggle sort of thing
lwarlow: theres questions about which pseudo classes it should match. i think :open is correct, maybe not
lwarlow: aria roles and states and stuff
masonf: the question i wanted to ask - i see the point, the shape seems ok, but i think where we should start or make sure we've discussed first: why isn't summary details the answer? i know theres issues with it, but like fundamentally summary details is a button that opens and closes regions of content, it meets everything you just said i think.
is it possible that we fix whatevers missing? or are there fundamental things it cant do?
scott: i look at details summary and i dont think its really the solution for imagine a static navigation. im thinking like small viewport, you have a list of links, but some of those links have a button next to them to expand and collapse some navigation. not a popup, but some navigation within that.
scott: i wouldnt think of that as a details summary semantically where theres a legend or label for contents, those are often just a down chevron, a single button that should be able to open and close things
scott: thats one of the use cases. theres others, but another one that i would point to: weve been talking about accessibility issues with details. in some browsers its mapped to a button and in gecko its a summary role, but thats not an aria thing
scott: if more browsers mimicked that, then that role doesn't have the presentational children of buttons
scott: it kind of mitigates the whole you can't put interactive content inside of a button
scott: there are use cases for that, and then theres use cases for buttons that open and close things
scott: i think thats how id summarize it - its semantically a bit different
masonf: i get that point. maybe we should be adding more behaviors to other elements that can do this? i wonder if this disclosure thing is a global attribute or just goes on summary details?
scott: that was one of lukes questions, i could see if very well being similar to the popover attribute. theres just enough things it does belong on that it makes sense for it to be a global attribute, but why would you put this on the body element?
gregwhitworth: i posted lea's status where she gives us props for not doing the element. i envision us hitting similar things where one of the reasons we went that route is because use csaes cant be solved by them being elemnts
gregwhitworth: the irony is that her tweet before that is supporting scotts initial thing where he wanted a drawer element
gregwhitworth: so it would be popover plus toggling
gregwhitworth: the invoker thing is starting to become the thing in which we say that this thing is going to do something with that. that was raised on that thread as well
gregwhitworth: i see the value, details summary is there, tabs we would be doing something similar. details summaries coudl be laid out to be tabs
lwarlow: i think on the cant do details summary, i dont know if these are not fixable problems, react aria has a details thing partially because of the styling thing. stuff like their design have it so you can have stuff adjacent to - inside the summary but not actually inside it. another button that does something else. in theory you can't put in
a summary but then youd have nested interactives
lwarlow: i think the other thing is the fact that the spec doesn't match impls, but details summary you cant necessarily change the roles
lwarlow: i think a details is just a group at the moment, and then summary is slightly weird. if you had other roles you needed to use you cant do that in the current model
scott: in the aria and html spec the reason that we have that rule in there is because if there have been cases where changing the roles of those elements it stops working in the accessibility tree. its more of an author rule, but visually it would look fine
lwarlow: the one other thing is you dont necessarily want the trigger to be adjacent to the thing thats expanding. now in chrome you can go ham with css and mess things about, but a hamburger menu if you want that to do an expanding thing - having a summary inside the details limits that
lwarlow: i did at some point make a tab component that is using details summary, and the exclusive stuff to make a tab like thing, and i used the prototype invokers and hiding the summary
lwarlow: you can do that, it requires js, but none of thats necessarily correct because of certain impl problems
lwarlow: this was brought up by someone on mastodon, my first thought was details summary already does this. to me theres enough distinction if we can come up with concrete use cases where details summary doesnt work
nmn: is there a use case for a toggle thats not to show or hide something?
nmn: you use css to hide the details, or extend details summary. would it make sense to allow details to be used without a summary, and you use an invoker to open or close it?
scott: i would think that would have backwards compat issues because if you don't put a summary in a details then it would automatically get added
lwarlow: command invokers dont currently touch details
lwarlow: there is a prototype to do it with details, but i dont necessarily know if thats what we want
lwarlow: maybe instead we would just have a new thing and say use invokers with that
<Zakim> scott, you wanted to say that's another use case. an expand all button or collapse all button.
scott: an expand all button and collapse all button is another instance where this would be useful because you wouldn't use a details summary to collapse other details
scott: my original thought was that in some cases i have a button that invokes - my content is actually a popover for larger screen views, but i could write a script and swap that out and have another feature where another button invokes the same thing but its displayed inline. or i could have two buttons and display one, but its the same content
that shows up as a popup or a disclosure
scott: one of them i can do with html and the other i have to do with javascript
masonf: some of the arguments are semantic, so whatwg would be ok with that
masonf: one thing that naman said is that a lot of the discussion about the magical hiding thing. what if the attribute was called openable, and that opts it in to matching or not matching the :open pseudo class, maybe adds toggle if you want, and its up to the developer to add a rule to display:none. all this attribute adds is one bit of state
which matches the pseudo-class, and then you dont have to worry about hiding
masonf: avoiding having to decide whether its display:none or visibility:hidden, and these questions it sidesteps
lwarlow: i like that, but theres no way in css to do the find in page stuff
lwarlow: content-visibility:hidden might match, but hidden=until-found is special html stuff
lwarlow i could see a div that has hidden=until-found, and you can kind of make it display when its opened. the only bit there is that once its opened...
lwarlow: you could special case it where you don't have to remove the attribute. it does get removed, but this element has this other thing, so we're going to leave it and let it do stuff
masonf: when it has openable and hidden=until-found they play well together
lwarlow: that does quite neatly avoid all the questions around does this work or does this not
lwarlow: maybe we do need default styles? but maybe not?
scott: since im not hearing anyone say i hate this, i was going to ask luke, do you want to help me write a proposal for this?
scott: since you already did work on the proposal for the pressed button which could the other question be for about, like other toggleable things, and this one is for show and hide and stuff
gregwhitworth: i would like clarity on the amount of things ive seen listed - invoker or commandfor? where does that line start and stop? i think that would be useful to understand
gregwhitworth: ive seen in the explainer video play start and stop so that its declarative. it feels like its becoming like state commands, and thats why im like at what point are those command this type of things?
gregwhitworth: what if devs think to try this
masonf: the proposal here is theres two parts: you put the openable attribute on something, and the other half is to use the command attribute to toggle it
scott: when i wrote this command/commandfor didn't exist yet, but now we can just use command
lwarlow: as for where the line is drawn, currently the thing going into html is custom command which is nice to have on its own, popover commands, and modal dialog
lwarlow: followups to that would be this thing if this happens may be details if this doesn't happen. input and seelct have showpicker methods so we could see if we have a declarative way to do that. input especially it could be useful, that would be a fast followup
lwarlow: media controls and whatnot, i think its cool if we could do them. differnet class of things. all of them are currently aria expand and stuff, except for the custom ones
lwarlow: not really a clear line of where to stop
<masonf> Proposed resolution: Add a global attribute called `openable` that opts an element into matching `:open`, adds JS methods like .open(), .close(), and .toggle(), and connects to command/commandfor.
gregwhitworth: thanks, and thats a separate issue, just a quick clarifier, and it sounds like were using it so cool
<keithamus> +1
<masonf> jarhar: for popover, we could have used :open, but we chose not to, because it conflicts with :open when on something like <dialog>
<masonf> jarhar: maybe we need a different pseudo class, other than :open.
<lwarlow> +1 (minus bikeshedding)
<masonf> jProposed resolution: Add a global attribute called `openable` that opts an element into matching `:open`, adds JS methods like .open(), .close(), and .toggle(), and connects to command/commandfor. All names subject to bikeshedding.
dbaron: the proposed resolution adds js methods. i dont think we have a mechanism for adding or removing js methods based on an attribute
masonf: yeah it would have to throw if we dont have the attribute
masonf: whatever we did for popover we should do
scott: this could be the same as popover, it just doesn't go into the top layer
<dbaron> (One other issue is whether there are existing elements with open/close/toggle methods.)
<masonf> Proposed resolution: Add a global attribute called `mason` that opts an element into matching `:open`, adds JS methods like .open(), .close(), and .toggle(), and connects to command/commandfor. All names subject to bikeshedding.
masonf: we dont need closewatcher, it doesn't block navigation
keithamus: this isn't necessarily floating ui
<lwarlow> +1
<scott> +1
<masonf> +100, given the name
<keithamus> +1
<jarhar> +1
<nmn> +1
RESOLUTION: Add a global attribute called `openable` that opts an element into matching `:open`, adds JS methods like .open(), .close(), and .toggle(), and connects to command/commandfor. All names subject to bikeshedding.