[whatwg] Suggestion for Menus in Web Forms 2.0

Matthew Thomas wrote:
>> Matthew Thomas wrote:
>>> Allowing a native-looking menu bar makes sense for applications that  
>>> are going to have complete control over their own interface.   
>>> However, the What-WG specifications (as opposed to other  
>>> specifications deemed too ambitious and/or unmixable) are designed 
>>> to  be implementable inside Web pages, where applications cannot 
>>> have  complete control over their own interface.
>>
>>
>>    I think you're imagining a constraint on WF2 that doesn't really
>> exist. WF2 can be used in chromeless windows.
> 
> The type of window used is irrelevant. To pick just three examples,  
> HTML5 applications will not be able to avoid that on some platforms  
> there will be a menu bar, they will not be able to control their  
> taskbar/Dock icon, and they will not be able to handle documents  
> dragged to the application's icon. None of those have anything to do  
> with the type of window.

    It has been suggested (I think by Ian) that there be an attribute 
for the <html> element that indicates if the web page is a web 
application that requires a chromeless window. A compliant browser could 
process such a page with something similar to pop-up blocking, and if 
the user permits, the page would be displayed without chrome regardless 
of how it was opened.

>>    Then again, I've seen Java applications in a browser that have such
>> menubars, so there may be a demand for this. Another thing is that
>> someone may want to create a simulated desktop interface where they can
>> open multiple "windows" within the browser windows. In that case, it
>> would be nice if these window-like blocks could have their own  menubars.
> 
> That doesn't make sense on those platforms where applications have menu  
> bars but windows do not.

    It does if you want to simulate your own desktop interface, which is 
the example I gave above. The webmaster may want a unique look and feel 
that don't belong to any specific operating system.

>>> Therefore, making <menubar> "look like a menu bar" would involve  
>>> having two or more visually similar menu bars on the screen  
>>> simultaneously. But this is bizarre behavior on some platforms, and  
>>> even on platforms where it is expected behavior, it is highly  
>>> confusing.
>>
>>    One thing we could do is come up with a way to display menubars on a
>> few key operating systems that doesn't confuse users, then allow enough
>> room in the spec for user agent vendors to create their own solutions.
> 
> IMO allowing "user agent vendors to create their own solutions" is a  
> copout from admitting that there is no practical solution for the  
> platforms some user agents are running on, which is bad for  
> interoperability.

    I'm not arrogant enough to think that I can always come up with a 
better UI solution than vendors for a specific platform, nor do I 
believe we can necessarily come up with the presentation details for 
menubars on every operating system that existed or will exist. Write the 
specification so that there is a RECOMMENDED solution for key operating 
systems, then make the specification loose enough so that it can be 
implemented without tying the hands of vendors that might have a better 
solution.

> (For an example of such silliness, see  
> <http://www.w3.org/TR/2003/CR-css3-color-20030514/#flavor>.) There's no  
> point in providing freedom to choose, if the number of practical  
> choices is zero.

    Prove that the choices are zero on all platforms.


>>    Furthermore, HTML 4.01 allows support for <link> to implemented in
>> any way the UA vendor chooses,
> 
> Which is partly why authors don't use it.

    Some do, but they don't rely on it as a general menu system.

>> so suddenly turning <link> into a menu system could cause serious  
>> problems.
> 
> Like it becoming useful, perhaps. :-)

    How about the fact that existing <link> elements are not necessarily 
ordered in a way that the webmaster might want them in a menu because 
many browsers group specific kinds of <link> elements in a predetermined 
fashion? What if the webmaster defines them in the order of { Last, 
Bottom, Next, First, Previous, Top }? I wouldn't want it to show up in a 
menu like that. But in current browsers, there's absolutely no reason 
not to put items in random order.

>> This is especially true if a browser vendor chose to put <link> items  
>> in a submenu off the main browser menu.
> 
> I don't remember anyone on this list suggesting that. Hiding them in a  
> menu would certainly fail my "reliably noticable" criterion  
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
> 001197.html>.

    I was referring to how a vendor implemented the HTML 4.01 
specification, not something you invented for the mailing list. If a UA 
vendor implemented support for link in a submenu, that existing browser 
will have to be modified to remove the submenu and add some new 
implementation.

>>> That would suit the usual use case for adjacent menus, and would  
>>> avoid wrongly implying that it should look like a native menu bar.
>>
>>    On a chromeless window, it probably SHOULD look like a native  
>> menubar.
> 
> No, because that would (on some platforms) still involve having two or  
> more visually similar menu bars on the screen simultaneously.

    Seeing as the window would be chromeless, I don't understand how.

