4 ms·

Erm, alert() is being deprecated? Don't like half the "JavaScript for beginners" books use alert() for the first few "Hello World"-type programs?

gkoberger 5y ago
It's not! Just being able to trigger alert from an iFrame that is being reconsidered.
- q-rews 5y ago
  > being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team. 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_breaks_v.html https://www.quirksmode.org/blog/archives/2017/09/chrome_brea... 2: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
  - bokan 5y ago
    Disclaimer: I'm the one who made the change in [1] so I'm biased but... 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.
    - jacquesm 5y ago
      Then you go to the standards body.
- anonydsfsfs 5y ago
  That's just the immediate change, but the Chrome team has said they plan on removing alert() entirely: https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647331804037120
  - shp0ngle 5y ago
    It's a random Twitter thread where it's not even clear if they talk about alert() in general, or iframe alerts.
    - dmitriid 5y ago
      It's not a random twitter thread. That's one of Chrome's main standards-writing people. And he explicitly talks about the removal of these entirely. There's more in Intent to Remove: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/Ut5AZXwuBAAJ 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 ---
      - shp0ngle 5y ago
        okay, that’s actually a useful source, thanks.
      - jrochkind1 5y ago
        Thanks for this! 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...)

gkoberger 5y ago

It's not! Just being able to trigger alert from an iFrame that is being reconsidered.

q-rews 5y ago
> being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team. 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_breaks_v.html https://www.quirksmode.org/blog/archives/2017/09/chrome_brea... 2: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
- bokan 5y ago
  Disclaimer: I'm the one who made the change in [1] so I'm biased but... 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.
  - jacquesm 5y ago
    Then you go to the standards body.
anonydsfsfs 5y ago
That's just the immediate change, but the Chrome team has said they plan on removing alert() entirely: https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647331804037120
- shp0ngle 5y ago
  It's a random Twitter thread where it's not even clear if they talk about alert() in general, or iframe alerts.
  - dmitriid 5y ago
    It's not a random twitter thread. That's one of Chrome's main standards-writing people. And he explicitly talks about the removal of these entirely. There's more in Intent to Remove: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/Ut5AZXwuBAAJ 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 ---
    - shp0ngle 5y ago
      okay, that’s actually a useful source, thanks.
    - jrochkind1 5y ago
      Thanks for this! 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...)