Other forms of sectionable content

[bkardell]

We debated a lot of things early in this, ultimately trying to settle on a few ideas we could solidify vs what we couldn't yet. A single element wrapper, good markup inside that is still good markup even if "there's no support" with a natural reading order, and nothing misleading in that case (a button that does nothing, or streams of run-on, unlabelled content. A key thing that limited this discussion was what was possible with shadow dom (only children can be projected into slots). Lots of other things seemed to make sense (more like Hixie's proposal) - acutal sections with headings, fieldsets and legends, maybe labelled lists or definition lists, or summary/details.

At some point we will have manually assignable slots which should (I think) allow descendants... I'd like to reconsider this at least verbally and whether we'll POC this (maybe even in a fork in chrome where I think it works with experimental features now?) because I do think there are cases where headings, which require numbers to get correct, are less than ideal.

[davatron5000]

ShadowDOM currently only supports direct children. But there are other elements used for sectioning content, or at least 'content that is labelled'. Cross-referencing with https://github.com/openui/open-ui/issues/412

Working with fieldset...

<spicy-sections>
  <fieldset id="billing">
    <legend>tab 1</legend>
    <p>content</p>
  </fieldset>
  <fieldset id="shipping">
    <legend>tab 3</legend>
    <p>content</p>
  </fieldset>
  <fieldset id="cc">
    <legend>tab 3</legend>
    <p>content</p>
  </fieldset>
</spicy-sections>

Working with details/summary...

<spicy-sections>
  <details>
    <summary>tab 1</summary>
    <p>content</p>
  </details>
  ...
</spicy-sections>

Any article, section, etc or other sectioning content.

<spicy-sections>
  <article>
    <h2>tab 1</h2>
    <p>lorem</p>
  </article>
  ...
</spicy-sections>

Definition Lists?

<spicy-sections>
  <dl>
    <div><!-- optional? -->
      <dt>tab 1</dt>
      <dd>content</dd>
    </div>
  </dl>
</spicy-sections>

Discussion

• @mirisuzanne Is this better as a spicy attribute on any "sectionable" content?
• @hidde Might be bad for a11y to allow more forms of content to be tabs/etc, better to restrict to certain elements that follow the label+content pattern (fieldset, etc).
• @bkardell Will modify our version to support <dl> usecase in a branch.
• https://tabatkins.github.io/css-toggle/
• Discussed Cascading Attribute Sheets
• @mirisuzanne "I will fix everything"

[scottaohara]

would this proposal destroy the semantics of the underlying elements. e.g., fieldset > legend, dl > dt + dd? Or would these elements continue to exist, unbroken, within the toggleable panels of content?

[hidde]

To me, ideally, it would be preferable to avoid destroying existing semantics, as they make useful navigation possible. I'm not sure if “browse by fieldset” is at thing like “browse by heading” is… but seems unnecessary to break that altogether for something that's fundamentally visible?

Another example we didn't list above could be a bunch of table's with their captions . Let's say, a couple of tables with financial results for different years that folks might want to navigate between using tabs, or using rotor-like interfaces in assistive technologies.

<table>
  <caption>Tab 1 - 2021 financial results</caption>
  <thead/>
  <tbody/>
</table>

<table>
  <caption>Tab 2 - 2020 financial results</caption>
  <thead/>
  <tbody/>
</table>

<table>
  <caption>Tab 3 - 2019 financial results</caption>
  <thead/>
  <tbody/>
</table>

[bkardell]

This is an excellent question @scottaohara, and one I don't have the answer to atm - I have a lot of thoughts tho. I'm keen to discuss it more and do some testing too. That said, I'm going to kind of blow past that for a minute in this issue (we can come back to it, maybe here or in another issue/discussions) and say that making the alternative forms we were discussing in this issue is not currently feasible in the way we were discussing, even in chromium. Imperative slotting currently only supports child elements too.

I mention that because it means that if you assume everything else with our custom element is 'ok' for a moment, and we knew the answer to those questions (either way) -- considering even trying to explore these opens several new cans of worms just to provide rough approximations --- I'm not sure it's reallly the the thing I'm inclined to to prioritize in terms of my own efforts in this repo... Idk, what do people think?

[scottaohara]

just got off a call to discuss this, among other things with @bkardell.

seems to me / us that it'd be a lot easier, and a lot less prone to errors (author errors, or breaking of semantic content - e.g., dl / tables getting broken apart, or unhelpful articles being added inside of tabpanels?) if this custom element stuck with a strict "use a heading to generate your tabs, or use this data-whatever attribute to indicate this div, or p will serve as the element that creates your tab label.

[rzhw]

Hey all, I wanted to chime in with another pattern that could be desirable, i.e. ​heading + subtitle + content, which according to HTML5 Doctor could be marked up as something like:

   ​<header>
     ​<h2>Title (I want to be a tab!)</h2>
     ​<p>I want to be a subtitle!</p>
   ​</header>
   ​<div>Hello I am content</div>

Which in its current form, wrapped in a <spicy-sections>, seems to result in nothing happening.

(By the way, I'm experimenting with spicy-sections in a real-world project over at google/osv#288. I'm aware that the issues section in this repo is being used for feedback, but felt creating a whole issue would've been too heavyweight. But so far I've found this project to work really, really well even in its current experimental form!)