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

[Ian Hickson]

On Tue, 1 Mar 2011, Ojan Vafai wrote:
>
> FWIW, chromium is planning on experimenting with disallowing modal 
> dialogs during the beforeunload/unload events. 
> http://code.google.com/p/chromium/issues/detail?id=68780

Please let us know how this goes, so I can update the spec accordingly (to 
at least allow this, or maybe require it, depending on how other browser 
vedors feel about this).


On Tue, 1 Mar 2011, Robert O'Callahan wrote:
> 
> That sounds fairly unpleasant for users of pages which give "are you 
> sure you want to leave this page and lose your data?" warnings.

Presumably this would continue to work, indeed.


On Tue, 1 Mar 2011, WeBMartians wrote:
> On 2011-02-28 19:42, Ian Hickson wrote:
> > On Thu, 25 Nov 2010, Biju wrote:
> > > 2. if we are still keeping them, can we disable them in 
> > > onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs 
> > > in those events to confuse users, so that they can trap users for 
> > > little longer.
> > That's not a bad idea. I recommend approaching the browser vendors to 
> > see if they are willing to implement it; if they do, then updating the 
> > spec accordingly would be a no-brainer.
> 
> I agree that the various traps put in place are exceptionally annoying. 
> An alternative would be a forced closing via the browser rather than 
> some modification of the behavior of Javascript. That would side step 
> the question of "Have you covered all of the annoying cases 
> (onbeforeunload, on unload, on hide...)?".

Well the browser is always allowed to just close things willy nilly, sure.


> > > 3. also if we are keeping them, can we add an optional parameter for 
> > > a timeout milliseconds to self dismiss the modal prompt.
> > What's the use case?
>
> For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, 
> ::MessageBox and its derivatives. The time out is a well-received idea.

On Tue, 1 Mar 2011, Aryeh Gregor wrote:
> 
> Timeouts on dialogs are typically a terrible idea, and we shouldn't 
> encourage them.  They mean that if the user wasn't paying attention -- 
> which could just mean they were looking at another tab, in browsers with 
> tab-modal dialogs -- they never see the dialog.  This is only useful in 
> the case where the dialog is so useless you don't actually care if the 
> user doesn't see it, in which case, why show it?  In practice, authors 
> often add timeouts to things that they expect the user to see, leaving 
> the user confused if they don't wind up seeing it.  IIRC, one of the 
> nice little improvements I made to MediaWiki a few years ago was 
> removing the last of the timed redirects from it.
> 
> OS APIs are much more enthusiastic about permitting programmers to shoot 
> themselves in the foot than web APIs.  Microsoft specifically also cares 
> much more about developers and less about users, because they depend on 
> developers to write Windows-only apps and maintain Microsoft's lock-in, 
> while users are forced to buy Windows anyway. Browsers, on the other 
> hand, care very strongly about users, because users can easily switch to 
> another browser at any time, while developers (authors) don't help or 
> hurt them much as long as they write cross-browser code.  So for 
> multiple reasons, the fact that Windows supports something doesn't mean 
> we should.  You need to give actual specific use-cases, not just cite 
> the fact that the feature exists in Windows.

I have to agree with Aryeh here.


On Tue, 1 Mar 2011, WeBMartians 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).

The existence of an API is not a use case (and Aryeh's comments weren't an 
ad hominem attack -- the only attack, if any, was in the description of 
timer-based messaging APIs as "terrible", but he backed that up with sound 
reasoning).


> You are correct that short duration time outs are, often, a terrible 
> idea ... but the standard should not hobble the developer. Terrible 
> ideas are a matter of opinion; my ideas are always grand and glorious, 
> never terrible ... just ask me ... for I never lie and am always right.

It's our job to filter out the bad ideas.


> ...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)
> 
> To say that the WWWeb should not be used for this is in itself a 
> terrible idea for you know that it will be used in this manner and 
> neither of us can prevent such stupidities.

I think this kind of thing might be reasonable to have, but the way to do 
that is probably more using a non-modal inline dialog, so that the script 
can react to the storm's sudden growth or disappearance as well.


On Tue, 1 Mar 2011, Aryeh Gregor wrote:
> On Mon, Feb 28, 2011 at 7:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > Well we can't remove support for them from browsers, since millions of 
> > pages use them. Conformance checkers can't really complain about usage 
> > of those APIs, since they can't easily check JavaScript runtime 
> > compliance. So what would deprecating them mean?
> 
> We could define script APIs, or features of them, as deprecated if 
> browsers were willing to log some kind of notice to their error consoles 
> when the feature is used.  They all have error consoles with different 
> reporting levels already, so it shouldn't be a pain for them to 
> implement.  They can have the deprecation warnings off by default so 
> they don't clutter the output.  At least Firefox already does this for 
> some things, like document.getSelection() (although that message will 
> probably go away in a future release).
> 
> Of course, this would only be useful if we had a good alternative to 
> recommend.  "Don't use alert(), use some giant JavaScript library 
> instead" is unlikely to be a very helpful message.  But it would be nice 
> for some of the crazier or more horrible APIs, if they have saner 
> replacements.

Do we have any data on whether these warnings have any useful effect?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'