21959 2013-05-07 22:17:16 +0000 [Shadow]: @host rules should be overridden by selectors in document 2013-07-17 22:17:40 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED INVALID P2 normal --- 14978 1 dfreedm dglazkov dominicc tasak public-webapps-bugzilla oldest_to_newest 87386 0 dfreedm 2013-05-07 22:17:16 +0000 As it stands now, @host is more specific a selector than any other but the style attribute on that element. This makes it very difficult to style composed elements with @host rules, as manipulation of the style element is required to do things such as collapse adjacent borders or translate the element's position. As a developer, I would rather use @host to be the "default" styling of an element, like a custom user-agent style. If there are stylings a developer would want to protect, then that developer should put that styling in an element in the ShadowRoot. 88266 1 tasak 2013-05-28 06:40:11 +0000 I would like to confirm one thing: Suppose that we have a tag selector in an author stylesheet, e.g. <style> div { color: green; } </style> and that we also have a shadow host whose id is "host" and whose shadow root has an id selector in @host @-rule, e.g. <div id="host"> #shadow-root <style> @host { #host { color: red; } } </style> Hello, World! So the text: "Hello, World!" should be shown in green color or red color? I mean, which is better: (a) any selector in an author stylesheet wins, or (b) it depends on specificity. If a selector in @host @-rules has higher specificity, the selector wins. 88267 2 dominicc 2013-05-28 06:40:41 +0000 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> 90897 3 dglazkov 2013-07-17 22:17:40 +0000 @host is dead. This is moot.