Again, it feels like it shouldn’t be difficult to pave these paths into markup. However, even in systems without markup, the shape of APIs varies pretty considerably. Translating this to markup adds a new set of challenges. There isn’t a clear/self evident mapping to DOM/markup at all – and whatever decisions we make somehow dictate something about how APIs should work on the web.
Some things we thought were important…
We thought it is worth thinking about progressive enhancement. Support for new features generally rolls out unevenly (we only got the last support for summary/details about a year ago, for example). This means that for potentially a long time, some browsers may not have support for native tabs.
But that’s only part of the story: When you consider “other browsers” – things like embedded devices which update more slowly still, or search engines or reader modes… What happens to content?
Further, we’d would like to test out any theory with a custom element (as above), and the script can fail to download. In fact, these things seem to dovetail nicely. We’d like the content to be “good” even if script for some reason doesn’t execute in that case.
This fed into roads we didn’t go down..
One popular approach involves putting the tab’s “label” as an attribute. That has a lot of really nice qualities, but it falls down on a number of other points. Without support (including all of those cases above), users would be left with information loss and a wall of run-on and unlabelled content. This also has pretty extreme limitations on what can be put into a tab label. No additional elements means no ruby text, for example, or interesting icon treatments or stylistic markup or structured text of any kind. So, we suggest that attributes for labels are not our first choice.
Another very popular set of solutions involves “table of contents (TOC) style” markup. These draw a parallel which equates tab labels to items in a table of contents. In fact, over the years this sort of pattern has been popular with progressive enhancement enthusiasts because you can use a list of links. The markup itself even “looks like tabs” already. It’s probably surprising then that this isn’t our first choice – why?
The short answer is that there are some fundamental flaws in this analogy which have impacts. Tables of contents are an enhancement of headings, not a replacement for them. That is, they are generally built based on headings that label content and simply repeated/reflected earlier. Without these already in place, the un-enhanced content is just a wall of unbroken text without labels. It’s almost exactly the same issue as attribute style. While it’s possible to repeat the headings too, why repeat yourself? If you have the heading, you can build the TOC, but not vice-versa.
Similarly, the argument that “the markup looks like tabs already” is less than perfect. As our research shows, tabset labels can exist along any axis, or even around the circumference of a circle. If you look at it just slightly differently, they can perhaps even be interleaved in the content (‘responsive tabs’ do this, and at one point ARIA’s “single select accordions” were also tabs).
So, we suggest TOC-style isn’t our first choice either.
A tabset element?
All of this helps shine light on some interesting questions and led to my post Design Afforance Controls which talks about why the way we approach this matters. It holds up flaws in the inherent control-specific-ness of
<details> and contrasts this with the fact that we don’t have a
<scrollpane> element – but rather employ those affordances when they make sense.
If a thing’s fundamental, primary “nature” is just “good sections”, don’t we often want to change our minds on presentation based on things like media or design? It’s worth considering.
So, it’s not that we shouldn’t have an element specifically for tabs as much as “isn’t this maybe more useful”?
What do you think?
Please let us know what you think about the ideas here! If you could provide “just good content” and have pretty much full stylistic control, and use CSS to express what kind of “showey/hidey” control it should be/when… How would you feel about that? Do you “get it”? Do you “buy the arguments”? Or are we just barking up the wrong tree? Your feedback will help inform how we discuss or advocate for things next in OpenUI to move things forward.
Mentions do not imply endorsements, but many thanks to folks who proofread this post, met along the way, helped research, had discussions, and did work. Very special thanks especially @jon_neal @TerribleMia and @davatron5000 for many thoughtful discussions.