Emulating <h1> styling in nested <section>s with shadow dom

73 views
Skip to first unread message

jyas...@gmail.com

unread,
Jan 3, 2014, 2:41:45 AM1/3/14
to polym...@googlegroups.com
I've attached 3 html files using nested <sections> and <h1> elements that I had naively expected to render the same way. However, the -shadow and -polymer versions fail to recognize that <h1>s nested 3 <section>s deep should be styled differently from <h1>s only 1 <section> down. I suspect this is due to the fact that "selectors don't cross the shadow boundary", as mentioned in http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/. That document also mentions the ^^ combinator, which looks like it might help, but my experiment with it didn't have an effect in Mac Chrome 33.0.1750.5.

Is it intended that the user agent's style on h1s in nested sections won't take effect when the sections are nested through shadow dom?

What's the intended way to style nested sectioning elements, when the appearance should depend on how deeply nested the element is?

Thanks,
Jeffrey
test-polymer.html
test.html
test-shadow.html

Eric Bidelman

unread,
Jan 3, 2014, 1:42:40 PM1/3/14
to Jeffrey Yasskin, polymer-dev
Hi Jeffrey,

You're right that the default UA styles aren't penetrating the shadow dom boundaries.
The rules in question look something like this:

:-webkit-any(article,aside,nav,section)
:-webkit-any(article,aside,nav,section) h1 {
  ...
}

Translating this selector (e.g. section section h1 { ... }), it doesn't apply to the elements inside the sub-shadow trees.

The ^ && ^^ combinators achieve what you want. I took the liberty of sticking the styling
in the element itself and cleaning things up a bit. This works for me in Canary:



Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Jeffrey Yasskin

unread,
Jan 3, 2014, 2:33:27 PM1/3/14
to ebi...@gmail.com, polym...@googlegroups.com
On Fri Jan 03 2014 at 10:43:10 AM, Eric Bidelman <ebi...@gmail.com> wrote:
Hi Jeffrey,

You're right that the default UA styles aren't penetrating the shadow dom boundaries.
The rules in question look something like this:

:-webkit-any(article,aside,nav,section)
:-webkit-any(article,aside,nav,section) h1 {
  ...
}

Translating this selector (e.g. section section h1 { ... }), it doesn't apply to the elements inside the sub-shadow trees.

Right. Is that a bug in the UA style rules? (I can file it, but I'd like to check here if there's a good reason for it first.)
 
The ^ && ^^ combinators achieve what you want. I took the liberty of sticking the styling
in the element itself and cleaning things up a bit. This works for me in Canary:


That's interesting. Your styles worked for me in Dev too, but when I change the style rules from "my-section ^^ my-section h1", etc. to "section ^^ section h1" in http://jsbin.com/IZIZiFEC/1/edit, they stop applying. My understanding of ^^ is that "my-section h1" shouldn't match at all, since my-section is in light dom, but h1 is in shadow dom, so I don't understand why your selectors work.

http://crbug.com/313941 might explain why my "section ^^ section h1" selectors don't work, since they're inside the scoped style, but they still don't work if I move the <style> outside the polymer-element (and add applyAuthorStyles).

Is there any spec for the cat and hat combinators beyond http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/#toc-style-cat-hat? http://w3c.github.io/webcomponents/spec/shadow/#h2_styles only has a TODO for them. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23467 links to a document describing them. Is that the place to check whether a behavior is a bug or intended?

Thanks,
Jeffrey 

Yvonne Yip

unread,
Jan 6, 2014, 3:14:29 PM1/6/14
to Jeffrey Yasskin, Eric Bidelman, polymer-dev
That "section ^^ section h1" works in your example seems like a bug. I've filed http://crbug.com/331871 to track.
Reply all
Reply to author
Forward
0 new messages