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

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

Received on Thursday, 22 December 2011 21:04:51 UTC