Bug 22390 - [Shadow]: Support ':host()' pseudo class.
Summary: [Shadow]: Support ':host()' pseudo class.
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 21391 (view as bug list)
Depends on:
Blocks: 23062
  Show dependency treegraph
 
Reported: 2013-06-17 06:23 UTC by Hayato Ito
Modified: 2014-04-24 01:22 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hayato Ito 2013-06-17 06:23:53 UTC
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.
Comment 1 Hayato Ito 2013-06-24 06:37:17 UTC
ping? Any comments?
Comment 2 Dimitri Glazkov 2013-06-24 15:41:13 UTC
(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
Comment 3 Tab Atkins Jr. 2013-06-24 18:21:13 UTC
: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.
Comment 4 Steve Orvell 2013-06-24 21:35:18 UTC
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.
Comment 5 Tab Atkins Jr. 2013-06-24 21:40:33 UTC
(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.
Comment 6 Hayato Ito 2013-06-25 02:31:10 UTC
(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.
Comment 7 Dimitri Glazkov 2013-07-17 22:14:08 UTC
*** Bug 21391 has been marked as a duplicate of this bug. ***
Comment 8 Hayato Ito 2014-04-24 01:22:39 UTC
Let me close this bug.
I believe CSS scoping spec [1] has already addressed this issue.

[1]: http://dev.w3.org/csswg/css-scoping/