[whatwg] Can we deprecate alert(), confirm(), prompt() ?

[Aryeh Gregor]

On Tue, Mar 1, 2011 at 9:52 PM, WeBMartians <webmartians at verizon.net> wrote:
> Aryeh! You have made an ad-hominem attack: shame on you! I mention the
> Microsoft use cases only to save space. There are similar cases in the Linux
> and Macintosh realms. Judge an idea by its merits, not by its source (even
> if that source is as disreputable as I certainly am).

I didn't make any ad hominem attacks.  I pointed out that we want
use-cases, not just the fact that something is present in an OS API.
Possibly Linux and/or Mac have similar APIs, but it still wouldn't
help your case if there are no concrete use-cases you can present.  OS
implementers have very different audiences and goals than browser
implementers, and just because OS implementers add a feature doesn't
mean browser implementers will want to.

> You are correct that short duration time outs are, often, a terrible idea
> ... but the standard should not hobble the developer.

Attempting to prevent developers from doing bad things to users,
either through malice or incompetence, is a recurring theme in web
APIs.

> ...and consider this: just how would you handle the case in which the WWWeb
> page says:
>
>   There is an approaching storm!
>   Do you wish to close the dykes?
>      No (let everybody drown)
>      Yes (if you don't answer in an hour, this will be the default)

Is this meant to be in a multiplayer game, where the player has to
make a decision within an hour?  I don't think such a game would want
to use modal dialogs at all, because they prevent JS from running, so
it wouldn't be able to update its state as long as the dialog is
displayed.  They should use custom dialogs instead.

More generally, any proposed addition to alert()/prompt()/confirm()
needs to explain why its intended audience would actually use those
APIs to begin with instead of hacking something more flexible up in
JavaScript.  They're not the best tool for almost any job except a
very simple one.