Intent to Ship: Deprecate special font size rules for H1 within some elements
Mason Freed
{Note: to make sure it's clear, this is the request to actually remove ("ship") the special rules, in M140.}
Contact emails
mas...@chromium.orgExplainer
NoneSpecification
https://github.com/whatwg/html/pull/11102Design 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>CSSTAG review
NoneTAG review status
Not applicableRisks
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 Firefox has now shipped the complete removal of this behavior for two milestones with no reported issues.
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
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
Yeshttps://wpt.fyi/results/html/rendering/non-replaced-elements/sections-and-headings
Flag name on about://flags
NoneFinch feature name
NoneNon-finch justification
NoneRollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://issues.chromium.org/issues/394111284Estimated milestones
| Shipping on desktop | 140 |
| DevTrial on desktop | 136 |
| Shipping on Android | 140 |
| DevTrial on Android | 136 |
| Shipping on WebView | 140 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/6192419898654720?gate=4740512881573888
Rick Byers
{Note: to make sure it's clear, this is the request to actually remove ("ship") the special rules, in M140.}
Contact emails
mas...@chromium.orgExplainer
NoneSpecification
https://github.com/whatwg/html/pull/11102Design docs
https://github.com/whatwg/html/issues/7867#issue-1218728578Summary
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>CSSTAG review
NoneTAG review status
Not applicableRisks
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 Firefox has now shipped the complete removal of this behavior for two milestones with no reported issues.
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
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
Yeshttps://wpt.fyi/results/html/rendering/non-replaced-elements/sections-and-headings
Flag name on about://flags
NoneFinch feature name
None
--
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%3DNeDga_GXVFf6fjoNQ7Y3w5xDDT5U0m75fGYEgnCEV4B2i%3Dg%40mail.gmail.com.
Mason Freed
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 Firefox has now shipped the complete removal of this behavior for two milestones with no reported issues.
I tend to agree this should be low risk. In particular I assume the "severity of breakage" is very low here (worst case some text is just a bit bigger) and "ease of mitigation" is very high, right? The accessibility and interoperability gains make this worth trying and accepting a bit of compat pain for, but I am a little worried we may find eg. some enterprise / LOB app which has an unacceptable UI regression. So I'm supportive as long as we've got a plan to flag off if needed.
Nice. Do we match Firefox at 100% passing when we ship this?
Finch feature name
NoneThis needs a kill switch flag, right? Just in case of an emergency web compat issue?
