- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Mon, 6 Sep 2004 23:36:25 +1200
On 29 Aug, 2004, at 4:33 AM, Ian Hickson wrote: > ... > On Thu, 26 Aug 2004, Matthew Thomas wrote: > ... >> 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.) > ... > Hitting enter would cause the page to just load normally in the > browser. It would be stupid for the default to be "trust this site". You were the one who drew it as the default ... > >>> :: (( Trust paypcl.com )) ( Display as Web page ) .... But anyway. > ... > :::: Security Warning ::::::::::::::::::::::::::::::::::::: > :: :: > :: This Web page wishes to launch an application in a :: > :: separate window. Do you trust this domain? :: > :: :: > :: paypcl.com ' > :: > :: ( Trust this site for now ) > :: > :: ( Always trust this site ) > :: > :: (( Display as Web page )) > :: > :::::. > > Would that be better? > ... Well, the button has gone from potentially misleading to reliably uninformative, so I guess so. :-) Look, what you really want is a non-modal panel in the viewport (like that used for popup windows in MSIE, and for junk mail in Apple Mail), right next to the address field. ,----------------------------------------------------------------------. |(X) :::::::::::::::::::::: [] Example Corp ::::::::::::::::::::::: (-)| |----------------------------------------------------------------------| | [<][>][X][@] [+] [http://app.example.com/ ] (______________) | |----------------------------------------------------------------------| | This page wants to replace Foo Browser's menus ( Replace Menus ) | | and toolbars with its own. | |--------------------------------------------------------------------+-| | _ _ _ _ |A| | |_ \/ _||\ /||_)| |_ | _ _ _ |:| | |_ /\/ || V || |_|_ |_(_)| |_). Home - Customize - Help |:| | ==============================|=================================== |:| : : : .... But I still think the possibility shouldn't exist in the first place. > ... >> 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 ..." > > You're assuming that we give the pages a way to tell if they are > running in a Web browser or "as a native application". No, I'm not. Read it again. The only way into the site is to do something that is only possible if the page is running "as a native application". And the reason is that you are allowing pulldown menus to degrade to nothing even when author CSS is ignored. > It could definitely see strong arguments for not making it possible to > distinguish the two. I agree with Jim Ley here: I doubt it'll ever be possible to prevent such detection -- even when using crappy methods that return false negatives in some cases (e.g. a getComputedStyle-related method that breaks in Opera and Mozilla when author styles are turned off or when a minimum font size is set or when images are turned off or ...). >> 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.) > > You can always find bad UI, you certainly don't have to give authors > access to a native menubar to do _that_. The point is not whether bad UI is *possible*, but whether it is *likely*. Since menu implementations vary so widely across platforms, it is much more *likely* that authors will produce layouts of menus that work on some platforms but not others, than it is with layouts of other controls. > ... > I've seen people implement entire scrollbars in JS, including all the > native scrollbar behaviour, just because they wanted Windows XP-styled > scrollbars on other platforms, requiring _hundreds_ of lines of code > despite the fact that the CSS equivalent is exactly one line long. The > difference is that CSS doesn't let you style the scrollbars. Personally, I'm quite happy for those authors to pay that stupidity tax (even if such artificial scrollbars are buggier), if it means fewer authors try to style scrollbars in the first place. >>> Nested optgroups don't imply submenus. Just more indented options >>> with headers. >> >> Well, that's not good design either ... > > Why not? I'm not saying it is, just curious as to why it isn't. > ... Because like the items in a real menu, every item in a GUI menu should be available in some possible situation. (Ideally, the help tip for an unavailable item should explain in what situation it will become available.) To have an item that is never available is false advertising, and will likely cause people to waste time trying to discover how to make it available. OSes could establish standard styles for "headers for menu sections" that looked unmistakably different from unavailable items -- like the "Entr?es", "Mains", "Desserts", etc headers in a real menu. But as far as I know, the number of OSes that have done that so far is zero. And I don't see why menus in Web apps are inherently so much more complicated than those in native apps, that they need more subdivision than menus in native apps do. (See also the first subsection of <http://daringfireball.net/2003/02/when_in_rome>.) -- Matthew Thomas http://mpt.net.nz/
Received on Monday, 6 September 2004 04:36:25 UTC