- From: <bugzilla@jessica.w3.org>
- Date: Fri, 03 Aug 2012 19:15:38 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18483
--- Comment #2 from Dimitri Glazkov <dglazkov@chromium.org> 2012-08-03 19:15:38 UTC ---
(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 :)
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 3 August 2012 19:15:40 UTC