Dimitri Glazkov

Web and About

What the Heck is Shadow DOM?

with 107 comments

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:

Typical Slider Control on WebKit

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:

WebKit Video Element With Controls

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:

Shadow DOM Example

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:

Slider with a custom-styled track

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:

Fully custom-styled slider

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:

Input Element and Nothing Else

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.

Written by Dimitri Glazkov

January 14, 2011 at 4:40 pm

Posted in WebKit

Tagged with , , ,

107 Responses

Subscribe to comments with RSS.

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

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

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

  4. Wow, really cool. I didn’t know this until now :D

    Kurtextrem

    January 15, 2011 at 9:59 am

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

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

  7. [...] 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

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

  9. [...] reading “What the Heck is Shadow DOM?” I was inspired to see how far I could style the <input type="range"> element. [...]

  10. [...] 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 [...]

  11. [...] What the Heck is Shadow DOM? « Dimitri Glazkov An interesting article about the hidden elements in the DOM. (tags: shadow dom javascript html) [...]

  12. [...] What the heck is Shadow DOM? [...]

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

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

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

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

  17. [...] 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

  18. [...] here to read the rest: The Shadow DOM No Responses to “The [...]

  19. So the SVG shadow DOM is shy?

    Stephan

    January 21, 2011 at 1:19 am

  20. [...] 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 [...]

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

  22. Dịch vụ rút gọn link của goolge
    http://goo.gl/g2DdB

    namluong

    January 21, 2011 at 11:44 pm

  23. [...] Originally posted from: The Shadow DOM [...]

  24. [...] Direct Link to Article — Permalink [...]

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

  26. [...] What the Heck is Shadow DOM? at Dimitri Glazkov (tagged: javascript css html5 webdev DOM ) [...]

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

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

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

  30. [...] 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 [...]

  31. [...] 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 [...]

  32. [...] 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 [...]

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

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

  35. [...] WHATWG wiederum möchte mit dem Component Model den Wildwuchs in Sachen Shadow DOM beseitigen und standardisierte Schnittstellen zum Befüllen desselben [...]

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

  37. [...] 最近になって再びスクロールバーをカスタマイズすることが出来るようになりましたが、今回は非標準CSSではなくWebKitを使うことになります。プロパティはベンダープレフィックス(::-webkit-scrollbarなど)で、シャドウDOMを使用しています。この方法が使われるようになって数年経ちますが、ディビッド・ハイアットさんが2009年の初めにブログで記事にしており、考え付くであろう全てのサンプルを掲載されています。 [...]

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

  39. [...] What the Heck is Shadow DOM? – Dimitri Glazkov [...]

  40. [...] 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 [...]

  41. [...] Fronteers ’11 Alex Russel gave a great talk about the Shadow DOM (presentation starting from slide [...]

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

  43. [...] to Dmitri Glazkov, Shadow DOM “refers to the ability of the browser to include a subtree of DOM elements into the rendering [...]

  44. [...] What the Heck is Shadow DOM? [...]

  45. Reblogged this on YGeek!.

    ygbr

    May 6, 2012 at 9:54 am

  46. [...] 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 [...]

  47. [...] 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 [...]

  48. [...] 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. [...]

  49. [...] eines Polyfills für Web Components (ihr wisst schon, Shadow DOM und so) und ein Adobe-Artikel zur Kombination von Shadow DOM und CSS3 [...]

  50. [...] 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 [...]

  51. [...] 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 [...]

  52. [...] 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/ [...]

  53. [...] talk on the shadow DOM was great, it’s a very exciting topic which she devlivered with some steady-handed live [...]

  54. [...] 표준을 제안해서 개발한 google의 Dimitri Glazkov가 shadow DOM의 이해를 돕기위해 What the Heck is Shadow DOM? 이라는 글을 자신의 블로그에 [...]

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

  56. [...] 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. [...]

  57. [...] 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 [...]

  58. [...] 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 [...]

  59. [...] 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 [...]

  60. [...] 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 [...]

  61. [...] 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 [...]

  62. [...] 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 [...]

  63. [...] 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 [...]

  64. [...] 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 [...]

  65. [...] 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 [...]

  66. [...] 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 [...]

  67. [...] 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 [...]

  68. [...] 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 [...]

  69. [...] 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 [...]

  70. [...] What the Heck is Shadow DOM? [...]

  71. [...] 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 [...]

  72. [...] What the Heck is Shadow DOM? [...]

  73. [...] A great post on Shadow Dom from Dimitri Glazkov [...]

  74. [...] 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 [...]

  75. [...] 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 [...]

  76. [...] 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 [...]

  77. […] für Web Components gebaut. Rodney erklärt den Unterschied zwischen Web Components und Shadow DOM und den diversen Einzelteilen der jeweiligen […]

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

  79. […] 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 […]

  80. […] 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. […]

  81. […] 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/ […]

  82. […] What the Heck is Shadow DOM? Indeed. […]

  83. Reblogged this on Sahara Hacker.

    Sam

    August 5, 2013 at 5:57 am

  84. […] 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 […]

  85. […] 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 […]

  86. […] 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. […]

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

  88. […] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]

  89. […] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]

  90. […] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]

  91. […] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]

  92. […] reading this superb intro article by Dimitri Glazkov I learned that “there’s a handy pseudo attribute capability, which […]

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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 33 other followers

%d bloggers like this: