- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Wed, 21 Dec 2011 08:58:20 -0800
- 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? :DG< > > -Brian > > On Dec 20, 2011 7:52 PM, "Edward O'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