Bug 52693

Summary:

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

Product:

WebKit

Reporter:

Kent Tamura <tkent>

Component:

CSS

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cmarcelo, koivisto, ojan, webmaster

Priority:

Keywords:

HTML5

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Bug Depends on:

38095

Bug Blocks:

32934

Attachments:

Description	Flags
Patch	none

Kent Tamura

Reported 2011-01-18 18:23:58 PST

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>

Attachments
Patch (46.28 KB, patch) 2011-03-23 03:09 PDT, Kent Tamura	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Lars Gunther

Comment 1 2011-01-19 16:20:43 PST

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

Kent Tamura

Comment 2 2011-03-23 03:09:04 PDT

Created attachment 86592 [details] Patch

Ojan Vafai

Comment 3 2011-03-23 15:09:31 PDT

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

Comment 4 2011-03-29 03:55:35 PDT

(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 5 2011-03-29 21:19:57 PDT

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

Comment 6 2011-03-29 21:42:34 PDT

(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 7 2011-03-30 00:00:37 PDT

Comment on attachment 86592 [details] Patch Clearing flags on attachment: 86592 Committed r82400: <http://trac.webkit.org/changeset/82400>

Kent Tamura

Comment 8 2011-03-30 00:00:44 PDT

All reviewed patches have been landed. Closing bug.

Antti Koivisto

Comment 9 2011-03-30 20:15:19 PDT

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

Note You need to log in before you can comment on or make changes to this bug.