Dimitri has been doing mostly spec work recently, with a team of engineers based in Tokyo doing implementation work.

High level overview

Web Components is the big umbrella over:

• Shadow DOM : An API to expose functionality that already exists in WebKIt. You can hide some DOM elements.
• HTML Templates : Likely not its own spec (just part of HTML). Allows you to define inert chunks of DOM. A means to define document fragments declaritvely.
• Custom Elements : Allows developers to extend meaning and API surface of elements.
• Decorators : A way to add presentational qualities to existing DOM elements declaratively and transiently (based on style matching).

Shadow DOM

• Implementation underway in WebKit
• Mozilla is generally interested, but focused on Boot 2 Gecko for now
• Microsoft has showed interest as well. Shadow DOM is remininscent of HTC/behaviors. Windows 8 controls effectively have a fake Shadow DOM built in JS. They want this to solve that problem in the long term.
• Spec is very robust. Will likely push to Working Draft at F2F in May
• Running behind a flag. Only in Canary/Dev in Chrome (basically the Nightly builds)
• We will not ship and release to web at large until at least one other implementation in progress.

HTML Templates

• A lot of interest from web developers.
• Interesting issues to consider, especially around modifying the HTML parser behavior
• Working with Henry Sivonen (sp?) at Mozilla to investigate purely additive things to do to the parser to not break existing content
• Hoping to push small delta to HTML spec instead of its own spec.

Custom Elements

• A prototype built using JavaScript and Shadow DOM exists; still test-driving it to see how it feels
• Dimitri will be working on it this quarter to spec it up.
• There are some trivial pieces (mainly on JavaScript standard semantics), but there are some non-trivial pieces, like firing callback to modify objects (parallels to mutation event problems).

Decorators

• Least support for this piece. Some active detractors.
• Not crucial for Web Componets to exist.

Read the explainer document (​http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html). It's the high level document that informs the direction of the specs, then go back and update it after the specs have been written.

Q: Is there more movement to more controls being implemented in WebKit using Shadow DOM? A: It's definitely a better solution, using common infrastructure. All custom rendering in the media element is gone on trunk except for two cases. File upload also doesn't use it. Popup menus aren't shadow DOM and likely won't be (because it can go outside the browser window).

Detailed description

Shadow DOM

