Meeting minutes
[accordion] Differing interpretations/models of exclusivity #752
<gregwhitworth> github: openui/
<gregwhitworth> dbaron: there's maybe two different accordion things we could discuss, bkardell_ raised this one
<gregwhitworth> dbaron: there are different notions of exclusive accordions across design systems
<gregwhitworth> dbaron: the brief distinction is the more common one is either 0 or more items to be open at a time
<gregwhitworth> dbaron: the less common one is, Google Pixel product page, it is exactly 1; rather than 0 or 1
<gregwhitworth> dbaron: it starts with 1 open and there is no way to close the opened one without opening another
<gregwhitworth> dbaron: I think it was FAST that did it as well
<gregwhitworth> dbaron: one of them has the option to be exclusive and it does it this way but it's controls are a little weird
<gregwhitworth> dbaron: my proposal to handle this that we should say that if you want to do this you need to do it from script
<gregwhitworth> dbaron: since it's not that common and it requires unusual UI to do it well to have the disappearing control we don't provide it as part of the platform
<gregwhitworth> bkardell_: my concern here is that it seems to be out of vogue
<gregwhitworth> bkardell_: but it used to be the dominant paradigm
<gregwhitworth> bkardell_: it's just tabs rarely
<gregwhitworth> bkardell_: for the exclusive version of this, most libs used to have this
<gregwhitworth> bkardell_: I call it the highlander one but there has to be 1 at all times
<gregwhitworth> bkardell_: one note I wanted to make, there are three or four systems that do it
<gregwhitworth> dbaron: I called it exact exclusive
<gregwhitworth> bkardell_: I don't think we're far enough along in this proposal to say that I disagree, but I'd love to file issues on those systems and have them weigh in
<gregwhitworth> bkardell_: I suspect a lot of them will have some insights or maybe none
<gregwhitworth> bkardell_: we would benefit from that
<gregwhitworth> bkardell_: the reason it matters is the way in which you need to spec this is very different
<gregwhitworth> bkardell_: they're basically radio buttons
<gregwhitworth> bkardell_: radio buttons, can be none but if you select one; there has to be one
<gregwhitworth> dbaron: I think either goes down that weirdish path
<gregwhitworth> dbaron: I haven't seen the radio button scenario where it starts off at 0 but then when you go to 1 it then can't go to 0
<gregwhitworth> bkardell_: this really matters?
<gregwhitworth> dbaron: the always 1 introduces a few issues how to specify it
<bkardell_> gregwhitworth: I dont disagree that there are use cases, but I agree the specification has to change
gregwhitworth: it sounds like david has tackled the 90% use case - let's theoretically pretend we add an attribute later on that is exclusive - could be implement it after the fact
dbaron: I think it can probably be added, but it's somewhat awkward
dbaron: the markup for this pattern is that there is no container
dbaron: it's linking a bunch of details elements with the name attribute
dbaron: which one wins, it's a little weird
bkardell_: anyone could argue that if you have a default in exclusive accordions and if any one of them is not defined as opened the first one is open
dbaron: that's probably fine
bkardell_: it would mean that if you took one out you would have to search the tree to find the next first one
chrishtr: I think we can add this on later
chrishtr: do you think that's a bad thing to do?
bkardell_: I think the purpose of the group is to pave the cowpaths and present something and I think we're reading tea leaves here a bit
bkardell_: I won't stand in the way of progress
bkardell_: I think it would be a good practice for us to bring in folks with library with differences that they do have good research for why they did what they did
chrishtr: I agree, but we also need to incubate things to improve the platform
bkardell_: agreed
chrishtr: in the interest of the second, that's where my suggestion is to not do it for now to reduce the complexity
chrishtr: do you disagree
bkardell_: no, I think we're early enough; it's a reasonable suggestion
scotto: one thing about this, well two things
scotto: while we're looking at radio buttons as a paradigm to not hold them on a pedestal and when you make a choice you can never undo it the need to unselect things so they move to checkboxes and get other issues
scotto: I personally think this is a good way for us to create a distinction between tabs and accordions behave
scotto: since tabs have aria semantics and accordions don't have actual mappings to speak of
scotto: a tab widget where there is one with always a persistent tab but an accordion can be something 0 - 1
bkardell_: we got here because it's a better pattern
bkardell_: there are a lot of subtle interactions and I want to ensure folks that aren't in this room
scotto: I think we could leverage this until told otherwise
bkardell_: agreed, but let's invite
chrishtr: so you're agreeing with dbaron and myself?
scotto: yeah
scotto: I would like us to generally try to not make one thing be everything
scotto: we've come up with one thing that does 17 different things
dbaron: for this specific issue is probably two pieces for a resolution
dbaron: 1. The current plan of record is this exact exclusive thing needs to be done in script and I will try and reach out to the people that design these widgets to get feedback
Proposed Resolution: Exact exclusive will not be a part of the proposal at this time and we'll tell people it needs to be done in script
RESOLUTION: Exact exclusive will not be a part of the proposal at this time and we'll tell people it needs to be done in script
Proposal for Exclusive Accordions
dbaron: I notice there aren't many people on the call today
dbaron: one of the ideas behind this proposal; try and do some small things that we can do faster
dbaron: and part of trying to do that; how fast is faster essentially
dbaron: given the number of people I don't want to constrain this too much today
dbaron: how much discussion should we have this in Open UI before we open an HTML PR
dbaron: it's not going to get merged tomorrow
dbaron: we should open it up to the wider group, probably next week when there are more before we do that
bkardell_: asking preliminarily?
dbaron: yes, relevant folks are here but will wait for next week
chrishtr: in particular there were two areas to verify
chrishtr: 1 - details and summary can be used as the basis of this?
chrishtr: I want to ensure that we can and know of any blockers
chrishtr: a11y and styling dimensions to that
chrishtr: other than that - I think things are straight forward and has legs
dbaron: I have been trying to make parallel progress on those other topics
scotto: in regards to going quickly; I've brought up a number of things where it's footgun but with this specific effort
scotto: doing something this useful and not addressing the underlying issues will be more widely used
scotto: the a11y concerns will be there either way; they don't block your work
scotto: there are some things we can talk about a bit more
scotto: they already have an expand and collapse state that can open and close but what happens when you're in this grouping that can close something that is no longer functional
scotto: do we need to add in a disabled state that currently isn't present
scotto: is it inset and mappings that can be updated of X number things that are toggle buttons
scotto: I'm on the first of 1 of N and it's expanded so I know the others are not
scotto: and that can be done relatively quickly and defer to Aaron on speed of mappings to get into the platform
scotto: the a11y content model issues with details and summary will always remain; I don't know how much we can fix these things
chrishtr: are there some that are not fixable with any design, or legacy?
scotto: a little bit of both
scotto: I've seen accordions where there is a primary trigger and then a paragraph that comes after that with "more...." that can be expanded/collapsed
scotto: if I have a "heading" and follow that up with a paragraph and a table all of that becomes the a11y name for this control and people can and do this
scotto: significantly change how this is constructed because "ALL" of it is the trigger
chrishtr: sounds like you want some additional text that is visible to improve the a11y name
scotto: that doesn't need to get in the way to make details summary into an accordion
chrishtr: I think that could be addressed with a child of details
<dbaron> chrishtr: summary-subheading or whatever
scotto: yes, there are things that need to happen now, no but how do we push this forward?
bkardell_: I was just going to mention to put the toggle button on the agenda today?
chrishtr: we've discussed that one
chrishtr: dbaron do you want to discuss why you think this is better
dbaron: some of the toggle button stuff runs into the issues we faced with CSS Toggles
dbaron: one thing that does some showing/hiding of content but you don't know what kind of thing it is so you can use it for multiple widgets and maybe those things should be distinguished?
scotto: the issue that I take with that is that the same thing could be said of details/summary
scotto: they can be strung together to make a tree component
scotto: the only thing that it can't be done is a typical tab solution
scotto: it is limiting in some of the layouts that you can do because you HAVE to have a summary inside of your details
scotto: the toggle button was done with popover but it would not be about promoting something to the top layer and rendering it to the DOM
scotto: the open/close hamburger thing it doesn't need to be top layer
scotto: a lot of problems with details/summary and their current mappings are completely bypassed because you can have a button inside of a heading but with a summary it can be screwy depending on if it is in a summary
scotto: I wasn't saying that that toggle has to be involved in details/summary but it was a primitive to build with
bkardell_: but if in history we did a toggle button, we would be in a different place
scotto: it's a basic piece that could be used as a building block to build a lot of other components
scotto: with the whole popover thing is that no one could explain what it was because it could be so many different things when we created it first as an element
scotto: the button already has is to have HTML & ARIA and it's been over a decade of this and it hasn't come to pass
scotto: it seems to have a button to be able to toggle content but haven't added it to the platform
chrishtr: the other core question we had, are there things that are not fixable about details & summary with work; and we don't think they're un-fixable
scotto: yeah, I think that's largely true
scotto: I mean, unpopular opinion, HTML being very permissive has cause many a11y issues whereas if they were more strict so there is no way that we can stop people from putting things inside the summary element, so that's always going to be there
scotto: it was more important to render something than break
chrishtr: right, even a new element would have that issue
chrishtr: let's put them on the roadmap and get them filed and the Chrome team will prioritize those to get them fixed
chrishtr: please enumerate them
chrishtr: I dropped them into the doc that you shared; if you want me to sync up and clean up the doc
dbaron: it's useful but I did some other things yesterday afternoon
bkardell_: just wanted to say that um, I get why we want to go really fast and a relatively easy one; it's pretty light on a lot right now
bkardell_: I will see if there are any issues that I feel like opening or not
bkardell_: do you have a fork of HTML that you've been working on with these ideas
dbaron: no
bkardell_: so what you're asking is "should you start the HTML PR fork?"
dbaron: yes
bkardell_: I think yes, because when authoring them you end up finding issues
chrishtr: this isn't about speed but being incremental
dbaron: I should add, the doc I shared with Scott is for it to turn into explainerish and we should leverage it to fix all of the a11y issues and solutions to them
chrishtr: bkardell_ and scotto you both have by far provided the most feedback on this so I want to ensure you're in alignment
scotto: yes, they do it already it just makes easier and it's not something they won't experience today