[openable] do we need exclusive openables?

[lukewarlow]

Details elements can be linked together to create an exclusive accordion pattern (this is contentious and should probably have an opt-out in browser settings).

We should decide if and how this pattern can be applied to openables. For tab like UI this would be nice to have without JS though you would still need JS for an accessible tab component (for now).

[brechtDR]

Sounds interesting but could also create author confusion (when to use openable, when to use details). What I rather see happening is the question for an "open all", "close all" method.

[sorvell]

I think this would be very useful. It supports things like tabs and menus or something like a legend row for a table that has different settings. Otherwise, users will need to wrap things in <details> and it seems like openable specifically exists to support cases where this is problematic?

For implementation, perhaps just openable=name?

[css-meeting-bot]

The Open UI Community Group just discussed [openable] do we need exclusive openables?, and agreed to the following:

• RESOLVED: We should support exclusive openables via the name attribute.

The full IRC log of that discussion

<hdv> lwarlow: we discussed openables a while back, it's a new attribute that allows you to make expandable regions of content
<hdv> lwarlow: the idea is more generic 'details'
<hdv> lwarlow: there are legitimate use cases, where panels of content are somewhat linked together, like tabs
<hdv> lwarlow: that you'd want one open at a time
<masonf> q+
<sorvell> q+
<scott> q+
<hdv> masonf: if you make things searchable, it'd be weird if suddenly a different tab would open
<hdv> masonf: it seems like exclusive openables should be a thing
<hdv> masonf: if it is made exclusive, please let's do it with the `name` attribute like everything else
<masonf> ack mason
<masonf> ack sorvell
<hdv> sorvell: I missed the reasoning for making this distinct
<hdv> sorvell: I see wrapping could be a problem, like in tables. Are there other cases where you would want this exclusive behaviour?
<hdv> sorvell: I think the answer is yes
<masonf> ack scott
<hdv> scott: some of these things we did talk about
<hdv> scott: re exclusivity… anecdotally speaking, I came across a few instances where details have been used with the name attribute, and people have been unsure why they're hearing x out of y announcements along with them
<hdv> scott: that was the way Chromium went to indicate there is some kind of special behaviour?
<hdv> scott: one where I saw it there were 28 of them, user feedback was 'what is this?'
<hdv> scott: everyone knows a radiobutton is x of y, because it makes sense in a radio group, in the exclusive accordion, if you know there's 28 of y, you don't know 28 of what? buttons? summaries?
<sarah6> q+
<hdv> masonf: david baron has some time next quarter to work on details/summary a11y stuff
<masonf> ack sarah
<hdv> sarah6: I can't imagine complex use caes for this, eg can't define content of every link in the page, hard for me to see actually use this for those scenarios? is this kind of a nice thing for people who want exclusive accordions or very small tabs?
<masonf> q+
<hdv> lwarlow: use case wise, probably right that tabs will end up using JS to add content to them, in which case you can probably use the same way to open/close them
<hdv> lwarlow: maybe lazyloading iframes?
<scott> q+
<hdv> lwarlow: it'd probably be the simpler use cases
<hdv> masonf: even for heavyweight cases where you'd load with JS, even then eventually you could have commandfor etc and just have a JS listener on beforetoggler, then all the mechanism is sorted declaratively
<sorvell> q+
<hdv> sarah6: is that easier than adding an eventlistener on click?
<hdv> masonf: manages state?
<masonf> ack mason
<hdv> lwarlow: comes down to how often your content loads with JS vs already on the page
<masonf> ack scott
<hdv> scott: I don't have strong feelings one way or another
<hdv> scott: one thing: because name already has specific behaviour/semantics for buttons, would it be ok to piggyback off of that like we do for details?
<hdv> scott: and in the context of a form, you wouldn't be able to use name?
<hdv> lwarlow: the name would go on the openable rather than the button
<hdv> masonf: unless the button was the openable?
<hdv> sorvell: or openable=name?
<hdv> scott: would assume goes on buttons as they make the behaviour happen
<hdv> scott: is where my head went
<hdv> lwarlow: my expectation would be that it was on the openable as it works better with the JS
<hdv> scott: just my initial reaction fwiw
<hdv> lwarlow: makes sense
<masonf> ack sorvell
<hdv> sorvell: I'm a little confused, some of this would be more flexible if you did it in JS; but argument maybe is 'does it _only_ make sense ins JS?'
<hdv> sorvell: if there are cases where you don't want JS that's great
<lwarlow> Proposed Resolution: We should support exclusive openables via the name attribute.
<masonf> +1
<keithamus> +1
<sorvell> +1 except maybe not name.
<lwarlow> RESOLVED: We should support exclusive openables via the name attribute.