16317 2012-03-12 01:04:55 +0000 [Shadow]: Clarify the meaning of /select/ and upper boundary encapsulation, styling 2012-10-23 23:05:57 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 16009 1 dominicc dglazkov hayato tasak public-webapps-bugzilla oldest_to_newest 65333 0 dominicc 2012-03-12 01:04:55 +0000 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? 65369 1 dglazkov 2012-03-12 19:14:54 +0000 I need to rework the rule applicability algorithm. 65465 2 dglazkov 2012-03-13 21:18:50 +0000 There is also going to be an exception with ::host pseudo-element. 65631 3 dglazkov 2012-03-15 21:57:13 +0000 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 65633 4 dglazkov 2012-03-15 22:15:07 +0000 (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. 65634 5 dglazkov 2012-03-15 22:15:43 +0000 Step 2: Relaxed the upper-boundary encapsulation restrictions to only upper boundary cases: http://dvcs.w3.org/hg/webcomponents/rev/cf9aec2d779c 65636 6 dglazkov 2012-03-15 22:22:02 +0000 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 65637 7 dglazkov 2012-03-15 22:33:19 +0000 Step 5: Tightened back the lower-boundary encapsulation http://dvcs.w3.org/hg/webcomponents/rev/c2f82425ba8d Do I win? 66037 8 dominicc 2012-03-26 06:20:47 +0000 You win. 76948 9 tasak 2012-10-23 11:00:51 +0000 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 76951 10 tasak 2012-10-23 11:13:08 +0000 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 76953 11 tasak 2012-10-23 11:26:19 +0000 *** Bug 19663 has been marked as a duplicate of this bug. *** 76954 12 tasak 2012-10-23 11:32:00 +0000 (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 76961 13 tasak 2012-10-23 13:27:04 +0000 > 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. 76962 14 tasak 2012-10-23 13:29:37 +0000 (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. 76986 15 dglazkov 2012-10-23 21:51:08 +0000 (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. 76987 16 dglazkov 2012-10-23 21:53:01 +0000 (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. 76988 17 dglazkov 2012-10-23 21:56:09 +0000 (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? 76989 18 dglazkov 2012-10-23 21:58:21 +0000 (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) 76997 19 dglazkov 2012-10-23 22:53:10 +0000 (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. 77002 20 dglazkov 2012-10-23 23:05:50 +0000 Closing this bug. Please file new bugs for each specific problem.