Remove UA style for h1-h6 in section (et. al.) and hgroup

[zcorpan]

If/when #7829 is merged, the following UA style doesn't make sense. Can it be removed?

In the following CSS block, x is shorthand for the following selector: :is(article, aside, nav, section)

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { margin-block-start: 0.83em; margin-block-end: 0.83em; font-size: 1.50em; }
x x h1 { margin-block-start: 1.00em; margin-block-end: 1.00em; font-size: 1.17em; }
x x x h1 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; }
x x x x h1 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x x x x h1 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

x hgroup > h1 ~ h2 { margin-block-start: 1.00em; margin-block-end: 1.00em; font-size: 1.17em; }
x x hgroup > h1 ~ h2 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; }
x x x hgroup > h1 ~ h2 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x x x hgroup > h1 ~ h2 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

x hgroup > h1 ~ h3 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; }
x x hgroup > h1 ~ h3 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x x hgroup > h1 ~ h3 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

x hgroup > h1 ~ h4 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x hgroup > h1 ~ h4 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

x hgroup > h1 ~ h5 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }> 

https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings

[domenic]

Seems extremely unlikely.

[annevk]

Unlikely, but also quite unfortunate. I'd certainly support someone investigating this.

cc @whatwg/css

[zcorpan]

The hgroup special styling could probably be removed since hgroup usage is a lot lower than the sectioning elements, and multiple headings in hgroup is non-conforming with #7829. And it's not implemented in any of Gecko, Chromium, WebKit!

Demo: https://h1-ua-style.glitch.me/

Maybe it's possible to remove the other rules also; author CSS to set the font-size was needed to get consistent style in older browsers (in particular IE8). But this would need some research.

[zcorpan]

h2-h5 in hgroup styling removed in https://github.com/whatwg/html/pull/7886

[zcorpan]

Adding agenda+ to check interest in adding a use counter for h1 with a sectioning element ancestor and no Author Origin style for font-size.

[zcorpan]

We didn't get to this issue in the triage meeting today. Optimistically tagging @mfreed7 :)

[mfreed7]

Sorry for the delay responding here. +@lilles because such an applied-styles use counter (at least in Chromium) would fall more onto his domain.

[lilles]

@mfreed7 I need an executive summary of what to respond to. I'm totally out of context.

[zcorpan]

Summary:

If it's web-compatible, I think we should remove this part of the spec:

In the following CSS block, x is shorthand for the following selector: :is(article, aside, nav, section)

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { margin-block-start: 0.83em; margin-block-end: 0.83em; font-size: 1.50em; }
x x h1 { margin-block-start: 1.00em; margin-block-end: 1.00em; font-size: 1.17em; }
x x x h1 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; }
x x x x h1 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x x x x h1 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

To determine web compatibility, is there interest in adding a use counter for h1 with a sectioning element ancestor and no Author Origin style for font-size? (I assume that changes to margin are more acceptable than font-size.)

When such a use counter exists on Stable, I can query for pages in httparchive that hit the use counter and analyze the compat impact.

[lilles]

Thanks! Looking at the UA sheet and our impl it seems that a counter shouldn't be too tricky to add. Reported: https://crbug.com/1334570

[lilles]

Counter landed (for M105): https://chromium-review.googlesource.com/c/chromium/src/+/3698090

ons. 8. jun. 2022 kl. 11:44 skrev Simon Pieters @.***>:

Summary:

If it's web-compatible, I think we should remove this part of the spec:

In the following CSS block, x is shorthand for the following selector: :is(article, aside, nav, section)

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { margin-block-start: 0.83em; margin-block-end: 0.83em; font-size: 1.50em; } x x h1 { margin-block-start: 1.00em; margin-block-end: 1.00em; font-size: 1.17em; } x x x h1 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; } x x x x h1 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; } x x x x x h1 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }

To determine web compatibility, is there interest in adding a use counter for h1 with a sectioning element ancestor and no Author Origin style for font-size? (I assume that changes to margin are more acceptable than font-size.)

When such a use counter exists on Stable, I can query for pages in httparchive that hit the use counter and analyze the compat impact.

— Reply to this email directly, view it on GitHub https://github.com/whatwg/html/issues/7867#issuecomment-1149698317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGZFVLC77YL2SOELQRPHPLVOBTPTANCNFSM5USM32CQ . You are receiving this because you were mentioned.Message ID: @.***>

-- Rune Lillesveen

[zcorpan]

