- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 May 2013 06:40:41 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21959 --- Comment #2 from Dominic Cooney <dominicc@chromium.org> --- I was chatting with tasak about this. The super specificity of @host rules [1] was added to the spec so that there's a defined cascade for @host rules. You could also say they have "super negative specificity" and maybe get something like the "default" behavior that you want. However he pointed out a problem to me: Since that line was written, @host semantics have gotten richer, so now you could have @host rules in different ShadowRoots overlapping, and there is no defined cascade order for them. So I think the solution here is to define an "order specified" for the CSS cascade that includes ShadowRoots. Although it is harder than just saying "@host rules have high/low specificity", I think it is necessary, because: 1. It defines what the behavior with multiple overlapping @host rules contributing styles from multiple ShadowRoots should be. 2. It allows more fine-grained control, for example, selector specificity makes sense again... #id selectors will be specific again. I *think* that the order should be: I. ShadowRoots come before the document/ShadowRoot their hosts are in (this gives you the "default" behavior you want for theming); II. older ShadowRoots should come before younger ones. I. gives you an outside-in precedence, so that if you have an outer component providing a theme, it will apply over the @host rules of the inner component. Is this what you'd want? [1] "When a rule in @host @-rule matches an element, it must have higher specificity than any selector, but lower specificity than declarations from a style attribute." <https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule> -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 28 May 2013 06:40:47 UTC