7 ms·

I believe this tweet has been twisted from the original tweet, which is that _cross origin_ alert (e.g. from an iframe) is the thing being removed. Using alert

by saulr 5y ago

I believe this tweet has been twisted from the original tweet, which is that _cross origin_ alert (e.g. from an iframe) is the thing being removed. Using alert etc from the main frame will continue to work.

phpnode 5y ago
They are planning to deprecate them from the platform entirely, this is the first step
- torstenvl 5y ago
  Please provide a link, or stop passing speculation off as truth.
  - phpnode 5y ago
    Tweets from Google employees who work on chrome: https://twitter.com/estark37/status/1422694855390629893 https://twitter.com/estark37/status/1422694855390629893 https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647483944034308 https://twitter.com/domenic/status/1422647483944034308 https://twitter.com/domenic/status/1422704005453582337 https://twitter.com/domenic/status/1422704005453582337
    - torstenvl 5y ago
      Those links contradict your assertion, instead indicating a move to "non-blocking alert()"
      - phpnode 5y ago
        That breaks the web by definition. There is no way to implement a non-blocking alert(), confirm(), or prompt() in a way that doesn't break existing code that uses them, and that's a lot of code, a lot of the web.
        zozbot234 5y ago
        It can block JavaScript execution on the page for compatibility with existing code, while leaving normal browsing unaffected otherwise.
        phpnode 5y ago
        the alert(), confirm(), and prompt() themselves interrupt normal browsing, so I'm not sure what you mean here. They're synchronous so block the main thread, but they also block other user interactions until they're dismissed, so what would be the benefit in leaving normal browsing unaffected if the user cannot browse anyway?
      - danShumway 5y ago
        From those links: > Yeah, I think the most likely eventual "removal" path is actually non-blocking alert(). (confirm() and prompt() cannot be converted to non-blocking though, so they'd have to be fully removed) Blocking Javascript execution is a fundamental part of the `alert` spec. Replacing it with a different, non-JS-blocking thing that happens to share the same name doesn't mean that `alert` wouldn't be removed as it exists today. And there's just no way at all to make `prompt`/`confirm` non-blocking, they have to block the main JS thread in order to keep the same API.

by saulr 5y ago

phpnode 5y ago

They are planning to deprecate them from the platform entirely, this is the first step

torstenvl 5y ago
Please provide a link, or stop passing speculation off as truth.
- phpnode 5y ago
  Tweets from Google employees who work on chrome: https://twitter.com/estark37/status/1422694855390629893 https://twitter.com/estark37/status/1422694855390629893 https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647331804037120 https://twitter.com/domenic/status/1422647483944034308 https://twitter.com/domenic/status/1422647483944034308 https://twitter.com/domenic/status/1422704005453582337 https://twitter.com/domenic/status/1422704005453582337
  - torstenvl 5y ago
    Those links contradict your assertion, instead indicating a move to "non-blocking alert()"
    - phpnode 5y ago
      That breaks the web by definition. There is no way to implement a non-blocking alert(), confirm(), or prompt() in a way that doesn't break existing code that uses them, and that's a lot of code, a lot of the web.
      - zozbot234 5y ago
        It can block JavaScript execution on the page for compatibility with existing code, while leaving normal browsing unaffected otherwise.
        phpnode 5y ago
        the alert(), confirm(), and prompt() themselves interrupt normal browsing, so I'm not sure what you mean here. They're synchronous so block the main thread, but they also block other user interactions until they're dismissed, so what would be the benefit in leaving normal browsing unaffected if the user cannot browse anyway?
    - danShumway 5y ago
      From those links: > Yeah, I think the most likely eventual "removal" path is actually non-blocking alert(). (confirm() and prompt() cannot be converted to non-blocking though, so they'd have to be fully removed) Blocking Javascript execution is a fundamental part of the `alert` spec. Replacing it with a different, non-JS-blocking thing that happens to share the same name doesn't mean that `alert` wouldn't be removed as it exists today. And there's just no way at all to make `prompt`/`confirm` non-blocking, they have to block the main JS thread in order to keep the same API.