Re: [webcomponents]: First draft of the Shadow DOM Specification
In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? Sure. Since Alice's shadow DOM subtree is added later than Bob's, his tree is older than hers. The way shadow insertion point works, it looks for an older tree in the tree stack, hosted by the ul element. In this case, the older tree is Bob's. Thus, Bob's entire shadow DOM tree is inserted in place of the shadow element. Does that make more sense? What can I do to improve the example? A diagram perhaps? Please file a bug with ideas. also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. In this particular case, since both Bob and Alice use DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Dec 23, 2011 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? Sure. Since Alice's shadow DOM subtree is added later than Bob's, his tree is older than hers. The way shadow insertion point works, it looks for an older tree in the tree stack, hosted by the ul element. In this case, the older tree is Bob's. Thus, Bob's entire shadow DOM tree is inserted in place of the shadow element. Does that make more sense? What can I do to improve the example? A diagram perhaps? Please file a bug with ideas. Hmmm. So if you say document.createElement('shadow') it actually gives you a reference to the most recently added shadow hosted by the same element? It doesn't really create? What if you did that and there were none? Would it throw? Seems kind of tough to wrap my head around let me think about it some more and I will file a bug if I have any ideas. also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. In this particular case, since both Bob and Alice use DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. A handler attached to DOMContentLoaded doesn't block painting... That doesn't sound right to me... It might be generally faster than people notice, but it still depends right? In practice a lot of css is already applied at that point...yeah? You could still get fouc right? :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG On Dec 23, 2011 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? Sure. Since Alice's shadow DOM subtree is added later than Bob's, his tree is older than hers. The way shadow insertion point works, it looks for an older tree in the tree stack, hosted by the ul element. In this case, the older tree is Bob's. Thus, Bob's entire shadow DOM tree is inserted in place of the shadow element. Does that make more sense? What can I do to improve the example? A diagram perhaps? Please file a bug with ideas. also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. In this particular case, since both Bob and Alice use DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Fri, Dec 23, 2011 at 10:37 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 23, 2011 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? Sure. Since Alice's shadow DOM subtree is added later than Bob's, his tree is older than hers. The way shadow insertion point works, it looks for an older tree in the tree stack, hosted by the ul element. In this case, the older tree is Bob's. Thus, Bob's entire shadow DOM tree is inserted in place of the shadow element. Does that make more sense? What can I do to improve the example? A diagram perhaps? Please file a bug with ideas. Hmmm. So if you say document.createElement('shadow') it actually gives you a reference to the most recently added shadow hosted by the same element? It doesn't really create? What if you did that and there were none? Would it throw? Seems kind of tough to wrap my head around let me think about it some more and I will file a bug if I have any ideas. No, in DOM you don't get any references to other shadows. You get an HTMLShadowElement, which is a DOM element that represents a shadow insertion point. From the DOM perspective, it will always look like an HTMLShadowElement: no more, no less. The replacement only happens when rendering. And yep, this is a newish concept in the Web platform. also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. In this particular case, since both Bob and Alice use DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. A handler attached to DOMContentLoaded doesn't block painting... That doesn't sound right to me... It might be generally faster than people notice, but it still depends right? In practice a lot of css is already applied at that point...yeah? You could still get fouc right? Right! All standard good Web development practices still apply. :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG On Dec 23, 2011 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree under the election story box. root.appendChild(document.createElement('shadow')); Is that wrong? If not, can you explain it? Sure. Since Alice's shadow DOM subtree is added later than Bob's, his tree is older than hers. The way shadow insertion point works, it looks for an older tree in the tree stack, hosted by the ul element. In this case, the older tree is Bob's. Thus, Bob's entire shadow DOM tree is inserted in place of the shadow element. Does that make more sense? What can I do to improve the example? A diagram perhaps? Please file a bug with ideas. also... How does this patter give browsers timely enough information to avoid fouc? It feels like there is a piece missing.. In this particular case, since both Bob and Alice use DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note : That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script document.addEventListener(DOMContentLoaded, function(){ console.log(main...); console.log(divs in the document: + document.querySelectorAll(div).length); }); /script What is the expected console output? -Brian On Dec 21, 2011 11:58 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? In short, yup. I do need to write a nice example that shows how it all fits together (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173). Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all over...or is that what you were specifically trying to avoid with your distinction about the type of boundary? Anything special there about blocking for stylesheets or script? Also, I might have missed this, but it seems like you would still have access to document object? I understand its not a security related boundary you are describing but would it be possible to just evaluate the meaning of document based on your position so as to avoid the confusion that will likely cause? There are no workers or any special considerations for things that aren't mentioned. It is just a DOM subtree. I wonder if there's a convention of stating this somehow without actually re-describing how HTML/DOM works? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? :DG -Brian On Dec 20, 2011 7:52 PM, Edward Oapos;Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would
Re: [webcomponents]: First draft of the Shadow DOM Specification
Good job! https://bugzilla.mozilla.org/show_bug.cgi?id=712622 On 12/21/2011 01:23 AM, Dimitri Glazkov wrote: Happy Holidays! In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html It's not quite a Christmas miracle, more like that extra unlabeled gift box you found in the drapes while breaking down the tree. Perhaps uncle Herman forgot to use proper glue. Or maybe it's from Santa. Who knows. Please feel encouraged to use your holiday downtime to look over the spec and file bugs. 3 XOXO3 :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Ohh, I think I understand the problem. Let me say it back to see if I do: * The upper-boundary encapsulation (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation) constraints do not mention CSSOM extensions to Document interface (http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface). * They should be included to the constraints to also say that you can't access stylesheets in shadow DOM subtrees. This also implies that style blocks, defined inside of a shadow DOM subtree should have no effect on the document, and unless the style block has a scoped attribute, it should have no effect inside of a shadow DOM subtree, either. Right? (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15314). Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script document.addEventListener(DOMContentLoaded, function(){ console.log(main...); console.log(divs in the document: + document.querySelectorAll(div).length); }); /script What is the expected console output? shadowRoot doesn't fire DOMContentLoaded, so the output will be: main... divs in the document: 2 There's also an interesting issue of when (and whether) script executes inside of a shadow DOM subtree (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15313 to track). :DG -Brian On Dec 21, 2011 11:58 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? In short, yup. I do need to write a nice example that shows how it all fits together (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173). Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all over...or is that what you were specifically trying to avoid with your distinction about the type of boundary? Anything special there about blocking for stylesheets or script? Also, I might have missed this, but it seems like you would still have access to document object? I understand its not a security related boundary you are describing but would it be possible to just evaluate the meaning of document based on your position so as to avoid the confusion that will likely cause? There are no workers or any special considerations for things that aren't mentioned. It is just a DOM subtree. I wonder if there's a convention of stating this somehow without actually re-describing how HTML/DOM works? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? :DG -Brian On Dec 20, 2011 7:52 PM, Edward Oapos;Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Ohh, I think I understand the problem. Let me say it back to see if I do: * The upper-boundary encapsulation ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation ) constraints do not mention CSSOM extensions to Document interface (http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface). * They should be included to the constraints to also say that you can't access stylesheets in shadow DOM subtrees. Yes! You might also consider adding them to the ShadowRoot since I see no real reason why they are relevant at the document level, but not at the ShadowRoot level. Either way it would implications for CSSOM implementation and possibly the draft - it should be linked like the other references. I think Anne is still listed as the editor there, but that's not right if I recall... Maybe cross post it? This also implies that style blocks, defined inside of a shadow DOM subtree should have no effect on the document, and unless the style block has a scoped attribute, it should have no effect inside of a shadow DOM subtree, either. Right? (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15314). Yes. That was definitely part of what I was wondering... Explicitly calling out those details about style blocks would definitely be helpful - I assumed that anything inside a shadow DOM would be assumed to be scoped. Either way, reasonable people could interpret it differently so best to call it out lest the worst possible thing happens and browsers implement it differently :) Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script document.addEventListener(DOMContentLoaded, function(){ console.log(main...); console.log(divs in the document: + document.querySelectorAll(div).length); }); /script What is the expected console output? shadowRoot doesn't fire DOMContentLoaded, so the output will be: main... divs in the document: 2 There's also an interesting issue of when (and whether) script executes inside of a shadow DOM subtree (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15313 to track). Yeah that's the nature of the question - whether it acts as sort of a document within a document firing DOMContentLoaded, etc - or whether there is a way to do effectively the same thing - when scripts execute, whether they block, etc. I'm not sure what you mean by whether - the whole events section really seems to imply that it must Did I misread? :DG -Brian On Dec 21, 2011 11:58 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? In short, yup. I do need to write a nice example that shows how it all fits together (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173). Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Ohh, I think I understand the problem. Let me say it back to see if I do: * The upper-boundary encapsulation (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation) constraints do not mention CSSOM extensions to Document interface (http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface). * They should be included to the constraints to also say that you can't access stylesheets in shadow DOM subtrees. Yes! You might also consider adding them to the ShadowRoot since I see no real reason why they are relevant at the document level, but not at the ShadowRoot level. Either way it would implications for CSSOM implementation and possibly the draft - it should be linked like the other references. I think Anne is still listed as the editor there, but that's not right if I recall... Maybe cross post it? This also implies that style blocks, defined inside of a shadow DOM subtree should have no effect on the document, and unless the style block has a scoped attribute, it should have no effect inside of a shadow DOM subtree, either. Right? (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15314). Yes. That was definitely part of what I was wondering... Explicitly calling out those details about style blocks would definitely be helpful - I assumed that anything inside a shadow DOM would be assumed to be scoped. Either way, reasonable people could interpret it differently so best to call it out lest the worst possible thing happens and browsers implement it differently :) Sounds good. Keep an eye on the bug for updates. Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script document.addEventListener(DOMContentLoaded, function(){ console.log(main...); console.log(divs in the document: + document.querySelectorAll(div).length); }); /script What is the expected console output? shadowRoot doesn't fire DOMContentLoaded, so the output will be: main... divs in the document: 2 There's also an interesting issue of when (and whether) script executes inside of a shadow DOM subtree (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15313 to track). Yeah that's the nature of the question - whether it acts as sort of a document within a document firing DOMContentLoaded, etc - or whether there is a way to do effectively the same thing - when scripts execute, whether they block, etc. I'm not sure what you mean by whether - the whole events section really seems to imply that it must Did I misread? Shadow DOM subtrees are somewhere in between being documents within a document and just detached chunks of DOM, but they are somewhat closer to just chunks. They are part of the document, and their only differences from any chunk of DOM are minimized to provide reasonable behavior when rendering them. Think of it as I used to have no way to demarcate the boundaries around my FunkyMultiStateButtonTextInput widget, and now I do!. It doesn't make yer FunkyMultiStateButtonTextInput a document though :) :DG :DG -Brian On Dec 21, 2011 11:58 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary
Re: [webcomponents]: First draft of the Shadow DOM Specification
So... I was going to ask a follow up here but as I tried to formulate I went back to the draft and it became kind of clear that I don't actually understand shadow or content elements at all... ShadowRoot has a constructor, but it doesn't seem to have anything in its signature that would give you a shadow or content element (unless maybe they return node lists that are actually specialized kinds of nodes?)... It seems like all of the examples are using fictional markup where I think the draft is actually saying a scripted API is required to create... Is that right? If so, it would be great to have some kind of scripted example, even if it is really basic for discussion... If not.. well... my re-read seems to have gotten me a little lost. -Brian On Thu, Dec 22, 2011 at 4:04 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Ohh, I think I understand the problem. Let me say it back to see if I do: * The upper-boundary encapsulation ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation ) constraints do not mention CSSOM extensions to Document interface (http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface). * They should be included to the constraints to also say that you can't access stylesheets in shadow DOM subtrees. Yes! You might also consider adding them to the ShadowRoot since I see no real reason why they are relevant at the document level, but not at the ShadowRoot level. Either way it would implications for CSSOM implementation and possibly the draft - it should be linked like the other references. I think Anne is still listed as the editor there, but that's not right if I recall... Maybe cross post it? This also implies that style blocks, defined inside of a shadow DOM subtree should have no effect on the document, and unless the style block has a scoped attribute, it should have no effect inside of a shadow DOM subtree, either. Right? (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15314). Yes. That was definitely part of what I was wondering... Explicitly calling out those details about style blocks would definitely be helpful - I assumed that anything inside a shadow DOM would be assumed to be scoped. Either way, reasonable people could interpret it differently so best to call it out lest the worst possible thing happens and browsers implement it differently :) Sounds good. Keep an eye on the bug for updates. Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script document.addEventListener(DOMContentLoaded, function(){ console.log(main...); console.log(divs in the document: + document.querySelectorAll(div).length); }); /script What is the expected console output? shadowRoot doesn't fire DOMContentLoaded, so the output will be: main... divs in the document: 2 There's also an interesting issue of when (and whether) script executes inside of a shadow DOM subtree (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15313 to track). Yeah that's the nature of the question - whether it acts as sort of a document within a document firing DOMContentLoaded, etc - or whether there is a way to do effectively the same thing - when scripts execute, whether they block, etc. I'm not sure what you mean by whether - the whole events
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Thu, Dec 22, 2011 at 1:56 PM, Brian Kardell bkard...@gmail.com wrote: So... I was going to ask a follow up here but as I tried to formulate I went back to the draft and it became kind of clear that I don't actually understand shadow or content elements at all... ShadowRoot has a constructor, but it doesn't seem to have anything in its signature that would give you a shadow or content element (unless maybe they return node lists that are actually specialized kinds of nodes?)... content and shadow elements are just HTML elements: var shadow = document.createElement(shadow); So you can do this: var div = document.body.appendChild(document.createElement(div)); var root = new ShadowRoot(div); var divInShadow = root.appendChild(document.createElement(div)); divInShadow.innerHTML = span class=foocontent/content/span; And then when: div.appendChild(document.createElement(p)).textContent = Ole!; Wll give you the following composition when rendering: body div div -- that's divInShadow -- span class=foo pOle!/p -- goes in place of content -- /span /div /div /body It seems like all of the examples are using fictional markup where I think the draft is actually saying a scripted API is required to create... Is that right? If so, it would be great to have some kind of scripted example, even if it is really basic for discussion... If not.. well... my re-read seems to have gotten me a little lost. Yep, need at least one example -- https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173 :DG -Brian On Thu, Dec 22, 2011 at 4:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? CSSOM interfaces are attached to the document specifically though - right? And they (at least that I can recall) have no association concept with scope (yet)... So I think that implies that unless you added at least the stylesheets collection to the ShadowRoot, it would be kind of non-sensical unless it is smart enough to figure out that when you say document inside a shadow boundary, you really mean the shadow root (but that seems to conflict with the rest of my reading). Ohh, I think I understand the problem. Let me say it back to see if I do: * The upper-boundary encapsulation (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation) constraints do not mention CSSOM extensions to Document interface (http://dev.w3.org/csswg/cssom/#extensions-to-the-document-interface). * They should be included to the constraints to also say that you can't access stylesheets in shadow DOM subtrees. Yes! You might also consider adding them to the ShadowRoot since I see no real reason why they are relevant at the document level, but not at the ShadowRoot level. Either way it would implications for CSSOM implementation and possibly the draft - it should be linked like the other references. I think Anne is still listed as the editor there, but that's not right if I recall... Maybe cross post it? This also implies that style blocks, defined inside of a shadow DOM subtree should have no effect on the document, and unless the style block has a scoped attribute, it should have no effect inside of a shadow DOM subtree, either. Right? (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15314). Yes. That was definitely part of what I was wondering... Explicitly calling out those details about style blocks would definitely be helpful - I assumed that anything inside a shadow DOM would be assumed to be scoped. Either way, reasonable people could interpret it differently so best to call it out lest the worst possible thing happens and browsers implement it differently :) Sounds good. Keep an eye on the bug for updates. Now that I am going back through based on your question above I am thinking that I might have misread...Can you clarify my understanding... Given a document like this: divA/div shadow-boundary divB/div script shadowRoot.addEventListener('DOMContentLoaded', function(){ console.log(shadow...); console.log(divs in the document: + document.querySelectorAll(div).length); console.log(divs in the shadow boundary: + shadowRoot.querySelectorAll('div').length); },false); /script /shadow-boundary divC/div script
Re: [webcomponents]: First draft of the Shadow DOM Specification
BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? In short, yup. I do need to write a nice example that shows how it all fits together (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173). Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all over...or is that what you were specifically trying to avoid with your distinction about the type of boundary? Anything special there about blocking for stylesheets or script? Also, I might have missed this, but it seems like you would still have access to document object? I understand its not a security related boundary you are describing but would it be possible to just evaluate the meaning of document based on your position so as to avoid the confusion that will likely cause? There are no workers or any special considerations for things that aren't mentioned. It is just a DOM subtree. I wonder if there's a convention of stating this somehow without actually re-describing how HTML/DOM works? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... ShadowRoot is a Node, so all of the typical DOM accessors apply. Is this what you had in mind? :DG -Brian On Dec 20, 2011 7:52 PM, Edward Oapos;Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Anyway, thanks for the writeup, and have a wonderful break! Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
[webcomponents]: First draft of the Shadow DOM Specification
Happy Holidays! In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html It's not quite a Christmas miracle, more like that extra unlabeled gift box you found in the drapes while breaking down the tree. Perhaps uncle Herman forgot to use proper glue. Or maybe it's from Santa. Who knows. Please feel encouraged to use your holiday downtime to look over the spec and file bugs. 3 XOXO 3 :DG
Re: [webcomponents]: First draft of the Shadow DOM Specification
Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Anyway, thanks for the writeup, and have a wonderful break! Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
Re: [webcomponents]: First draft of the Shadow DOM Specification
On 12/20/11 4:49 PM, Edward O'Connor wrote: #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Would you expand more on that non-shadow-DOM-specific idea? In the meantime, I'm happy with the ::shadow(controls) selector.
Re: [webcomponents]: First draft of the Shadow DOM Specification
On Tue, Dec 20, 2011 at 4:49 PM, Edward O'Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls Oooh, good catch. I actually haven't specified a method for addressing shadow DOM elements in the subtree yet. That's bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15196 (or thereabouts). I need to rewrite the example to not use that plumbing (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15288). I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) Yes, I like that. Need to talk with the CSS people and get this done. There are also CSS Variables that could fit into this shape. could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Anyway, thanks for the writeup, and have a wonderful break! You're welcome! And everyone, please note that reading this spec is an excellent excuse for hiding from your in-laws or getting out of that annual Mall of America family shopping marathon. :DG Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
Re: [webcomponents]: First draft of the Shadow DOM Specification
Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs inheritance I think would be made especially easier to understand with a good example. I think it is saying that a rule based on the selector 'div' would not apply to div inside the shadow tree, but whatever the font size is at that point in the calculation when it crosses over is maintained...is that right? Is there any implication here beyond events? For example, do shadow doms run in a kind of worker or something to allow less worry of stomping all over...or is that what you were specifically trying to avoid with your distinction about the type of boundary? Anything special there about blocking for stylesheets or script? Also, I might have missed this, but it seems like you would still have access to document object? I understand its not a security related boundary you are describing but would it be possible to just evaluate the meaning of document based on your position so as to avoid the confusion that will likely cause? One more thing... Is there any CSSOM or like access on ShadowRoot? It feels like there should be... -Brian On Dec 20, 2011 7:52 PM, Edward Oapos;Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding upstairs at my in-law's house next week. That said, I wanted to quickly note something I noticed while skimming this just now. In your Event Retargeting Example[1], you have a pseudo= attribute which allows the author of the shadow DOM to specify the name of a pseudo-element which will match that element. For example, in div id=player shadow-boundary div pseudo=controls … /div /shadow-boundary /div the web author would be able to select the player's controls by writing #player::controls I'm worried that users may stomp all over the CSS WG's ability to mint future pseudo-element names. I'd rather use a functional syntax to distinguish between custom, user-defined pseudo-elements and engine-supplied, CSS WG-blessed ones. Something like #player::shadow(controls) or #player::custom(controls) could do the trick. The latter (or some other, non-shadow-DOM-specific name) is potentially more exciting because there may be more use cases for author-supplied pseudo-elements than just the shadow DOM. For instance, I could imagine an extension to DOM Range which would allow a user to name a range for selector matching. Anyway, thanks for the writeup, and have a wonderful break! Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example