Intent to Deprecate and Remove: Deprecate special font size rules for H1 within some elements

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

None

Specification

None

Summary

The HTML spec contains a list of special rules for <h1> tags nested within <article>, <aside>, <nav>, or <section> tags: https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings These special rules are deprecated, because they cause accessibility issues. Namely, they visually reduce the font size for nested <h1>s so that they "look" like <h2>s, but nothing in the accessibility tree reflects this demotion.

Blink component

Blink>CSS

Motivation

None

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6192419898654720?gate=5420483144843264

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

This Intent is missing a lot of fields we usually require:

• Explainer
• Specification
• Motivation
• TAG review
• Gecko/WebKit signals
• Web developer signals
• Web platform tests
• Finch feature name
• Estimated milestones

Please fill those out and send an updated Intent when they are ready. (Or let us know why you think they're appropriate to omit.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjZLhF5dL%2BsLWC2RqgZ2SnM2pBh9y7Y5CZFKFThG0RbQg%40mail.gmail.com.

[Mason Freed]

Yep, sorry about the missing fields - I noticed a few of those after sending the initial intent. I just updated the rest, see below for some comments:

On Mon, Mar 3, 2025 at 5:01 PM Domenic Denicola <dom...@chromium.org> wrote:

This Intent is missing a lot of fields we usually require:

• Explainer

No explainer for this change - just the spec discussion. Hopefully that's ok? (It's not my deprecation, Mozilla is driving this deprecation.)

• Specification

No spec PR yet, though I just requested one.

• Motivation

Done. 

• TAG review

No such field for a deprecation, or... I couldn't find it. Let me know if I missed it somewhere. 

• Gecko/WebKit signals
• Web developer signals
• Web platform tests

Done. 

• Finch feature name

None yet, since this is just the deprecation, not the removal. All I am adding is a console warning at this point. 

• Estimated milestones

I added "Dev trial" start milestones (M136) but I don't know about the final removal milestone. This is mostly dependent on Mozilla, who is driving this.

 

