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 <dglazkov@chromium.org>wrote:

> On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell <bkardell@gmail.com>
> wrote:
> >
> >
> > On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov <dglazkov@chromium.org>
> > wrote:
> >>
> >> On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell <bkardell@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" <dglazkov@google.com>
> wrote:
> >> >>
> >> >> On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell <bkardell@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&apos;Connor" <
> eoconnor@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
> >> >> >>
> >> >> >
> >
> >
>