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

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