>> Keep in mind, an element name like "menubar" or "menulist" can  
>> communicate more than just visual position. Native menubar rendering  
>> on a chromeless window, for instance, would be impossible without 
>> such  an element.
> 
> I don't know what you're trying to say here.

    Good example would be MS Office for Windows (and maybe Mac too, but 
I wouldn't know). Look at the menubar. See the little grippy? Grab it 
and you can put the menu on the sides of the window, or on the bottom, 
or make it a menu in a little floating toolbox.

    Furthermore, without a parent tag, there's no semantic connection 
between the separate menu items.

>>    I don't mind presenting <menu> as a button when not in the context
>> of  a menubar. However, should this be required in the spec, or simply
>> recommended?
> 
> How strongly the Web Apps spec suggests particular visual presentation  
> is suggested for <menu> probably depends on how strongly the What-WG  
> specs suggest particular visual presentation for controls in general. I  
> don't think Ian has said anything about that yet.

    I think that's because we're supposed to talk about instead of 
having Ian unilaterally decide for us.

>>    You're confusing the implementation of a drop-down list for <select>
>> with the <select> element itself. The <select> element could be
>> implemented in a manner similar to that shown in the HTML 4.01
>> specification, for instance:
>>
>> http://www.w3.org/TR/html401/images/optgroup_exmpl.gif
>>
>>    The <select> element could be implemented as a pull-down menu.
> 
> That would be even worse, but in a different way: it would mean in some  
> cases the current selection wasn't visible at all even immediately  
> after the menu was opened. For example, someone who chose "Uzbekistan"  
> by mistake instead of "USA" would have to scroll through (nearly) the  
> whole damn menu of countries again, instead of mousing down on the menu  
> and dragging northward ~5 pixels. (On the Windows platform, and in  
> Gecko on all platforms, decrementing a <select> value is more  
> time-consuming -- you need to click the menu, then move down(!) to  
> click the up arrow, then move across to click the correct item. But  
> that's still not as bad as a pull-down menu would be.)

    In most <select> implementations, you can simply use the arrows to 
select the next or previous item. This behavior would not have to change 
to use a popup menu instead of a drop-down list. There's also nothing 
stopping vendors from opening up the entire menu to the location of the 
selected item and moving the mouse pointer to a position over that item.

> That's probably why no toolkit I know of presents any of its  
> one-of-many selection controls (listboxes, scrolling listboxes, option  
> menus, or sets of radiobuttons) in the way the W3C illustrates. It  
> would be far too annoying.

    So it can't be done because you've never seen it done?

>> Besides, in the context of using <select> WITHIN <menu>, a pull-down
>> menu would almost certainly be used.
> 
> Sure, but that's not what was being discussed.

    By making <optgroup> non-nesting, you make the <select>-based 
solution that's in the current WA1 spec useless for menus more than two 
levels deep. The subjects of <optgroup> nesting and WA1 menus are related.

>>> Another reason not to have <optgroup>s inside <select>s is that  
>>> option menus are supposed to show their state even when closed, but  
>>> they cannot do so reliably if two or more submenus contain items 
>>> with  the same text.
>>
>>    Easy to fix. Display the <option> |label| as in the menu and the  
>> child text of the <option> as the selection. This is consistent with  
>> the example from section 17.6.1 of the HTML 4.01 spec:
> 
> As I said, "the distinction could not be shown in a single  
> native-looking option menu while the menu was closed, without making  
> the menu abnormally wide". The W3C's example uses abnormally short  
> submenu items in an attempt to make <optgroup> look practically  
> implementable.

    How would any of the selection be narrower in any other type of 
control that's one line of text high when closed? You'd have to have a 
tree of some kind, which is kinda silly if you're selecting something 
from a group of categories and subcategories that aren't necessarily in 
the name of the item. For instance, my car is a 1994 Subaru SVX Lsi:

Subaru->Car->Sports Car->SVX->Lsi->1994

    By your reasoning, the selection would read:

"Subaru - Car - Sports Car - SVX - Lsi - 1994"

    In reality, it would simply be "1994 Subaru SVX Lsi". That's the 
whole reason there's a separate |label| property. The W3C wanted you to 
make the selection name different from the menu name so that the actual 
text node under the <option> could exclude unnecessary information about 
the submenu titles, allowing the web master to avoid large 
treeview-style controls.

Received on Sunday, 8 August 2004 14:36:17 UTC