[whatwg] Menu controls

On 10/06/2004, at 3:57 AM, Jose Dinuncio wrote:
>
> El mi?, 09-06-2004 a las 09:33, Didier PH Martin escribi?:
> ...
>> Questions:
>> A) How to define a menu bar?
>> B) How to define a control bar?
>> c) How to define a status bar?
> ...
> Why not just
>
> <hlayout>
>
>   <hbox>
>     <menubar>
>       <menu title="F_ile">
>         <option>Save</option>
>         ...
>       </menu>
>     </menubar>
>   </hbox>
> ...

Is this application supposed to appear inside a browser window? If so, 
the above won't make sense on those platforms where there is only one 
menu bar shown at a time (e.g. Mac OS X, KDE with "Current 
application's menu bar on the top of the screen" checked, and 
OpenStep), because the menu bar already contains the browser's menus. 
And even on those platforms where nested menu bars are possible, they 
would still be extremely error-prone -- people wanting to choose 
something from your app's "File" menu would often go to the browser's 
"File" menu by mistake.

If Web Forms 2.0 is going to be an extension of HTML forms (as opposed 
to XUL or XAML), I think very few apps built on it would be complicated 
enough to benefit from a full-blown menu bar. (The HTML editor example 
above is wanted often enough, e.g. for Webmail, that it should be built 
into the browser anyway. That way people don't have to learn a 
different HTML editing UI for every site that wants to use one.)

Menu-wise, I think these *would* be useful additions to HTML forms for 
Web apps:

1.  A control for single pulldown menus that aren't in a
     menu bar. XHTML 2's NL element seems to be intended for
     implementation as a pulldown menu, but as far as I can
     see it's intended for hyperlinks rather than for
     commands that can act on previous user input.

     Some sites roll their own pulldown menus using
     HTML+CSS+JS; but they never get submenu behavior
     correct (submenus often disappear when you're moving
     diagonally towards the item you want), and browser
     differences occasionally make the menus completely
     unusable. (Sometimes the JavaScript doesn't work at all;
     other times a tiny gap is rendered between the menu
     title and the menu, and crossing the gap makes the menu
     disappear).

     Other sites use SELECT for this purpose, together with
     JavaScript, or an "OK" button, or both. This is rather
     unfortunate -- the title of the menu is inserted
     as the first "option", so the title incorrectly
     disappears when a command is chosen.

2.  Some method of integration to allow Web apps to respond
     to the browser's Cut, Copy, Paste, and Select All menu
     items and keyboard equivalents. These work automatically
     for text fields in any Web application; it would be
     great if apps could make them work for stocks, address
     book cards, message attachments, transactions, photos,
     and so on too.

     I'd add Undo and Redo to that list, but unfortunately
     IE6 doesn't have Undo and Redo menu items.

-- 
Matthew Thomas
http://mpt.net.nz/

Received on Wednesday, 9 June 2004 14:39:40 UTC