W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Dimitri Glazkov <dglazkov@google.com>
Date: Wed, 21 Dec 2011 08:58:20 -0800
Message-ID: <CADh5Ky1aQjkXYqOoQ86bWxAyeJ5Wpp5XkZoAgNEBZK5bub02fg@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: "Edward O'Connor" <eoconnor@apple.com>, public-webapps@w3.org
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?


> -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 Wednesday, 21 December 2011 16:59:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC