Up arrows on open accordian panels imply a 'can_be_closed' functionality, that isn't possible

[christopherallanperry]

Coming with fresh eyes to this, the presentation of an up-arrow on an open panel (within a panelset) implies that clicking it will close that panel. In reality, that's not currently possible in any browser I tried. Whilst that functionality would only apply in the accordion view, it feels like a user would expect it so long as the arrow shows as it currently does.

Is there any reason why one panel must always remain open in a panelset, as it functions as expected in the earlier 'Expandable/Collapsable Panel' demo?

[ZoeBijl]

While I see no obvious reason—there could very well be one mind you—to have no items visible; I do agree this should be allowed—just because it is frustrating not being able to close it with that shiny arrow looking at me.

One example where this could be important is an overview where every panel contains subtitles for different pages. You wouldn't want the open panel to be seen as a sort of index/outline for the current page. I.e. it could cause confusing. That is user scented and not user centred; this would have to be researched.

[bkardell]

"Is there any reason why one panel must always remain open in a panelset, as it functions as expected in the earlier 'Expandable/Collapsable Panel' demo?"

Yes, because that is the definition of 'panelset' :) It's all about that 'single selection metaphor' that you can easily re-apply to many possible visualizations. Otherwise you could just leave off the panelset tag and have a stack of independent panels..

The arrows however are merely decoration, they actually serve no functional value and default decorations are definitely bikeshedable/overridable with CSS..

[christopherallanperry]

OK, that's clear enough. Happy to close this one down.

[ZoeBijl]

@bkardell I see this as something people will want. Or at least, I would want this ;) You can still have the “One selected” metaphor, just collapse it initially. Or would this break other stuff?

[ZoeBijl]

I'll try to summarise my discussion with @bkardell on Twitter here:

In response to Brian's article about the history of the web—in which he linked to a demonstration video of OWL's Guide—I said that Guide's accordion like functionality could have all panels closed. Brian responded with “A stack of panels with nothing enforcing open/close behavior is that. Panelset is the single select common to many”. I then asked “Is it a philosophy thing then?” Because in my mind it can still be a set. As much as an advent calendar is a set of days. Brian then said “single-select is what makes it visualizable in N common visual metaphors. How could you display as tabs with N selected?” I said that “you could—for all intends and purposes—have a tab interface with no tab active.”

Brian said “Is it, or is it maybe an empty panelset and some other thing that gets hidden if there are panels or something? ‘set’ is the confusing bit. Maybe bikeshed a better name.”

After that I suggested we move this to GitHub for clarity sake. And that is where we are now ;)

[bkardell]

So, this has come up in a few contexts. The thing that panelset adds (currently, according to how I initially proposed it) is the ability to select "one at a time" because this same functionality has N possible common visualizations: tabsets, single-select accordions, coverflows, decks, carousels and so on. Part of the interesting thing to me is that in aria terms, they're basically the same thing you're trying to describe and in terms of mobile responsive design we are increasingly seeing cases where a natural interface on a desktop might be tabs, but that becomes impractical on a smaller screen where an accordion or deck might be a better metaphor. Having impleted and used lot of these in my time as elements I wondered how their "thingness" could change. The answer seemed to be "it doesn't, they're the same really - all you are trying to do is creatively visualize it N different ways", potentially based on some runtime criteria.

It's been brought up in terms of an accordion a few times now - why can't you multi-select? My answer has always been pretty simple - because that only really works on something that "looks like an accordion" but which is in reality just a stack of with nothing managing any relationship between them at all. This way it makes no pretention to be a "single select thing" and the whole model is pretty simple.

I think that the real issue is panelset is vague. We took it from "tabset" but dropped the "tab" and called it "panel". If it somehow conveyed "a single select tab-like interaction kinda thing which can be visualized N ways" accurately, then perhaps it'd not be so confusing. I don't have a better name, but the good news is that the interwebs are pretty good at bikeshedding, so I'm happy to hear some.

[ZoeBijl]

which is in reality just a stack of with nothing managing any relationship between them at all. This way it makes no pretention to be a "single select thing".

Fair enough. I wasn't proposing that we'd have multiple open panels though. I was proposing that you could close all. it's like a <select> where nothing has been selected. Even so, it would be good to—for example—allow a multiple attribute that would allow multiple panels to be active.

A couple of examples that could be panelsets, but also can be all closed:

1. Bootstrap's accordion has one open by default, but can all be closed.
2. Wikipedia's mobile article view has all titles as accordion titles, all closed by default. Common ancestor would be the article itself—although here you can have multiple open thingies.

I don't have a better name

Maybe just drop set and call it panels? But I like panelset, because it is a set of panels however we spin it.

[bkardell]

what do you see here? http://codepen.io/anon/pen/meYrjx

[bkardell]

also, both bootstrap's thing and the wikipedia seem like they work equally well as panels without a panelset - they're just independently maintained states of panels, right? Is there a specific benefit to putting them in a set - a11y or otherwise which justifies the complexity over just having them have no larger state maintainer?

[ZoeBijl]

If you add multiple to that select, it defaults to none selected. You can select none or more. But you have a point, because we're talking about a single select. I guess you could easily add relationship with a container—e.g. section or article—if you really needed to.

But I don't see how allowing no panel to be selected—or multiple panels open for that matter—complicates things. I'm looking from a developers point of view, as I've never been on the implementer side of things. Could you explain a little bit.

The panelset element manages the selection of its child panel elements. In other words, when panel elements are children of a panelset element, they are automatically collapsible.

Then why not allow them all to collapse?

Unless the multiple attribute is set, the first panel element within a panelset element should be expanded by default. Any subsequent claims of expansion trump the original claim.

Done ;)

[bkardell]

I just don't see decks and tabs and carousels where undefined or N selections is actually a thing that has shown up in the common parlance at all. I can't honestly say I've ever seen it - please show me if I am wrong though. At the same time, It seems to me that without the <panelset> container it's effectively what you want (explain if I am wrong here) - you can expand 0...N of them. It's shorter too. Is there a value in defining that in the wrapper? What is it?

Maybe there's value in swapping the question around. Imagine that like I said

<panel>...</panel>
<panel>...</panel>
<panel>...</panel>
<panel>...</panel>

Creates 4 independent panels which you can open/close at will, including the initial state from 0 to N of them.

Imagine further that

<singleselectorthingy>
    <panel>...</panel>
    <panel>...</panel>
    <panel>...</panel>
</singleselectorthingy>

Works as described by me. N visualizations are possible with the mere switch of an attribute, all are equally accessible with known keyboard interactions and so on.

Create a new tag, even with a crappy name and explain to me what it's value would be/what it does. Then we can decide if it and <singleselectorthingy> are indeed the same thing and discuss implementation details.

[ZoeBijl]

<none-selector-thingy> would indicate is that the content is related and no <panel>'s are open. The trumping of openness would still be true.

<multiple-selector-thingy> would indicate that the content is related and none/one/multiple panel(s) are open. Maybe a user could switch between <panel>s within the group with keyboard shortcuts. Like with role="feed". I'm not sure that would ever happen though; I'm still waiting on landmark navigation via keyboard…

To answer your first question, no it's not, because the relationship between the <panel>s is lost. But that can be fixed with a <section> or <articles> I guess. Other than that, yes it is the same.

I'll re-read the spec again tomorrow before I go deeper into the argument; don't want to say informed things.