What the Heck is Shadow DOM?
If you build Web sites, you probably use Javascript libraries. If so, you are probably grateful to the nameless heroes who make these libraries not suck.
One common problem these brave soldiers of the Web have to face is encapsulation. You know, one of them turtles on which the Object-Oriented Programming foundation sits, upon which stands most of the modern software engineering. How do you create that boundary between the code that you wrote and the code that will consume it?
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.
What do you mean I must put each of my custom buttons in a separate iframe? What kind of insane are you?
So we need something better. Turns out, most browsers have been sneakily employing a powerful technique to hide their gory implementation details. This technique is called the shadow DOM.
My name is DOM, Shadow DOM
Shadow DOM refers to the ability of the browser to include a subtree of DOM elements into the rendering of a document, but not into the main document DOM tree. Consider a simple slider:
<input id="foo" type="range">
Pop this code into any WebKit-powered browser, and it’ll appear like so:
Simple enough. There’s a slider track and there’s a thumb, which you can slide along the track.
Wait, what? There’s a separate movable element inside of the input element? How come I can’t see it from Javascript?
var slider = document.getElementsById("foo");
console.log(slider.firstChild); // returns null
Is this some sort of magic?
No magic, my fair person of the Web. Just shadow DOM in action. You see, browser developers realized that coding the appearance and behavior of HTML elements completely by hand is a) hard and b) silly. So they sort of cheated.
They created a boundary between what you, the Web developer can reach and what’s considered implementation details, thus inaccessible to you. The browser however, can traipse across this boundary at will. With this boundary in place, they were able to build all HTML elements using the same good-old Web technologies, out of the divs and spans just like you would.
Some of these are simple, like the slider above. Some get pretty complex. Check out the video element. It’s got trigger buttons, timelines, a hover-appearing volume control, you name it:
All of this is just HTML and CSS — hidden inside of a shadow DOM subtree.
To borrow a verse from that magnetic meme duo, “how does it work?” To build a better mental model, let’s pretend we have a way to poke at it with Javascript. Given this simple page:
<html>
<head>
<style> p { color: Green; } </style>
</head>
<body>
<p>My Future is so bright</p>
<div id="foo"></div>
<script>
var foo = document.getElementById('foo');
// WARNING: Pseudocode, not a real API.
foo.shadow = document.createElement('p');
foo.shadow.textContent = 'I gotta wear shades';
</script>
</body>
</html>
We get the DOM tree like this:
<p>My Future is so bright</p> <div id="foo"></div>
But it is rendered as if it were this:
<p>My Future is so bright</p>
<div id="foo"> <!-- shadow subtree begins -->
<p>I gotta wear shades</p>
</div> <!-- shadow subtree ends -->
Or visually like so:
Notice how the second part of the rendered sentence is not green? That’s because the p selector I have in my document can’t reach into the shadow DOM. How cool is that?! What would a framework developer give to have powers like this? The ability to write your widget and not worry about some random selector fiddling with your style seems … downright intoxicating.
Course of Events
To keep things natural, events fired in shadow DOM subtree can be listened to in the document. For instance, if you click on the mute button in the audio element, your event listeners on an enclosing div would hear the click:
<div onclick="alert('who dat?')">
<audio controls src="test.wav"></audio>
</div>
However, if you ask to identify who fired the event, you’ll find out it was the audio element itself, not some button inside of it.
<div onclick="alert('fired by:' + event.target)">
<audio controls src="test.wav"></audio>
</div>
Why? Because when crossing the shadow DOM boundary, the events are re-targeted to avoid exposing things inside of the shadow subtree. This way, you get to hear the events, fired from the shadow DOM, and the implementor gets to keep their details hidden from you.
Reaching into Shadows with CSS
One other trick up the sleeve is the ability to control how and whether CSS reaches into the shadow subtree. Suppose I want to customize the look of my slider. Instead of the standard OS-specific appearance, I want it be stylish, like so:
input[type=range].custom {
-webkit-appearance: none;
background-color: Red;
width: 200px;
}
The result I get is:
Ok, that’s nice, but how do I style the thumb? We already determined the that our usual selectors don’t go into the shadow DOM tree. Turns out, there’s a handy pseudo attribute capability, which allows shadow DOM subtrees to associate an arbitrary pseudo-element identifier with an element in the subtree. For example, the thumb in the WebKit slider can be reached at:
input[type=range].custom::-webkit-slider-thumb {
-webkit-appearance: none;
background-color: Green;
opacity: 0.5;
width: 10px;
height: 40px;
}
Which gives us:
Ain’t it great? Think about it. You can style elements in the shadow DOM without actually being able to access them. And the builder of the shadow DOM subtree gets to decide which specific parts of their tree can be styled. Don’t you wish you had powers like this when building your UI widget toolkit?
Shadows with Holes, How’s that for a Mind-bender?
Speaking of awesome powers, what happens when you add a child to an element with a shadow DOM subtree? Let’s experiment:
// Create an element with a shadow DOM subtree.
var input = document.body.appendChild(document.createElement('input'));
// Add a child to it.
var test = input.appendChild(document.createElement('p'));
// .. with some text.
test.textContent = 'Team Edward';
Displaying as:
Whoa. Welcome to the twilight DOM — a chunk of document that’s accessible by traversal but not rendered on the page. Is it useful? Not very. But it’s there for you, if you need it. Teens seem to like it.
But what if we did have the ability to show element’s children as part of its shadow DOM subtree? Think of the shadow DOM as a template with a hole, through which the element’s children peek:
// WARNING: Pseudocode, not a real API.
var element = document.getElementById('element');
// Create a shadow subtree.
element.shadow = document.createElement('div');
element.shadow.innerHTML = '<h1>Think of the Children</h1>' +
<div class="children">{{children-go-here}}</div>';
// Now add some children.
var test = element.appendChild(document.createElement('p'));
test.textContent = 'I see the light!';
As a result, if you traverse the DOM you will see this:
<div id="element">
<p>I see the light</p>
</div>
But it will render like this:
<div id="element">
<div> <!-- shadow tree begins -->
<h1>Think of the Children</h1>
<div class="children"> <!-- shadow tree hole begins -->
<p>I see the light</p>
</div> <!-- shadow tree hole ends -->
</div> <!-- shadow tree ends -->
</div>
As you add children to element, they act as normal children if you look at them from the DOM, but rendering-wise, they are teleported into a hole in the shadow DOM subtree.
This is the point where you admit that this is pretty cool and start asking:
When can I have it in my browser?
Homework Assignment
Did you think you’d read through all this preaching and get away without homework? As a Javascript library or framework developer, try to think of all the different great things having shadow DOM would allow you to do. Then think of specific use cases (actual/pseudo code a plus) of where shadow DOM could be applied. To help you get your thinking groove going, here is current list of use cases.
Finally. share your use cases on public-webapps mailing list. The discussion about adding these capabilities to the Web platform is under way and your help is needed.
If you aren’t a much a framework writer, you can still participate — by cheering for the shadow DOM and spreading the joy on your favorite social networking site. Because joy is what’s it’s all about.
PS. SVG and Shadow DOM
Almost forgot. Believe it or not, SVG has actually had shadow DOM since the beginning. The trouble is, its shadow DOM is very… shady. No, that’s not it. There’s another qualifier that also begins with “sh” and ends with a “y”. Yeah, that one. I could go on, but trust me on this. Or read the spec.
There is one major flaw with cross-browser compatibility for the CSS pseudo-element approach, which is that one invalid selector will cause the entire rule to be dropped. Suppose Mozilla implements the slider-thumb pseudo as well, CSS like this would be impossible:
input[type=range].custom::-webkit-slider-thumb, input[type=range].custom::-moz-slider-thumb
{
properties
}
This is behavior which has been in CSS since forever, used for hacks and therefore not likely to change. I addressed the problem a couple of months ago on www-style myself.
The Shadow DOM itself is great, of course. I’ve seen the patches come by :)
Peter Beverloo
January 14, 2011 at 5:51 pm
I came across this and hung my head at realising it lead towards duplication.
But between CSS autoprefixer and SASS mixins it’s actually really easy to solve.
Random guy 246783
April 30, 2015 at 6:08 am
This is exactly how IE’s HTML components (aka behaviors) implementation worked. This is also how Microsoft’s WPF works. They refer to them as the Visual Tree and the Logical Tree. Had the HTML components proposal from 1998[1] ever been adopted and carried forward we’d all be living in a better world. Amazed that we still have now standard control model to this day.
[1] http://www.w3.org/TR/NOTE-HTMLComponents
Drew Marsh
January 14, 2011 at 9:22 pm
When you mention SVG’s shadow DOM, do you mean the svg:use tag?
Brad Neuberg
January 15, 2011 at 12:50 am
Yes!
Dimitri Glazkov
January 15, 2011 at 9:19 am
Okay, Dmitri, here’s your homework. Tell the SVG WG exactly what you don’t like about the SVG shadow DOM, and how you would want it to work instead. We’ll fix it in SVG 2.
For historical perspective, SVG defined the shadow DOM over a decade ago, so it’s not surprising that some tweaks are needed.
Nice article, btw… I’ve always liked the shadow DOM, and even just a few years ago, it was utterly reviled by browser developers. So, I’m glad to see it get some props (like the rainbow it is).
shepazu
January 15, 2011 at 10:08 am
Yes sir! :)
Dimitri Glazkov
January 15, 2011 at 1:16 pm
SVG tried to invent proper shadow DOM long time ago (called “RCC”) and we even implemented it in Adobe SVG viewer, but it went nowhere in W3C: http://www.w3.org/TR/2003/WD-SVG12-20030715/#rcc-dom
Peter Sorotokin
January 17, 2011 at 11:40 pm
Wow, really cool. I didn’t know this until now :D
Kurtextrem
January 15, 2011 at 9:59 am
Dimitri, did you hear about Ample SDK http://www.amplesdk.com/ ? It does nicely pretty much what you are discussing here on top of the existing technologies (HTML4+CSS1+DOM0). Basically it creates and maintains its own DOM (with standard L2 APIs) out of XUL, SVG or any other markup document included (or referenced) in an HTML webpage in . Indeed the events propagation works in this DOM. For example in case of SVG the host tree will only contain SVG nodes, but the shadow in case of IE, for example, will contain VML nodes (see http://www.amplesdk.com/examples/markup/svg/tiger/ in IE6, for exmple). With XUL everything is rendered in shadow tree using HTML4 (see http://www.amplesdk.com/examples/markup/xul/views/). The developer interacts with Ample SDK DOM through “ample” object which is the “document” object of Ample SDK.
Next to the benefit of browser-independent DOM re-implemented, developer can also use many “new” features of CSS, such as pseudo-elements classes to reach out shadow DOM if needed and so on. See tutorial for details http://www.amplesdk.com/tutorials/adg/
Sergey Ilinsky
January 15, 2011 at 11:50 am
I am familiar with Ample — and kudos! You are definitely on my “framework hero” list. I should’ve linked to it in my post. But what Ample does is a hack, approaching horrifying proportions. You are basically building a rendering engine inside of a rendering engine. Yes, you are enabling new capabilities, but they come at the expense of performance, latency, and just plain living in a detached layer that has little to do with what is really going in the renderer. And yes, I totally understand why you’re doing it and even support it, because supplying an even ground in today’s browser landscape is just tough.
Finally, with your skills, you should stop worrying about the legacy browsers and start hacking on the actual rendering engines instead. Like WebKit. Or Gecko. Let me know if you’re interested :)
Dimitri Glazkov
January 15, 2011 at 1:00 pm
As a developer, I hate them because I can’t style them to my will…
For example, I want to skin the arrow in select-element, but I am not allowed to do. In order to do it, I have to emulate same behaviour of select, using div’s and other elements.
Harp B
January 15, 2011 at 2:54 pm
[…] What the Heck is Shadow DOM? If you build Web sites, you probably use Javascript libraries. If so, you are probably grateful to the nameless heroes […] […]
Top Posts — WordPress.com
January 15, 2011 at 4:05 pm
Just out of curiosity, is there any way to find out which elements that lies within the Shadow DOM? For example, I haven’t been able to find a way to access the up & down buttons of an input type=”number” in JS. Could this be because they lie in the Shadow DOM?
Martin
January 15, 2011 at 5:14 pm
The way to do this is by studying the code. For example, in WebKit the magic is currently in TextControlInnerElements.cpp (http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/rendering/TextControlInnerElements.cpp&q=SpinButtonElement&exact_package=chromium&l=260) and RenderTextControlSingleLine.cpp (http://www.google.com/codesearch/p?vert=chromium#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderTextControlSingleLine.cpp). But don’t expect it to be here for long — we’re planning a rather large refactoring of this code soonish.
Dimitri Glazkov
January 15, 2011 at 6:08 pm
[…] reading “What the Heck is Shadow DOM?” I was inspired to see how far I could style the <input type="range"> element. […]
Implementing iPhone’s slider unlock with input type=”range” | David B. Calhoun – Developer Blog
January 16, 2011 at 5:11 pm
[…] Thursday, Kent Tamura landed support for the Interactive Validation UI using the new Shadow DOM model. With most bugs out of the way, messages and an –albeit internal– API being available […]
CSS Variables and mixins, Interactive Validation and prerendering « Peter Beverloo
January 17, 2011 at 12:41 pm
[…] What the Heck is Shadow DOM? « Dimitri Glazkov An interesting article about the hidden elements in the DOM. (tags: shadow dom javascript html) […]
links for 2011-01-17 « General Musing
January 17, 2011 at 5:06 pm
[…] What the heck is Shadow DOM? […]
Revision 10: H.264 vs. WebM, Shadow DOM und w3fools.com | Working Draft
January 18, 2011 at 12:46 pm
But if you can’t access this “Shadow DOM” stuff then how does the Shadow DOM really matter? Forgive me if I missed something. Can people actually make re-usable custom components that are tucked into the shadows of the Shadow DOM?
egenergy
January 19, 2011 at 8:53 pm
Use case: you are creating a reusable custom control out of conventional HTML elements. (For example, a fancy select box, or a calendar control.)
Problem 1: the elements that comprise your clever control are affected by external stylesheets, perhaps in ways that will break them horribly.
Problem 2: other JavaScripts that do clever stuff might accidentally interact with your controls in ways that you would prefer they couldn’t.
Solution: the Shadow DOM will let you build a DOM subtree that cannot be touched by CSS and JavaScript through conventional means.
Jordan Gray (@jordangray)
August 6, 2011 at 1:50 pm
The link to the public-webapps mailing list is broken, should be http://lists.w3.org/Archives/Public/public-webapps/
Dom
January 20, 2011 at 3:38 am
Very cool, and pretty mind-boggling when it gets to ‘holes’ – I’ll have to read that again!
Could we please have a working link to the ‘current list of use cases’ – or have they actually disappeared?
Marjolein Katsma
January 20, 2011 at 5:03 am
Oh good, it seems the link to the ‘current list of use cases’ (or its target) has been repaired!
Marjolein Katsma
January 20, 2011 at 5:12 am
[…] elements, only they are behind a bit of a glass wall. You can see, but not touch. Direct Link to… [full post] Chris Coyier CSS-Tricks link 0 0 0 0 0 [20 […]
The Shadow DOM
January 20, 2011 at 10:02 am
[…] here to read the rest: The Shadow DOM No Responses to “The […]
The Shadow DOM | The Web Design Development Company | Web Design | Web Development | SEO Based Website Designers
January 20, 2011 at 10:34 am
So the SVG shadow DOM is shy?
Stephan
January 21, 2011 at 1:19 am
[…] has a logo: you’ve probably heard about this by now… What the Heck is Shadow DOM? is a look at parts of the DOM only accessible by the browser itself, but sometimes styleable. Case […]
JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: Twitter onscroll performance, Ace editor, CSSOM, Modernizr 2.0 beta
January 21, 2011 at 1:31 am
-webkit-slider-thumb pseudo class??? Please tell me there’s a list of these things out there; I’d love the ability to reskin the native video controls.
RussellUresti
January 21, 2011 at 10:10 am
Dịch vụ rút gọn link của goolge
http://goo.gl/g2DdB
namluong
January 21, 2011 at 11:44 pm
[…] Originally posted from: The Shadow DOM […]
My Stream » The Shadow DOM
January 22, 2011 at 12:32 am
[…] Direct Link to Article — Permalink […]
The Shadow DOM | Silver-Tab.com
January 22, 2011 at 12:33 pm
Interesting idea, allowing component creators to have the ability to create “shadow DOM” elements, but, I don’t see any compelling argument for it. The ability to encapsulate a “component” is indeed important, but, to that end, you only mention JavaScript events and CSS. As far as JavaScript event encapsulation, it’s already possible to trap events at a specific DOM element and to have events originate from a given element, so, that is not an issue. CSS encapsulation? That is a valid issue, but, it is an issue with CSS (being addressed by CSS3 no less), not a reason to add a component model to browsers.
Doug
January 27, 2011 at 10:56 am
[…] What the Heck is Shadow DOM? at Dimitri Glazkov (tagged: javascript css html5 webdev DOM ) […]
Linkdump for February 1st at found_drama
February 1, 2011 at 2:02 pm
Thats awesome!
I am just a little web-developer who is interested in those things.
My current challenge style the html5 progress tag in opera. This Shadow DOM seems like “42” to my question.
Where is the green coming from?
Is there a way of finding the super crazy pseudo selector to figure out where the color in the browser is controlled?
Type-Style
February 2, 2011 at 4:10 am
It occurs to me that content added via pseudo-elements :before and :after can be considered Shadow DOM.
France
February 3, 2011 at 9:49 am
Is that true, that the :before and :after are Shadow DOM?? Awesome…
mannclay
March 15, 2011 at 5:18 pm
At least in WebKit, the content property is implemented by injecting rendering objects directly, without DOM. So in this particular case, there is no shadow DOM involved.
Dimitri Glazkov
March 17, 2011 at 8:40 am
[…] link tip: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ […]
shadow DOM | Jen's Webstek
April 3, 2011 at 6:54 am
[…] now, because the properties are vendor-prefixed (e.g. ::-webkit-scrollbar) and use the “Shadow DOM“. This has been around for a couple of years. David Hyatt blogged it in early 2009 and put […]
Custom Scrollbars in WebKit / Weblog – Hans van Goor
May 2, 2011 at 9:46 am
[…] pero es hora de Webkit. Es un poco mejor ahora ya que estan prefijadas para webkit y usan el shadow-DOM , esto ha sido hace un par de años, David Hyatt lo bloggeo y puso junto unos ejemplos de las […]
ScrollBars Personalizadas – Taringa! Buzz
May 11, 2011 at 9:26 pm
[…] aktuelle Canary-Build von Chrome zeigt seit neustem alle zu einem Element gehörigen Shadow-DOM-Elemente. Damit lässt sich also herausfinden, wie man per CSS an in HTML-Elementen steckende […]
Revision 25: Visibility API und Chromebooks | Working Draft
May 17, 2011 at 8:30 am
Just an update on this – Chrome now lets users see the shadow DOM! http://peter.sh/2011/05/inspectable-shadow-dom-the-file-browser-and-new-default-avatars/
David Calhoun
June 7, 2011 at 5:33 am
Mozilla’s XBL system exposes a mechanism like this to developers, which is used to implement the XUL widgets that make up the UI of Mozilla’s apps.
It would be awesome to see a facility like this standardized across browsers for use in web pages.
Mozilla tried to write a specification for such a thing:
http://www-archive.mozilla.org/projects/xbl/xbl2.html
Martin Atkins
June 16, 2011 at 5:04 pm
XBL 2.0 is also W3C Candidate Recommendation:
http://www.w3.org/TR/xbl/
Just no one implemented it yet. At least in the Browsers. There is a JS implementation from Sergey (above):
http://code.google.com/p/xbl/
Although XBL was designed with other intention than those of the WebApps WG, this concept of templating reusable components and bind them to implementations is very nice. Through the interface it provide well-defined access to the shadow tree, as well as events. And it’s based on the experiences made with XBL1.0 in XUL (or even remade from scratch?). Thus if there are shadow trees in the rendering engine already, why not expose them to all users to create reusable components?
Kristian Sons
July 10, 2011 at 10:11 pm
[…] WHATWG wiederum möchte mit dem Component Model den Wildwuchs in Sachen Shadow DOM beseitigen und standardisierte Schnittstellen zum Befüllen desselben […]
Revision 38: Gridsysteme und Best Practices | Working Draft
August 30, 2011 at 3:10 am
A shadow dom would hide complexity from the programmer. Complexity is basically the worst enemy you can have. Picture for yourself how hard something would get to debug when it also has many property’s that are inaccessible once set (a shadow dom would be that).
The way to writing more functional and bugfree apps is not abstracting complexity, it’s removing complexity. I think the added complexity of a shadow dom would not be a good idea. I do think standardizing the look and customisability of the elements we have now would be a good idea (like what happened to buttons, sort of). HTML + CSS + Javascript is about dynamic interactive applications, not about structured data anymore. If you ask me there should be a single standardized browser css template, and a collection of public domain fonts that are enforced be included.
Bah!
Lodewijk Andre de la Porte
September 1, 2011 at 11:32 am
[…] 最近になって再びスクロールバーをカスタマイズすることが出来るようになりましたが、今回は非標準CSSではなくWebKitを使うことになります。プロパティはベンダープレフィックス（::-webkit-scrollbarなど）で、シャドウＤＯＭを使用しています。この方法が使われるようになって数年経ちますが、ディビッド・ハイアットさんが2009年の初めにブログで記事にしており、考え付くであろう全てのサンプルを掲載されています。 […]
WebKitを使ってスクロールバーをカスタマイズ - CSSPRO
September 7, 2011 at 8:01 pm
I tried to style a Number Input element: http://lab.simurai.com/css/umbrui But something I just couldn’t figure out.. how to style the up/down buttons individually? Is there some secret pseudo element for each of them? The ::spin-button only affects them both together.
simurai (@simurai)
September 12, 2011 at 7:59 am
[…] What the Heck is Shadow DOM? – Dimitri Glazkov […]
JavaScript Reference Links | kabayview.com
October 10, 2011 at 8:02 am
[…] Model provides programmatic ways to ways to build components, utilizing features such as the Shadow DOM, templates and the ability to create your own elements. It layers a declarative form of the same […]
Microdata, the Web Component Model and hybi-17 for Web Sockets « Peter Beverloo
October 18, 2011 at 1:52 am
[…] Fronteers ’11 Alex Russel gave a great talk about the Shadow DOM (presentation starting from slide […]
HTML Component Model & the Shadow DOM | Bram.us
October 25, 2011 at 7:09 am
A Great article on a great implementation of a great idea. I must love Web Components.
Can I translate this article to Japanese, to let Japanese web devs know better this?
大形尚弘 (@oogatta)
February 2, 2012 at 7:10 pm
Sure thing. Go for it.
Dimitri Glazkov
February 2, 2012 at 7:33 pm
[…] What the Heck is Shadow DOM? […]
A Short Simple Video Explaining the Shadow DOM and Web Components « Christian Cantrell
March 22, 2012 at 7:56 am
[…] to Dmitri Glazkov, Shadow DOM “refers to the ability of the browser to include a subtree of DOM elements into the rendering […]
Adobe Explains Shadow DOM And Web Components | WebProNews
March 22, 2012 at 9:35 am
[…] What the Heck is Shadow DOM? […]
Explanation of the Shadow DOM and Web Components – Short Video « Daniel Moore
March 22, 2012 at 4:30 pm
Reblogged this on YGeek!.
ygbr
May 6, 2012 at 9:54 am
[…] now, because the properties are vendor-prefixed (e.g. ::-webkit-scrollbar) and use the "Shadow DOM". This has been around for a couple of years. David Hyatt blogged it in early 2009 and put […]
Custom Scrollbars in WebKit | UmarHamzaOnline.Com
May 19, 2012 at 6:24 am
[…] the past year or so there has been much hype surrounding the shadow DOM and the new options it allows for styling standard elements such as […]
Inspecting the Shadow DOM in Google Chrome Inspector | Oliver Smith
May 19, 2012 at 7:27 am
[…] What the Heck is Shadow DOM?. That’s exactly my first question that came up in my head when I first heard about this. All the above examples I mentioned about are based on this WebKit only ability to control a shadow DOM subtree of an element. […]
CSS generated content on replaced elements - RedTeamDesign
June 19, 2012 at 10:01 pm
[…] eines Polyfills für Web Components (ihr wisst schon, Shadow DOM und so) und ein Adobe-Artikel zur Kombination von Shadow DOM und CSS3 […]
Revision 77: Do not Track, IHK-Petition und Web Components | Working Draft
June 27, 2012 at 1:24 am
[…] standpoint is that the HTML inserted into a document using web componets is included in the Shadow DOM not the regular HTML DOM. I wanted to check how this affects the use of ARIA roles, states and […]
Notes on Web Components + ARIA | The Paciello Group Blog
July 6, 2012 at 8:42 am
[…] now, because the properties are vendor-prefixed (e.g. ::-webkit-scrollbar) and use the “Shadow DOM“. This has been around for a couple of years. David Hyatt blogged it in early 2009 and put […]
Custom Scrollbars in WebKit | css3China.com
August 13, 2012 at 8:02 pm
[…] Wymądrzać się nie będę. Jeżeli interesuje was ten temat, zapraszam tutaj: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ […]
:after i :before - doman.art.pl
August 15, 2012 at 2:09 pm
[…] talk on the shadow DOM was great, it’s a very exciting topic which she devlivered with some steady-handed live […]
Scott Logic » JSConf EU 2012
October 12, 2012 at 8:41 am
[…] 표준을 제안해서 개발한 google의 Dimitri Glazkov가 shadow DOM의 이해를 돕기위해 What the Heck is Shadow DOM? 이라는 글을 자신의 블로그에 […]
HTML5 대한민국 관심그룹 18차회의를 다녀와서… | Wise Blog
October 15, 2012 at 1:04 am
I think that Shadow DOM can be used for hiding DOMs from the container page. However, malicious host pages can redefine WebKitShadowRoot object. For instance, page A at Host A has script B from Host B. Script B can use ShadowDOM to hide some DOMs from PageA. However, page A can redefine WebKitShowRoot objects to reveal information. I claim that WebKitShadowRoot must be non-over-writable like window and document objects. However, the current chrome browser does not support this. Please enlighten me if I am incorrect.
cssamuelson
October 22, 2012 at 11:00 am
cssamuelson@, As the spec explains (http://www.w3.org/TR/shadow-dom/#introduction), Shadow DOM is not meant to provide any security assurances. The boundaries it provides are for functional encapsulation. Having said that, there is a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509 filed on spec, which deals with the concept of “isolation”, or turning the functional boundary into a trust boundary.
Dimitri Glazkov
October 22, 2012 at 11:09 am
Thank you Glazkov for the immediate reply. Though, Shadow DOM is “NOT” meant for security assurance, obviously Shadow DOM can be used for hiding DOMs from the hosting page by making ShadowRoot inaccessible from the hosting page. There is no way for the hosting page to access Shadow DOMs unless going through ShadowRoot. I think that it is correct. Moreover, What goods can come from allowing redefinition of ShadowRoot object for the purpose of functional encapsulation ?
cssamuelson
October 22, 2012 at 11:42 am
[…] What the Heck is Shadow DOM?. That’s exactly my first question that came up in my head when I first heard about this. All the above examples I mentioned about are based on this WebKit only ability to control a shadow DOM subtree of an element. […]
CSS generated content on replaced elements | Создание сайтов во Владивостоке
November 11, 2012 at 3:05 am
[…] zumindest laut Peters Padawanen ein echtes Problem darstellt. Hans setzt Hoffnung in gestaltbares Shadow DOM bzw. das Web Component Model. Rodney meint, die sollen sich mal nicht so anstellen: Web-Zeug sieht […]
Revision 96: News, HTML5 und Links | Working Draft
November 14, 2012 at 1:28 pm
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | DigitalMofo
December 22, 2012 at 2:08 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | MyOfflineTheme.com Skyrocket Your Offline Business Just Now
December 22, 2012 at 2:29 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | Creative Online Journal by Emrah Akman
December 22, 2012 at 4:14 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013
December 22, 2012 at 7:45 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Today’s Links | JohnAspinall.co.uk
December 22, 2012 at 8:23 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 - Steve deGuzman
December 22, 2012 at 10:34 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 « Books
December 22, 2012 at 12:06 pm
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | Diancin Designs
December 22, 2012 at 10:59 pm
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 - Цялостни IT решения,bussines 2 bussines,Оферти,Обяви,Работа, Коли под наем,Rent A Car ,Уеб Дизайн,nternet access, hosting, web design, netwo
December 23, 2012 at 4:03 pm
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
UX News & Links December 24, 2012 | Erie Design Partners
December 24, 2012 at 2:14 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | Dank Logic
December 26, 2012 at 12:53 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | EasyWeb
December 26, 2012 at 7:52 am
[…] What the Heck is Shadow DOM? […]
Web Components On Google Developers Live Israel | Ido Green
January 2, 2013 at 10:50 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better FrontEnd Engineer In 2013 - rehavaPress
January 6, 2013 at 5:59 pm
[…] What the Heck is Shadow DOM? […]
Meet Shadow DOM – a New Kid in Town | samuli.hakoniemi.net
January 22, 2013 at 12:51 pm
[…] A great post on Shadow Dom from Dimitri Glazkov […]
Google Developers Live On Web Components (Part 2) | Ido Green
January 23, 2013 at 11:48 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 » 7D Interactive : Innovative Web Development & SEO in Maryland
February 19, 2013 at 5:24 am
[…] there any way to use these shadow dom elements to apply css only to a specific element. I’m thinking that I want the webkit customer […]
apply webkit scrollbar style to just textarea | BlogoSfera
March 6, 2013 at 4:04 pm
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
Change an input’s HTML5 placeholder color with CSS | Everyday I'm coding
March 12, 2013 at 2:07 am
[…] für Web Components gebaut. Rodney erklärt den Unterschied zwischen Web Components und Shadow DOM und den diversen Einzelteilen der jeweiligen […]
Revision 121: requestAutocomplete, Web Components, Offline-Detection | Working Draft
May 22, 2013 at 10:25 am
Hi,
The Document Object Model (DOM) is an API for HTML and XML documents. It provides a structural representation of the
document, enabling you to modify its content and visual presentation by using a scripting language such as JavaScript.
Which information given by you on DOM, very informative. So thanks for sharing your knowledge. There are few other link
that’s also helpful for developers.
http://www.mindstick.com/Articles/d4d10ebd-58c8-45a1-88f4-724497f7a36e/?JavaScript%20Document%20Object%20Model
http://msdn.microsoft.com/en-us/library/dd282900(v=vs.85).aspx
Alex Leblois
May 31, 2013 at 3:56 am
[…] components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit […]
Talks To Help You Become A Better Front-End Engineer In 2013 | Smashing Magazine
June 28, 2013 at 8:39 pm
[…] You can show the Shadow DOM inside the Chrome dev tools – it’s hidden behind the cog on the bottom right. There’s a great summary of what Shadow DOM actually is here. […]
Live blogging at WDCNZ 2013 | Xero Blog
July 24, 2013 at 8:27 pm
[…] Unfortunately you can’t style select elements generated by Safari and Chrome. What you’re dealing with has been coined Shadow DOM: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ […]
vertical alignment for FORM INPUT FIELDS in safari and chrome - CSS Solutions - Developers Q & A
July 26, 2013 at 11:11 pm
[…] What the Heck is Shadow DOM? Indeed. […]
Useful links: Shadow DOM, social media & Myers Briggs, | Web TeacherWeb Teacher
July 31, 2013 at 5:38 am
Reblogged this on Sahara Hacker.
Sam
August 5, 2013 at 5:57 am
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
Change an input’s color with CSS and HTML5 placeholder
August 5, 2013 at 6:21 am
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
Change an input's HTML5 placeholder color with CSS - oneuptime | oneuptime
August 26, 2013 at 2:14 am
[…] You can show the Shadow DOM inside the Chrome dev tools – it’s hidden behind the cog on the bottom right. There’s a great summary of what Shadow DOM actually is here. […]
Live blogging at WDCNZ 2013 - Accounting
August 29, 2013 at 11:48 am
Delete my prior comment since it won’t show HTML code. It was just saying that you seem to have an unnecessary DIV in the “gotta wear shades” example. Can’t it just be a P element with an ID of “foo” without needing a DIV around it?
Christian Z. (@ocmexfood)
September 10, 2013 at 4:03 pm
[…] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]
Hiding Native HTML5 Video Controls in Full-Screen Mode | Web Development, Search Engine Optimization, Social Media Marketing Guru
September 26, 2013 at 10:16 am
[…] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]
Beta Sites Galore | Hiding Native HTML5 Video Controls in Full-Screen Mode
September 26, 2013 at 10:37 am
[…] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]
Hiding Native HTML5 Video Controls in Full-Screen Mode - Abstract PHP
September 27, 2013 at 4:24 am
[…] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]
Hiding Native HTML5 Video Controls in Full-Screen Mode | Lunarium Design
September 27, 2013 at 6:30 am
[…] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]
Hiding Native HTML5 Video Controls in Full-Screen Mode | CSS Patterns
September 29, 2013 at 4:21 pm
There is a small mistake in the first JavaScript (var slider = document.getElementsById(“foo”);)
It should say “getElementById” without an “s”
André Jochim
May 1, 2014 at 10:43 pm
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
How to: Change an input's HTML5 placeholder color with CSS | SevenNet
November 20, 2014 at 6:45 pm
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
How to: Change an input's HTML5 placeholder color with CSS | Technical information for you
December 2, 2014 at 8:47 pm
[…] What the Heck is Shadow DOM? – Dimitri Glazkov […]
Panduan Mendesain Elemen-Elemen Formulir HTML dari Awal | DTE :]
December 5, 2014 at 10:33 pm
[…] the best implementation is still going on. Note the pseudo-elements act like real elements in the Shadow DOM. A padding on an input will not get the same background color as the […]
Solution: Change an input's HTML5 placeholder color with CSS #dev #it #computers | Good Answer
December 7, 2014 at 9:22 pm
[…] http://developer.mozilla.org/en/docs/Determining_the_dimensions_of_elements http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ http://answers.oreilly.com/topic/1819-how-to-change-an-elements-css-properties-with-javascript/ […]
Javascript Dom Articles - Khai's personal knowledge vault.
January 15, 2015 at 12:48 am
[…] Dimitri Glazkov on the Shadow DOM […]
Putting the “Aech” in HTML | aechcutt.com
March 13, 2015 at 12:42 pm
[…] We can also remove the controls from Safari, but differently than Firefox using a method that tackles the Shadow DOM: […]
Numeric Inputs – A Comparison of Browser Defaults | Lunarium Design
March 25, 2015 at 9:38 am
[…] also remove the controls from Safari, but differently than Firefox using a method that tackles the Shadow DOM […]
Numeric Inputs – A Comparison of Browser Defaults - A Geek's View
March 25, 2015 at 9:40 am
[…] We can also remove the controls from Safari, but differently than Firefox using a method that tackles the Shadow DOM: […]
Numeric Inputs – A Comparison of Browser Defaults | Idun Design
March 25, 2015 at 9:45 am
[…] We can also remove the controls from Safari, but differently than Firefox using a method that tackles the Shadow DOM: […]
Numeric Inputs – A Comparison of Browser Defaults - Daniele Milana
March 25, 2015 at 4:18 pm
[…] We can also remove the controls from Safari, but differently than Firefox using a method that tackles the Shadow DOM: […]
Numeric Inputs – A Comparison of Browser Defaults - Browser Zone
March 26, 2015 at 3:16 am
Reblogged this on Ruby on Rails Blog.
Karthikeyan
April 12, 2015 at 10:04 am
Reblogged this on thinkingruby.
railsfreak
April 12, 2015 at 1:52 pm
[…] What the Heck is Shadow DOM? […]
The shadow side of HTML
April 17, 2015 at 2:33 am
Reblogged this on gravitybrake.
gravitybrake
May 5, 2015 at 9:47 am
[…] This is only working in this order. You can not do ::after:hover because you can’t detect the hover over a pseudo element. That’s probably because it’s not a real element. It does not exist in the DOM. It’s only available in the so called Shadow DOM. […]
Why you can do :hover::after and not ::after:hover › Martin Wolf Front End Web Development
May 19, 2015 at 8:05 am
[…] What is the shadow DOM? […]
What is the shadow DOM? - Todd Gallimore
June 19, 2015 at 3:48 am
Reblogged this on cyberkrul and commented:
Shadow DOM …
cyberkrul
June 26, 2015 at 7:18 am
[…] What the Heck is Shadow DOM? […]
Styling SVG <use> Content with CSS » CSS 3 & HTML 5 Links und Infos
July 16, 2015 at 7:50 am
[…] What the Heck is Shadow DOM? […]
Styling SVG <use> Content with CSS - InfoLogs
July 16, 2015 at 10:00 am
[…] What the Heck is Shadow DOM? […]
Styling SVG <use> Content with CSS - Daniele Milana
July 16, 2015 at 3:14 pm
[…] accessible (well almost, there is a loop hole) by the scripts associated with the component, aka Shadow DOM. The styles rules would also only be applied locally. So basically we get fully separate and […]
I Ching App with Polymer and ES6 |
July 16, 2015 at 4:21 pm
[…] What the Heck is Shadow Dom? […]
Trying Out Polymer « maureen.l.davey
July 27, 2015 at 5:18 am
Dimitri Glazkov your page here was very informative. But better yet it was HILARIOUS. I like your writing style. I had to try not to laugh. It would have been interesting explaining my cackling to my non-IT nextdoor colleagues. :)
Bond James
July 28, 2015 at 7:18 am
[…] bit better now, because the properties are vendor-prefixed (e.g. ::-webkit-scrollbar) and use the "Shadow DOM". This has been around for a couple of years. David Hyatt blogged it in early 2009 and put together […]
Customizing -webkit Scrollbars! | Tony Collings' Technical Blog
August 12, 2015 at 8:21 am