There's more in Intent to Remove: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
--- start quote, emphasis mine ---
We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal
--- end quote ---
It ought to be a lot easier than this detective-work to discover this plan. Like, we should probably all know about it, and stop using these user-agent modals now working to replace all use of them?
(rails-ujs, for instance, still uses window.confirm for opt-in "are you sure" on form submissions. not sure what a good replacement is honestly. This is something I would hope to see people discussing and figuring out...)
Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1]
More context on the same blog [2]
1: https://www.quirksmode.org/blog/archives/2017/09/chrome_brea...
2: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc.
The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail.
> They might pull the “proposal” only to just do it again later
It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.