This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16317 - [Shadow]: Clarify the meaning of /select/ and upper boundary encapsulation, styling
Summary: [Shadow]: Clarify the meaning of /select/ and upper boundary encapsulation, s...
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: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 19663 (view as bug list)
Depends on:
Blocks: 16009
  Show dependency treegraph
 
Reported: 2012-03-12 01:04 UTC by Dominic Cooney
Modified: 2012-10-23 23:05 UTC (History)
2 users (show)

See Also:


Attachments

Description Dominic Cooney 2012-03-12 01:04:55 UTC
Section 7.3 describes CSS selectors like:

.some-insertion-point /select/ div.special

where the left-hand side selects an insertion point and the right-hand side selects an element distributed to that point. Hence the left-hand side is in a shadow tree and the right-hand side is in a different level.

However Section 5.1 states:

The selectors must not cross the shadow boundary

And the algorithm at the start of Section 7 describes rules in the document applying to nodes in the shadow tree if apply-author-styles is set, but not rules in the shadow tree applying to nodes in the document (ie styles flow at most "one way", if at all.)

The intent of the /select/ combinator seems to be to style nodes in the document from rules in the document (by the algorithm in Section 7, rules in the shadow tree could not apply to nodes in the document.) However then the selector violates upper-boundary encapsulation by mentioning an insertion point in the shadow tree.

This section is unclear and needs to be clarified. Is upper-boundary encapsulation relaxed? Are there exceptions for applying style rules that use the /select/ combinator? Is the combinator expected to work in querySelector as well as stylesheets?
Comment 1 Dimitri Glazkov 2012-03-12 19:14:54 UTC
I need to rework the rule applicability algorithm.
Comment 2 Dimitri Glazkov 2012-03-13 21:18:50 UTC
There is also going to be an exception with ::host pseudo-element.
Comment 3 Dimitri Glazkov 2012-03-15 21:57:13 UTC
Step 1: Reworked the rule applicability algorithm to use "applicable in tree", rather than "applicable to node". This allows us to separate the notion of "applicable" and "matching".

For example, ".some-insertion-point /select/ div.special" is _applicable_ in a shadow DOM subtree, even though it _matches_ nodes outside of the shadow DOM tree.

