Bug 18483 - [Shadow]: Shared stylesheets may make @host ambiguous
[Shadow]: Shared stylesheets may make @host ambiguous
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 normal
: ---
Assigned To: Dimitri Glazkov
public-webapps-bugzilla
:
Depends on:
Blocks: 16009
  Show dependency treegraph
 
Reported: 2012-08-03 17:45 UTC by Dimitri Glazkov
Modified: 2013-04-01 22:48 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2012-08-03 17:45:52 UTC
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'.
Comment 1 Tony Ross [MSFT] 2012-08-03 18:56:09 UTC
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; }
> }
Comment 2 Dimitri Glazkov 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 :)
Comment 3 Dimitri Glazkov 2012-08-06 21:26:34 UTC
Sakamoto-san -- heads up. A huge update to how @host works is coming.
Comment 4 Takashi Sakamoto 2012-08-07 11:03:49 UTC
(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
Comment 5 Dimitri Glazkov 2012-08-08 20:54:20 UTC
http://dvcs.w3.org/hg/webcomponents/rev/aadaf5d62fff
Comment 6 Tab Atkins Jr. 2013-01-31 19:25:52 UTC
(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.
Comment 7 Dimitri Glazkov 2013-02-01 17:30:07 UTC
(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 :-\
Comment 8 Tab Atkins Jr. 2013-02-01 18:50:50 UTC
(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.
Comment 9 Steve Orvell 2013-02-21 02:48:11 UTC
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.
Comment 10 Dimitri Glazkov 2013-04-01 22:48:21 UTC
See follow up discussion in bug 21391.