Seems extremely unlikely.

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

cc @whatwg/css

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.

h2-h5 in hgroup styling removed in #7886

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.

We didn't get to this issue in the triage meeting today. Optimistically tagging @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.

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

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.

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

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.

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

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

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?

Make sense, thank you for clarifying!

Stylesheet for web developers to opt in to the new (or original) styling now:

h1 { margin-block: 0.67em; font-size: 2em; }

If you want to add this to a reset stylesheet but don't want to override any other style rule, use :where() which has zero specificity:

:where(h1) { margin-block: 0.67em; font-size: 2em; }

Gecko will now show a console warning when there's no author-specified font-size or margin: https://bugzilla.mozilla.org/show_bug.cgi?id=1937568

@mfreed7

+@lilles who added the use counter.

Yes, marking something deprecated in Chromium will lower the Lighthouse score for "Best Practices" by enough to guarantee that the overall Lighthouse score isn't "green". (I pushed for that as part of the mutation events deprecation.)

I've filed https://issues.chromium.org/issues/394111284

Hey so I've finally gotten around to marking this deprecated. One question: all of the announcements and discussion has been around "h1 within section". But the spec talks about <h1> within four different elements: <article>, <aside>, <nav>, <section>. The Chrome use counter currently counts any of the four, and my plan was to mark all four deprecated. But I wanted to confirm here first.

Thank you!

Yes, should be h1 in any of article, aside, nav, section.

Thank you!

Yes, should be h1 in any of article, aside, nav, section.

Thanks! Is there a spec PR to actually remove the section in question? Even if it doesn't land, it'd be helpful for my intent to deprecate, which requests links to the spec or spec PR. Since I think this is a serious attempt to remove this stuff, it seems like we should put up a PR to do so.

There is now: #11102

There is now: #11102

Thanks!

And just a quick update that Chrome v136 will now show deprecation warnings for <h1> inside the 4 elements, when the <h1> uses the default smaller font size. Which does hurt the Lighthouse score:

Can you comment on the timeline for removal of this behavior from stable Firefox? There were questions from the Blink API owners about that. I'd like to follow your lead, letting Firefox turn them off for a bit and see what problems surface, and then if not too bad, disable in Blink.

Great! We're planning to start a staged rollout soon (bug). There's no set timeline yet, I can comment here when I know.

The current plan is:

• March 31: roll out to 50% of Firefox 138 Beta (desktop)
• April 14: roll out to 100% of Firefox 138 Beta (desktop)
• April 29: roll out to 5% of Firefox 138 Release (desktop)
• May 13: roll out to 50% 10% of Firefox 138 Release (desktop)
• If this goes well, roll out to 100% of desktop and flip the pref on all platforms. If it rides the trains for 140, it reaches the release channel on June 24.

Intent to unship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/CzG_pVa7pws/m/Ab3Bwsg2BQAJ

We published an article on MDN https://developer.mozilla.org/en-US/blog/h1-element-styles/ (comments on Hacker News)

Status update: we have received 0 broken site reports due to this change since starting the rollout in beta. We'll continue with the rollout in release as planned.

Status update: the change has been rolled out to 5% of Firefox 138 release since April 29. Still no broken site reports. The rollout will continue as planned and we have landed the pref flip now which is targeting v140.

I think the Chromium use counter has some amount of false positives because some sites have a flash of unstyled content (due to forcing layout or loading CSS async). See GoogleChrome/lighthouse#16404 (comment)

I think the Chromium use counter has some amount of false positives because some sites have a flash of unstyled content (due to forcing layout or loading CSS async). See GoogleChrome/lighthouse#16404 (comment)

Thanks for the link - I hadn't seen that bug report. (Makes me happy that the deprecation->Lighthouse->developer path is working!) At first I was thinking about how to avoid providing the deprecation message in that FOUC case, but I think maybe the counter/message is working as expected. I agree that it likely means the counter is likely a bit higher than it should be, but maybe it's ok given the state of this removal?

I agree that it likely means the counter is likely a bit higher than it should be, but maybe it's ok given the state of this removal?

Yeah, no need to tweak the use counter IMO.

Status update: still no broken site reports. Rollout is now active for 10% of release.

Status update: still no reported regressions. I'm calling success on the rollout experiment. When 139 is released, I plan to increase the rollout on desktop to 100%. The pref flip will ride the trains for 140.