http://dvcs.w3.org/hg/webcomponents/rev/8d191f75a97d
Comment 4 Dimitri Glazkov 2012-03-15 22:15:07 UTC
(In reply to comment #3)
> Step 1: Reworked the rule applicability algorithm to use "applicable in tree",
> rather than "applicable to node". This allows us to separate the notion of
> "applicable" and "matching".
> 
> For example, ".some-insertion-point /select/ div.special" is _applicable_ in a
> shadow DOM subtree, even though it _matches_ nodes outside of the shadow DOM
> tree.
> 
> http://dvcs.w3.org/hg/webcomponents/rev/8d191f75a97d

Oops, that was http://dvcs.w3.org/hg/webcomponents/rev/b2f0d136b2c5.
Comment 5 Dimitri Glazkov 2012-03-15 22:15:43 UTC
Step 2: Relaxed the upper-boundary encapsulation restrictions to only upper boundary cases:

http://dvcs.w3.org/hg/webcomponents/rev/cf9aec2d779c
Comment 6 Dimitri Glazkov 2012-03-15 22:22:02 UTC
Step 3: Made sure that the spec talks in term of rule _applicability_ in trees, rather than matching nodes.

http://dvcs.w3.org/hg/webcomponents/rev/a5358f551b7f
Comment 7 Dimitri Glazkov 2012-03-15 22:33:19 UTC
Step 5: Tightened back the lower-boundary encapsulation http://dvcs.w3.org/hg/webcomponents/rev/c2f82425ba8d

Do I win?
Comment 8 Dominic Cooney 2012-03-26 06:20:47 UTC
You win.
Comment 9 Takashi Sakamoto 2012-10-23 11:00:51 UTC
I would like to confirm one thing. According to the spec, the following selector doesn't work:

.some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special

Is this correct?

Best regards,
Takashi Sakamoto
Comment 10 Takashi Sakamoto 2012-10-23 11:13:08 UTC
I'm sorry. I would like to confirm one more thing.
The spec only says:

Otherwise, if RULE is either an @host @-rule or contains a select reference combinator and RULE is declared in shadow root style sheets:
- Let BOTTOM the shadow DOM subtree, with which these shadow root style sheets are associated
- If the shadow host of BOTTOM is in TREE, then RULE is applicable in TREE.

RULE is applicable in TREE means,
----
Suppose that there are several different shadow hosts, e.g.

<shadow host1>
...
<shadow host2>
..
<shadow hostN>

Every shadow host's shadow dom subtree has some rule which has /select/. If the rules are very simple, e.g. content /select/ * or shadow /select/ *, shadow host1's rule can be applied to shadow hostN?
----

I think, shadow host1's rules which have /select/ can be applied to only shadow host1's children. shadow hostN's rules which have /select/ can be applied to only shadow hostN's children.

So probably we need some comment about "scope" of rules which has /select/.

Best regards,
Takashi Sakamoto
Comment 11 Takashi Sakamoto 2012-10-23 11:26:19 UTC
*** Bug 19663 has been marked as a duplicate of this bug. ***
Comment 12 Takashi Sakamoto 2012-10-23 11:32:00 UTC
(In reply to comment #9)
> I would like to confirm one thing. According to the spec, the following
> selector doesn't work:
> 
> .some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special
> 
> Is this correct?
> 
> Best regards,
> Takashi Sakamoto

I mean, multiple shadow case and nested shadow case.

Best regards,
Takashi Sakamoto
Comment 13 Takashi Sakamoto 2012-10-23 13:27:04 UTC
> I mean, multiple shadow case and nested shadow case.

I forgot to ask about whether /select/ rules in inert shadow dom subtrees should be applied or not.

Suppose that there exist the following DOM tree:

<host> ---- <sr1> ---- <sr2> ----- <sr3> ... --- <sr N>
   |
   +--child

and all shadow roots have <style> which has /select/ rules. But some of shadow roots have no <shadow>, i.e. inert shadow roots.

I think, this should work in the same mannar as @host @-rules. /select/ rules in inert shadow roots should not be applied. Is this correct?

And I think,/select/ rules in younger shadow DOM subtree should have higher priority than rules in older shadow DOM subtree.
Comment 14 Takashi Sakamoto 2012-10-23 13:29:37 UTC
(In reply to comment #9)
> I would like to confirm one thing. According to the spec, the following
> selector doesn't work:
> 
> .some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special
> 
> Is this correct?
> 
> Best regards,
> Takashi Sakamoto

I think, if we don't have any shadow re-projection, we need something like "shadow /select/ shadow /select/ ..." to support multiple shadow root case.
Comment 15 Dimitri Glazkov 2012-10-23 21:51:08 UTC
(In reply to comment #9)
> I would like to confirm one thing. According to the spec, the following
> selector doesn't work:
> 
> .some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special
> 
> Is this correct?

That wasn't the intention of the spec. Seems like a bug.
Comment 16 Dimitri Glazkov 2012-10-23 21:53:01 UTC
(In reply to comment #10)
> I'm sorry. I would like to confirm one more thing.
> The spec only says:
> 
> Otherwise, if RULE is either an @host @-rule or contains a select reference
> combinator and RULE is declared in shadow root style sheets:
> - Let BOTTOM the shadow DOM subtree, with which these shadow root style
> sheets are associated
> - If the shadow host of BOTTOM is in TREE, then RULE is applicable in TREE.
> 
> RULE is applicable in TREE means,
> ----
> Suppose that there are several different shadow hosts, e.g.
> 
> <shadow host1>
> ...
> <shadow host2>
> ..
> <shadow hostN>
> 
> Every shadow host's shadow dom subtree has some rule which has /select/. If
> the rules are very simple, e.g. content /select/ * or shadow /select/ *,
> shadow host1's rule can be applied to shadow hostN?
> ----
> 
> I think, shadow host1's rules which have /select/ can be applied to only
> shadow host1's children. shadow hostN's rules which have /select/ can be
> applied to only shadow hostN's children.

Right.

> 
> So probably we need some comment about "scope" of rules which has /select/.

Yup.

Also -- please file a new bug in the future, rather than reusing an old bug. I'd love to keep the same system as in WebKit here.
Comment 17 Dimitri Glazkov 2012-10-23 21:56:09 UTC
(In reply to comment #13)
> > I mean, multiple shadow case and nested shadow case.
> 
> I forgot to ask about whether /select/ rules in inert shadow dom subtrees
> should be applied or not.
> 
> Suppose that there exist the following DOM tree:
> 
> <host> ---- <sr1> ---- <sr2> ----- <sr3> ... --- <sr N>
>    |
>    +--child
> 
> and all shadow roots have <style> which has /select/ rules. But some of
> shadow roots have no <shadow>, i.e. inert shadow roots.
> 
> I think, this should work in the same mannar as @host @-rules. /select/
> rules in inert shadow roots should not be applied. Is this correct?

Can you explain why this matters? If the tree is inert, the fact that the rule applies or not is not possible to detect -- right?

> 
> And I think,/select/ rules in younger shadow DOM subtree should have higher
> priority than rules in older shadow DOM subtree.

You mean specificity?
Comment 18 Dimitri Glazkov 2012-10-23 21:58:21 UTC
(In reply to comment #14)
> (In reply to comment #9)
> > I would like to confirm one thing. According to the spec, the following
> > selector doesn't work:
> > 
> > .some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special
> > 
> > Is this correct?
> > 
> > Best regards,
> > Takashi Sakamoto
> 
> I think, if we don't have any shadow re-projection, we need something like
> "shadow /select/ shadow /select/ ..." to support multiple shadow root case.

There is not /select/ attribute on "shadow". Can you explain why we would need something like this? (possibly on a new bug :P)
Comment 19 Dimitri Glazkov 2012-10-23 22:53:10 UTC
(In reply to comment #9)
> I would like to confirm one thing. According to the spec, the following
> selector doesn't work:
> 
> .some-insertion-point1 /select/ .some-insertion-point2 /select/ div.special
> 
> Is this correct?
> 
> Best regards,
> Takashi Sakamoto

Filed bug 19681 to track fixing this.
Comment 20 Dimitri Glazkov 2012-10-23 23:05:50 UTC
Closing this bug. Please file new bugs for each specific problem.