Presumably the host element contains some piece of information (e.g. a class or attribute) which identified it as a particular widget type in the first place. 

Perhaps if @host was expanded to allow selector blocks for clarifying which host should match (think elm.matchesSelector) this would be solved. If I understand correctly, this aligns with Roland's original proposal for @host in bug 16519:

> Another brainstorming thought: what about a @host rule instead? This would have
> the advantage that the breaking behavior is explicit, and makes sure only the
> host element is affected (rules inside @host can match the host element only)
> E.g.:
> 
> @host {
>   div { background-color: white; }
>   .warning { background-color: yellow; }
>   .important .warning { background-color: orange; }
> }

(In reply to comment #1)
> Presumably the host element contains some piece of information (e.g. a class or
> attribute) which identified it as a particular widget type in the first place. 
> 
> Perhaps if @host was expanded to allow selector blocks for clarifying which
> host should match (think elm.matchesSelector) this would be solved. If I
> understand correctly, this aligns with Roland's original proposal for @host in
> bug 16519:
> 
> > Another brainstorming thought: what about a @host rule instead? This would have
> > the advantage that the breaking behavior is explicit, and makes sure only the
> > host element is affected (rules inside @host can match the host element only)
> > E.g.:
> > 
> > @host {
> >   div { background-color: white; }
> >   .warning { background-color: yellow; }
> >   .important .warning { background-color: orange; }
> > }

It sounds like Roland was right :)

Sakamoto-san -- heads up. A huge update to how @host works is coming.

(In reply to comment #3)
> Sakamoto-san -- heads up. A huge update to how @host works is coming.

Thank you. I updated my WIP patch and my design doc.

Best regards,
Takashi Sakamoto

http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff

(In reply to comment #5)
> http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff

Based on the recent internal thread, I suggest a slightly different syntax.  (Sorry for not getting to this earlier - I've been laboring under a mistaken idea of what @host does!)

I believe the syntax should instead be:

@host <selector>? { <declaration-list> }

If the selector is omitted, it defaults to "*".

This allows us to still address this bug's issue just as easily as before, but it makes the simple case (when you are only styling one type of element) easier to write.

(In reply to comment #6)
> (In reply to comment #5)
> > http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff
> 
> Based on the recent internal thread, I suggest a slightly different syntax. 
> (Sorry for not getting to this earlier - I've been laboring under a mistaken
> idea of what @host does!)
> 
> I believe the syntax should instead be:
> 
> @host <selector>? { <declaration-list> }
> 
> If the selector is omitted, it defaults to "*".
> 
> This allows us to still address this bug's issue just as easily as before,
> but it makes the simple case (when you are only styling one type of element)
> easier to write.

I would _really_ like to keep the syntax the same as before. At-rules are confusing enough, and the space between @host and <selector> has been perceived as a descendant combinator by several folks. Not that the nested parens is much better :-\

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff
> > 
> > Based on the recent internal thread, I suggest a slightly different syntax. 
> > (Sorry for not getting to this earlier - I've been laboring under a mistaken
> > idea of what @host does!)
> > 
> > I believe the syntax should instead be:
> > 
> > @host <selector>? { <declaration-list> }
> > 
> > If the selector is omitted, it defaults to "*".
> > 
> > This allows us to still address this bug's issue just as easily as before,
> > but it makes the simple case (when you are only styling one type of element)
> > easier to write.
> 
> I would _really_ like to keep the syntax the same as before. At-rules are
> confusing enough, and the space between @host and <selector> has been
> perceived as a descendant combinator by several folks. Not that the nested
> parens is much better :-\

It's not a huge deal.  I'm okay if it stays the way it is; the current syntax makes sense, it's just suboptimal in the common case.

The (In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff
> > > 
> > > Based on the recent internal thread, I suggest a slightly different syntax. 
> > > (Sorry for not getting to this earlier - I've been laboring under a mistaken
> > > idea of what @host does!)
> > > 
> > > I believe the syntax should instead be:
> > > 
> > > @host <selector>? { <declaration-list> }
> > > 
> > > If the selector is omitted, it defaults to "*".
> > > 
> > > This allows us to still address this bug's issue just as easily as before,
> > > but it makes the simple case (when you are only styling one type of element)
> > > easier to write.
> > 
> > I would _really_ like to keep the syntax the same as before. At-rules are
> > confusing enough, and the space between @host and <selector> has been
> > perceived as a descendant combinator by several folks. Not that the nested
> > parens is much better :-\
> 
> It's not a huge deal.  I'm okay if it stays the way it is; the current
> syntax makes sense, it's just suboptimal in the common case.

I agree with Tab here but feel more strongly about it.

Let's imagine this common case: I want to style the background color of my host element. With the current syntax, this simple rule is much more difficult to construct than it should be.

@host {
  * {
    background: tomato;
  }
}

With the proposed optional syntax, this is:

@host {
  background: tomato;
}

Personally, I think the optional selector in the proposed syntax is ok, but if it's deemed too confusing (it does look like a descendent selector) perhaps just this common case could be supported and for further qualification of the rule you would use the original nested syntax.

See follow up discussion in bug 21391.