What is done with various forms of markup, and what is 'valid'

[bkardell]

When we initially began this with discussions and work on the earlier generic-components version, an initial compromise was that because of how slots work, it was technically still functional to put label, label, label followed by content, content, content, though, not advised.

I'm fairly certain the current code isn't going to 'work' if you do that because there are some places that reason that the content is labelled by its preceding child (or vice versa). I guess the two questions this begs are "is that a bug?" and "we should define very specifically what happens and why for some unexpected cases".

This seems kind of pertinent to other discussion too - in #30 @scottohara and I discussed that in practice having a non-heading bit of block text before the content could work pretty well for cases where authors felt that headings were inappropriate. Really, all we need are pairs, preferably that read in natural order. Do we require an attribute on non-headings, or can we just assume that each nth-child is a heading and the nth-child+1 is content? ...

[jonathantneal]

First question: Currently the implementation is based on "grabbing headings and putting them into slots". Do we want to keep doing that or enforce label + content?

I would want to enforce label, then content.

[bkardell]

So, where we landed on this was that after some thought we are leaning toward:

1. It has to be pairs for now, but we'll try to be careful to see if there is some kind of 'auto' in an ultimate proposal where you could "just throw some markdown at it" in theory ("seems very hard tho tbh" - bk)... So we'll open a new issue about dropping the undocumented support we have that lets you do label, label, label form inherited from our work in generic components and indecision earlier.

2. It probably does ultimately make sense to allow some kind of label that isn't h1-h6, and text that introduces a section is a kind of primitive idea that works everywhere and still stops short of being a "heading" in all the right ways. You can still add role/level to that if you want, but then what's the point, really?

   2.1 It would be best for a large number of reasons (including defining the question asked here) for the thing you intend to be a "primitive label" to be explicit, and the most straightforward way to do this is probably by just demanding it be a specific element in the vein of summary/details. Mia also pointed out that it is kind of ok that it isn't necessarily even block - sometimes that could be desirable even. The idea we came up with was to add support for a <spicy-h> in our prototype, and do a little public straw polling to see what people thought/open a new issue to add that.

[bkardell]

What should happen in the various cases, especially tabs for this markup...?

<spicy-sections>
  <wrong> label 1 </wrong>
  <div> content 1 </div>
  <h2> label 2 </h2>
  <div> content 2 </div>
  <h2> label 3 </h2>
  <div> content 3 </div
</spicy-sections>

Currently what happens is that we just project all labels into the tab list slot and all content into the content slot, but manage visibility of the selected one... However, here, there is no way to select. Due to what is probably an error in our code, this results in the content appearing to be sort of 'in between' the two - content 1 is displayed always. However, if we hide it in that case we have content loss. In native summary details like cases, a default 'details' summary is provided in the shadow dom in that case. That would be impossible in our current approach and require a major overhaul, plus, a generic tab label is not useful either. What do you all think?