[whatwg] Suggestion for Menus in Web Forms 2.0

On Mon, 6 Sep 2004, Matthew Thomas wrote:
>> ...
> 
> 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 |:|
> | ==============================|=================================== |:|
> :                                                                    : :

Indeed, that would work too.


> .... But I still think the possibility shouldn't exist in the first place.

Why should Web-hosted applications be second-closs citizens? It seems 
likely that users will spend more and more time using their Web browser 
and less and less time using native applications (e.g. people moving to 
Webmail instead of installing a local mail clients; users using online 
mapping software instead of buying native mapping software, etc). Why 
should users stop using system menus, etc, in this new world?


> > > 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.

Oh, quite the opposite, my intention was to make the non-native case have 
the pull-down menu be available, just not as the primary menu bar. For 
example (and this is only an example) from a button in a toolbar, or in 
the page's context menu, or what-not.


> > 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 ...).

At the end of the day I don't see why authors would even bother. They can 
do that now with full-screen mode (only be usable in full-screen mode) but 
they don't.


> > > 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 don't see how it is more likely than with any of the other tools we're 
proposing here. Sure, give authors more rope and they'll hang themselves 
all the quicker, but that's no reason to pre-emptively cripple the 
authoring environment.


> > > > 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.

Windows XP (the OS) uses list view headers in various places, so it's not 
like this is unknown. I've no idea why native app authors don't need this 
UI idiom much; in fact I don't know if they do or don't, I don't hear 
complaints from native code authors. However, I've certainly heard so many 
people clamouring for nested <optgroup> support in HTML that I know that 
on the Web, there is a demand for it. We don't _need_ to satisfy that 
demand by necessarily allowing nested <optgroup>, maybe it's just a 
symptom of a problem that has a better solution, but I don't know what 
problem it is. It's not just people wanting collapsible tree views; I _am_ 
hearding demand for that too, but those requests sound very different. 
(And indeed tree views are a lot more complicated than just <select> 
with multi-level headers.)

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

Received on Tuesday, 16 November 2004 07:06:17 UTC