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

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 16:46:03 UTC