Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
Now, this is how you design a web component. It’s a progressive enhancement.
Wrap your existing table element inside table-saw and it will behave responsively. If anything goes wrong with the JavaScript, the fallback is the regular table that’s already in your markup.
I just wish the installation didn’t assume that you’re using npm …it’s not really “zero dependency” if it depends on that.
A spot-on summary of where we’ve ended up with web components.
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.
But then…
Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.
Alas, that’s true. Lea wonders how this can be fixed:
I’m not sure if this is a design issue, or a documentation issue.
I worry that is a cultural issue.
Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.
Just today I was discussing with Trys and Cassie why developers tend to create bespoke JavaScript-driven components rather than using the elements that browsers give us for free. It all comes down to the ability to style the user interface.
Here, Brian proposes a kind of minimum viable web component that handles logic like keyboard control and accessibility, but leaves the styling practically untouched. Check out his panel-set demo of a tabbed interface.
I really, really like the way that it wraps existing content. If the web component fails for any reason, the content is still available. So the web component is a progressive enhancement:
An experimental custom element that wraps plain-old HTML (view the source) and decorates function, keyboard handling, accessibility information.
You might want to use `display: contents` …maybe.
Web components are supposed to extend the web, not replace it.
Extending the wheel, instead of reinventing it.
HTML’s new `command` attribute on the `button` element could be a game-changer.
If the JavaScript API requires a user gesture, maybe it’s time for a new button type.