Bug 52693 – H1 element should have different default style if it is in HTML5 sectioning elements

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Kent Tamura]

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>

[Lars Gunther]

Perhaps take a look at the -moz-any() selector for inspiration. That would help authors too.

[Kent Tamura]

Created attachment 86592 [details]
Patch

[Ojan Vafai]

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?

[Kent Tamura]

(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.

[Ojan Vafai]

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?

[Kent Tamura]

(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.

[Kent Tamura]

Comment on attachment 86592 [details]
Patch

Clearing flags on attachment: 86592

Committed r82400: <http://trac.webkit.org/changeset/82400>

[Kent Tamura]

All reviewed patches have been landed.  Closing bug.

[Antti Koivisto]

(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.