[trangus_1985]

> can't think of a nice way to visually distinguish it from the browser's chrome

i don't think it's about visual design. Having a signalling mechanism that lives outside of the dom is confusing to users, and alert is a rare exception from wayyyy back when. It looks like google is doing this for user security, and I support it.

I don't support the way they're going about it. If Mozilla and Microsoft and W3C are willing to get on board, I would greatly support it. But this is more throwing their weight around, and it sucks!

>existing web

i'm gonna be honest, i havent seen a meaningful alert be used in recent memory, and i work with a lot of web apps. All alert()s could be easily replaced with something inline. I'm not a huge fan of breaking changes, but this is one (with a multi year rollout) that I would support.

[MinusGix]

It isn't uncommon for me to find a site that uses it legitimately. Sometimes for telling the user info, sometimes for reporting an error, and sometimes for other goals. Sure, it'd be better if they did it in a more normal manner (writing their message into an HTML paragraph), but they do use it. But a lot of these sites are dead (though some aren't) and so it for the most part doesn't matter if you remove it now or after three years. They'll still break or lose functionality. Just spit out a warning to the dev console when it is used.

[plopz]

>i'm gonna be honest, i havent seen a meaningful alert be used in recent memory, and i work with a lot of web apps.

I see them used very often to indicate unsaved changes when a user leaves a page.

[trangus_1985]

that's confirm(). alert() cant block a page close in progress (by design, afaik)

I'm actually not a huge fan of the design of confirm() either, but at least that has a valid, modern use

[lkschubert8]

Isnt that confirm()

[david_allison]

> In general all of the simple dialogs (alert(), prompt(), confirm(), and beforeunload) are deprecated and being removed slowly but surely from the web platform. They use trusted browser UI, which opens them up to abuse, and they block the event loop, which is not in keeping with the web's cooperative task model. So this is just a first step toward eventually completely removing them, which will take many years.

https://github.com/whatwg/html/issues/6897#issuecomment-8857...

[phpnode]

The UX issue is directly highlighted in their rationale for the change.

Calls to alert(), confirm() and prompt() cannot be polyfilled or safely replaced in the general case because they explicitly block the main thread. That behaviour might not be desirable, but it was the path chosen when the relevant code was written. While some maintained applications will be able to switch to asynchronous alternatives, many older and unmaintained websites - the long tail of the web, will stop working.