Tabs in HTML?
Please help us evaluate an idea!
I've fallen a bit behind on my podcast consumption (thanks to being very busy), but I was recently catching up during a drive in the car and was pleased to hear Dave Rupert and Chris Coyier having some good discussion on the Shop Talk Show episode 466 (time jumped to the start) about some work we've been doing and that we're looking for more opinions/thoughts on. Dave did a bang-up job explaining I think, but just trying to imagine it all might be a little difficult, so I wanted to share something a little more concrete, provide some context around it, and to re-iterate that "we'd like (need) your help in evaluating this idea ".
Show me something...
Imagine that you could have something that worked .... kind of like this (insert giant hand wavey motions): You write some good old HTML that looks just like HTML you write today, but are able to express that want you to sometimes treat it with different interaction affordances - just like the way scroll panes work on the Web today...
A running demo showing sections that gain tabset or collapse affordances as the screen resizes.
You should be able to load the demo in this video yourself in any browser...
Show me the demoIf you view the source of that page, you'll see there is just a single element that we have cleverly named <spicy-sections>.
Please check it out: It's very easy to try. Note that the actual syntax or way to express the association with interactive afforances is entirely up in the air. This custom element isn't a proposal itself. There are many efforts happening in parallel discussing precisely how this should (and shouldn't or can and can't) work, but the custom element should help you explore the ideas.
Play with it. Build something useful. Ask questions, show us your uses, give us feedback about what you like or don't. This will help us shape good and successful approaches and inform actual proposals. Question #1 is on the crux of the idea itself.
If the answer to "how do I get a native tabset in the browser?"" involved using 0...1 'new' elements (perhaps one to identify content which could fit these models) and some CSS (or CSS-like) means of expressing 'when'" - would you call that a win? Do you get it? Do you love it? Do you hate it? What are your questions?
A little background
There are lots of efforts around adding new elements to HTML - many of which are being coordiated through an effort in WICG called "Open UI". This effort involves browser implementers, developers, UI Toolkit makers, etc, and I think that's great. I really want the web to have a better set of tools for making basic UI and I hope that Open UI can show us a better way forward than we've done in the past.
To me, this means involving more people. It means meeting developers closer to where they are and giving them something useful to evaluate, to tighten the feedback loop and make sure we're able to course correct. But it also means that we should be producing things out in the open along the way that allow anyone to see how we even got to here. Proposals shouldn't lack a back-story or explantion, or seem like they appeared out of nowhere. There shouln''t be any things "you just have to trust us on".
So, that's what we're trying to do: A group of us have been looking at 'tabs' - and there is a reason we're asking. Chances are, I think, this won't match your first ideas about how the browser would get native support for tabs. It didn't match my own, in fact. I've built and used a lot of tabs over the last 20+ years, and never thought of it this way either. So, I wanted to add some context and explanation for the curious...
Step 1: Define Tabs?
I realize this sounds almost silly. In fact, when I asked the question "can we define 'tabs'" a friend replied to me...
You know what tabs are, Brian".
I mean... You use them every day, on every OS. Everybody knows they exist in every toolbox. All that's left is to "just pave the cowpaths!" But when you get right down to it, it's a lot more complicated than that.
Different "tabset" implementations have different features and different limits. All of them have changed and evolved over time. Today, most UI toolboxes have multiple APIs for creating things that users would just call "tabs" - and there are reasons for that. Sometimes these APIs are even the basis of things a user might not call tabs! In many cases, the APIs themselves aren't called "tabs" (or anything close to that). So, if we want to discuss these things (any components, really), we need to begin with a survey and lay down some clear definitions and goals. We laid this all out in this research identifying the parts and features in the landscape.
An interesting distinction
One thing which falls out this is an intesting distinction of 2 broad "kinds of tabset-like controls":
- One kind is actually a window manager. The tabs at the top of the browser you're looking at right now are windows that happen to be arranged visually as groups that look like tabs.
- Another kind manages exclusive display and focus management patterns of what are, effectively, sections within the same document that happen to look like tabs.
As end-users we probably don't think about this much, but it is a pretty important distinction actually and there are differences we understand commonly. In fact, so many expectations about both the shape of the UI and user interactions flow from this. Text searching happens in a window, not across windows, for example. Windows can be "dragged out" and displayed as, well, windows. The keyboard interactions and accessibility roles of windows are expected to be... windows. And so on.
For our purposes, we have chosen to focus primarily on the ltter kind which are prevalent in UI kits for the Web.
Markup and APIs
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.
To illustrate this, we have also collected a bunch of research showing all sorts of variants over the years and various dissected pros and cons of each.
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..
Attributes?
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.
TOC Style?
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 <summary> and <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.