45

I heard of shadow DOM which seems to solve the problem of encapsulation in web widget development. DOM and CSS rules get encapsulated which is good for maintenance. But then isn't this what iframes are for? What problems are there with iframes that made it necessary for W3C to come up with Shadow DOM or HTML5 Web Components?

Le Curious
  • 1,451
  • 1
  • 13
  • 13

2 Answers2

47

Today, iframes are commonly used to assure separate scope and styling. Examples include Google's map and YouTube videos.

However, iframes are designed to embed another full document within the current 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 web components which offer an elegant way to expose a clean API for accessing the values of custom elements.

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. 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).

In summary, 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.

Cory House
  • 14,235
  • 13
  • 70
  • 87
11

iframes are use as just encapsulation objects...

with the exception of SVG (more on that later), today’s Web platform offers only one built-in mechanism to isolate one chunk of code from another — and it ain’t pretty. Yup, I am talking about iframes. For most encapsulation needs, frames are too heavy and restrictive.

Shadow DOM allows you to provide better and easier encapsulation, by creating another clone of the DOM or part of it.

For example imagine you build a widget (as I have) that is used across websites. You widget might be affected by the css on the page and look horrible, whereas with Shadow DOM it will not :)

Here is an excellent article on the topic:

What The Heck is Shadow DOM/

David Baxter
  • 3
  • 3
Dory Zidon
  • 10,497
  • 2
  • 25
  • 39
  • can we have multiple instances of the same widget in different shadow-doms? Eg:- CSS/JS/HTML would be same but pointing to a different datasource/API – udarakr Mar 20 '17 at 08:40
  • 1
    'Better' and 'easier' are subjective. – Pavlo Apr 16 '18 at 14:09
  • 1
    What if you're embedding not just a widget but a full HTML document or even an interactive web page? Is shadow DOM still a good fit for this use case? In my experience, I've never used iframe for widgets other than embedding full page applications within another application or portal. Doing so will result in another plethora of issues than necessary compared when using iframe that provides complete encapsulation. – supertonsky Jun 16 '21 at 07:09