18483 2012-08-03 17:45:52 +0000 [Shadow]: Shared stylesheets may make @host ambiguous 2013-04-01 22:48:21 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 16009 1 dglazkov dglazkov jackalmage sorvell tasak tross public-webapps-bugzilla oldest_to_newest 71822 0 dglazkov 2012-08-03 17:45:52 +0000 Since bug 15818, we now have the ability to share stylesheets across instances of shadow DOM. For example, a widget library could only have one stylesheet to style all widgets. This creates a potential issue, where it's hard to tell which widget's host the @host at-rule refers to. This sounds bad and in need of fixin'. 71827 1 tross 2012-08-03 18:56:09 +0000 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; } > } 71829 2 dglazkov 2012-08-03 19:15:38 +0000 (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 :) 71860 3 dglazkov 2012-08-06 21:26:34 +0000 Sakamoto-san -- heads up. A huge update to how @host works is coming. 71880 4 tasak 2012-08-07 11:03:49 +0000 (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 71947 5 dglazkov 2012-08-08 20:54:20 +0000 http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff 82424 6 jackalmage 2013-01-31 19:25:52 +0000 (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. 82478 7 dglazkov 2013-02-01 17:30:07 +0000 (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 :-\ 82479 8 jackalmage 2013-02-01 18:50:50 +0000 (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. 83469 9 sorvell 2013-02-21 02:48:11 +0000 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. 85336 10 dglazkov 2013-04-01 22:48:21 +0000 See follow up discussion in bug 21391.