Changes between Version 1 and Version 2 of WebComponentsStatusMeetingNotes


Ignore:
Timestamp:
Apr 19, 2012 9:49:08 PM (12 years ago)
Author:
paulirish@chromium.org
Comment:

formatting!

Legend:

Unmodified
Added
Removed
Modified

  • WebComponentsStatusMeetingNotes

    v1 v2  
    1010
    1111== Shadow DOM ==
    12 * Implementation underway in WebKit
    13 * Mozilla is generally interested, but focused on Boot 2 Gecko for now
    14 * 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.
    15 * Spec is very robust. Will likely push to Working Draft at F2F in May
    16 * Running behind a flag. Only in Canary/Dev in Chrome (basically the Nightly builds)
    17 * We will not ship and release to web at large until at least one other implementation in progress.
    18 
     12  * Implementation underway in WebKit
     13  * Mozilla is generally interested, but focused on Boot 2 Gecko for now
     14  * 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.
     15  * Spec is very robust. Will likely push to Working Draft at F2F in May
     16  * Running behind a flag. Only in Canary/Dev in Chrome (basically the Nightly builds)
     17  * We will not ship and release to web at large until at least one other implementation in progress.
     18 
    1919== HTML Templates ==
    20 * A lot of interest from web developers.
    21 * Interesting issues to consider, especially around modifying the HTML parser behavior
    22 * Working with Henry Sivonen (sp?) at Mozilla to investigate purely additive things to do to the parser to not break existing content
    23 * Hoping to push small delta to HTML spec instead of its own spec.
    24 
     20 
     21  * A lot of interest from web developers.
     22  * Interesting issues to consider, especially around modifying the HTML parser behavior
     23  * Working with Henry Sivonen (sp?) at Mozilla to investigate purely additive things to do to the parser to not break existing content
     24  * Hoping to push small delta to HTML spec instead of its own spec.
     25 
    2526== Custom Elements ==
    26 * A prototype built using JavaScript and Shadow DOM exists; still test-driving it to see how it feels
    27 * Dimitri will be working on it this quarter to spec it up.
    28 * 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).
    29 
     27  * A prototype built using JavaScript and Shadow DOM exists; still test-driving it to see how it feels
     28  * Dimitri will be working on it this quarter to spec it up.
     29  * 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).
     30 
    3031== Decorators ==
    31 * Least support for this piece. Some active detractors.
    32 * Not crucial for Web Componets to exist.
     32  * Least support for this piece. Some active detractors.
     33  * Not crucial for Web Componets to exist.
    3334
    3435Read 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.
    … …  
    4041
    4142== Shadow DOM ==
    42 * For any given node, you can have a shadowRoot. You can have more than one of them, in a stack.
    43 * Every shadowRoot is a document fragment that can have zero or more nodes of its own that define a DOM subtree.
    44 * Those nodes are '''not''' accessible to the document tree (except through teh shadowRoot)
    45 * Allows creating a sub-tree associated with an element but not presented as part of it in the DOM
    46 * When rendering, there's an algorithm to render them as part of the document tree.
    47 * 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.
    48 * 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.
    49 * 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.
    50 * 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.
    51 * 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.
    52 * 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'.
    53 * 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.
    54 * This allows you to add extra controls and behaviors easily.
     43  * For any given node, you can have a shadowRoot. You can have more than one of them, in a stack.
     44  * Every shadowRoot is a document fragment that can have zero or more nodes of its own that define a DOM subtree.
     45  * Those nodes are '''not''' accessible to the document tree (except through teh shadowRoot)
     46  * Allows creating a sub-tree associated with an element but not presented as part of it in the DOM
     47  * When rendering, there's an algorithm to render them as part of the document tree.
     48  * 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.
     49  * 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.
     50  * 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.
     51  * 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.
     52  * 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.
     53  * 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'.
     54  * 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.
     55  * This allows you to add extra controls and behaviors easily.
    5556
    5657Q: When does the selector run and change the render tree (the DOM is NOT affected)
    … …  
    5859Link to example: http://dglazkov.github.com/Tabs/ (needs Shadow DOM enabled in Chrome's flags)
    5960
    60 * 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).
     61  * 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).
    6162
    6263Q: Does the Shadow DOM spec say which elements happen to use Shadow DOM in the browser's implication
    … …  
    7576A: 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). 
    7677
    77 * 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.
     78  * 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.
     79 
     80  * 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.
    7881
    79 * 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.
    80 
    81 * All of the built in components are hermetically sealed by not exposing shadowRoot.
    82 * You could build your component in a stack of shadows if you wanted to expose only part of your component.
     82  * All of the built in components are hermetically sealed by not exposing shadowRoot.
     83  * You could build your component in a stack of shadows if you wanted to expose only part of your component.
    8384
    8485Q: What about browser extensions being able to break encapsulation.
    … …  
    8889A: 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.
    8990
    90 * Currently we're focusing on robustness. Using a fuzzer. We get a steady trickle constantly. Then we'll focus on performance.
    91 * 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.
    92 
    93 * There is some remaining work we're holding off on (waiting for other implementors to provide feedback)
    94 * 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.
     91  * Currently we're focusing on robustness. Using a fuzzer. We get a steady trickle constantly. Then we'll focus on performance.
     92  * 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.
     93 
     94  * There is some remaining work we're holding off on (waiting for other implementors to provide feedback)
     95  * 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.
    9596
    9697Q: This is all largely about convenience to developers. But what's the cost compared to just straightforward DOM?
    … …  
    106107A: 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,
    107108
    108