Home / Newsletters /

#281: Tabs and Spicy Drama

[Robin]: If you want to make a tab component today then you have to either

  1. Make your own custom tabs — which is a faff because making them is not easy at all or,
  2. Just npm install something popular.

Although, every project I’ve worked on in the last decade has its own custom tabs component—and to me that always feels like a waste. We keep reinventing the wheel over and over again!

So why isn’t there an HTML element to help us out here? Why isn’t there a <tabs> element that could do all the basics for us and make sure we’re doing things accessibly without having to build everything from scratch each time. The drama!

Dave Rupert wrote all about native HTML tabs back in October:

For the past year I’ve been on a team of folks inside Open UI dedicated to figuring out how get a native, accessible element into HTML. We’re a team of people with varying backgrounds; spec authors, browser vendors, implementors, and normie practitioners like myself. Open UI is a community group so we can’t technically make HTML (for legal reasons), but we can present research to the W3C working groups. I see Open UI as an ad hoc research arm for the W3C with specific experience in design systems and common web componentry.

Exciting! Except so far they’ve come to the conclusion that we don’t need a native <tabs> element in HTML at all. Their solution right now? spicy-sections, a web component that wraps any markup you’ve written and gives you a custom property that lets you change the component based on the width of the browser.

Chris made a real good example of this where it started to click for me. First, you need to import the custom element like this:

<script type="module" src="/SpicySections.js"></script>

And then wrap it around your HTML…

<spicy-sections>
  <!-- any heading here, followed by an element containing content -->
  <h2>Ingredients</h2>
  <div>A list of ingredients</div>

  <!-- repeat the pattern... -->
  <h2>Instructions</h2>
  <div>A list of instructions</div>
</spicy-sections>

Then you can use a CSS custom property built into <spicy-sections> which tells it how to behave and—watch out—this CSS I’m about to show you looks weird as heck:

spicy-sections {
  --const-mq-affordances:
    [screen and (max-width: 40em) ] collapse |
    [screen and (min-width: 60em) ] tab-bar;
  display: block;
}

Weird! But also, that kiiinda makes sense to me. What’s happening here is you’re setting props for that web component and toggling between collapse and tab-bar when the browser meets those min-width/max-width conditions. Here’s an example Chris made where the largest browser width looks like this…

Great, we have tabs. Lovely. Next up, at smaller sizes, we have something like this where the content breaks out of the tabs into each of their own sections…

And then finally, at mobile-ish sizes, we have the following design where you can click each of these sections to pop them open…

I love this but I have a ton of questions. First up, it’s probably not going to be called <spicy-sections> when, and or if, it lands in browsers eventually. So what will it be called? Also, I’m not entirely sure I understand the greater implications on the rest of the HTML language here. Like, does this open up other doors to other features like tabs?

Oh, one last note: this chat between Dave and Chris all about <tabs> and this spicy-sections stuff is very much worth listening to if you’re more interested in all this.

? Google Fonts Knowledge

Well, this sure looks like a neat repository for all things fonts: Google Fonts Knowledge. It has a ton of in-depth examples on how to improve your typography skills and covers everything from choosing fonts to the nitty-gritty details of making paragraphs real good. Perhaps my favorite bit of typographic advice here though is a post that explores how to pick the right number for the job.

See the differences here? Each type of number has a very specific job and learning the differences will help our interfaces out a whole bunch.

? Where am I?

Telling users where they currently are should be the top priority of any bit of software. Where you are in terms of content (subheadings and good typography) where you are in terms of navigation (homepage, subpage, breadcrumbs, etc.) and where you are on the current page (selected items, focus states and the like).

Videogames are real bad at this. Whenever I use a menu in a videogame I feel adrift at sea, lost without a sail. It’s not clear what item I have selected or how to go back to a previous section or where to find the thing I’m looking for.

This is true of websites as well. I feel like we’re still collectively getting out of this culture of poor accessibility when we all decided that focus states are for nerds. Clicking or tabbing onto an input for example might just add a slight box-shadow to it.

Stephanie Eckles says heck no to all this:

Take two minutes right now and visit your current project in a browser. Then, using only the Tab key, you should be able to navigate between interactive elements including buttons, links, and form elements.

If you are sighted, you should be able to visually follow the focus as it jumps between elements in the DOM. But if you do not see any visual change, or only a barely noticeable visual change, then you’ve found the one thing you can do to make a big difference for your visitors.

I completely agree: I think these visual changes should be extreme and it should be painfully obvious what you’ve selected as you move around a bit of software.

1?? What is one thing people can do to make better websites?

“Help users accomplish what they came for,,” says Anna Migas:

