This is excellent advice and I’m glad to see this getting addressed nice and early in the era of customisable select elements:
always provide text content or accessible text attributes for your option elements.
This is a great case study featuring a really useful HTML web component called validation-enhancer.
The results? When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures. It was a flood!
Fixed an issue on iOS and iPadOS where
datalistsuggestions were presented directly over the associated input, obscuring it.
I really like the thinking that goes into this approach. It seems so counter-intuitive at first, but there’s no arguing with the snappy resilient results.
Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.
This really gets to the heart of one of the biggest benefits of HTML web components: composability. You can nest your regular markup inside multiple custom elements; something that is can’t do.
The other exciting approach doesn’t exist yet: custom attributes. Again, they’d be a great way of using composability to turbo-charge your existing HTML in all sorts of ways.
This is such a brilliant idea! Why not allow an img element inside video element in order to provide a responsive, accessible poster image?
Here’s another nice progressive web component for your forms, this time for showing error messages.
Here’s an excellent progressive web component from Aaron—wrap a custom element around your exising form and your good to go:
At its core,
form-saveris a small web component that wraps a form, keeps an eye on it, stores values inlocalStorage, and restores them when the page loads again. Better yet, it clears out saved data after a successful submission so you’re not accidentally resurrecting stale information the next time someone stops by.
Web development follows a familiar cycle. First we glue together a solution with whatever we have — JavaScript, image hacks, Flash, anything. Then the platform matures, and CSS or HTML eventually makes that same workaround native. Rounded corners, custom fonts, smooth scrolling, sticky positioning: all of these started as JavaScript-heavy hacks before CSS turned them into a single declaration.
We are in another one of those transition moments. A new wave of long-requested CSS features is finally landing, and many of them are explicitly designed to replace patterns that used to require JavaScript. Not as approximations — as first-class platform primitives that handle the edge cases, run in the right thread, and need zero dependencies.
I’m slapping my forehead—progressive web components is a perfect name for what I’ve been calling HTML web components. Why didn’t I think of that?
A Progressive Web Component is a native Custom Element designed in two layers: a base layer of HTML and CSS that renders immediately, without JavaScript, and an enhancement layer of JavaScript that adds reactivity, event handling, and more advanced templating.
In my previous post, I mentioned that I’ve used the web install API in production. Specifically, I’ve used it on The Session. In order to do that, I had to register for the origin trial.
I’ve just signed up for another origin trial. This time it’s for the proposed focusgroup attribute:
The
focusgroupHTML attribute is a proposed declarative way to add keyboard arrow-key navigation to composite widgets such as toolbars, tablists, menus, listboxes, etc. without writing any roving-tabindex JavaScript. One attribute replaces hundreds of lines of boilerplate.
I’ve got an HTML web component on The Session called tab-controls. And yes, there’s a bunch of code in there to listen for keyboard events and respond appropriately. I would very much like to rip that code out.
So now that I’ve opted into the origin trial, I’ve added this to my HTML:
<tab-controls role="tablist" focusgroup="tablist">
If this focusgroup attribute takes off, I’ll be able to remove the role attribute but for now, it’s very much needed.
In the JavaScript for my tab-controls custom element, I need to be able to detect support for focusgroup. Here’s how I’m doing it:
if (!this.focusgroup) {
// do all my key handling stuff here
}
Here’s the important thing: don’t use getAttribute('focusgroup') to test for browser support. That will return true if the attribute is in the HTML. But the attribute will only get converted into a property if the browser understands it.
Jake has a lot more detail on the differences between attributes and properties.
Anyway, I figured I’d share that little snippet in case you too were interested in trying out the focusgroup proposal using progressive enhancement.
This is a clever technique for a CSS/HTML only way of just-in-time loading of iframes using details and summary.
This is an excellent one-stop shop of interface patterns:
This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.
This episode of the Shop Talk Show is the dictionary definition of “rambling” but I had a lot of fun rambling with Chris and Dave!
Well, this is horrifying.
The datalist element is all fucked up on iOS. Again.
I haven’t “upgraded” my iPhone to iOS 26 and I have no plans to. The whole Liquid Glass thing is literally offputting. So I wouldn’t have known about the latest regression in Safari if a friend hadn’t texted me about the problem.
He was trying to do a search on The Session. He was looking for the tune, The Road To Town. He started typing this into the form on the home page of the site. He got as far as “The Road To”. That’s when the entire input was obscured by a suggestion from the associated datalist.
This is incredibly annoying and seems to be a pattern of behaviour for Safari. Features are supported …technically. But the implementation is so buggy as to be unusable.
I’ll probably have to do some user-agent sniffing, which I hate. And it won’t be enough to just sniff for Safari on iOS 26. Remember that every browser on iOS is just Webkit in a trenchcoat.
Time to file a bug and then wait God knows how long for an update to get rolled out.
Update: I filed a bug, but in the meantime it looks like user-agent sniffing is going to be impossible.
Great minds think alike! I have a very similar HTML web component on the front page of The Session called input-autosuggest.
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
Spot-on observations from Terence linking the fundamental nature of parsing in web browsers with the completely wrong-headed takes of some technologists who have built on top of the web.