Thanks @lilles! Per https://chromiumdash.appspot.com/schedule it should reach stable on August 30. With some luck it will be included in the September 1st HTTP Archive run.

[domenic]

Data so far is not that encouraging: https://chromestatus.com/metrics/feature/timeline/popularity/4272

[matuzo]

Hi, I'm a teacher, and the other day I talked about the section element and the outline algorithm that was in the spec but never implemented. I also showed students how the font size of nested section headings still decreases visually. They found that confusing. I'm only mentioning that to emphasise that as an author, I also believe that these UA styles should be removed.

Is this the right place to keep track of the progress? The last comment was a year ago. Are there any updates?

Thank you, Manuel

[domenic]

Thanks for pinging this thread. Per the above data, it looks like removing this would break about 0.6% of the web.

I suspect no browsers are enthusiastic about doing that. So, shall we close this?

[matuzo]

Make sense, thank you for clarifying!

[zcorpan]

I'd like to still do an analysis of impact for the affected pages. If the difference is minor for the vast majority of pages then it's not a breaking change.

[zcorpan]

I've analyzed the first 30 URLs from top sites listed in https://chromestatus.com/metrics/feature/timeline/popularity/4272 with a custom build of Firefox with this change applied and compared to regular Firefox Nightly.

Findings: The sites are either unaffected or the change looks OK (I wouldn't expect browser bug reports for these), or in some cases revert to author-intended size.

0.5-0.6% of pages and page loads is still a lot, so there could of course be something that breaks more substantially. Still, I think it's worth it to try to make this change, to make HTML default styling make more sense for the long term.

Notes (updated 2024-05-14 to group by impact and add info for arstechnica.com):

• 🟢 https://24.hu/ uses h1 for the site logo, which is abspos and has no text, so no change.
• 🟢 https://adultgamesworld.com/ (NSFW) site heading, no visual change.
• 🟢 https://ae.linkedin.com/ has author-specified font-size on the one relevant h1.
• 🟢 https://akispetretzikis.com/ has author-specified font-size on the relevant h1s.
• 🟢 https://ameblo.jp/ no visual change.
• 🟢 https://ar.linkedin.com/ same as earlier linkedin.
• 🟢 https://au.linkedin.com/ same as earlier linkedin.
• 🟢 https://auladigital.leya.com/ has author-specified font-size on the relevant h1s.
• 🟢 https://br.linkedin.com/ same as earlier linkedin.
• 🟢 https://br.privalia.com/public/ no element matching :is(article, aside, nav, section) h1 in devtools.
• 🟢 https://bs.benefit-one.inc/ no visual difference.
• 🟢 https://ca.linkedin.com/ same as earlier linkedin.
• 🟢 https://canaltech.com.br/ no visual difference (h1 is display: none).
• 🟢 https://casinoextreme.eu/ no visual difference (out of view SEO text)
• 🟢 https://co.linkedin.com/ same as earlier linkedin.
• 🟢 https://comic-days.com/ no visual difference.
• 🟢 https://comic-gardo.com/ no visual difference.
• 🟢 https://consulta.trf4.jus.br/ no visual difference.
• 🟡 https://1000giribest.com/ (NSFW) has a slight spacing difference in a heading (it sets font-size on a child a element). Seems OK.
• 🟡 https://192-168-1-1ip.mobi/ the main content heading "192.168.1.1 Admin Login" is affected, but seems OK. The next heading "How to login 192.168.1.1 in 5 easy steps" is an h2, so arguably the page expects different sizes.
• 🟡 https://19216811.vn/ similar to the above. Seems OK.
• 🟡 https://2sao.vn/ uses h1 for the site logo (an image), but the font-size difference causes a few pixels more spacing for the top nav. Seems OK.
• 🟡 https://63pokupki.ru/ the heading "Что такое совместные покупки (закупки)" is a bit larger, but seems OK.
• 🟡 https://acstuff.ru/ the card headings are larger. Maybe the smaller text is intended, but the site is still usable and looks OK.
• 🟡 https://arstechnica.com/ no element matching :is(article, aside, nav, section) h1 in devtools for the desktop site, but the mobile site has a spacing difference for some links. (2 bugs filed for Firefox Nightly.)
• 🟡 https://beyondhallyu.com/ the heading "ASIA TOGEL88: Platform Terpercaya untuk Penggemar Togel dan Permainan Kasino" is bigger, but it looks OK.
• 🟡 https://clave-dninbrt.seg-social.gob.es/ the heading font-size is larger, but it looks OK.
• 🟡 https://clickbuy.com.vn/ the heading "Website bán hàng công nghệ uy tín hàng đầu Việt Nam" at the bottom is larger, but looks OK.
• 🟡 https://corretor.portoseguro.com.br/ the carousel text on the right has different line-height (but same font-size). Looks OK.
• ⚪️ https://caturwinvip.net/ ? I get "Website Access Restricted"

[zcorpan]

https://bugzilla.mozilla.org/show_bug.cgi?id=1883896

[zcorpan]

I've landed a patch now that only affects Firefox Nightly. I'll let it sit for a bit and see if we get bug reports. If it seems OK, I plan to submit a spec PR.

[pdjstone]

Could this change be causing this issue https://webcompat.com/issues/134857 ?

[zcorpan]

@pdjstone yes. See https://bugzilla.mozilla.org/show_bug.cgi?id=1886480

[zcorpan]

Firefox has had this change in Nightly for about 2 months now, and we've received 2 bugs about arstechnica.com having too much spacing (on mobile only).

Looking back at my previous analysis above, 11 out of 29 pages had some visual difference. Even though my assessment is generally "looks OK", we did get bugs about arstechnica.com, and 38% of 0.6% is still ~0.23% of sites potentially being affected.

I wonder at this point if there's interest from WebKit and/or Chromium to also pursue this change? If so, we might want to do something to get the numbers down, e.g. console warning in devtools, check in Lighthouse, etc., before shipping to stable.

[annevk]

In principle this seems fine to try from WebKit's point of view.

[mfreed7]

In principle, Chromium is supportive of this a11y-enhancing change. We are more than a bit concerned about the compat impact, and whether it'll be landable, but I'm glad it sounds like Gecko is going to blaze the trail there and hopefully report back here with successes and failures? I'm in the process of landing my own breaking change, and we only have so much bandwidth available to break things.

I'd be happy to help with console warnings and such, but... is there really a way to do that? I'm not sure how you'd disambiguate "good/expected" usage with "unexpected" usage. I definitely don't think it'd be good to just spam the console for anyone using a header tag. Help me understand what you end up doing in Gecko and we can try to follow suit.

[PaulineNemchak]

Hi, I don't see why people would want only h1 headings be smaller in articles and sections. It makes h1 and h2 tags the same size and a bit confusing and also leads to necessity to override font sizes. Maybe there was some logic behind that?

[pepelsbey]

Maybe there was some logic behind that?

@PaulineNemchak There was an idea once to use only h1s for headings, determining level by nesting into specific elements. This dream is long gone, but styles are still there.

You brought up a good point about h1 and h2 looking unexpectedly the same.

[zcorpan]

Update: We've shipped this change in Nightly only for about 9 months (https://bugzilla.mozilla.org/show_bug.cgi?id=1883896), and only one page reported as regressed, which has since been fixed (https://bugzilla.mozilla.org/show_bug.cgi?id=1886480).

@mfreed7:

I'd be happy to help with console warnings and such, but... is there really a way to do that? I'm not sure how you'd disambiguate "good/expected" usage with "unexpected" usage. I definitely don't think it'd be good to just spam the console for anyone using a header tag. Help me understand what you end up doing in Gecko and we can try to follow suit.

We haven't implemented any console message yet, but I envisioned logging a message when h1 in a sectioning element is rendered but doesn't have author-defined font-size or block margins. When the change has shipped everywhere, there's no need for the warning anymore.

[zcorpan]

The use counter seems to be flat or possibly trending slowly in the wrong direction.

I queried httparchive for all pages that trigger the use counter, and analyzed the top-ranked pages (23 pages with rank bucket 1000).

https://docs.google.com/spreadsheets/d/1YfrbqE-lJRN0cEq0SC-cQs5FC6XvvyhdVEsrhjwpOy8/edit?usp=sharing

One page has an improved rendering (current behavior is h1 and h2 have the same size). Two pages from one site (1, 2) has a difference in font size but it's minor and probably not noticeable. The rest had no visual difference.

I'll try to move this forward for Firefox, probably with a staged rollout A/B experiment or maybe shipping to early beta. I'll look into console warning also.

@mfreed7 is there some integration between Chromium API deprecations and Lighthouse? Maybe the use counter code path could log a deprecation signal also? I found https://developer.chrome.com/docs/lighthouse/best-practices/deprecations

[zcorpan]

Posts on socials

https://x.com/zcorpan/status/1879929421911724168 https://bsky.app/profile/zcorpan.bsky.social/post/3lfupkjkkms2s https://mastodon.social/@zcorpan/113838709354772546