default expansion state

[chaals]

Different metaphors have different possible defaults for what should be expanded. Carousel, Deck, tabs generally have exactly one thing at all times. Accordion often doesn't...

Should there be defaults according to which presentation?

[bkardell]

Currently I was aiming for all that manage the single select metaphor - I am not sure that this could accomodate what you're asking for - but basically just a stack of expandable panels with no surrounding panelset would accomplish that, right? and it wouldn't have the leaks I was trying to avoid - like what if the view changes as a result of resizing your screen - with the single select idea, everything holds up - if you go multiple, it falls down.

[LJWatson]

@bkardell A stack of stand-alone panels (with their expanded state managed individually) would lose the collection semantics needed for an accordion/carousel/whatever to be meaningful.

[bkardell]

@LjWatson dammit. that's right. I'm not sure how to resolve this. My gut preference is to just not support it - I believe some UI toolkits call them separate things even. Currently the thing revolves around 'single selection', the whole thing just gets a lot more complicated/harder to explain if you allow multi. Thoughts?

[chaals]

How hard is it to support? consider the forms analogy. radio buttons, checkboxes, and select options are all really the same thing, except radio has exactly 1 value, the others have multiple or zero possible.

I think explaining it could be relatively easy - you can support multi on accordion (other types?) but on types that don't, expanding one automatically collapses the others - so a carousel always moves to the selected thing, but a in accordion mode doesn't auto-collapse. If you move from a multi-supporter to another one, the last thing opened is the one…

[LJWatson]

@bkardell @chaals

If we support single selection in some visual metaphors, and multi-selection in others, we're going to have to communicate the visual metaphor at a semantic level.

At the moment the panelset/panel composite is based on the notion that the underlying semantics and interaction remain the same, regardless of the visual representation. If we change behaviour based on visual representation, we'll need to communicate that at a semantic level.

[bkardell]

@LjWatson Yes, that's what I was saying.

[LJWatson]

@bkardell

The challenge is what we do about it? @Chaals has a point, the accordion selection pattern is different from the others. We could:

•   Exclude the accordion metaphor from the allowed visual representations.

•   Introduce semantics for each metaphor.

•   Other?

[bkardell]

Again, I dont think this is entirely straightfoward in the sense that accordion does not always (or even usually) mean that. Noticing similarities between these metaphors is not new and a number of approaches to this have been taken - bootstrap for example uses a collapse concept to create both accordions and carousels which are single select:

http://getbootstrap.com/2.3.2/javascript.html#collapse

Responsive designs have been created to make tabsets and accordions that work interchangably as single select mechanisms: https://github.com/aexmachina/tabcordion https://github.com/flatlogic/bootstrap-tabcollapse

Microsoft uses a similar concept in XAML (another declarative UI language for rich toolkits that was hotly developed during the end of the XHTML era to kill HTML, competing with Mozilla's XUL, Adobe's Flex and Java's JFX) to perform a very similar mental model to ours: They are just a managed group of collapsable panels (they say 'expanders') where only one can be expanded at a time. https://code.msdn.microsoft.com/windowsdesktop/Grouping-Expanders-just-b1bbba57

Numerous demos of accordions aren't even the visualization you'd call an accordion, for example, this one on MDN is actually more like coverflow https://developer.mozilla.org/en-US/demos/detail/pure-css-accordion/launch and it clearly doesn't support multi-expansion.

I can't see any logical way you could start as an accordion, allow multi-select, switch to any other view without multiselect, make a selection and then flip back without losing all of the previously selected which is why doing it via the attribute switching (or similar) falls down for me. You could however make two distinct 'set' elements with different semantics?

[ZoeBijl]

Wouldn't this be solvable with an attribute like multiple that can be set similar to how it works with <select>'s. That way we have semantics and can style accordingly. If desired, a developer can set the attribute via JavaScript when it is needed—with a window resize perhaps.

Or am I missing something?