common-panel-title

[hhubbell]

If a developer were to want a more "Rich" panel title - for instance a title/subtitle, or a title with some sort of alert icon - how would they go about doing so, if at all? Would it make sense to include a common-panel-title element in the spec, or is that beginning to muddy the waters of what the common-panel element should be.

[LJWatson]

I think there is a case for making common-panel-title an element in its own right.

The existing ARIA design pattern has three roles (tablist, tab and tabpanel). It makes sense to map these roles to any new HTML elements intended for the same purpose.

It would make keyboard focus easier. The common-panel-title element would be a logical hook for keyboard focus, and as an element in its own right it would make focus management between multiple panels within a set easier. Again, paving the ARIA design pattern cowpath.

I believe it would also make styling easier?

If we did this we'd need some way to establish a relationship between the two elements (common-panel-title and common-panel) in the DOM. I wonder whether using common-panel-set regardless of how many panels were included would be workable?

So for example:

<common-panel-set>
    <common-panel-title>Favorite books</common-panel-title>
    <common-panel>
          <p>My favorite books...</p>
    </common-panel>
</common-panel-set>

To impose the ARIA roles and keyboard focus on top:

<common-panel-set role="tablist">
    <common-panel-title role="tab" tabindex="0" aria-controls="panel1">Favorite books</common-panel-title>
    <common-panel role="tabpanel" id="panel1">
          <p>My favorite books...</p>
    </common-panel>
</common-panel-set>

[bkardell]

@LjWatson

We need to think about the simple panel cases too, so title would necessarily need to be a child of panel ala

<common-panel>
    <common-panel-title>My Favorite Books</common-panel-title>
   <p>My favorite books are....</p>
</common-panel>

I have a number of concerns here which follow from this and I'm worried that it creates more problems than it solves... Let's discuss them.

First, if we do that, I think it would make sense to introduce a element so that you'd wind up with something more intuitively mapped like

<common-panel>
    <common-panel-title>My Favorite Books</common-panel-title>
   <common-panel-content><p>My favorite books are....</p></common-panel-content>
</common-panel>

Second, now there is no inherently implied "the title has to be text" so now we have to start asking questions like what would it mean to allow it to have rich content. It could really mess with both rendering and focus management pretty easily (by someone messing with position: property in CSS, for example, or using big elements or elements with a non-zero tabIndex).

Finally, how do you say "there can be only 1 title element child or 1 content element child"? It starts to feel like it gets possible to write wishy washy HTML which I'm not sure make sense

<common-panel>
    <common-panel-title><h1 style="position: relative">My Favorite Books <input type="text"></input></h1></common-panel-title>
    <common-panel-title>My Favorite Movies</common-panel-title>
   <common-panel-content><p>My favorite books are....</p></common-panel-content>
   <common-panel-content><p>Whose content am I?...</p></common-panel-content>
</common-panel>

[darobin]

I really think this ought to be an element. I idly wonder if label could simply cut it (with only the first one that has no for and no form control child being used, and having it wired to the whole panel). I don't have a strong position on whether there should be an element for content, I don't think it's necessary (it would tend to create problems IMHO). I reckon going the scoobidoo route and taking "whatever isn't the title" is good.

[bkardell]

@darobin can you please share a snippet example of what you're proposing? I'm unclear. If it's

<common-panel>
    <label>10 Best Movies</label>
    Here's a list of my favorite movies as determined by my arbitrary whims...
    <ul>....</ul>
</common-panel>

I'd have to disagree that that is better than even.

<common-panel>
    <common-panel-title>10 Best Movies</common-panel-title>
    Here's a list of my favorite movies as determined by my arbitrary whims...
    <ul>....</ul>
</common-panel>

I'm not sure the scooby-doo rule is so much easier to read, it's certainly harder to program and easier on both ends to get wrong imo. I suppose we could say both content and title must be children and last one in wins (or first, I'm not sure if there's a good precedent that accurately applies?). Still doesn't answer the fact that if you can inject markup into the title you could break all kindsa shit pretty easily. Does it matter? Maybe not if we are super careful...

[LJWatson]

@bkardell "First, if we do that, I think it would make sense to introduce a element so that you'd wind up with something more intuitively mapped like

<common-panel>
    <common-panel-title>My Favorite Books</common-panel-title>
   <common-panel-content><p>My favorite books are....</p></common-panel-content>
</common-panel>

I think this might be too verbose? Having common-panel-title as a child of common-panel makes sense, but I think leaving common-panel-set as the only potential container keeps the code cleaner.

So a single panel would be something like:

<common-panel>
    <common-panel-title>My Favorite Books</common-panel-title>
    ...
</common-panel>

A collection would be something like:

<common-panel-set>
    <common-panel>
        <common-panel-title>Title 1</common-panel-title>
        ...
    </common-panel>

    <common-panel>
        <common-panel-title>Title 2</common-panel-title>
        ...
    </common-panel>
</common-panel-set>

"Second, now there is no inherently implied "the title has to be text" so now we have to start asking questions like what would it mean to allow it to have rich content. It could really mess with both rendering and focus management pretty easily (by someone messing with position: property in CSS, for example, or using big elements or elements with a non-zero tabIndex)."

I don't think we can reasonably prevent the title from being styled? If memory serves it was a lack of styling capability for native form controls that led us to so many (llargely inaccessible) custom form components on the web. We'd risk pushing people away from using these native panels and back to custom widgets I think.

If the common-panel-title were focusable it wouldn't be any more prone to tabindex crime than any other interactive element already is. Relatively speaking though natively interactive elements tend to come in for tabindex abuse less than non-interactive ones.

[bkardell]

@LjWatson

"""I don't think we can reasonably prevent the title from being styled? If memory serves it was a lack of styling capability for native form controls that led us to so many (llargely inaccessible) custom form components on the web. We'd risk pushing people away from using these native panels and back to custom widgets I think.""""

They are styleable all of the hooks and pieces are there with pseudo-elements (or first class elements in the existing prototype). This is separation of concerns - structure isn't about styling. It is possible to richly style this as it is, but it is not possible to say that the title is made up of, say, 3 paragraphs, two buttons, a iframe, some inline elements and another panelset... that's the concern... It's easy to say something non-sensical and breaking.

I suppose we could solve this by saying we only lift out the .textContent in the title element... That's not too bad, but it has little benefit then, it's effectively an attribute and it doesn't solve the <ruby> problem

[LJWatson]

@bkardell "They are styleable all of the hooks and pieces are there with pseudo-elements (or first class elements in the existing prototype)."

Ok, in which case I'm less worried about it being an element in its own right.

If we do stick with the idea though, I'm inclined to agree with @darobin in that we don't need a common-panel-content element. It sounds as though it would work along similar lines to details/summary?

[bkardell]

done, common-panel-title is now it's own element.... Implementation leaves something to be desired in the prototype, but it works.