I’m really excited about the new HTML5 Web Components Standard. The Shadow DOM is particularly interesting, as it finally gives us encapsulated markup and styling. This should radically decrease the complexity of our CSS and help us finally design and deliver reusable components that don’t conflict with one another. We now have the tools to design our own custom HTML elements that feel native and offer even greater power than today’s HTML elements.
However, at first I had to wonder: Why do we need the Shadow DOM when we already have a way to encapsulate markup and styles using iframes? It’s an interesting point. Today iframes are commonly used to assure separate scope and styling. Examples include Google’s embedded maps and YouTube videos.
However, iframes are designed to embed another full document within another HTML document. This means accessing values in a given DOM element in an iframe from the parent document is a hassle by design. The DOM elements are in a completely separate context, so you need to traverse the iframe’s DOM to access the values you’re looking for.
Contrast this with HTML5 web components which offer an elegant way to expose a clean API for accessing the values of custom elements. Well written web components that utilize the Shadow DOM are as easy to access and manipulate as any native HTML elements. Try accessing the value of an input that exists in iframe from the parent document. It is a painful, clunky, and brittle process in comparison.
Imagine creating a page using a set of 5 iframes that each contain one component. Each component would need a separate URL to host the iframe’s content. The resulting markup would be littered with iframe tags, yielding markup with low semantic meaning that is also clunky to read and manage. Oh, and you’d also have to deal with the pain of properly sizing each iframe.
In contrast, web components support declaring rich semantic tags for each component. These tags operate as first class citizens in HTML. This aids the reader (in other words, the maintenance developer).
So while both iframes and the shadow DOM provide encapsulation, only the shadow DOM was designed for use with web components, and thus avoids the excessive separation, setup overhead, and clunky markup that occurs with iframes.
Excited about web components? Chrome and Opera already offer full support so get started!
Thanks Cory, Nice read.
I would like something to this as well which is Search Engine Optimization. Web components and custom elements definitely give us better SEO.
In iframe world we have slice and dice our content sometime into different URLs, as you described, and search engines agent would struggle co-relating them together. Where as web component and custom elements give us ability to declare our content in single page using different custom tags.
This isn’t true. I like webComponents but even with Polymer’s polyfills they doesn’t cover all browsers we currently have to support. I hope this would be changed in a few years from now.
But..
1. You can create IFRAMEs without loading content through an url – they can be generated on fly from HTML templates. Micro library which already does this: https://github.com/vmysla/IFRAMEr
2. Accessing IFRAME elements also isn’t a problem. This script for example overrides JQuery element accessor and makes you abitity to work with inner frame’s elements as they are on the page: https://gist.github.com/vmysla/00806f5c98b51857ee36
But I agree that in a long term run – shadow dom should completely replace IFRAMEs.
@Vlad – “This isn’t true”
What specifically are you saying isn’t true?
Accessing Iframe elements or bidirectional communication between frame and parent page isn’t as painful as people speak about it. The level of complexity is the same as for shadow Dom when you frame isn’t loaded form thirparty doman