Bug 23467 - [Shadow]: clarify ^ and ^^ combinator
[Shadow]: clarify ^ and ^^ combinator
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Hayato Ito
public-webapps-bugzilla
:
Depends on:
Blocks: 23062
  Show dependency treegraph
 
Reported: 2013-10-09 07:17 UTC by Takashi Sakamoto
Modified: 2014-04-24 00:54 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Takashi Sakamoto 2013-10-09 07:17:03 UTC
We need to clarify how ^ and ^^ combinator work.

I think, at least, we need to discuss:
- case 1: we have multiple shadow roots and each shadow tree has some rules with ^ or ^^, 
- case 2: ^ and ^^ and :host

c.f. http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0608.html


I wrote the document for this purpose:
https://docs.google.com/document/d/18DsYEiRKg1HmO1UjgHn1CPtwmoXqt8ofmg2Gexdi6Os/edit?usp=sharing
Comment 1 Steve Orvell 2013-10-09 18:51:26 UTC
There are a couple of things in the linked document that I think are incorrect. I requested comment access but in the meantime, I'll post my notes here:

The definition of ^^ is incomplete. The second bullet point should be amended as follows:

"B is in a shadow tree which is a descendant tree (c.f. tree of tree concept) of a shadow tree hosted by A *or a descendant of A*."

In the matching tables:

div ^ div: the cell for div#b and style2 should not match. This is because from style2's perspective, div#b is not in a shadowRoot. There are a number of other incorrect matches in this and the other tables that seem like the same mistake.

div:host tables: there should be no matches for any of these because div:host should not match the host node. My understanding is that :host matches the host element iff there is no selector to the left (possibly this is not true if it's inside a css function).
Comment 2 Takashi Sakamoto 2013-10-24 01:47:15 UTC
I changed the doc permisson.

I would like to confirm:
> div ^ div: the cell for div#b and style2 should not match. This is because from style2's perspective, div#b is not in a shadowRoot. There are a number of other incorrect matches in this and the other tables that seem like the same mistake.

The style2 is in the oldest shadow root hosted by div#host. So div#b is in a shadow root.

> div:host tables: there should be no matches for any of these because div:host should not match the host node. My understanding is that :host matches the host element iff there is no selector to the left (possibly this is not true if it's inside a css function).

This is one of topics I would like to discuss.
So "div:host ^ *" and "div:host ^^ *" should not match any elements. Is it ok?

I mean,
(1) div ^ * ==> we can specify any element in a shadow tree when the shadow tree's shadow host is div.
(2) div:host ==> we cannot specify div + shadow host.

So "^" and "^^" provides another way to specify shadow host (different from :host).

I'm afraid that this behavior confuses web developers.
Comment 3 Steve Orvell 2013-10-24 18:06:20 UTC
I added a few comments to the document.

> So "div:host ^ *" and "div:host ^^ *" should not match any elements. Is it ok?

Yes, this is ok.

> So "^" and "^^" provides another way to specify shadow host (different from
> :host).

I also think this is ok. They go different directions. Using ^ and ^^, you can only target elements in roots below the current scope. Using :host, you can target the host element which is above the current scope.
Comment 4 Takashi Sakamoto 2013-10-25 06:18:51 UTC
Thank you.

So I have another concern about ^ and ^^.

Suppose that we have "div ^ *".

(a) "div" in a shadow tree cannot match the tree's shadow host.

div[id=host]
    #shadow-root
        style
            div { border: 1px solid green; }


So div#host's border color should not green. This means, [tag] and [shadow host] has no intersection.

(b) "div:host" in a shadow tree cannot match the tree's shadow host.

Because of no intersection between [tag] and [shadow host], "div:host" cannot match any shadow hosts.

I think, we have already agreed with the above (a) and (b).
So I'm thinking of the following (c).

(c) the "div" of "div ^ *" in a shadow tree can match the tree's shadow host?

If the div can match the shadow host, [tag] and [shadow host] has some intersection... 
So (a) and (b) should match?

Or we should use PseudoElement? e.g. "div ^ *" is something like ::hat(div, *)?
Comment 5 Takashi Sakamoto 2013-10-25 10:39:41 UTC
I would like to confirm one thing.

Suppose that we have the following tree:

div[id=host]
    #shadow-root
        style
            div ^ div{ border: 1px solid green; }
        div[id=A]


The div ^ div should match div[id=A]?

i.e. the left "div" of the style in a shadow tree can match div[id=host]?

I think, the left "div" should not match div[id=host].

So div[id=A] doesn't have green border.
Comment 6 Steve Orvell 2013-10-25 15:33:51 UTC
Re: commment #4:

> (a) "div" in a shadow tree cannot match the tree's shadow host.
> (b) "div:host" in a shadow tree cannot match the tree's shadow host.

Yup, agree on both.

> (c) the "div" of "div ^ *" in a shadow tree can match the tree's shadow host?

No, why would it? It cannot because of (a).

> Or we should use PseudoElement? e.g. "div ^ *" is something like ::hat(div, *)?

Can you explain what problem you're solving here?

If the concern is how to write a selector that does: "from a style in a shadowRoot, match a div in any of the host's shadowRoot's if the host is a div" then that is:

:host(div:host) ^ div
Comment 7 Steve Orvell 2013-10-25 15:35:48 UTC
Re: comment #5

> The div ^ div should match div[id=A]?

It should not.

> I think, the left "div" should not match div[id=host].
> So div[id=A] doesn't have green border.

Yup, we agree.
Comment 8 Steve Orvell 2013-10-26 00:48:31 UTC
Thanks for posting the document above. In conjunction with https://www.w3.org/Bugs/Public/show_bug.cgi?id=23636, there were enough changes that I went ahead and made a copy with some modifications:

https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDbCUTdnr_7lxwrlywmpKj04aD5TRVKjd446o/edit#
Comment 9 Hayato Ito 2014-04-24 00:54:27 UTC
Let me close this bug.
I believe CSS scoping spec [1] has already addressed this feature.

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