On Thu, Mar 20, 2025 at 9:06 AM Chris Harrelson <chris...@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 <zcor...@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
> cheers,
>>>
>>> On Thu, Mar 20, 2025 at 12:37 AM Mason Freed <mas...@chromium.org>
>>> wrote:
>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>> On Tuesday, March 18, 2025 at 5:50:10 PM UTC-4 Mason Freed wrote:
>>>>>
>>>>>> On Mon, Mar 17, 2025 at 11:15 AM Alex Russell <
>>>>>> slightly...@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
>>>>>> <https://github.com/whatwg/html/issues/7867#issuecomment-2711723856>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On Thursday, March 6, 2025 at 5:20:03 PM UTC-8 Mason Freed wrote:
>>>>>>>
>>>>>>>> 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 <bratel...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>> *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 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/CAM%3DNeDiq9dDw-po-DKJ-Oh6Bm8Z1sBSio1_KnT-nBN9Z%3D4ESRw%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiq9dDw-po-DKJ-Oh6Bm8Z1sBSio1_KnT-nBN9Z%3D4ESRw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Simon Pieters
>>> https://www.mozilla.com/
>>>
>> --
>> 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/CADsXd2N3Vu8nd2Haeqsf5mdkmXY5MnKutMBhHS7vb%3DN_zMSSHg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N3Vu8nd2Haeqsf5mdkmXY5MnKutMBhHS7vb%3DN_zMSSHg%40mail.gmail.com?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/CAM%3DNeDhB9%2BpP_AUa7SAS8RSgcG8evu23akgogHE3-qEL6d0H%3DQ%40mail.gmail.com.
