- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sat, 03 Mar 2018 16:40:31 +0000
- To: public-css-archive@w3.org
> So in practice, at least to the implementations I know (WebKit / Blink / Servo / Gecko), it imposes the requirement of knowing where the selector has been declared / where the rule comes from, so we can know which shadow root does it come from / which shadow host matches it. I'm still not seeing this. The origin of the selector has *absolutely nothing* to do with this; it's purely about which element the ::part is descending from. As I explained in your examples earlier, a given part name can match an element from inside (`:host::part(bar)`) *or* outside (`x-foo::part(bar)`) a particular shadow tree, which shows that the tree context has no relevance here. (It just happens that, due to the way we've restricted selectors and shadow trees, a given element is only directly reachable from certain contexts.) If you store the part-name information on the target element, rather than the shadow host, then yeah, you'll need to store it as a (shadow host, part name) tuple, but that's still got nothing to do with the selector's context. ^_^ > Other question as I look more through this... Where do these rules fit in the cascade? After normal author rules? How do these interact with ::slotted, in particular where nested slots and forwarding interact? All those need to be well defined for the spec to be implementable. How selectors reaching across shadow trees work in the cascade is already well-defined by the Shadow DOM spec. Unless we specifically want some special effect, there is no need to define anything further. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2368#issuecomment-370161382 using your GitHub account
Received on Saturday, 3 March 2018 16:40:39 UTC