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

For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, 
::MessageBox and its derivatives. The time out is a well-received idea.

As to comment 2, 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...)?".

On 2011-02-28 19:42, Ian Hickson wrote:
> On Thu, 25 Nov 2010, Biju wrote:
>> 1. Can we deprecate alert(), confirm(), prompt() ?
>> At present many web2.0 js libs are providing alternate [and cool
>> looking] methods to achieve use cases where we need to use alert(),
>> confirm(), prompt(). So do we need those modal dialogs any longer?
> 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?
>
>
>> 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.
>
>
>> 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?
>
>
> On Thu, 25 Nov 2010, Biju wrote:
>> 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.
> As you point out in your original e-mail, it seems like this kind of use
> case is better handled by Web 2.0 JavaScript libraries. In the medium term
> I expect we will introduce a feature to create modal and non-modal in-page
> dialogs using markup, so this will likely become moot.
>
>
> On Thu, 25 Nov 2010, Markus Ernst wrote:
>> Maybe, instead of your original suggestion, it might be worth thinking
>> about making alert()/confirm()/prompt() dialogs styleable via CSS? Then
>> those fancy JS lib dialogs would get obsolete, and we had the favour of
>> both nice look and support for the special purposes of those dialogs.
> This would be a side-effect of the aforementioned markup-based dialogs.
>
>
> On Thu, 25 Nov 2010, Biju wrote:
>> The request I put is NOT about whether you can make it PRETTY looking or
>> not. The question is about why we are allowing website have something
>> which is MODAL (ie, both window modal and tab modal
>>    https://bugzilla.mozilla.org/show_bug.cgi?id=59314)
>> In my opinion a no website should have that much control over user
>> interaction.
> On Thu, 25 Nov 2010, Nikita Popov wrote:
>> That alert()s, prompt()s and confirm()s are window-modal is only an
>> implementation issue: Some years ago browsers implemented these prompts
>> the most convenient way: By opening a native modal dialog. But right now
>> broswer vendors realize that this isn't really the best solution -
>> because of DOS attacks and simply because it doesn't make any sense.
>>
>> And as you already mentioned: Firefox landed tab-modal dialogs a few
>> days ago. Opera already had them. Other browsers will follow.
> On Thu, 25 Nov 2010, Markus Ernst wrote:
>> Opera even provided a "Stop executing scripts" checkbox in the alert()
>> dialog for years already, which made it my preferred browser for
>> debugging my scripts (handy if you have forgotten an i++ in a loop, and
>> placed an alert() inside).
> Indeed.
>
>
> On Thu, 25 Nov 2010, Benjamin Poulain wrote:
>> The specification deprecates some elements that use to be widely used
>> (the elements font, big, center, etc).
> Actually it obsoletes them.
>
>
>> Deprecating is only a recommendation for authors to not use the feature.
> It's hard to effectively do that with script since there's no good way to
> do scripting validation.
>

Received on Tuesday, 1 March 2011 06:12:20 UTC