Why “Just Adding Tabs to HTML” Isn’t So Simple
Brian Kardell has shared an update on the ongoing effort to bring native tabs to HTML. On the surface, it sounds easy — we all use tabs daily and know exactly what they look like. But specs require precise definitions, and that’s where things get complicated quickly.
Even if you settle on a solid definition, the markup expression isn’t obvious. There are several viable ways to structure tabs that each make their own kind of sense. One approach, the “Table of Contents” style, puts all the tab links in a row (as anchors or buttons) followed by the content panels below. It’s logical at a glance — the markup visually resembles tabs. But it has its downsides, and the alternative of using sections with headers seems more practical in practice. As Kardell points out, if you have the heading, you can build the TOC, but not the other way around.
Spicy sections are yet another pattern being explored. That’s just one issue the group is wrestling with — there are more ahead.
This work is hard to envy but easy to look forward to. Building tabs isn’t hard to do, but it’s very hard to do right. Too often, implementations are just a click handler on a row of links that shows or hides divs below — which works only if you completely ignore accessibility, including focus management, keyboard navigation, and ARIA expectations.
The problem gets more discussion on ShopTalk, and a different angle appears in a CodePen Radio chat where Stephen and I dive into CodePen’s own <Tabs /> React component.
