What if HTML had “tabs”? That would be cool, says I. Dave has been spending some of his time and energy, along with a group of “Tabvengers” from OpenUI, on this. A lot of research leads to a bit of a plot twist:
Our research showed there are a lot of variations for what makes up a tab control. There’s a lot of variations in markup patterns as well. There’s variations written in operating systems, video games, jQuery, React components, and web components. But we think we’ve boiled some of this ocean and have come to a decent consensus on what might make for a good
<tabs>
element… and it isn’t<tabs>
!!!
It kinda comes down to design affordances. Sure, the type of UI that looks like literal paper manilla folders is one kind of design affordance. But it’s functionally similar to a one-at-a-time accordion. And accordions are fairly similar to <details>
/<summary>
elements — so maybe the most helpful thing HTML could do is allow us to use different design affordances, and perhaps even switch between them as needed (say, at different widths).
Then the question is, what HTML would support all those different designs? That actually has a pretty satisfying answer: regular ol’ header-based semantic HTML, so like:
<h2>Header</h2>
<p>Content</p>
<h2>Header</h2>
<p>Content</p>
<h2>Header</h2>
<p>Content</p>
Which means…
- The base HTML is sound and can render just fine as one design choice
- The headers can become a “tab” it that particular design
- The headers can become a “summary” in that particular design
This is the base of what the Tabvengers are calling <spicy-sections>
. Just wrap that semantic HTML in the web component, and then use CSS to control which type of design kicks in when.
<spicy-sections>
<h2>Header</h2>
<p>Content</p>
<h2>Header</h2>
<p>Content</p>
<h2>Header</h2>
<p>Content</p>
</spicy-sections>
spicy-sections {
--const-mq-affordances:
[screen and (max-width: 40em) ] collapse |
[screen and (min-width: 60em) ] tab-bar;
display: block;
}
Brian Kardell made up an example:
I made one as well to get a feel for it:
Here’s a video in case you’re in a place you can’t easily pop over and resize a browser window to get a feel yourself:
This is a totally hand-built Web Component for now, but maybe it can ignite all the right conversations at the spec-writing and browser-implementing levels such that we get something along these lines in “real” HTML and CSS one day. I’d be happy about that, as that means fewer developers (including me) having to code “tabs” from scratch, and probably screw up the accessibility along the way. The more of that, the better.
If you’d like to hear more about all this, check out ShopTalk 486 at 15:17. Plus here’s some exploration from Hidde de Vries. And if you’re interested in more about Web Components and how they can be gosh-darned useful, not only for things like this, but much more in Dave’s recent talk HTML with Superpowers.
Nice.
The markup pattern you’ve used is similar to what I use in our component library:
And on mobile / smaller screens, the visual appearance turns the tabs into accordions.
[screen and (max-width: 40em) ] collapse |
[screen and (min-width: 60em) ] tab-bar;
Is there more information anywhere on the use of square brackets here?
This article reminded me to update a responsive accordion / tab test I did a couple of years ago to try and simplify a tabbed interface.
Have updated what I originally came up with a while back with grid[ish] and content based growth, today at: https://codepen.io/frownonline/pen/KNLPOg
Why there isn’t a native tab [or responsive menu toggle element like details / summary] yet, still eludes me. Resorting to scripts to do these fundamental controls seems hacky to me [even if the JS is efficient & elegant].
Hi Frown,
This looks good to me – not an expert. What do you mean when you say ‘Needs refinement’?
PB