W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

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

From: <ash@ashleysheridan.co.uk>
Date: Thu, 25 Nov 2010 12:41:14 +0000
Message-ID: <20101125124812.1FF3B8DB005D@zapata.dreamhost.com>
Code their site for speech browsers? Seriously?!

It's very easy to develop sites and apps that can be made accessible. Javascript lightboxes are not truly modal, and I've only ever seen them cater for people who have eyesight. If we further muddy the waters, it will only lead to more designers/developers creating something for a particular audience and ignoring the people who they're not "targeting". Until a decent alternative is available, is there even any sense in deprecating these dialogues?

Thanks,
Ash
http://www.ashleysheridan.co.uk

----- Reply message -----
From: "Biju" <bijumaillist@gmail.com>
Date: Thu, Nov 25, 2010 12:21
Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
To: <whatwg at lists.whatwg.org>

On Thu, Nov 25, 2010 at 3:30 AM, Nils Dagsson Moskopp
>
>> 1. Can we deprecate alert(), confirm(), prompt() ?
>
> If sites rely on them, it is not possible to deprecate them.
That is why I asked to deprecate, but not obsolete..

> However, I melieve browsers are making these dialogs tab-modal.
Yes I know but still there are problems
https://bugzilla.mozilla.org/show_bug.cgi?id=613800#c1
(I assume that will be fixed)
But see also https://bugzilla.mozilla.org/show_bug.cgi?id=391834

>> 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.
>
> ?Do you want to save your complicated mashup??
For that we dont need alert/confirm/prompt.
Return value in onbeforeunload will take care of it

You may want to also look Jesse Ruderman suggestion on that
https://bugzilla.mozilla.org/show_bug.cgi?id=578828

>> 3. also if we are keeping them, can we add an optional parameter for a
>> timeout milliseconds to self dismiss the modal prompt.
>
> Why would you need that?
This is especially useful with alert()
In a software application there is no need to have prompt to the user
if the application is not planning to do any branching after user
response.
When we have alert(), it dont give user any choice other than pressing OK
Hence it not possible to code any branching statement after result of
user action. (with exception "Press OK after you insert DVD to the
drive" )

So only use for alert() I see is not make a delay, that use case can
be improved if web programmer can provide a default time out.


On Thu, Nov 25, 2010 at 3:41 AM, ash at ashleysheridan.co.uk
<ash at ashleysheridan.co.uk> wrote:
> Modal dialogues have a very special purpose, which works consistently across
> various browsers in that we can program in with javascript some very
> specific responses. What would happen if someone came to your site with a
> speech/Braille browser? How would they know your pretty js lib built

That is a valid point. But how many good sites use
alert/confirm/prompt for every thing. So all those case speech/Braille
browser have problem to deal with.
If we want use that feature the web site need to code their site for
speech/Braille browser. If that is the case we could achieve same
thing with HTML.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101125/51f7787a/attachment.htm>
Received on Thursday, 25 November 2010 04:41:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC