Extending Built-in Elements

Photo by darylgio agoncillo on Unsplash

Looking at the history of Custom Elements we can analyze few facts:

Even if agreed between more browsers vendors, the V1 API left web developers with tons of issues that were previously, somehow, solved:

To me, V0 API was the classic example that pragmatic is better than perfect, but also that pragmatic works (and V1 is everything but perfect anyway).

Instead, in 2018, the most basic/needed specification out of Web Components is still under development and quite fragmented beside few exceptions:

…but what is that all the browsers have in common since ever?

Built-in Elements

Without even waiting a single day for custom elements to land on the Web, all successful, sometimes heavy, but super dev friendly frameworks, based their success on regular DOM elements such DIVs, BUTTONs, TABLEs, you name it.

Yes, once everything boils down to an over-polluted page full of DIVs that “just works”, one starts wondering if Web Components have ever been an answer or, if that’s the case, what is it that such specification exactly solved.

As of today, it surely caused an ulcera to my liver due the amount of time, stress, and discussions I’ve had since day 0 about this topic with other developers involved with this standard and its implementation.

I was so happy about CE potentials that I’ve even brought CEs down to IE8!

The mandatory Shadow DOM failure

I think Shadow DOM is the reason #1 Web Components never shined. Even if very good in theory, the reality about Shadow DOM is the following one:

Accordingly, if you ever waited for Shadow DOM to land everywhere so you can start using Web Components, keep looking around at how much fun other developers are having instead, with their components solution based on regular built-in elements.

It’s literally that easy peasy lemon squeezy !

And more often than it should, that also makes me wonder if I’m even stupid in just waiting for standards to become a reality … I mean, in general …

It’s time to move forward with built-in extends

Since at least two major browser vendors decided that custom elements built-in extend are OK, and Chrome and Firefox cover the majority of the users, and since the only one strongly opposed to custom elements built-in delivers the fastest and most expensive Hardware out there (yeah, that’s Apple), so that a tiny patch won’t hurt at all in the real world, it’s time to move on and re-write the history of custom elements once again, this time doing what is the most natural thing to do, something that gives developers pseudo shadow DOM out of the box (input, button, table, select, checkbox), something that implements accessibility out of the box, and something that works from the most ancient browser to the most modern one, without fearing JS incompatibilities.

Strawberry on top, it’s something any Server Side Rendering can deliver.

The built-in element patch

Fully based on native customElements implementation, built-in element is a polyfill that weights less than 1 Kb, it leaves Chrome and Firefox completely untouched, and it uses modern features on Safari, which is why it’s so lightweight.

All other old or not-there-yet browsers will also be unaffected, thanks to the document-register-element polyfill, the one that AMP and AFrame use too, which already provides custom elements and built-in capabilities.

<script>
if (!this.customElements)
document.write('<script src="//unpkg.com/document-register-element"><\x2fscript>');
</script>

Explained in my bloatless Web post, above technique won’t ever affect modern browsers neither and it will always work in old one.

And because document-register-element is based on ES3 compatible syntax, and since the eventually transpiled part of built-in-element would basically run only in Safari, or even Edge if they decide to not implement built-in for the time being, you can be sure this solution works from IE9 to latest Chrome, passing through even Android 2 phones, covering more than most FWs.

Is the button text blue? Can you click it? That’s it, you’re good to go.

The overhead is minimal for modern browsers, and identical for battle tested old browsers so that starting from now, every browser, and every server, can deliver custom elements built-in.

Yes, even your framework of choice 🎉

… but what exactly do built-in extends solve?

… but I still want Shadow DOM

If you keep it simple … repeat with me … if you keep it very simple, you can forget heavy polyfills that are not super reliable and use simple solutions such attachshadow but I still suggest, for any other case, to consider using instead the built-in-element approach: that would rarely fail any expectation.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrea Giammarchi

Web, Mobile, IoT, and all JS things since 00's. Formerly JS engineer at @nokia, @facebook, @twitter.