I had a chance to go on Igalia Chats and walk through the history of Shadow DOM with Eric Meyer, Brian Kardell, and Jeremy Keith. It was a fun, and pretty light discussion, but I learned a ton.
I had a chance to talk to Eric Meyer, Brian Kardell, and Jeremy Keith about a technology that kind of spans the history of the web itself, Shadow DOM. Give it a listen! It was a really fun and winding chat from the point of view of people worked with and on the web.
Here’s a few notes I made along the way:
Shadow DOM, somewhat simplifying it, is a way to add a subtree of elements inside of a document that is set apart from the rest of it. Everything inside that subtree is hidden from the styles and behaviors of its containing webpage. This is what’s known as encapsulation. That’s where the story of Shadow DOM begins.
There is encapsulation on the web, of course. The earliest examples we have are <frame> and <iframe> elements, and <svg>. These are self-contained parts of a webpage. They can have their own styles, and their own scripts, and anything that runs inside won’t leak out, and nothing from the parent page can leak in. Different versions of this were introduced in the very first browsers.
The idea behind what would eventually become Shadow DOM was to give that same ability to developers on their own custom elements. There were a lot of attempts at doing that.
HTML components date back to 1998, for instance. They never really took off, but one thing that’s amazing about HTML components is how their general structure resemembles what we would call a single file component today, i.e.
<HTML>
<HEAD>
<STYLE>
#flier {
behavior: url( fly.htc );
text-align: center;
}
</STYLE>
</HEAD>
<BODY>
<H1 ID=flier>Flying titles!</H1>
<P><BUTTON onclick="document.getElementsByTagname( "H1" )[0].stop();">Stop</BUTTON></P>
<SCRIPT>
var flyingElem = document.getElementsByTagname( "H1" )[0];
flyingElem.onFlyFinished = "alert('finished flying!');"
flyingElem.direction = "left";
flyingElem.start();
</SCRIPT>
</BODY>
</HTML>
After that, the web split into different factions, and browsers decamped to their own interpretations of the web, all buoyed by the rise of XML. As a result we had encapsulation realized in different ways by different browsers, but grounded in XML. Firefox, recently spun off from Netscape, had XUL (which Brian reminds us is a Ghostbusters reference), and eventually XBL. Microsoft developed XAML and Silverlight.
Both technologies used the structure of XML to address the problem of encapsulation. And both moved toward the idea of custom elements as a way of creating a root for a subtree, separate from the rest of the document, to attach to. That was an important idea moving forward.
Firefox used XBL to create internal components for their browsers, the toolbars and searchbar and other bits and pieces of UI that lived in the chrome of browsers. Microsoft used their implementation to develop and package Silverlight, to spread embeddable apps to developers.
Then, for ten years, not much happened at all as web standards bodies and browser makers fissured and then came back together around what would eventually be known as HTML 5 and the living standard.
It was the Webkit team that started the encapsulation conversation back up, starting in about 2010. In our talk, Brian references an email from Maciej Stachowiak at Apple, where he attempts to define the different types of encapsulation.
- Encapsulation against accidental exposure…
- Encapsulation against deliberate access…
- Inverse encapsulation…
- Isolation for security purposes…
- Inverse isolation for security purposes…
And the basis of that discussion, what exactly encapsulation meant and how it could be implemented, grounded not one, but two different iterations of Web Components, which included Shadow DOM, in the years that followed. What would come to be known as version 0 came first, around 2011. But certain changes were soon made which required a new version, version 1, in 2015. And that’s the version that exists today.
The greatest gift of Shadow DOM is it’s subtree, separate and apart from the rest of the page. Encapsulation for individual developers finally added to web standards. Using Shadow DOM, it’s possible to create a component which is entirely self-contained, something that doesn’t need and can’t be interfered with by the rest of the document.
But that gift can also be baffling, and complicated. There have even been implementations of Web Components that explicitly avoid it, Light DOM.
Yet there’s a reason that Shadow DOM has been one of the most enduring ideas in the history of web standards, and why it’s run a as a decades-long throughline. It’s all about the possibility. What happens when you give developers an ability to completely encapsulate their code. What could be possible? We now are able to recognize that possibility, and there will be many more iterations to come.
Leave a Reply