22390 2013-06-17 06:23:53 +0000 [Shadow]: Support ':host()' pseudo class. 2014-04-24 01:22:39 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 23062 1 hayato hayato dglazkov dominicc jackalmage sorvell tasak public-webapps-bugzilla oldest_to_newest 89379 0 hayato 2013-06-17 06:23:53 +0000 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. 89741 1 hayato 2013-06-24 06:37:17 +0000 ping? Any comments? 89759 2 dglazkov 2013-06-24 15:41:13 +0000 (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 89763 3 jackalmage 2013-06-24 18:21:13 +0000 :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. 89771 4 sorvell 2013-06-24 21:35:18 +0000 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. 89772 5 jackalmage 2013-06-24 21:40:33 +0000 (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. 89780 6 hayato 2013-06-25 02:31:10 +0000 (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. 90896 7 dglazkov 2013-07-17 22:14:08 +0000 *** Bug 21391 has been marked as a duplicate of this bug. *** 104308 8 hayato 2014-04-24 01:22:39 +0000 Let me close this bug. I believe CSS scoping spec [1] has already addressed this issue. [1]: http://dev.w3.org/csswg/css-scoping/