17515 2012-06-16 15:41:30 +0000 [Shadow]: @host and shadow insertion point 2013-07-17 18:21:04 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED WONTFIX P2 normal --- 18382 15480 1 dglazkov dglazkov dominicc public-webapps-bugzilla oldest_to_newest 69149 0 dglazkov 2012-06-16 15:41:30 +0000 what does the @host do when the tree is itself assigned into a shadow insertion point? Should it match <shadow>? 69175 1 dominicc 2012-06-18 01:48:13 +0000 To clarify, this would let people style the <shadow> element, however it would only affect inherited values since <shadow> element is not itself rendered? The news widget use case in the spec would get more utility by @host identifying <shadow>, since it is still a news widget. But what is the essential issue? Is uniform composition like that always the case? Maybe more use cases will be illustrative. 71528 2 dglazkov 2012-07-26 22:24:58 +0000 Bug 18382 has a different approach to the problem. 71821 3 dglazkov 2012-08-03 17:37:44 +0000 When shadow DOM is used to create controls/widget, the @host rules could be seen as a way to provide default styling for the box, surrounding the said widget. For example, imagine that <input type="text">'s typical outline is actually styled using @host rules. Now, I want to add small icon inside of the input field to indicate something about the text content (calendar icon, for instance, to click and bring up a date picker). Always applying @host to the shadow host is the desired behavior here, since when I include the older shadow in my calendar icon shadow DOM subtree, I still want the text field's outline to be on the host, not at inclusion point. However, if instead I want to add, say a password-strength indicator to the right of the field, I do want to put the outline styles somewhere on the <shadow> (but where?) 71825 4 dglazkov 2012-08-03 17:59:26 +0000 Punting until next draft. 90856 5 dglazkov 2013-07-17 18:21:04 +0000 There's no @host anymore, closing.