This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21390 - [Shadow]: add support for styling shadowDOM contents based on host element
Summary: [Shadow]: add support for styling shadowDOM contents based on host element
Status: RESOLVED DUPLICATE of bug 20957
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14978 21499
  Show dependency treegraph
 
Reported: 2013-03-25 19:26 UTC by Steve Orvell
Modified: 2013-07-17 22:12 UTC (History)
3 users (show)

See Also:


Attachments

Description Steve Orvell 2013-03-25 19:26:15 UTC
It should be possible to style shadowDOM contents based on a selector the host element matches.

In general, it is common to define a set of theme styles that apply if a given ancestor selector matches. If nodes within a shadowDOM can be styled conditionally based on the host element, then shadowDOM can easily support this design pattern.

At a recent discussion, a ::shadow() pseudo-selector was proposed for this purpose. It would be used in an @host rule as follows:

@host {  
  /* match .foo shadowDOM nodes inside host elements matching .bar */
  .bar::shadow(.foo) {
    ...
  }
}

The ::shadow() pseudo-selector should also support the :root pseudo-selector to enable children selectors, for example:

@host {  
  /* match .foo shadowDOM children inside host elements matching .bar */
  .bar::shadow(:root > .foo) {
    ...
  }
}
Comment 1 Takashi Sakamoto 2013-05-15 02:26:32 UTC
I would like to confirm how ::shadow works. 

(In reply to comment #0)

> @host {  
>   /* match .foo shadowDOM children inside host elements matching .bar */
>   .bar::shadow(:root > .foo) {
>     ...
>   }
> }

Since "match .foo shadowDOM children inside host elements matching .bar", ".bar::shadow(:root > .foo)" doesn't match a host element whose class is bar and whose shadow root has any direct child whose class is foo.

So, if we write the followings, what elements should the followings match?

@host {  
  .bar::shadow(:root > .foo) > div {
     ....
  }
  .bar::shadow(:root > .foo) div {
     ....
  }
}

Are the above rules the same as the followings?

@host {  
  .bar::shadow(:root > .foo > div) {
     ....
  }
  .bar::shadow(:root > .foo div) {
     ....
  }
}

Or should we disallow the above rules?
Comment 2 Steve Orvell 2013-05-17 23:05:33 UTC
(In reply to comment #1)
> Since "match .foo shadowDOM children inside host elements matching .bar",
> ".bar::shadow(:root > .foo)" doesn't match a host element whose class is bar
> and whose shadow root has any direct child whose class is foo.

I'm not sure I follow this. Are you just saying that we're changing the @host rule from always matching the host element to matching other elements? If so, then yes, that's the goal of adding ::shadow, to be able to style shadowDOM elements based on the host's selectors.


> So, if we write the followings, what elements should the followings match?
> 
> @host {  
>   .bar::shadow(:root > .foo) > div {
>      ....
>   }
>   .bar::shadow(:root > .foo) div {
>      ....
>   }
> }
> 
> Are the above rules the same as the followings?
> 
> @host {  
>   .bar::shadow(:root > .foo > div) {
>      ....
>   }
>   .bar::shadow(:root > .foo div) {
>      ....
>   }
> }
> 
> Or should we disallow the above rules?

Yes, the above rules (first set) don't make sense. I vote to disallow that.

This points out that the syntax here is awkward.
Comment 3 Takashi Sakamoto 2013-05-20 08:07:11 UTC
Thank you for replying.

(In reply to comment #2)

> I'm not sure I follow this. Are you just saying that we're changing the
> @host rule from always matching the host element to matching other elements?
> If so, then yes, that's the goal of adding ::shadow, to be able to style
> shadowDOM elements based on the host's selectors.

I just confirm ::shadow's situation.

When we write something like "div:not(...)", we want to get "div" (:not(...) is just specifying div's condition. So "..." part is just a sub-selector).

div::shadow(...) is different from the above. We don't want to get "div". We need to look into "..." part from "div".

> Yes, the above rules (first set) don't make sense. I vote to disallow that.

That makes sense.

I would like to ask one more. I found another concerns, i.e. multiple pseudo elements. 

@host {  
  // unknown pseudo + ::shadow
  .bar::x-unknown-pseudo::shadow(.foo) {
    ...
  }
  // multiple ::shadow
  .bar::shadow(.foo)::shadow(.foobar) {
    ...
  }
  // ::shadow + ::distributed
  .bar::shadow(.foobar)::distributed(.foo) {
    ...
  }
}

We should support all the above cases, support some of the above or disallow all the above?
Comment 4 Takashi Sakamoto 2013-05-20 15:10:48 UTC
(In reply to comment #3)

I'm sorry. I found http://www.w3.org/TR/2012/WD-selectors4-20120823/#pseudo-elements

Only one pseudo-element may appear per selector, and only if the subject of the selector is the last compound selector in the selector. If present the pseudo-element must appear after the compound selector that represents the subjects of the selector. 

So my examples are disallowed, because mutiple pseudo elements are specified.
(I don't know the future pseudo-elements and CSS selector... 
 c.f. A future version of this specification may allow multiple pseudo-elements per selector.)

The spec also says:
"Syntactically, a pseudo-element may be followed by any combination of the user action pseudo-classes. Whether these pseudo-classes can match on the pseudo-element depends on the pseudo-class and pseudo-element”s definition: unless otherwise-specified, none of these pseudo-classes will match on the pseudo-element."

So we probably need to define what pseudo-classes can work with ::shadow.
Comment 5 Dimitri Glazkov 2013-07-17 22:12:35 UTC

*** This bug has been marked as a duplicate of bug 20957 ***