what does the @host do when the tree is itself assigned into a shadow insertion point?
Should it match <shadow>?
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.
Bug 18382 has a different approach to the problem.
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?)
Punting until next draft.
There's no @host anymore, closing.