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:


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



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