An article about how web components could, and should, extend existing elements with some useful links/resources - bit.ly/1D8BtwF
Responsible Web Components
Bruce has written a great article called On the accessibility of web components. Again. In it, he takes issue with the tone of a recent presentation on web components, wherein Dimitri Glazkov declares:
Custom elements is really neat. It basically says, “HTML it’s been a pleasure”.
Bruce paraphrases this as:
Bye-bye HTML; you weren’t useful enough. Hello, brave new world of custom elements.
Like Bruce, I’m worried about this year-zero thinking. First of all, I think it’s self-defeating. In my experience, the web technologies that succeed are the ones that build upon what already exists, rather than sweeping everything aside. Evolution, not revolution.
Secondly, web components—or more specifically, custom elements—already allow us to extend existing HTML elements. That means we can use web components as a form of progressive enhancement, turbo-charging pre-existing elements instead of creating brand new elements from scratch. That way, we can easily provide fallback content for non-supporting browsers.
But, as Bruce asks:
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
span. Web components now simply gives the option of then sweeping all that non-semantic junk under a nice, self-contained rug.
That’s a depressing thought. But it might very well be true.
Why aren’t web components required to be created with
is=“some-component”on an existing HTML element? This seems like an obvious approach; sure, someone who wants to make something meaningless will just do
<div is=my-thing>or (worse)
<body is=my-thing>but it would provide a pretty heavy hint that you’re supposed to be doing things The Right Way, and you’d get basic accessibility stuff thrown in for free.
That’s a good question. After all, writing
<new-shiny></new-shiny> is basically the same as
<span is=“new-shiny”></span>. It might not make much of a difference in the case of a
div, but it could make an enormous difference in the case of, say, form elements.
Take a look at IBM’s library of web components. They’re well-written and they look good, but time and time again, they create new custom elements instead of extending existing HTML.
<input type=“checkbox” is=“d-checkbox”>and
<input type=“checkbox” is=“d-switch”>
<input is=“d-combo-box”><datalist is=“d-list”>
Although, as Bruce points out:
Of course, not every new element you’ll want to make can extend an existing HTML element.
But I still think that the majority of web components could, and should, extend existing elements. Addy Osmani has put together some design principles for web components and Steve Faulkner has created a handy punch-list for web components, but I’d like to propose that a fundamental principle of good web component design should be: “Where possible, extend an existing HTML element instead of creating a new element from scratch.”
Rather than just complain about this kind of thing, I figured I’d try my hand at putting it into practice…
Dave recently made a really nice web component for playing back podcast audio files. I could imagine using something like this on Huffduffer. It’s called
podcast-player and you use it thusly:
One option for providing fallback content would be to include it within the custom element tags:
<podcast-player src="my.mp3"> <a href="my.mp3">Listen</a> </podcast-player>
That would require minimum change to Dave’s code. I’d just need to make sure that the fallback content within
podcast-player elements is removed in supporting browsers.
I forked Dave’s code to try out another idea. I figured that if the starting point was a regular link to the audio file, that would also be a way of providing fallback for browsers that don’t cut the web component mustard:
<a href="my.mp3" is="podcast-player">Listen</a>
It required surprisingly few changes to the code. I needed to remove the fallback content (that “Listen” text), and I needed to prevent the default behaviour (following the
href), but it was fairly straightforward.
However, I’m sure it could be improved in one of two ways:
- I should probably supply an ARIA
roleto the extended link. I’m not sure what would be the right one, though …
- Perhaps a link isn’t the right element to extend. Really I should be extending an
audioelement (which itself allows for fallback content). When I tried that, I found it too hard to overcome the default browser rules for hiding anything between the opening and closing tags. But you’re smarter than me, so I bet you could create
Fork the code and have at it.
@adactio I will go to every standards meeting until I get it done, because otherwise we are hosed for <form> and web components.