Web Components Guide
This new resource on Web Components from Keith Cirkel and Kristján Oddsson of GitHub (and friends) is looking great so far.
Nordhealth’s Design System
There’s so much to admire in Nord Health’s Design System and specifically its reference website.
Let's talk about web components (by Brad Frost)
Brad breaks down the good, bad and ugly of web components but also makes a compelling argument that we should get behind this technology.
I come from the Zeldman school of web standards, am a strong proponent of progressive enhancement, care deeply about accessibility, and want to do my part to make sure that the web lives up to its ideals. And I bet you feel similar. It’s in that spirit that I want to see web components succeed. Because web components are a part of the web!
WebC, the latest addition to the Eleventy suite of technologies, is focused on making Web Components easier to use. I have to admit, it took me a while to work out the idea behind this one, but I see it now and it looks interesting.
Web components as progressive enhancement, by Cloud Four
By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.
Great article by Paul Herbert of Oregon’s Cloud Four. Using a web component to enhance an existing HTML element such as
<textarea> (rather than always creating a custom element from scratch) feels very lean, resilient and maintainable.
Web Components with Declarative Shadow DOM via Lit and Eleventy
Here’s a new development in the Web Components story, and one that may have positive implications for resilience, performance and progressive enhancement.
Minimum Viable Web Component (by Zach Leatherman)
What open-source design systems are built with web components?
Alex Page, a Design System engineer at Spotify, has just asked:
What open-source design systems are built with web components? Anyone exploring this space? Curious to learn what is working and what is challenging. #designsystems #webcomponents
And there are lots of interesting examples in the replies.
My first Web Component: a disclosure widget
After a couple of years of reading about web components (and a lot of head-scratching), I’ve finally got around to properly creating one… or at least a rough first draft!
Front-end architecture for a new website (in 2021)
Just taking a moment for some musings on which way the front-end wind is blowing (from my perspective at least) and how that might practically impact my approach on the next small-ish website that I code.
Collapsible sections, on Inclusive Components
It’s a few years old now, but this tutorial from Heydon Pickering on how to create an accessible, progressively enhanced user interface comprised of multiple collapsible and expandable sections is fantastic. It covers using the appropriate HTML elements (buttons) and ARIA attributes, how best to handle icons (minimal inline SVG), turning it into a web component and plenty more besides.
HTML with Superpowers (from Dave Rupert)
Progressively enhanced burger menu tutorial by Andy Bell
Here’s a smart and comprehensive tutorial from Andy Bell on how to create a progressively enhanced narrow-screen navigation solution using a custom element. Andy also uses
Proxy for “enabled” and “open” state management,
ResizeObserver on the custom element’s containing
header for a Container Query like solution, and puts some serious effort into accessible focus management.
Container Queries in Web Components | Max Böck
Max’s demo is really clever and features lots of interesting web component related techniques.
I came up with this demo of a book store. Each of the books is draggable and can be moved to one of three sections, with varying available space. Depending on where it is placed, different styles will be applied to the book.
Ruthlessly eliminating layout shift on netlify.com, by Zach Leatherman
I love hearing about clever front-end solutions which combine technologies and achieve multiple goals. In Zach’s post we hear how Netlify’s website suffered from layout shift when conditionally rendering dismissible promo banners, and how he addressed this by rethinking the problem and shifting responsibilities around the stack.
Here’s my summary of the smart ideas covered in the post:
- decide on the appropriate server-rendered content… in this case showing rather than hiding the banner, making the most common use case faster to load
- have the banner “dismiss” button’s event handling script store the banner’s
hrefin the user’s localStorage as an identifier accessible on return visits
<head>… in this case a check for this banner’s identifier existing in localStorage
- under certain conditions – in this case when the banner was previously seen and dismissed – set a “state” class (
banner--hide) on the
<html>element, leading to the component being hidden seamlessly by CSS
- build the banner as a web component, the first layer of which being a custom element
- delegate responsibility for presenting the banner’s “dismiss” button to the same script responsible for the component’s enhancements, meaning that a broken button won’t be presented if that script were to break.
So much to like in there!
Here are some further thoughts the article provoked.
Web components FTW
It feels like creating a component such as this one as a web component leads to a real convergence of benefits:
- tool-free, async loading of the component JS as an ES module
- fast, native element discovery (no need for a
- enforces using a nice, idiomatic class providing encapsulation and high-performing native callbacks
- resilience and progressive enhancement by putting all your JS-dependent stuff into the JS class and having that enhance your basic custom element. If that JS breaks, you still have the basic element and won’t present any broken elements.
Even better, you end up with framework-independent, standards-based component that you could share with others for reuse elsewhere, just like Zach did.
I could see there being a case where there are multiple banners during the same time period. I guess in that situation the localStorage
banner value could be a stringified object rather than a simple, single-URL string.
Setting context on the root
It’s really handy to have a way to exert just-in-time control over the display of a server-rendered element in a way that avoids flashes of content… and adding a class to the
We’re already familiar with the technique of placing classes on the root element from libraries like modernizr and some font-loading approaches, but this article serves as a reminder that we can employ it whenever we need it.
Handling the close button
I think what Zach’s saying is that the alternatives – inserting the button with JS, or toggling the
hidden attribute or its CSS counterpart
display:none – would affect geometry causing the browser to perform layout… whereas modifying opacity does not.
If I were going down Zach’s route I think I’d replace
visibility since the latter hiding method removes the hidden element from the document which feels more accessible, while still avoiding triggering the reflow that
In a server-side scripted application – one using Rails or PHP, for example – you could alternatively handle persisting state with cookies rather than localStorage… allowing you to test for the presence of the cookie on the server then handle conditional rendering of the banner on the server too, rather than needing classes which trigger hiding. I can see an argument for that. Thing is though, not everyone’s working in that environment. Zach has provided a standalone solution.
- Zach’s Herald of the dog web component
- CSS Triggers of reflow and repaint
- Minimising layout thrashing
One web component to rule them all? (on Filament Group, Inc.)
Scott Jehl has taken a refreshingly Progressive Enhancement -centric look at Web Components.
this pattern provides a nice hook for adding progressive enhancements to already-meaningful HTML contained in these custom elements, leaving them resilient in the case of of script loading failures and allowing the page to start rendering before the JS happens to run.
Minimalist Container Queries
Scott Jehl’s experimental take on a container/element query aimed at letting us set responsive styles for our elements based on their immediate context rather than that of the viewport.
I made a quick and minimal take on approximating Container/Element Queries using a web component and basic CSS selectors.
See all tags.