I’m interested by Shoelace’s MO as a collection of pre-rolled, customisable web components. The idea is that it lets individuals and teams start building with web components – components that are web-native, framework-agnostic and portable – way more quickly.
I guess it’s a kind of Bootstrap for web components? I’m interested to see how well it’s done, how customisable the components are, and how useful it is in real life. Or if nothing else, I’m interested to see how they built their components!
It’s definitely an interesting idea.
This new resource on Web Components from Keith Cirkel and Kristján Oddsson of GitHub (and friends) is looking great so far.
There’s so much to admire in Nord Health’s Design System and specifically its reference website.
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!
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.
Here’s a new development in the Web Components story, and one that may have positive implications for resilience, performance and progressive enhancement.
Alex Page, a Design System engineer at Spotify, has just asked:
And there are lots of interesting examples in the replies.
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!
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.
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.
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.
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.
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.
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.
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.