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
On 2025-03-05 04:46, Vladimir Levin wrote:
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
<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
<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
<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
<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
<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
<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
<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
<https://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
<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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db4cf7ef-eea7-4aed-b0b0-2402c6e3826cn%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/6962495b-444c-4e66-beaa-807471b2fd4d%40gmail.com.
