[whatwg] Thoughts on Context and Popup Menus for Web Applications 1.0

Lachlan Hunt wrote:
> Matthew Raymond wrote:
> 
>>    I have a few suggestions for menus outside the context of a menu 
>> bar. The first is a suggestion for context menus (menus that, in 
>> Windows, show up when you right-click on something). The second is 
>> for popup menus (menus that appear when you click on or activate a
>> control, et cetera).
> 
> We should not give authors the power to override the UAs context menu. 
> Enough authors already try with JavaScript which more often than not 
> just creates usability problems.

    I know what you mean. I remember using a company website where you 
couldn't paste into a text field for a search because the webmaster had 
apparently decided that the clipboard was the work of the devil.

 > Thankfully, descent browsers now
> prevent authors blocking/overriding the context menu, let's not make it 
> easier for them.

    Who's to say the UA couldn't just append the menu to the context 
menu? Or append the browser context menu as a submenu? Or provide a 
context button as part of the control? Or allow access to the context 
menu when an additional key is pressed (such as alt + [right-click])?

    The UA vendors aren't stupid. Let's provide a semantic and let them 
figure the behavior out for themselves.

> I'm not objecting to having elements specifically for menus, as long as 
> their names are semantic (unlike <popup> which also suggests its 
> presentation), I object to the method you have proposed for accessing 
> the menu.  The method should not be defined like that, but should be 
> left to UA and the presentation (CSS) and sometimes behavour 
> (JavaScript) layers to determine.

    Then simply change "popup" to "menu". Simple enough. I'm not married 
to the word "popup"; I'm simply trying to distinguish it from a context 
menu.

    Actually, "menu" isn't the best name, since in my scheme, |popup| 
corresponded to a <popup> element, whereas you can't do that with "menu" 
because a <menu> element has to be in a containing element like 
<menubar>. Perhaps "menulist"?

> If a UA wants to implement it in the context menu, then that's up to the 
> UA developers (not the document author or the specification), though I 
> would probably complain to the UA developers about any decision like 
> that.

    If overriding the browser context menus is a problem, why would any 
UA vendor in their right mind do this?

 > I would recommend that it be accessed by, for example, clicking a
> control (eg. button or label) in visual UAs, not just by right-clicking 
> anywhere.

    For |popup|, the point was that the element had to be activated in 
some way (by clicking on it or selecting it and hitting enter, for 
example). My apologies if I didn't make that clear.

>>    The deal breaker for me, though, is that you can't tell what the 
>> hyperlink does just by looking at it. For instance, what does the 
>> following do?...
>>
>> | <a href="#guess">Does this point to a menu?</a>
> 
> A link should not provide information about it's behaviour, but about 
> the information that it [provides].

    How can you justify changing the behavior of markup in the 
specification, yet rejecting structural changes to markup because the 
UAs can implement whatever behavior they desire for the <a> element? The 
spec currently says that the above hyperlink example can bring up a 
menu. That's behavior. A menu-related attribute need not necessarily 
define the behavior, but merely associate the element with a menu. I 
believe I have the semantic high ground on this one.

    It should also be pointed out that the menu in the <a> element 
method still has to have a menu, and that menu has to be in a containing 
element. As the spec stands, that means <menubar>, so you'd end up with 
a menubar you may not want.

>>    Now, figure out what this does:
>>
>> | <button popup="obvious">This displays a popup menu.</button>
> 
> That will only display a popup for visual UAs, which is why I object to 
> the name popup for the attribute and element.  In UAs that don't support 
> popups, the text is meaningless.  It provides no information about its 
> purpose or what information can be accessed by activating it.

    Are you honestly trying to tell me that you don't think popup menus 
can be done in text mode?!? How is it we can do menus in text mode but 
not popups? Remember that by "popup", I mean a method of accessing a 
menu by activating or clicking on a control. If you don't like the name 
"popup" then fine, but I don't see while the underlying principle of 
activating a menu with a button or other control is impossible in text 
mode UAs.

Received on Wednesday, 10 November 2004 08:11:56 UTC