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 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/CAM%3DNeDiDFFOt9jvtXp1jSyX4UJsH%3DwxhR%2B%2BjpoZGBxbQN%3D5Wew%40mail.gmail.com.
