I’m on Team Dave.
I’m on Team Dave.
Three technologies that Ada is excited about:
In which Brian takes a long winding route through an explanation of why the
is attribute for custom elements is dead before he demonstrates the correct way to use web components:
<!-- instead of writing this --> <input type="radio" is="x-radio"> <!-- you write this --> <x-radio> <input type="radio"> </x-radio>
Sadly, none of the showcase examples I’ve seen for web components do this.
I think this is the best delivery of this talk I’ve ever given. It was something about being in that wonderful venue.
I got quite worked up around the the 32 minute mark.
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
At the 14 minute mark I had to deal with an obstreperous member of the audience. He wasn’t heckling exactly …he just had a very bad experience with web components, and I think my talk was triggering for him.
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Monica explains how Shadow DOM could be the perfect answer for scoping CSS:
Although, in a way, Shadow DOM is also another flavour of CSS-in-JS:
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
A really great introduction to web components by Monica. But I couldn’t help but be disheartened by this:
Web components tend to have dependencies on other web components, so you need a package manager to herd all them cats.
For me, this kind of interdependence lessens the standalone nature of web components—it just doesn’t feel quite so encapsulated to me. I know that this can be solved with build tools, but now you’ve got two problems (and one more dependency).
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown> ## Render some markdown! </ah-markdown>
I spoke my brains in this podcast episode, all about web components, progressive enhancement and backwards compatibility.
An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.
It’s good to see that the examples have some thought given to fallback content.
There’s also a corresponding tutorial on custom elements
Adam Onishi has written up his thoughts on web components and progressive enhancements, following on from a discussion we were having on Slack. He shares a lot of the same frustrations as I do.
Two years ago, I said:
I have conflicting feelings about Web Components. I am simultaneously very excited and very nervous.
I still feel that way. In theory, web components are very exciting. In practice, web components are very worrying. The worrying aspect comes from the treatment of backwards compatibility.
It all comes down to the way custom elements work. When you make up a custom element, it’s basically a
One of the proposed ways around this was to allow custom elements to extend existing elements (not just
spans). The proposed syntax for this was an
Browser makers responded to this by saying “Nah, that’s too hard.”
To be honest, I had pretty much given up on the
is functionality ever seeing the light of day, but Monica has rekindled my hope:
@adactio I will go to every standards meeting until I get it done, because otherwise we are hosed for <form> and web components.— Monica Dinosaurescu (@notwaldorf) June 16, 2016
class FancySelect extends HTMLSelectElement
is attribute and extending existing elements …before carrying as though those two minutes never happened.
But even without any means of extending existing elements, it should still be possible to define custom elements that have some kind of fallback in non-supporting browsers:
<fancy-select> <select>...</select> </fancy-select>
In that situation, you at least get a regular ol’
Adam has a great example of this in his post:
I’ve been thinking of a gallery component lately, where you’d have a custom element, say <o-gallery> for want of a better example, and simply populate it with images you want to display, with custom elements and shadow DOM you can add all the rest, controls/layout etc. Markup would be something like:
<o-gallery> <img src=""> <img src=""> <img src=""> </o-gallery>
If none of the extra stuff loads, what do we get? Well you get 3 images on the page. You still get the content, but just none of the fancy interactivity.
Yes! This, in my opinion, is how we should be approaching the design of web components. This is what gets me excited about web components.
Then I look at pretty much all the examples of web components out there and my nervousness kicks in. Hardly any of them spare a thought for backwards-compatibility. Take a look, for example, at the entire contents of the
body element for the Polymer Shop demo site:
This seems really odd to me, because I don’t think it’s a good way to “sell” a technology.
Compare service workers to web components.
First of all, ask the question “who benefits from this technology?” In the case of service workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.
The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”
Service workers work well and fail well. If a browser supports service workers, the user gets all the benefits. If a browser doesn’t support service workers, the user get the same experience they would have always had.
Web components (will) work well, but fail badly. If a browser supports web components, the user gets the experience that the developer has crafted using these new technologies. If a browser doesn’t support web components, the user gets …probably nothing. It depends on how the web components have been designed.
It’s so much easier to get excited about implementing service workers. You’ve literally got nothing to lose and everything to gain. That’s not the case with web components. Or at least not with the way they are currently being sold.
See, this is why I think it’s so important to put some effort into designing web components that have some kind of fallback. Those web components will work well and fail well.
Look at the way new elements are designed for HTML. Think of complex additions like
picture. Each one has been designed with backwards-compatibility in mind—there’s always a way to provide fallback content.
Web components give us developers the same power that, up until now, only belonged to browser makers. Web components also give us developers the same responsibilities as browser makers. We should take that responsibility seriously.
Web components are supposed to be the poster child for The Extensible Web Manifesto. I’m all for an extensible web. But the way that web components are currently being built looks more like an endorsement of The Replaceable Web Manifesto. I’m not okay with a replaceable web.
Here’s hoping that my concerns won’t be dismissed as “piffle and tosh” again by the very people who should be thinking about these issues.
Adam and I share the same hopes and frustrations with web components. They can be written in a resilient, layered way that allows for progressive enhancement, but just about every example out there demonstrates a “my way or the highway” approach to using them.
We were chatting about this in the Design Systems slack channel, and it helped clarify some of my thoughts. I’ll try to poop out a blog post about this soon.
A good introduction to custom elements, one piece of the web components stack.
Depending on how you’re currently structuring your CSS and class attributes, web components might not make all that much of a difference to your workflow.
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
Contrary to popular belief, web standards aren’t created by a shadowy cabal and then handed down to browser makers to implement. Quite the opposite. Browser makers come together in standards bodies and try to come to an agreement about how to collectively create and implement standards. That keeps them very busy. They don’t tend to get out very often, but when they do, the browser/standards makers have one message for developers: “We want to make your life better, so tell us what you want and that’s what we’ll work on!”
In practice, this turns out not to be the case.
Case in point: responsive images. For years, this was the number one feature that developers were crying out for. And yet, the standards bodies—and, therefore, browser makers—dragged their heels. First they denied that it was even a problem worth solving. Then they said it was simply too hard. Eventually, thanks to the herculean efforts of the Responsive Images Community Group, the browser makers finally began to work on what developers had been begging for.
Now that same community group is representing the majority of developers once again. Element queries—or container queries—have been top of the wish list of working devs for quite a while now. The response from browser makers is the same as it was for responsive images. They say it’s simply too hard.
Here’s a third example: web components. There are many moving parts to web components, but one of the most exciting to developers who care about accessibility and backwards-compatibility is the idea of extending existing elements:
It’s my opinion that, for as long as there is a dependence on JS for custom elements, we should extend existing elements when writing custom elements. It makes sense for developers, because new elements have access to properties and methods that have been defined and tested for many years; and it makes sense for users, as they have fallback in case of JS failure, and baked-in accessibility fundamentals.
So instead of having to create a whole new element from scratch like this:
…you could piggy-back on an existing element like this:
<button is="taco-button">Click me!</button>
That way, you get the best of both worlds: the native semantics of
button topped with all the enhancements you want to add with your
taco-button custom element. Brilliant! Github is using this to extend the
time element, for example.
I’m not wedded to the
is syntax, but I do think it’s vital that there is some declarative mechanism to extend existing elements instead of creating every custom element from scratch each time.
Now it looks like that’s the bit of web components that isn’t going to make the cut. Why? Because browser makers say it’s simply too hard.
It probably wouldn’t bother me so much except that browser makers still trot out the party line, “We want to hear what developers want!” Their actions demonstrate that this claim is somewhat hollow.
I don’t hold out much hope that we’ll get the ability to extend existing elements for web components. I think we can still find ways to piggy-back on existing semantics, but it’s going to take more work:
That isn’t very elegant and I can foresee a lot of trickiness trying to sift the fallback content (the
button tags) from the actual content (the “Click me!” text).
But I guess that’s what we’ll be stuck with. The alternative is simply too hard.