[whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt).

[Ian Hickson]

On Sat, 26 Feb 2011, Ben Rimmington wrote:
>
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#simple-dialogs>
> 
> An optional callback parameter could be added to the simple dialogs API:
> 
> > result = window.alert(message, [callback]);
> > 
> > result = window.confirm(message, [callback]);
> > 
> > result = window.prompt(message, [default], [callback]);

Assuming that the use case here is "display an alert, confirmation, or 
prompt, but make it possible to do so while continuing to run background 
animations and the like", it seems like a better solution would be to 
introduce a <dialog> element so that authors can design inline dialog 
boxes that do whatever they want, including being able to style them, etc. 
This would solve multiple problems at once.

I've been considering such a feature for some time. Some JS libraries 
already support things a bit like this; part of designing an element and 
associated API to do this built-in to the platform will be researching how 
those APIs work today. If anyone is interested in helping out with this, 
please let me know, or just start putting data on a wiki page.


On Sun, 27 Feb 2011, Diego Perini wrote:
> 
> Firefox 3.6.13 already returns 4 for "window.prompt.length".
> 
> Are the 2 extra parameters already known/used ?

On Sun, 27 Feb 2011, Boris Zbarsky wrote:
> 
> From the source:
> 
> 128   DOMString    prompt([optional] in DOMString aMessage,
> 129                       [optional] in DOMString aInitial,
> 130                       [optional] in DOMString aTitle,
> 131                       [optional] in unsigned long aSavePassword);
> 
> note that the extra two args (which never did anything) were removed in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=563556 and will not be 
> present in Gecko 2.0.

I haven't changed the spec with regard to this.


On Mon, 28 Feb 2011, Bjartur Thorlacius wrote:
> 
> Can't we extend the existing window.status?
> It's supported by some older UAs (and ignored by others, because of
> confusing UI), but if the UI distinguishes page messages from browser
> and system messages, it's usable (aside from a historical API, but if
> browsers ignore setting the window.status to the empty string).

Not sure how this would work.


On Tue, 1 Mar 2011, Ben Rimmington wrote:
> 
> The window.status property [1] doesn't seem to be in the WHATWG HTML 
> spec

Yeah, I never got around to speccing that. I've added it. It does nothing.


> I could only find the window.statusbar.visible property [2].

That's somewhat unrelated (though equally useless these days).


> However, some mobile platforms have a local notification service [...]. 
> A new window.notify() function might be useful, so that a background 
> card/tab/window can display a message to the user.

On Tue, 1 Mar 2011, James Graham wrote:
> 
> See [1] for the current state-of-play in giving access to system 
> notification mechanisms.
> 
> [1] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'