This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At a recent discussion, a ':context()' pseudo class was proposed. A ':context' pseudo class could replace @host rules. I've written a proposal about how a ':context' pseudo class should behave.: https://docs.google.com/document/d/1Az5JGK3EiBkH6zjx7U_RQrdTWYdC7vnK866Yt6dYTAs/edit?usp=sharing I appreiciate any comments.
ping? Any comments?
(In reply to comment #1) > ping? Any comments? We just had a f2f on Friday and slightly tweaked the names. The ::context() is going to be called ::host(). I'll post more on public-webapps today. http://www.w3.org/2013/06/21-webapps-minutes.html
:host(), of course. (one colon, not two). Full details: :host (no parentheses) matches the host element. (Kinda like :root, but for the shadow tree rather than the document.) :host(<compound-selector>) attempts to match the selector against each element in the fully-composed ancestor list, starting from and including the host element, ending in the document root. It matches the host element if the compound selector successfully matches against anything. :host() (empty argument) is identical to :host(*), which is identical to :host - they match the host element unconditionally.
In the f2f on this last Friday, we decided that :host should *not* allow combinators, as Tab noted. The idea is that from a given shadowRoot, it's important to be able to glean some information about the composed tree (for example, does it match an important theming selector), but it's brittle to rely on composed tree structure (is A inside of B) because its details may change and shouldn't be known to a given shadowRoot. Hayato-san, in your document, it looks like you're proposing that :host allow combinators as long as they match within the host scope. That's an interesting restriction and addresses the concern above, but my sense is that the additional expressiveness is offset by the arcane host scope matching behavior.
(In reply to comment #4) > In the f2f on this last Friday, we decided that :host should *not* allow > combinators, as Tab noted. > > The idea is that from a given shadowRoot, it's important to be able to glean > some information about the composed tree (for example, does it match an > important theming selector), but it's brittle to rely on composed tree > structure (is A inside of B) because its details may change and shouldn't be > known to a given shadowRoot. > > Hayato-san, in your document, it looks like you're proposing that :host > allow combinators as long as they match within the host scope. That's an > interesting restriction and addresses the concern above, but my sense is > that the additional expressiveness is offset by the arcane host scope > matching behavior. Yes, we do *not* want combinators, even if they're just parent or descendant combinators. We're matching against the fully composed ancestor list, which includes the shadow trees of any enclosing components, and we don't want to expose the details of those trees more than necessary.
(In reply to comment #5) > (In reply to comment #4) > > In the f2f on this last Friday, we decided that :host should *not* allow > > combinators, as Tab noted. > > > > The idea is that from a given shadowRoot, it's important to be able to glean > > some information about the composed tree (for example, does it match an > > important theming selector), but it's brittle to rely on composed tree > > structure (is A inside of B) because its details may change and shouldn't be > > known to a given shadowRoot. > > > > Hayato-san, in your document, it looks like you're proposing that :host > > allow combinators as long as they match within the host scope. That's an > > interesting restriction and addresses the concern above, but my sense is > > that the additional expressiveness is offset by the arcane host scope > > matching behavior. > > Yes, we do *not* want combinators, even if they're just parent or descendant > combinators. We're matching against the fully composed ancestor list, which > includes the shadow trees of any enclosing components, and we don't want to > expose the details of those trees more than necessary. Okay. I don't have a strong opinion for that. While we lose a power of a combinator, we get a power to match against the fully composed ancestor list. It would be enough in practical cases. Sounds good to me.
*** Bug 21391 has been marked as a duplicate of this bug. ***
Let me close this bug. I believe CSS scoping spec [1] has already addressed this issue. [1]: http://dev.w3.org/csswg/css-scoping/