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 <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 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 <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 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 <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/db4cf7ef-eea7-4aed-b0b0-2402c6e3826cn%40chromium.org.
