Playing with Shadow DOM
Original Source: https://css-tricks.com/playing-shadow-dom/
About a year ago, Twitter announced it would start displaying embedded tweets with the shadow DOM rather than an <iframe>, if the browser supports shadom DOM?
Why? Well, speed is one reason.
They say:
Much lower memory utilization in the browser, and much faster render times. Tweets will appear faster and pages will scroll more smoothly, even when displaying multiple Tweets on the same page.
Why the choice? Why is it necessary to use either iframes or shadow DOM? Why not just inject the content onto the page?
It’s a totally understandable need for control. An embedded Tweet should look and behave just exactly like an embedded Tweet. They don’t want to worry about the styles of the page bleeding in and messing that up.
An <iframe> makes style scoping very easy. Point the src of the iframe at a URL that displays what you want an embedded tweet to look like, and you’re good. The only styles used will be those you include in that document.
Twitter does this iframe-injection in a progressive enhancement and syndication-friendly way. They provide a <blockquote> with the Tweet and a <script>. The script does the iframe-injection. If the script doesn’t run, no matter, a happy blockquote. If the script does run, a fully functional embedded Tweet.
That script is the key here. Scripts can do just about anything, and they host it, so they can change it up anytime. That’s what they use to detect shadow DOM support and go that route instead. And as we covered, shadow DOM is faster to render and has lower memory needs. Shadow DOM can also help with the style scoping thing, which we’ll look at in a moment.
Height flexibility
There’s another thing too, that happens to be near and dear to my heart. An <iframe> doesn’t adjust in height to fit its contents like you expect other elements to do. You set a height and that’s that. It will have scrollbars, if you allow it and the content needs it. Back in the Wufoo days, we had to jump quite a few hoops to get embedded forms (in frames) to be as tall as they needed to be. Today, at CodePen, our Embedded Pens have adjustable heights, but there isn’t any option for just “as tall as they need to be”. (I’m exactly sure if that makes sense for CodePen Embeds or not, but anyway, you can’t do it right now.)
An element with a shadow DOM is just like any other element and that it will expand to the content naturally. I’m sure that is appealing to Twitter as well. If they calculate the height wrong, they run the risk of cutting of content or at least having the embedded Tweet look busted.
Most Basic Usage
Here’s the bare minimum of how you establish a shadow DOM and put stuff in it:
See the Pen Most basic shadow DOM by Chris Coyier (@chriscoyier) on CodePen.
Notice how the styling within the Shadow DOM doesn’t leak out to the regular paragraph element? Both paragraphs would be red if they did.
And notice how the paragraph inside the shadow DOM isn’t sans-serif like the one outside? Well, normally that would be. Inherited styles still inherit through the shadow DOM (so in that way it’s not quite as strong a barrier as an iframe). But, we’re forcing it back to the initial state on purpose like this:
:host {
all: initial;
}
Handling that fallback
My first thought for dealing with a fallback for browsers that don’t support shadow DOM was that you could chuck the same exact content you were stuffing into the shadow DOM into an iframe with srcdoc, like…
<iframe srcdoc=”the same content”>
Or more likely this is something you’re doing in JavaScript, so you’d test for support first, then either do the shadow DOM stuff or dynamically create the iframe:
See the Pen Shadow DOM Basic by Chris Coyier (@chriscoyier) on CodePen.
Turns out srcdoc isn’t the best choice (alone) for a fallback as there is no IE or Edge support for it. But also that it’s not too big of a deal to just use a data URL for the regular src. Here’s a fork by Šime Vidas where he fixes that up:
let content = `
<style>
body { /* for fallback iframe */
margin: 0;
}
p {
border: 1px solid #ccc;
padding: 1rem;
color: red;
font-family: sans-serif;
}
</style>
<p>Element with Shadow DOM</p>
`;
let el = document.querySelector(‘.my-element’);
if (document.body.attachShadow) {
let shadow = el.attachShadow({ mode: ‘open’ }); // Allows JS access inside
shadow.innerHTML = content;
} else {
let newiframe = document.createElement(‘iframe’);
‘srcdoc’ in newiframe ?
newiframe.srcdoc = content :
newiframe.src = ‘data:text/html;charset=UTF-8,’ + content;
let parent = el.parentNode;
parent.replaceChild(newiframe, el);
}
TL;DR
Shadow DOM is pretty cool.
It’s comparable to an iframe in many ways, including style encapsulation. Embedded third-party content is a pretty good use case.
It’s possible to use it while falling back to an iframe pretty easily.
It’s a part of the larger world of web components, but you don’t have to go all-in on all that if you don’t want to.
Here’s another simple demo (this one using a custom element), but instead of rolling our own back support, it’s polyfilled.
Playing with Shadow DOM is a post from CSS-Tricks
