http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#fonts-and-colors <quote> The article, aside, nav, and section elements are expected to affect the font size of h1 elements, based on the nesting depth. If x is a selector that matches elements that are either article, aside, nav, or section elements, then the following rules capture what is expected: @namespace url(http://www.w3.org/1999/xhtml); x h1 { font-size: 1.50em; } x x h1 { font-size: 1.17em; } x x x h1 { font-size: 1.00em; } x x x x h1 { font-size: 0.83em; } x x x x x h1 { font-size: 0.67em; } </quote> http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#margins-and-padding <quote> The article, aside, nav, and section elements are expected to affect the margins of h1 elements, based on the nesting depth. If x is a selector that matches elements that are either article, aside, nav, or section elements, then the following rules capture what is expected: @namespace url(http://www.w3.org/1999/xhtml); x h1 { margin-top: 0.83em; margin-bottom: 0.83em; } x x h1 { margin-top: 1.00em; margin-bottom: 1.00em; } x x x h1 { margin-top: 1.33em; margin-bottom: 1.33em; } x x x x h1 { margin-top: 1.67em; margin-bottom: 1.67em; } x x x x x h1 { margin-top: 2.33em; margin-bottom: 2.33em; } </quote>
Perhaps take a look at the -moz-any() selector for inspiration. That would help authors too.
Created attachment 86592 [details] Patch
Yay! :-webkit-any has some performance problems (can't take advantage of a lot of fast selector checking paths). I think this is OK though. Antti, what do you think? Should this block on improving the performance or does it not matter when it's just a handful of selectors?
(In reply to comment #3) > Yay! :-webkit-any has some performance problems (can't take advantage of a lot of fast selector checking paths). I think this is OK though. Antti, what do you think? Should this block on improving the performance or does it not matter when it's just a handful of selectors? I checked Chromium's page_cycler test results with/without this change. My conclusion is that this change won't make performance regression of loading major sites. I think regression of loading pages contains article/aside/nav/section is acceptable for now.
Comment on attachment 86592 [details] Patch I think you're right. We don't need to be overly worried about performance here. I notice the other places where we set margin we also set -webkit-margin-start and -webkit-margin-end. Do you know what those are for? Do we need them here?
(In reply to comment #5) > (From update of attachment 86592 [details]) > notice the other places where we set margin we also set -webkit-margin-start and -webkit-margin-end. Do you know what those are for? Do we need them here? -webkit-margin-start means margin-left in horizontal writing, margin-top in vertical writing. -webkit-margin-end means margin-right in horizontal writing, magin-bottom in vertical writing. We don't need to specify them in this patch because HTML5 doesn't ask to update margin-left and margin-right. Margin-left and margin-right of H2-H6 are identical with H1's.
Comment on attachment 86592 [details] Patch Clearing flags on attachment: 86592 Committed r82400: <http://trac.webkit.org/changeset/82400>
All reviewed patches have been landed. Closing bug.
(In reply to comment #3) > Yay! :-webkit-any has some performance problems (can't take advantage of a lot of fast selector checking paths). I think this is OK though. Antti, what do you think? Should this block on improving the performance or does it not matter when it's just a handful of selectors? In principle this is not great in terms of performance though in practice impact should be limited (we only end up to slow path for h1 elements which are not that common). One option would be to expand the rightmost :-webkit-any to subcomponents (which would allow ancestor filter to work). Probably not worth it unless some profile says otherwise.