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

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?

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?

One more thing... Is there any CSSOM or like access on ShadowRoot?  It
feels like there should be...

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