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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> > > 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 > > > *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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?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 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 > <https://chromestatus.com/>. > > On Tue, Mar 4, 2025 at 3:47 PM Jason Robbins <jrobb...@google.com> wrote: > >> 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! >> >> On Tuesday, March 4, 2025 at 3:43:34 PM UTC-8 Jason Robbins wrote: >> >>> 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 >>> <https://chromestatus.com/feature/6192419898654720> 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! >>> >>> >>> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-qFMvsdy7RsNHPB0JxGi7u%3Dc9bUEwrFKRof2smEcWXQA%40mail.gmail.com.
