This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
I need to rework the rule applicability algorithm.
There is also going to be an exception with ::host pseudo-element.
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
(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.
Step 2: Relaxed the upper-boundary encapsulation restrictions to only upper boundary cases: http://dvcs.w3.org/hg/webcomponents/rev/cf9aec2d779c
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
Step 5: Tightened back the lower-boundary encapsulation http://dvcs.w3.org/hg/webcomponents/rev/c2f82425ba8d Do I win?
You win.
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'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
*** Bug 19663 has been marked as a duplicate of this bug. ***
(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
> 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.
(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.
(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.
(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.
(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?
(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)
(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.
Closing this bug. Please file new bugs for each specific problem.