A Tab Interface Before Its Time

A photo of a steampunk robot sitting in the corner of a dusty shed. It is covered in spider webs, dust, and is partially draped in a sheet. It looks a little rusty, but also looks like it could still work if given a little care.
Credit: Aaron Gustafson × DALL·E

I finally got around to reading the CSS Tricks piece on “Spicy Sections” and it’s cool how closely what the OpenUI folks are talking about aligns with work I was doing in the mid-to-late oughts.

Back in 2007, I built a little standalone JavaScript called TabInterface.js. I built it to generate tabbed interfaces using the natural document outline (h1-h6) to inform the UI. It only required that the author add a single wrapper to indicate the content could be converted into a tabbed interface. For example, given the following HTML:

<div id="recipe" class="tabbed">





You would use JavaScript to update the code to turn it into a tabbed interface:

.forEach(function( item, i ){
new TabInterface( item, i );

What I always loved about this approach was that it was the best of both worlds:

  • Semantic, strucutred content as the no-JS and print experience. This is great because JS isn’t a given and you really don’t want to have an interface look like tabs without behaving like them too.
  • Tabbed content when JS was available. The ideal experience, at least on desktop screens, but more on that in a moment.

I think the first talk I gave that included this was “Fundamental Progressive Enhancement,” which I delivered at Web Builder 2.0 in October of 2008. I also wrote about the approach in a 2-part article for Net Magazine (Part 1, Part 2) the following year.

Of course, that was all before media queries and responsive design. By the time that rolled around, I had begun recommending that folks only convert the interface to tabs when there was room for it and to un-tab if needed (like when a device is rotated).

Over the years, my approach continued to evolve to include

  • Testing to see if the tabs would even fit horizontally, considering the viewport width and length of the headings (TabInterface does support alternate, shorter markup-driven headings too).
  • Adapting to provide an accordion when horizontal space was scarce.
    • This could use details & summary, if supported or
    • div elements if not.

Anyway, it’s wild to see the idea finally beginning to get some traction in a broader sense. Clearly TabInterface was an idea before its time.


  1. “It’s cool to see ideas I was playing with over a dozen years ago starting to make it into new markup constructs.” – @AaronGustafson aaron-gustafson.com/notebook/a-tab…