- From: Darin Fisher <darin@chromium.org>
- Date: Mon, 16 Apr 2012 16:18:22 -0700
On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher <darin at chromium.org> wrote: > > On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak <mjs at apple.com> > wrote: > >> 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. > > I think you'll have a hard time finding people who prefer that. ^_^ > > > 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. > > Hixie provided (in another thread) an example of the code required for > <dialog> that was feature-equivalent to popping a prompt. The > difference is minimal. > > ~TJ > Oh, indeed he did. Using <form> and <input> inside a <dialog> to create simple dialogs is a nice idea. I suppose the UA stylesheet could have some extra rules to make that have a decent default rendering. Hmm... I'm starting to care a bit less about async{Alert,Confirm,Prompt}. Although, it still bugs me that the path of least resistance for simple dialogs will remain good old thread-blocking modal alert/confirm/prompt :-( -Darin
Received on Monday, 16 April 2012 16:18:22 UTC