Re: [webcomponents]: First draft of the Shadow DOM Specification

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.

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:
>
>
> <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).

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

Received on Thursday, 22 December 2011 20:15:44 UTC