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