[whatwg] Thoughts on Context and Popup Menus for Web Applications 1.0
mattraymond at earthlink.net
Wed Nov 10 08:11:56 PST 2004
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.
> 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
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
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
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
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
More information about the whatwg