- From: Koji Ishii <kojiishi@gmail.com>
- Date: Fri, 12 Jun 2015 13:10:55 +0900
- To: Rune Lillesveen <rune@opera.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Hayato Ito <hayato@google.com>, www-style list <www-style@w3.org>, sorvell@google.com, Elliott Sprehn <esprehn@google.com>, Olli Pettay <olli@pettay.fi>
- Message-ID: <CAN9ydbUFvf75fdbQp+UAk_LekrJYCQ7+sfC94bUW8dEsipYLZQ@mail.gmail.com>
On Thu, Jun 11, 2015 at 5:04 PM, Rune Lillesveen <rune@opera.com> wrote: > > [snip] > > >> For the example above, the composed tree path from the <inner> element > >> and up is: > >> > >> inner -> host2 -> div -> host1_1 -> host1 > >> > >> This gives a total parent/child ordering of the scopes that apply to a > >> given element: > >> > >> scope(D) -> scope(C) -> scope(B) -> scope(A) > >> > >> If you include the shadow roots you pass through traversing the > >> composed tree, you end up with: > >> > >> inner -> scope(D) -> host2 -> div -> scope(C) -> host1_1 -> scope(B) > >> -> host1 -> scope(A) > >> > >> (should work for multiple shadow roots as well) > >> > >> The ordering of rules from stylesheets A-D for the <inner> element > >> would then be: > >> > >> 1. scope(D) Important > >> 2. scope(C) Important > >> 3. scope(B) Important > >> 4. scope(A) Important > >> 5. scope(A) normal > >> 6. scope(B) normal > >> 7. scope(C) normal > >> 8. scope(D) normal > >> > >> That means specificity will not make a rule from one shadow tree beat > >> a rule from another. I don't know why it currently is like that, or if > >> it makes sense. > > > > Yes, "Origin and Scopes" should win over the specificity in terms of the > > priority. I believe that's what the current spec defines, and that's what > > you would like it to be, right? > > Yes. The current spec says so for inner/outer, but not for scopes > which do not have a parent/child relationship in the tree-of-trees. > Right, I got your point. IIUC we're in consensus that when comparing two declarations in different trees, the Shadow Tree cascade criteria[1] should define to use the composed tree to define which tree wins. What I meant was, assuming it was fixed, it catches all different trees cases that the criteria in lower priorities (Scopes, Specificity, and Order of Appearance[2]) does not affect precedence. Specificity is determined per declaration, so we do not want to fall back to it when comparing two declarations in different trees. One thing we need to solve is that, when you build an ordered list of tree scopes from a composed tree, a node tree could appear multiple times. I discussed this with Hayato, he'll give some thoughts on it and follow up on this thread. [1] http://dev.w3.org/csswg/css-scoping/#cascading [2] http://dev.w3.org/csswg/css-cascade/#cascading /koji
Received on Friday, 12 June 2015 04:11:22 UTC