Over the years, new browser capabilities and the tech stack have made it possible to add more and more complexity to an average website. We see it everywhere: in pages presenting the product, in booking services, in portfolios, and in online shops. We try to delight the user instead of focusing on one simple task: helping the user accomplish what they came to do.

All visual effects, fancy graphics, beautiful interactions, and tracking scripts should come second.

I worked for a place once where folks kept using the word “delight” when it comes to design and it always bugged me. They’d keep asking me to make the design “delightful” by adding bigger colors, flashier graphics, big illustrations. But to me, delight is nothing fancy. Instead, great software is everything working as I expect it to. Fast, efficient, no junk. So Anna reminds me that you can’t make things delightful on the surface without fixing all the problems under the hood.

Also, I loved this bit, where Anna writes:

I challenge you to take time to look at your website as if it was your first time around.

That’s real hard! I still struggle with this, trying to see an interface I’ve made as if I wasn’t the one who made it. Sure, all these things on the screen make sense to me (where I have all the context in the world). But what about everyone else?

?? enterkeyhint

I missed this one: a good while back Stefan Judis mentioned the enterkeyhint attribute is available in browsers and lets you configure the submit button text like “Done” or “Search” in mobile browsers:

And you can use it like this:

<input type="text" name="name" enterkeyhint="done">

You can’t just throw any old text into that attribute though. There’s a list of text options that you can put in there right now, like done, next, previous, etc. But it’s still handy. Also it’s available in Firefox now! Neat stuff.

A developer’s guide to headless commerce

Want to offer an e-commerce experience that’s truly as unique as your business? With Ecwid’s headless commerce options, now you can! Let customers shop and check out on your website without being tied to a specific front end or user interface while still offering Ecwid’s powerful e-commerce know-how. See how headless commerce can transform your business!

Check out the free guide

A developer’s guide to headless commerce

Netlify recently launched the Netlify Jamstack Innovation Fund and are planning to invest $10 million in early stage startups building for the Jamstack ecosystem, and combining advisory programs to help them build a better business. It’s a big bet, but we’re doing this because the success of these companies is our success. The Jamstack requires a thriving ecosystem. We win together.

Apply now

[Chris]: Vinegar is a Safari extension (works across macOS/iPadOS/iOS) that removes the YouTube default player and replaces it with an HTML <video> tag. Pretty much, anyway, I see some additional UI sugar there where it lets you pick a resolution and stuff. Its existence is a pretty damning indictment of the YouTube player. Doesn’t custom players exist to enhance what the web can do by default? But by restoring the HTML native experience, Vinegar actually brings features back, like picture-in-picture and AirPlay options, while blocking ads and preventing (some) tracking.

The ads thing here seems like a pretty big deal. YouTube ads are pretty annoying and the fact that a two-dollar extension can entirely block them is a good deal. I pay for YouTube Premium ($11.99) a month, and even that annoys me because it only works for my personal account. Even if I ponied up the $17.99 for a family plan to share it across accounts, it wouldn’t work for me because you can’t share that with like “brand” accounts or whatever. So whenever I’m logged into YouTube as CSS-Tricks or CodePen, I still get ads, and I either just have to deal with it or do the account switching dance all the time. I’ll take a Chrome extension, please.

But I wonder… will I really like Vinegar long-term? The default YouTube player, while it does shovel ads at me and surely tracks my every movement, does offer other functionality. For example, I do that thing where you right-click the video nubbie and “Copy video URL at current time” quite a bit, so that would be gone. The option to kick the video down to the mini-player or toggle the “theater mode” UI is gone. The auto-play toggle is gone. I’m sure there is other stuff. Did you know you can double-tap the right side of the video to go ahead 10 seconds on mobile?

I’m not trying to convince you to that you should or shouldn’t use Vinegar. I’m just curious what the percentage of people is that, even after trying it, end up going back, and why. Was it one tiny little thing that got you?

I was thinking about this in the context of another third-party intervention on a major website: Modern for Wikipedia. Looks great right?

It’s free, but pardon me as I look a gift horse in the mouth. I lasted less than a day with it installed. As I visited pages (both randomly and specific, as a typical day is for me) there were scrollbars in weird places, styling edge cases where things were awkwardly aligned, and places where the fundraising UI boxes on the page would squish the content columns so narrow it was one-word-per line. The dark modes didn’t take well on many pages. I started to miss some of the options in the sidebar I was used to. In the end, I just flipped it off.

It’s not that they didn’t do a good job. They did 10 times better than I’d ever manage to get done reskinning the entirety of Wikipedia. Therein lies the problem, it’s too big of a job to do from the outside as a free side project. That’s why companies have entire internal design teams. They spend all day every day smoothing out the rough edges and improving the experience of actually using the product. You might be able to do better, but it’s a tall order.