This is an interesting thought from Scott: using Shadow DOM in HTML web components but only as a way of providing sort-of user-agent styles:
providing some default, low-specificity styles for our slotted light-dom HTML elements while allowing them to be easily overridden.
Three great examples of HTML web components:
What I hope is that you now have the same sort of epiphany that I had when reading Jeremy Keith’s post: HTML Web Components are an HTML-first feature.
So many of the problems and challenges of working with Web Components just fall away when you ditch the shadow DOM and use them as a light wrapper for progressive enhancement.
Some lovely HTML web components—perfect for progressive enhancement!
Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”
HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.
Design systems should hope for the same.
Laying out sheet music with CSS grid—sounds extreme until you see it abstracted into a web component.
We need fluid and responsive music rendering for the web!
More thoughts on naming web components.
When I documented my approach to HTML web components I sang the praises of composability:
Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes.
I feel the same way about design systems. In my experience, the design systems that encourage mixing and matching different combinations are the ones that actually get used.
The design systems that struggle with adoption often have the best of intentions. “Look, there are all these pre-made components for you—you should just use them!” But that can be very disempowering. Where’s the sense of agency in using a pre-made solution?
Robin wrote a fascinating post recently called The Other Side (almost certainly not a reference to the Salter Cane song of the same name). He went from being on a design system team trying to enforce adoption to being on a team on the receiving end:
I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.
But by golly if a design system says “no” to me then I will do my very best to blow it up.
Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!
It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.
There’s a tired cliché of an analogy when it comes to design systems: LEGO. It’s not a good analogy but I think it can help to understand this imbalance.
Remember old-school LEGO? The pieces were unopinionated. You had to use your imagination to combine them into something.
Later we got LEGO kits. You followed instructions to create a pre-ordained final combination.
I’m not just being an old man yelling at a cloud when I say that those later sets were different. Not bad, necessarily. But the fun came from cosplaying as a factory worker rather than inventing from whole cloth.
There are certainly organisations where pre-made kits are going to be useful. But when you start mandating their use, don’t be surprised when you get pushback from designers who miss the combinatorial power of using simple building blocks. As Robin says:
I want the design system to carefully guide me instead of brute-forcing its decisions onto my work.
Brad recently wrote about the art of design system recipes. Recipes are combinations of the building blocks in a design system, but they’re not intended to be The One True Way for everyone else solving a similar problem. It’s totally fine if a recipe is a one-off solution.
The design system’s core components are the ingredients stocked in the pantry. Other product designers then take those ingredients to create product-specific compositions that meet their product needs.
I suspect that a lot of design systems have made the mistake of canonising recipes too soon, mandating their use.
A Darwinian approach works better. If multiple people keep creating the same recipe independently then and only then should it be considered for inclusion in the design system.
A design system team should be reluctant to allow a new component into the inner sanctum. Instead I see design system teams eager to mint as many ready-made components as possible.
But if the true test of a design system is in its adoption, then the safest bet is to stick to the basic building blocks. Support designers by taking care of their baseline needs. But don’t stop them from composing.
I’ve been deep-diving into HTML web components over the past few weeks. I decided to refactor the JavaScript on The Session to use custom elements wherever it made sense.
I really enjoyed doing this, even though the end result for users is exactly the same as before. This was one of those refactors that was for me, and also for future me. The front-end codebase looks a lot more understandable and therefore maintainable.
Most of the JavaScript on The Session is good ol’ DOM scripting. Listen for events; when an event happens, make some update to some element. It’s the kind of stuff we might have used jQuery for in the past.
Chris invoked Betteridge’s law of headlines recently by asking Will Web Components replace React and Vue? I agree with his assessment. The reactivity you get with full-on frameworks isn’t something that web components offer. But I do think web components can replace jQuery and other approaches to scripting the DOM.
I’ve written about my preferred way to do DOM scripting: element.target.closest. One of the advantages to that approach is that even if the DOM gets updated—perhaps via Ajax—the event listening will still work.
Well, this is exactly the kind of thing that custom elements take care of for you. The connectedCallback method gets fired whenever an instance of the custom element is added to the document, regardless of whether that’s in the initial page load or later in an Ajax update.
So my client-side scripting style has updated over time:
event.target.closest.None of these progressions were particularly ground-breaking or allowed me to do anything I couldn’t do previously. But each progression improved the resilience and maintainability of my code.
Like Chris, I’m using web components to progressively enhance what’s already in the markup. In fact, looking at the code that Chris is sharing, I think we may be writing some very similar web components!
A few patterns have emerged for me…
Naming things is famously hard. Every time you make a new custom element you have to give it a name that includes a hyphen. I settled on the convention of using the first part of the name to echo the element being enhanced.
If I’m adding an enhancement to a button element, I’ll wrap it in a custom element that starts with button-. I’ve now got custom elements like button-geolocate, button-confirm, button-clipboard and so on.
Likewise if the custom element is enhancing a link, it will begin with a-. If it’s enhancing a form, it will begin with form-.
The name of the custom element tells me how it’s expected to be used. If I find myself wrapping a div with button-geolocate I shouldn’t be surprised when it doesn’t work.
You can use any attributes you want on a web component. You made up the name of the custom element and you can make up the names of the attributes too.
I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.
So I use data- attributes. I’ve already got a hyphen in the name of my custom element, so it makes sense to have hyphens in my attributes too. And by using data- attributes, the browser gives me automatic reflection of the value in the dataset property.
Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.
My favourite web components aren’t all-singing, all-dancing powerhouses. Rather they do one thing, often a very simple thing.
Here are some examples:
aria-collapsable for toggling the display of one element when you click on another.play-button for adding a play button to an audio or video element.ajax-form for sending a form via Ajax instead of a full page refresh.user-avatar for adding a tooltip to an image.table-saw for making tables responsive.All of those are HTML web components in that they extend your existing markup rather than JavaScript web components that are used to replace HTML. All of those are also unambitious by design. They each do one thing and one thing only.
But what if my web component needs to do two things?
I make two web components.
The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.
What if you’ve got some text that you want to be a level-three heading and also a link? You don’t bemoan the lack of an element that does both things. You wrap an a element in an h3 element.
The same goes for custom elements. If I find myself adding multiple behaviours to a single custom element, I stop and ask myself if this should be multiple custom elements instead.
Take some of those button- elements I mentioned earlier. One of them copies text to the clipboard, button-clipboard. Another throws up a confirmation dialog to complete an action, button-confirm. Suppose I want users to confirm when they’re copying something to their clipboard (not a realistic example, I admit). I don’t have to create a new hybrid web component. Instead I wrap the button in the two existing custom elements.
Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes. And it has the added benefit of stopping my code getting too complex and hard to understand.
Okay, so I’ve broken all of my behavioural enhancements down into single-responsibility web components. But what if one web component needs to have awareness of something that happens in another web component?
Here’s an example from The Session: the results page when you search for sessions in London.
There’s a map. That’s one web component. There’s a list of locations. That’s another web component. There are links for traversing backwards and forwards through the locations via Ajax. Those links are in web components too.
I want the map to update when the list of locations changes. Where should that logic live? How do I get the list of locations to communicate with the map?
When a list of locations is added to the document, it emits a custom event that bubbles all the way up. In fact, that’s all this component does.
You can call the event anything you want. It could be a newLocations event. That event is dispatched in the connectedCallback of the component.
Meanwhile in the map component, an event listener listens for any newLocations events on the document. When that event handler is triggered, the map updates.
The web component that lists locations has no idea that there’s a map on the same page. It doesn’t need to. It just needs to dispatch its event, no questions asked.
There’s nothing specific to web components here. Event-driven programming is a tried and tested approach. It’s just a little easier to do thanks to the connectedCallback method.
I’m documenting all this here as a snapshot of my current thinking on HTML web components when it comes to:
I may well end up changing my approach again in the future. For now though, these ideas are serving me well.
Snook’s Law in action:
Big, flashy things get noticed. Quiet, boring things don’t.
There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.
A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here.
Those HTML web components I made for date inputs are very simple. All they do is slightly extend the behaviour of the existing input elements.
This would be the ideal use-case for the is attribute:
<input is="input-date-future" type="date">
Alas, Apple have gone on record to say that they will never ship support for customized built-in elements.
So instead we have to make HTML web components by wrapping existing elements in new custom elements:
<input-date-future>
<input type="date">
<input-date-future>
The end result is the same. Mostly.
Because there’s now an additional element in the DOM, there could be unexpected styling implications. Like, suppose the original element was direct child of a flex or grid container. Now that will no longer be true.
So something I’ve started doing with HTML web components like these is adding something like this inside the connectedCallback method:
connectedCallback() {
this.style.display = 'contents';
…
}
This tells the browser that, as far as styling is concerned, there’s nothing to see here. Move along.
Or you could (and probably should) do it in your stylesheet instead:
input-date-future {
display: contents;
}
Just to be clear, you should only use display: contents if your HTML web component is augmenting what’s within it. If you add any behaviours or styling to the custom element itself, then don’t add this style declaration.
It’s a bit of a hack to work around the lack of universal support for the is attribute, but it’ll do.
I had the opportunity to trim some code from The Session recently. That’s always a good feeling.
In this case, it was a progressive enhancement pattern that was no longer needed. Kind of like removing a polyfill.
There are a couple of places on the site where you can input a date. This is exactly what input type="date" is for. But when I was making the interface, the support for this type of input was patchy.
So instead the interface used three select dropdowns: one for days, one for months, and one for years. Then I did a bit of feature detection and if the browser supported input type="date", I replaced the three selects with one date input.
It was a little fiddly but it worked.
Fast forward to today and input type="date" is supported across the board. So I threw away the JavaScript and updated the HTML to use date inputs by default. Nice!
I was discussing date inputs recently when I was talking to students in Amsterdam:
They’re given a PDF inheritance-tax form and told to convert it for the web.
That form included dates. The dates were all in the past so the students wanted to be able to set a max value on the datepicker. Ideally that should be done on the server, but it would be nice if you could easily do it in the browser too.
Wouldn’t it be nice if you could specify past dates like this?
<input type="date" max="today">
Or for future dates:
<input type="date" min="today">
Alas, no such syntactic sugar exists in HTML so we need to use JavaScript.
This seems like an ideal use-case for HTML web components:
Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.
In this case, it would be nice to augment an existing input type="date" element. Something like this:
<input-date-past>
<input type="date">
</input-date-past>
Here’s the JavaScript that does the augmentation:
customElements.define('input-date-past', class extends HTMLElement {
constructor() {
super();
}
connectedCallback() {
this.querySelector('input[type="date"]').setAttribute('max', new Date().toISOString().substring(0,10));
}
});
That’s it.
Here’s a CodePen where you can see it in action along with another HTML web component for future dates called, you guessed it, input-date-future.
See the Pen Date input HTML web components by Jeremy Keith (@adactio) on CodePen.
Robin describes his experience of using a design system, having previously been one of the people making and enforcing a design system:
However it’s only now as a product designer that I realize just how much I want the design system to carefully guide me instead of brute-forcing its decisions onto my work. I want to fall into the loving embrace of the system because I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.
But by golly if a design system says “no” to me then I will do my very best to blow it up.
I somehow missed this when it came out in January but Amber just pointed me to it—an interview with Chris about HTML web components, available for your huffduffing pleasure.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
This is a good description of the appeal of HTML web components:
WC lifecycles are crazy simple: you register the component with
customElements.defineand it’s off to the races. Just write a class and the browser will take care of elements appearing and disappearing for you, regardless of whether they came from a full reload, a fetch request, or—god forbid—adocument.write. The syntax looks great in markup, too: no more having to decorate withjs-somethingclasses or data attributes, you just wrap your shit in a custom element calledsomething-controllerand everyone can see what you’re up to. Since I’m firmly in camp “progressively enhance or go home” this fits me like a glove, and I also have great hopes for Web Components improving the poor state of pulling in epic dependencies like date pickers or text editors.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
Isn’t this a lovely little HTML web component? All it does is hook up a button element with an audio or video element: exactly the kind of discrete drudge work that’s good to automate away.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
The power of interoperability:
Web components won’t take web development by storm, or show us the One True Way to build websites. They don’t need to dethrone JavaScript frameworks. We probably won’t even all learn how to write them!
What web components will do — at least, I hope — is let us collectively build a rich ecosystem of dynamic components that work with any web stack. No more silos. That’s the web component success story.