http://adactio.com/journal/11052 by @adactio reminds me of the fallback problems with html audio http://epeus.blogspot.com/2010/01/audio-video-html5-and-standards.html
Extensible web components
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.
bk “Adactio: Journal—Extensible web components” adactio.com/journal/11052
‘Any developer convenience gained by the use of […] can’t come at the expense of the user—that price is too high’ adactio.com/journal/11052
“The way that web components are currently being built looks like an endorsement of The Replaceable Web Manifesto” adactio.com/journal/11052
Extensible Web Components adactio.com/journal/11052
Extensible web components - adactio.com/journal/11052
Adactio: Journal—Extensible web components adactio.com/journal/11052
«When evaluating a tech we ask “how well does it work?” It’s just as important to ask “how well does it fail?”» adactio.com/journal/11052
“Extensible web components” adactio.com/journal/11052
adactio.com/journal/11052 extensible webcomponents
Extensible Web Components adactio.com/journal/11052