Hey Mason,

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?

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 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/825f55e2-1f1d-4cec-a371-13c4a73f2b47n%40chromium.org.

Reply via email to