Is panel-title a required child of panel element?

[tigt]

If so, how does it interact with normal heading elements? Is something like:

<paneltitle><h2>Text</h2></paneltitle>

permissible? (For backwards compatibility reasons, I'd vote yes.)

[stevefaulkner]

@Tigt <paneltitle> is not mapped to a heading role, its a grouping element that, i guess, is expected to include a child heading http://bkardell.github.io/common-panel/index.src.html#the-paneltitle-element

[LJWatson]

@Tigt

A problem with mapping paneltitle to heading is that with the tab and accordion metaphors, you'd end up with multiple headings in quick succession and no content between them.

The only instance (that I've come across) where paneltitle wouldn't be a desireable child of panel, is with the carousel metaphor. Question is whether we make it required with this exception, or don't make it required at all?

[tigt]

Makes sense. For carousels, they always seem to have at least a summary line of what the slide is about, so as long as they can style <paneltitle> as they like... On Jul 20, 2015 5:15 AM, "Léonie Watson" notifications@github.com wrote:

@Tigt https://github.com/Tigt

A problem with mapping paneltitle to heading is that with the tab and accordion metaphors, you'd end up with multiple headings in quick succession and no content between them.

The only instance (that I've come across) where paneltitle wouldn't be a desireable child of panel, is with the carousel metaphor. Question is whether we make it required with this exception, or don't make it required at all?

— Reply to this email directly or view it on GitHub https://github.com/bkardell/common-panel/issues/32#issuecomment-122820024 .

[bkardell]

To respond to @stevefaulkner's OP, I think yes... Don't you? If you have just a panel with no paneltitle what would it be? It would be kind of like a focusable grouping div... also, what would happen if you put a bunch of titleless panels in a panelset - you'd be left without what to select...

[cptvitamin]

I tend to agree that <paneltitle> is a required child of <panel> for the exact reason @bkardell points out:

you'd be left without what to select...

as long as its styleable as @Tigt points out:

so as long as they can style <paneltitle> as they like...

I would imagine that the <paneltitle> would serve as the accessible name of the <panel>

[bkardell]

@LjWatson you said:

The only instance (that I've come across) where paneltitle wouldn't be a desireable child of panel, is with the carousel metaphor. Question is whether we make it required with this exception, or don't make it required at all?

This is potentially an interesting point. I've been thinking all along around the lines of what @cptvitamin said: it provides the accessible name regardless of whether it is even shown or not. In terms of a set especially one that you might want to display N ways, you'd need this meta-data to draw values in tabs or accordions etc else you really couldn't. However, perhaps you could make a case that there are certain kinds of information that don't actually lend themselves to being useful in some views. A comic strip for example is full of panels where it's basically just a sequence. It still might be useful here, and it certainly seems intuitive to me that an author might just try calling them 1, 2, 3 and so on. Would this violate something inherent or would that be legit?

[cptvitamin]

Very good food for thought @bkardell. The comic strip is an interesting use case to consider. In that case, the relationship of the panel to the panelset is more akin to how a list item relates to a list. That said, we may be conflating two separate use cases. Is that a good thing or a bad thing? It's interesting to think about this in terms of a list. In a list, the list item is a group, that consists of the marker and the content. In the case of the panel, we could think of the paneltitle as an author specified marker. I guess that would mean paneltitle is not required.

On a separate note, if we start to consider a comic strip as a use case for panel/panelsets then we would have to reconsider this spec text:

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.

Only because I think users would find it confusing if they could collapse comic strip panels.

[tigt]

I may have mucked things up with the comic suggestion, especially since my use-case isn't having <panel> as an actual, well, comic panel. It was having it as sort of mini "pages," kind of like the sashes on a window.

Might not be worth the bending of the semantics. The mini-pages/panelsets/sashes were an odd space between a <li> and a <section>, so this seemed like an alright compromise. Of course, it's confusing that <panel> wouldn't actually be a panel, so.

[bkardell]

@Tigt no way, this is actually why this (custom element proposals that real people can actually try to use) is a better process for determining how to propose new elements - if I call it a panel and the first thing you think is "oh, like a comic book panel" and then we say "yeah, well.. no, not that" - that's potentially confusing and if this winds up being a big problem, we should change the name or something. I'm not saying that is the case, but the best thing is to let people use it and be able to take feedback before we go too far down a standards path and create elements guaranteed to be used improperly. Can you maybe provide some sort of illustration of what you mean "mini-pages"?

I'm definitely intrigued by this use case of comics and whether we can somehow meet it. In all cases we create a one at a time series of "things" you can kind of "flip through" and the nice thing is that it tells you "there are N like things here" and gives you some name by which you can choose the active one and then "go into it to see its contents". The polymer team has this thing called "iron-pages" which manages a series of children with one at a time active behavior but give you no declarative means of turning those into views like accordions, etc - that's another layer. panelset as currently defined is that with some given visualizations but on my team for example we have created complex visualizations which are aria hidden which can also flip to the right card in the deck and set focus there - this retains the a11y benefits of the panelset but gives some nice visual affordances atop. In these cases the title is kind of integrated into the card view itself. It seems like something like this could almost work for comic panels too, the trouble is just that they are simply a sequence. Is it actually troubling or helpful to know that there are 10 'panels' in a strip that don't have names, just numbers. It would look kind of strange to render that as an accordion but is there a better way to mark up such a thing in HTML and make it accessible?

[tigt]

I've been working on a job application thing that explains the concept, so I'll be sure to post it here once it's done. The gist is that while a single panel is the atomic unit of a comic, it's groups of panels that are the molecules, and therefore far more interesting.

In an attempt at making responsive comics, it was more important to isolate and preserve the groups of panels that appear within normal book pages, and have those squash and stretch and go to 100vw and 100vh to fill the screen and be paged through.

I called them "panelsets" (which is how I found this spec :) for a while, but given terminology clashes ("window," "page," "frame," "screen," and other obvious candidates all mean very established things in web pages), I've been calling them "sashes," like the part of a window frame you can move up and down to let air in:

Because they're individual units that can contain multiple panes.

I'm perfectly fine with <panel> not actually meaning a comic's panel (I'm making the comics out of SVG, which precludes that), it's just one of those quirks of naming things within code. Like how XMLHttpRequest doesn't just get XML, or only use HTTP, or even is a request.

[cptvitamin]

This reminds me of the use case that @chaals mentioned on the html-a11y-tf call last week, nested panelsets, or a tree view. I think the model that @Tigt just described works if we think of them as nested panelsets. @Tigt, what do you think? On a side note. I remember my wife (a real architect) getting a bit upset when I came home with a business card that said "Web Architect" on it. I'm not sure she will take too kindly to HTML elements named <sash> and <muntin> ;)

@bkardell is right though, the naming has to be spot on, otherwise it will just get misused, like <aside>. This is definitely a healthy discussion.

[tigt]

@cptvitamin Oh yeah, I just meant I was using class="sash" for my own internal purposes.

Nested panelsets does sound interesting. I don't think there is a better name out there, because "panel" has good connotations (there's probably more than one) and is a common word to boot.