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

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).

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.

...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.

By-the-Way - I advocate no change to alerts and such ... the above can 
be implemented with setTimeout without any changes to existing browsers.

Best (and please understand my admonitions to be accompanied by 
affection and great respect)!
BdG/WeBMartians
===
On 2011-03-01 19:46, 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.
>
> On Tue, Mar 1, 2011 at 9:12 AM, WeBMartians<webmartians at verizon.net>  wrote:
>> For comment 3, simply reference the use cases for Microsoft's AfxMsgBox,
>> ::MessageBox and its derivatives. The time out is a well-received idea.
> 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.
>

Received on Tuesday, 1 March 2011 18:52:46 UTC