- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Thu, 26 Aug 2004 22:34:16 +1200
On 26 Aug, 2004, at 10:07 AM, Ian Hickson wrote: > ... > Well, we want to be able to do both, really. Have Web applications run > inside browser chrome, and also have Web applications run as > first-class applications. The latter would of course only be allowed > if the user said that he trusted the site, and so forth, e.g. after > being explose to a Web page that said: > > :::: Security Warning ::::::::::::::::::::::::::::::::::::: > :: :: > :: The Web page at this domain: :: > :: ': > :: paypcl.com > :: > :: ...wishes to At which point I stop reading and blindly hit Enter, because I'm a human, and it's a prompt, and never the twain shall meet. (Yes, good that you put it in the content area rather than in an alert, but that doesn't alter its uncompromising promptiness.) Five seconds later: Hmmm, hang on, was that paypal.com, or something else? I can't remember. I'll just check the address field ... Oh drat, there isn't one. And I can't turn it back on, either, because there's no View menu any more. > ... > :: (( Trust paypcl.com )) ( Display as Web page ) I could pick on this particular implementation (for example, www.llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch.com would have to become "(( Trust www.lla?och.com ))", in which case www.goohax0rz.evilpeoplelivehere.muahahaogle.com would become "(( Trust www.goo?gle.com ))", and being used to such ellipsized labels, people would accept the latter unthinkingly) ... But I won't, because there's a much nastier aspect to allowing sites to replace the UA menus, even optionally. It's that in a few years, once HTML5 is widely implemented, authors start doing this: "We don't allow copying, printing, saving, or viewing source of articles on this site. To enter the site, please choose 'Enter Example.com' from the 'Enter Here' menu. To see the menu, you must have allowed Example.com application rights ..." And then there'll be those authors who create a menu bar of 20 menus, and it seems fine on *their* platform (a wrapping multi-line menu bar is only slightly more awful than multi-line tabs, and Microsoft already uses the latter, so it can't be *that* bad, right?), oblivious to those platforms where the menu bar is only ever a single line and menus that don't fit are simply never shown. (That some of your menus are never shown on a particular platform is much more obvious if you're a native developer for that platform.) > ... > One of the problems at the moment is that the menu will be different > if it is interpreted "natively" or if it is rendered just using CSS. > For > example, this menu bar/list/whatever: > > <menulist> > <menu label="File"> > <command label="Save" ...> > <command label="Save As..." ...> > </menu> > <menu label="Edit"> > <command label="Cut" ...> > <command label="Copy" ...> > </menu> > </menulist> > > ....would work fine if handled natively -- but the CSS version would > show nothing at all. Are you thinking of that as a bug, or a feature? Conceptually, pull-down menus contain commands, boolean options, radio options, separators, and submenus. Except for submenus, HTML already has elements for these: <button>/<a href>, <input type="checkbox">, <select>, and <hr>. If a collection of these was wrapped in a <menu> container (together with a <menutitle>), a WA-supporting UA could render it as a pull-down menu (ignoring any elements other than the ones I've listed here and their <label>s). And in a WA-ignorant UA, every item would still be usable; authors could even use <div>s, <table>s, or whatever to optimize the layout for the non-menu case. > ... >> (Outside a <menulist>, UAs could present a <menu> as a button with a >> downward-pointing triangle at the end of it, just like native >> standalone pull-down menus. This would both advertise their >> menu-ness, and avoid the confusion of them looking like a native menu >> bar.) > > This isn't what authors want, based on what you see on sites today. Do you really think authors would reject the opportunity to drop their code-heavy and (almost invariably) buggy JS-driven pull-down menus in exchange for faster, lighter, more reliable native pull-down menus, merely because those native menus were displayed with native-menu-style triangles at the end of them? Or did you mean something else? > ... > Nested optgroups don't imply submenus. Just more indented options with > headers. Well, that's not good design either ... Except in, uh, the mind of the designer of Safari's View menu. *sigh* Never mind. Too many windmills, not enough horses. -- Matthew Thomas http://mpt.net.nz/
Received on Thursday, 26 August 2004 03:34:16 UTC