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.