Please fill those out and send an updated Intent when they are ready. (Or let us know why you think they're appropriate to omit.)

The kicker: the chromestatus tool only gives you one shot at creating the intent email. Now that I've done it once, that button is gone. In order to send another email, it seems that I'd have to create an entirely new chromestatus entry, and I'm loath to do that. Let me know if it's enough to point you to the chromestatus page itself to see the updated sections? Sorry.

Thanks,

Mason

[Jason Robbins]

The kicker: the chromestatus tool only gives you one shot at creating the intent email. Now that I've done it once, that button is gone. In order to send another email, it seems that I'd have to create an entirely new chromestatus entry, and I'm loath to do that. Let me know if it's enough to point you to the chromestatus page itself to see the updated sections? Sorry.

 

Mason, here's a link to the intent preview page for this feature entry that you could copy again:

https://chromestatus.com/feature/6192419898654720/gate/5420483144843264/intent

 

ChromeStatus doesn't offer that button after the intent thread is detected simply because we reuse that UI area to show review status info, which is typically the next step in the process.  However, that button is just a link to the intent preview page, and it is always available if you fill in the feature ID and gate ID.  Of course, any copy-and-pasted email can fall out of date, and it only has a subset of the feature entry fields, so reviewers should make use of the full feature entry as needed.

Thanks,

jason!

[Jason Robbins]

Oh, and to clarify, I was suggesting that you could copy using the small copy-icon button and paste it on this thread as a reply.  Don't start a new blink-dev thread or use the "Post directly to blink-dev" button (because that will start a new thread).

Thanks,

jason!

[Mason Freed]

Thanks Jason! Here's the new/updated email:

Contact emails

mas...@chromium.org

Explainer

None

Specification

None

Design docs

https://github.com/whatwg/html/issues/7867#issue-1218728578

Summary

The HTML spec contains a list of special rules for <h1> tags nested within <article>, <aside>, <nav>, or <section> tags: https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings These special rules are deprecated, because they cause accessibility issues. Namely, they visually reduce the font size for nested <h1>s so that they "look" like <h2>s, but nothing in the accessibility tree reflects this demotion.

Blink component

Blink>CSS

Motivation

The current behavior is an accessibility problem: the font size is reduced as if an <h2> is being used, but the a11y tree still shows the item as an <h1>. By removing these special rules, we'll nudge developers to do the "better" thing of actually using an <h2>.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Use counters are relatively high: https://chromestatus.com/metrics/feature/timeline/popularity/4272 However, analysis from Mozilla shows that perhaps the impact is not as large as the use counters would suggest: https://github.com/whatwg/html/issues/7867#issuecomment-2595987424

Gecko: Shipped/Shipping (https://github.com/whatwg/html/issues/7867#issuecomment-2541654834) Firefox has shipped this removal in Nightly since ~March 2024, and is the one driving this deprecation.

WebKit: Positive (https://github.com/whatwg/html/issues/7867#issuecomment-2124317504) This isn't a standards position, just a github comment.

Web developers: No signals No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/html/rendering/non-replaced-elements/sections-and-headings

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

No Finch flag yet - this is just at the "Intent to Deprecate" stage, not the "Removal" stage. Only warnings will be shown for now.

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/394111284

Estimated milestones

DevTrial on desktop	136
DevTrial on Android	136

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6192419898654720?gate=5420483144843264

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

Thanks very much Mason (and Jason).

It wasn't clear to me that this was just in the initial "deprecate" stage, not the "remove" stage: I wish ChromeStatus tooling separated those more cleanly (like it does Dev Trial vs. Ship). Given that you're still in the preparatory deprecation stage, this level of detail seems fine!

I do think a short explainer-like thing will be desirable before we get to the removal stage. Maybe just a few paragraphs detailing what's changing, what impact it might have on developers, and how they can adapt. Hopefully Mozilla can help put that together. A reasonable place for that to live would be the top message of the spec PR.

[Vladimir Levin]

Re TAG: I don't believe we need a TAG review for deprecations or removals.

On Tuesday, March 4, 2025 at 8:54:00 PM UTC-5 Domenic Denicola wrote:

Thanks very much Mason (and Jason).

It wasn't clear to me that this was just in the initial "deprecate" stage, not the "remove" stage: I wish ChromeStatus tooling separated those more cleanly (like it does Dev Trial vs. Ship). Given that you're still in the preparatory deprecation stage, this level of detail seems fine!

I do think a short explainer-like thing will be desirable before we get to the removal stage. Maybe just a few paragraphs detailing what's changing, what impact it might have on developers, and how they can adapt. Hopefully Mozilla can help put that together. A reasonable place for that to live would be the top message of the spec PR.

On Wed, Mar 5, 2025 at 9:36 AM Mason Freed <mas...@chromium.org> wrote:

Thanks Jason! Here's the new/updated email:

Contact emailsmas...@chromium.org

ExplainerNone

SpecificationNone

Design docs
https://github.com/whatwg/html/issues/7867#issue-1218728578

Summary

The HTML spec contains a list of special rules for <h1> tags nested within <article>, <aside>, <nav>, or <section> tags: https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings These special rules are deprecated, because they cause accessibility issues. Namely, they visually reduce the font size for nested <h1>s so that they "look" like <h2>s, but nothing in the accessibility tree reflects this demotion.

Blink componentBlink>CSS

Motivation

The current behavior is an accessibility problem: the font size is reduced as if an <h2> is being used, but the a11y tree still shows the item as an <h1>. By removing these special rules, we'll nudge developers to do the "better" thing of actually using an <h2>.

Initial public proposalNone

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Use counters are relatively high: https://chromestatus.com/metrics/feature/timeline/popularity/4272 However, analysis from Mozilla shows that perhaps the impact is not as large as the use counters would suggest: https://github.com/whatwg/html/issues/7867#issuecomment-2595987424

For posterity, it looks like about 0.6% of page loads would be affected, and that seems to have a gradual trend up.

A deprecation seems fine here. What do you estimate a removal timeline to be? Ideally we can reduce the usecounters as much as we can before a removal.

Gecko: Shipped/Shipping (https://github.com/whatwg/html/issues/7867#issuecomment-2541654834) Firefox has shipped this removal in Nightly since ~March 2024, and is the one driving this deprecation.

Again for posterity, it seems like there was a single report about this, which was fixed on the author's side:

https://mastodon.social/@zcorpan/113843744254923492 

WebKit: Positive (https://github.com/whatwg/html/issues/7867#issuecomment-2124317504) This isn't a standards position, just a github comment.

Web developers: No signals No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?Yes

https://wpt.fyi/results/html/rendering/non-replaced-elements/sections-and-headings

Flag name on about://flagsNone

Finch feature nameNone

Non-finch justification

No Finch flag yet - this is just at the "Intent to Deprecate" stage, not the "Removal" stage. Only warnings will be shown for now.

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/394111284

Estimated milestonesDevTrial on desktop136DevTrial on Android136

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/6192419898654720?gate=5420483144843264

This intent message was generated by Chrome Platform Status.

[Daniel Bratell]

Use counter is 0.6% but judging from the comment https://github.com/whatwg/html/issues/7867#issuecomment-1977647444 the effect seems smaller. Of 30-ish sites investigated there, 15 were unaffected and the rest had seemingly minor changes.

The high counter might be because linkedin triggers it, and linkedin was seemingly not affected.

This does not mean that it's safe to remove the slightly (to me) unexpected quirk, but it might be.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db4cf7ef-eea7-4aed-b0b0-2402c6e3826cn%40chromium.org.

[Mason Freed]

On Tue, Mar 4, 2025 at 7:46 PM Vladimir Levin <vmp...@chromium.org> wrote:

Re TAG: I don't believe we need a TAG review for deprecations or removals.

Great, thanks for confirming.

 

On Tuesday, March 4, 2025 at 8:54:00 PM UTC-5 Domenic Denicola wrote:

It wasn't clear to me that this was just in the initial "deprecate" stage, not the "remove" stage: I wish ChromeStatus tooling separated those more cleanly (like it does Dev Trial vs. Ship). Given that you're still in the preparatory deprecation stage, this level of detail seems fine!

+1. I used to edit the subject like to say "Intent to Deprecate" (i.e. remove the "and Remove") but that broke some of the tooling, so now I don't touch it. But I do wish the descriptions changed to say "deprecation" instead of "dev trial" and "remove" instead of "ship".

 

I do think a short explainer-like thing will be desirable before we get to the removal stage. Maybe just a few paragraphs detailing what's changing, what impact it might have on developers, and how they can adapt. Hopefully Mozilla can help put that together. A reasonable place for that to live would be the top message of the spec PR.

Sure, that makes sense. I think at that point there might be more data to pull into the explainer also.

 

Interoperability and Compatibility

Use counters are relatively high: https://chromestatus.com/metrics/feature/timeline/popularity/4272 However, analysis from Mozilla shows that perhaps the impact is not as large as the use counters would suggest: https://github.com/whatwg/html/issues/7867#issuecomment-2595987424

For posterity, it looks like about 0.6% of page loads would be affected, and that seems to have a gradual trend up.

A deprecation seems fine here. What do you estimate a removal timeline to be? Ideally we can reduce the usecounters as much as we can before a removal.

I agree, it'd be nice to see the use counters go down before that, but I always notice that deprecating things seems to make usage go up. I don't have a great estimate for the removal timeline - I'm following Mozilla's lead on this, and ideally they turn it off by default first for a while, before Blink does. Sorry I don't have a more definite schedule!

 

Again for posterity, it seems like there was a single report about this, which was fixed on the author's side:

https://mastodon.social/@zcorpan/113843744254923492 

Yep, thanks.

On Wed, Mar 5, 2025 at 8:00 AM Daniel Bratell <brat...@gmail.com> wrote:

Use counter is 0.6% but judging from the comment https://github.com/whatwg/html/issues/7867#issuecomment-1977647444 the effect seems smaller. Of 30-ish sites investigated there, 15 were unaffected and the rest had seemingly minor changes.

The high counter might be because linkedin triggers it, and linkedin was seemingly not affected.

This does not mean that it's safe to remove the slightly (to me) unexpected quirk, but it might be.

Unclear to me also, but I'm hopeful.

Thanks, everyone!

Mason

[Alex Russell]

Hey Mason,

This looks good, but I'm not sure I understand the plan. Is it to deprecate (w/ console warnings) for some period of time? Are you going to propose a reverse-OT? Or removal once usage falls below some threshold?

Best,

Alex

[Mason Freed]

On Mon, Mar 17, 2025 at 11:15 AM Alex Russell <sligh...@chromium.org> wrote:

This looks good, but I'm not sure I understand the plan. Is it to deprecate (w/ console warnings) for some period of time? Are you going to propose a reverse-OT? Or removal once usage falls below some threshold?

Yep, it's a good question. The plan is to show console warnings starting now (M136) for a period of time, and wait for Mozilla to start/complete their removal. They are starting an experiment soon to assess the risk and compat, and my plan is to follow their lead. So I would say that once they've moved forward with a general removal, I'd send an I2R (remove) and turn it off in Chrome. I'd likely do that slowly via Finch, to ensure no breakage. I've historically found it tough to assess actual risk via use counters alone, and the only true test is to use Finch and slowly/carefully test a removal. Once that process is successful, we would disable it by default in code for all browsers.

Thanks,

Mason

[Vladimir Levin]

The thing that gives me pause is the nature of the console warning. It isn't that <h1> within, say, <article> is deprecated, it's the fact that the special rules will be removed and thus the font size may look different. I'm not sure what action would be suggested for the authors. Can you comment on that? Is the recommendation to switch to <h2> to keep the current look? Or to just be aware of the change?

[Mason Freed]

On Tue, Mar 18, 2025 at 7:25 PM Vladimir Levin <vmp...@chromium.org> wrote:

The thing that gives me pause is the nature of the console warning. It isn't that <h1> within, say, <article> is deprecated, it's the fact that the special rules will be removed and thus the font size may look different. I'm not sure what action would be suggested for the authors. Can you comment on that? Is the recommendation to switch to <h2> to keep the current look? Or to just be aware of the change?

Great question. So the current text (at least the English version) says this:

The website has an <h1> tag within an <article>, <aside>, <nav>, or <section>, and relies on deprecated UA stylesheet rules for the resulting font size. See the second block of 'x h1' styles in https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings. These special rules are deprecated and will be removed. See https://github.com/whatwg/html/issues/7867.

So it does go to some length to try to explain the exact thing that is being changed, but still it can be a bit confusing. And it doesn't make specific suggestions for how to fix it, since I think those will be very site-specific. Suggestions appreciated for how to improve the effectiveness and clarity of the message! I do agree it would help to have a very clear message to avoid folks making changes they don't need to make.

Thanks,

Mason

[Simon Pieters]

Hi!

Suggestions for web developers:

* Use h1 only for the page's top-level heading. Use h2-h6 for other headings.

* Specify font-size and margin for h1 in your CSS.

Firefox has a similar console warning which reads:

Found a sectioned h1 element with no specified font-size or margin properties. More information: https://developer.mozilla.org/docs/Web/HTML/Element/Heading_Elements#specifying_a_uniform_font_size_for_h1

cheers,

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiq9dDw-po-DKJ-Oh6Bm8Z1sBSio1_KnT-nBN9Z%3D4ESRw%40mail.gmail.com.

--

Simon Pieters

https://www.mozilla.com/

[Vladimir Levin]

Thanks for the answers!

LGTM1 to deprecate. This console message may be interpreted as noise if the author decides that they are OK with the deprecation, but would not be able to silence the warning. Because of this, the API owners strongly suggest that we try to limit the deprecation to 3 milestones and either proceed with removal or re-evaluate.

Thanks!

Vlad

[Chris Harrelson]

LGTM2

(Note: this LGTM is just for deprecation, please come back again for approval to remove.)

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N3Vu8nd2Haeqsf5mdkmXY5MnKutMBhHS7vb%3DN_zMSSHg%40mail.gmail.com.

[Mason Freed]

On Thu, Mar 20, 2025 at 9:06 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

(Note: this LGTM is just for deprecation, please come back again for approval to remove.)

Will do. And yeah I didn't think I needed LGTMs to deprecate, only to remove, right? Akin to I2P not needing LGTM, but I2S needing them?

 

On Thu, Mar 20, 2025 at 8:25 AM Vladimir Levin <vmp...@chromium.org> wrote:

LGTM1 to deprecate. This console message may be interpreted as noise if the author decides that they are OK with the deprecation, but would not be able to silence the warning. Because of this, the API owners strongly suggest that we try to limit the deprecation to 3 milestones and either proceed with removal or re-evaluate.

Ok, hopefully the timeline is short. Developers would be able to silence the warnings with a rule like `section h1 {font-size: 2em;}` so maybe that alleviates the time pressure?

 

On Thu, Mar 20, 2025 at 7:22 AM Simon Pieters <zco...@mozilla.com> wrote:

Firefox has a similar console warning which reads:

Found a sectioned h1 element with no specified font-size or margin properties. More information: https://developer.mozilla.org/docs/Web/HTML/Element/Heading_Elements#specifying_a_uniform_font_size_for_h1

Thanks! That's a helpful link. I've updated our deprecation message to look closer to yours, and to include that link.

Thanks,

Mason

[Chris Harrelson]

On Fri, Mar 21, 2025 at 2:34 PM Mason Freed <mas...@chromium.org> wrote:

On Thu, Mar 20, 2025 at 9:06 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

(Note: this LGTM is just for deprecation, please come back again for approval to remove.)

Will do. And yeah I didn't think I needed LGTMs to deprecate, only to remove, right? Akin to I2P not needing LGTM, but I2S needing them?

One LGTM is needed for this situation.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhB9%2BpP_AUa7SAS8RSgcG8evu23akgogHE3-qEL6d0H%3DQ%40mail.gmail.com.