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=foo><content></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>
<p>Ole!</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:
>> >> >
>> >> >
>> >> > <div>A</div>
>> >> >
>> >> > <shadow-boundary>
>> >> >
>> >> > <div>B</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>
>> >> >
>> >> > <div>C</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 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 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
>> >> >> >>
>> >> >> >> 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
>> >> >> >>
>> >> >> >
>> >
>> >
>
>