• For any given node, you can have a shadowRoot. You can have more than one of them, in a stack.
• Every shadowRoot is a document fragment that can have zero or more nodes of its own that define a DOM subtree.
• Those nodes are not accessible to the document tree (except through teh shadowRoot)
• Allows creating a sub-tree associated with an element but not presented as part of it in the DOM
• When rendering, there's an algorithm to render them as part of the document tree.
• Shadow DOM spec formalizes how they're composed, interact with the document, and what the encapsualtion boundaries are between the document and the shadow tree.
• This gives you the capability to add more rendering to an existing node. Example: a navigation bar with no content when viewed from the rest of the document, but renders, has styling, etc in reality.
• You to compose the logical DOM children of the node into the shadow DOM for rendering. Without this, all that would render would be in the shadow DOM.
• Insertion points are special nodes that allow you to specify "holes" in the shadow DOM where the logical children should render. For example, take the <aside> in the node and put it into a specific part of a flexbox in the shadow DOM.
• Insertion points are <content> nodes. Has a special attribute: "select". Allows you to specify a limited subset of CSS selectors. This is how you select which parts of the logical DOM children of the node are rendered in which <content> nodes.
• This allows you to create layout managers. So the navigation bar example could have two content areas: one area takes all <li>'s (that are not taken by the other), the other takes all the <li>'s with a class of 'login'.
• Another example: you pick out breaking news (via their class names), and put them in a special section at the top. No need to change markup (it's presentational anyway), just create two <content> nodes, one of which gets the breaking news and one of which gets the other content.
• This allows you to add extra controls and behaviors easily.

Q: When does the selector run and change the render tree (the DOM is NOT affected) A: It's live. When you change the relevant styling, it will show up in different parts as appropriate. There's a tab manager control exmaple. The DOM tree inside provided by the user of the component just have <header> and <section>. The tab strip control will dynamically change the select attribute of the <content> hole to select the selected tab. Link to example: ​http://dglazkov.github.com/Tabs/ (needs Shadow DOM enabled in Chrome's flags)

• HTMLContentElement is a sub-class of insertion point. That's necessary because there's a <shadow> element that's also an insertion point. Instead of grabbing stuff from outside, it grabs stuff from OTHER shadowRoots below in the stack. This allows you to add more styling around other things, including things that WebKit happens to implement with Shadow DOM (like HTMLInputElement).

Q: Does the Shadow DOM spec say which elements happen to use Shadow DOM in the browser's implication A: All the spec says is, there's a set of elements, and here's what their equivalent behavior should be. Some cases like <input> are easier; others like <video> are hard.

Q: What elements have a shadow in WebKit? A: Every input element. progress meter. details. audio/video. The others are specified "as if" they just have a single <content> element in their shadow root.

Q: Where there's a text field and something is added on "top" of it A: In the example, the button over the input goes to the right. There's a tree-flattening step where conceptually a DOM tree is produced to render (althoguh in reality it doesn't exist). Shadow insertion allows you to take whatever is below you WHOLESALE and if you want put stuff around it. Shadow doesn't have a select attribute--you take all of it or none. If you take none, the other shadowRoots become latent and don't render at all.

Q: How does this interact with event handling? Like in video? A: There's a notion of retargeting of events. We treat the boundary between shadowRoot and element as a place where the target of event changes. We don't want a guy on the outside to know the structure of the shadow. Today if you hit play in <video>, you'll get an event, but it will _look_ like a click on the video element.

Q: But how do you _let_ people see where it came from? A: When you build a Shadow DOM, you attach events directly to it. The component author decides which events to expose to the rest of the document (by creating an explicit event). But the user of the component can't get events that arent' chosen to be exposed. Some events don't bubble out. Mutation events are explicitly forbidden inside of shadow DOM (but mutation observers, the new one, do work).

• Selection is a beast, especially with multiple ranges. There is a serious discussion thave about this. rniwa would probably say, "no multiple selection". It gets complicated very quickly. Currently, if a selection starts in the shadow DOM, we can't expose it--because from the perspective of the doc nothing happened.

• If a component decides to expose its shadowRoot somewhere, then anyone can interact with it--it's just DOM. But by default the shadowRoot object isn't shared. IF it is, the containing page can do anything it wants. So if the component exposes any element, then you can walk up to the shadow DOM in the containing thing. The parentnode of the shadowRoot is null (although there is a host attribute that points to the document), to prevent accidentally walking back up into the document and exposing your root if you don't want to.

• All of the built in components are hermetically sealed by not exposing shadowRoot.
• You could build your component in a stack of shadows if you wanted to expose only part of your component.

Q: What about browser extensions being able to break encapsulation. A: Extensions need to be special for many reasons. There's something in Windows Presentation Framework (WPF) that's very similar with a Logical Tree. You can instantiate a LogicalTreeWalker and suddenly walk the whole tree, without encapsulation.

Q: Can you have multiple content notes with overlapping select selectors? A: There's a way to break ties: whoever's first in tree order (the youngest tree). The subset of CSS is basically any seletors that Don't affect nodes that select below the top-level children of the node. The rationale is fuzzy, but it might be that it's harder to do selection in some cases (perhaps in other implementations). Select already can have O(n^{2) behavior, so if you involve grandchildren it can get even more hairy. Performance testing will be important here.}

• Currently we're focusing on robustness. Using a fuzzer. We get a steady trickle constantly. Then we'll focus on performance.
• First week we ran it, we got <select> and <video> bugs all the time. All of these bugs are posted to crbug.com and upstreamed to WebKit.

• There is some remaining work we're holding off on (waiting for other implementors to provide feedback)
• One cool thing to add is a shared stylesheet. Important for widget toolkits--right now you'd have to have a <style> block in every instance of the component. Still don't have an elegant way to do this.

Q: This is all largely about convenience to developers. But what's the cost compared to just straightforward DOM? A: Don't know yet. But our goal is to not regress performance, to have comparable performance. Twitter's component model-like framework (Twitter Bootstrap) might be a good thing to compare against. Another could be comparison of a shadow DOM implementation of a complex element with a hardcoded implementaiton. Likely not as fast, but we should have a goal. A third one: the equivalent of a server-side script. The reality is that components exist in web development in the wild today, in a number of ad hoc strategies.

Q: Reference counted doubly linked lists (whicih this talk implies is used) should create a cycle. How do you do that? A: <no answer>

Q: have you verified GC doesn't lead us to hold onto roots we don't use? It can get complicated. A: That's why we want to have the hackathon tomorrow to go over the design issues. It's where really smart people can help us understand what areas to look into more closely, and how to improve overall readability of the design in WebKit. We ahve ideas on how to make that last one part.

Q: This whole thing sounds complicated. Can web authors use it? A: Very confident they can. People are already using it. There will be a layered understanding of it. Framework authors will know it better than the users of the frameworks. We built this because the status quo is MORE confusing for web developers. You have to create a parallel DOM structure that's basically just wrappers to allow something LIKE this to exist. It's way more complicated--and slow! Also, their parallel structures aren't compatible across frameworks,