On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote:
>
>
> On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <m...@apple.com> wrote:
>
> On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
>
>>
>>
>> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak <m...@apple.com> wrote:
>>
>> On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
>>
>> >
>> > <dialog> will give a better user experience than even a non-modal version
>> > of window.confirm() or window.alert(). Dialogs that are fully in-page
>>
>> Oops, got cut off here. What I meant to say is something like "dialogs that
>> are fully in-page are the emerging standard for high-quality page-modal
>> prompting".
>>
>> Non-blocking window.{alert,confirm,prompt} would most likely be rendered by
>> UAs as in-page overlays / tab-scoped dialogs. This is what we would do in
>> Chrome, and it seems like others would do the same given the prevalence of
>> the standard window.{alert,confirm,prompt} being implemented in a tab-scoped
>> manner already by some browsers (albeit with bugs).
>>
>> I think people use alert, confirm and prompt in part because they are so
>> easy to use. People who choose window.{alert,confirm,prompt} probably don't
>> care about loss of customization or else they would roll their own dialogs.
>>
>> Why not provide less sucky versions of those common dialogs?
>>
>> Benefit: Less code for simple dialogs.
>> Con: Another web platform API to standardize.
>
>
> Con: Encourages poor HI design (since these stock dialogs should almost never
> be used).
>
> That being said, I find in-page UI less objectionable than a pop-up alert,
> but in that case I'm not sure it makes sense to overload the existing API. It
> would be better to make new methods so feature testing is possible. Even
> given all that, I'm not confident of the value add over <dialog>.
>
>
> It seems like "poor HI design" is rather subjective. Some might prefer the
> OS-native look-and-feel of these simple dialogs.
The APIs as they currently exist are unable to provide an experience that is
consistent with Mac OS X or iOS HI design. Modal alerts are rarely used in
general, and when they are used, the buttons need to have labels that conform
to the action rather than generic labels like "OK". I feel that the original
design of alert(), confirm() and prompt() is very Windows-centric, and really
Windows-circa-late-90s-centric.
You could enhance the API to make these dialogs sufficiently more customizable.
But then I am even more skeptical of the value over <dialog>.
> Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt}
> or whatever name variant we prefer.
>
> You don't see much value in the simplicity of having these methods be
> provided by the platform? It seems like <dialog> requires much more code to
> setup.
I think there's almost 0 times that it is correct to pop up an OK/Cancel
dialog. If you incorporate customizing the button labels, I don't think
<dialog> is materially more complicated.
Regards,
Maciej
