Re: Question on Context menus

On Thu, 15 Oct 2009, Jeff Schiller wrote:
> 
> 1) None of the examples of <menu> usage in the HTML5 spec show
> <command> elements being used

I've added some.


> nor does the <menu> element's content model explicitly mention <command> 
> elements, though "4.11.3.2 Building menus and toolbars" does.

It also doesn't mention <input>s or <button>s. :-)


> Furthermore, the section on the <command> element does not contain an 
> informative example either.  Can an example be adding showing a <menu> 
> with <command> children?

Done.


> Should the menu's content model be updated to expliclty list <command> 
> elements?

I don't see why; they're already allowed simply because they're part of 
flow content, no?


> 2) The <menu> element's contents are described as either flow content or 
> a series of <li> elements.  Why are <li> elements explicitly mentioned?  

Because <li> elements aren't flow content, so otherwise they wouldn't be 
allowed. They are allowed because they were allowed in HTML4, HTML 3.2, 
and HTML 2.


> 3) 4.11.3.1: For the second example listed :
> 
> <form action="redirect.cgi">
>  <menu type="toolbar">
>   <label for="goto">Go to...</label>
>   <menu label="Go">
>    <select id="goto"
>            onchange="if (this.options[this.selectedIndex].value)
>                      window.location = this.options[this.selectedIndex].value">
>     <option value="" selected="selected"> Select site: </option>
>     <option value="http://www.apple.com/"> Apple </option>
>     <option value="http://www.mozilla.org/"> Mozilla </option>
>     <option value="http://www.opera.com/"> Opera </option>
>    </select>
>    <span><input type="submit" value="Go"></span>
>   </menu>
>  </menu>
> 
> The processing steps in 4.11.3.2 says that the <label> children should
> be iterated, but the label in the above example only has a text
> element child, what should be done with it?

Nothing, text nodes fall under "any other node" and get ignored.


> It doesn't appear you can define a command with a label so would "Go 
> to..." get dropped?  I suspect it should be shown.

It should be dropped in this example; it's only useful for legacy UAs. In 
new UAs, the label "Go" would be used instead.


> 4) 4.11.3.2: "Any menu item with no label, or whose label is the empty 
> string, must be removed" - shouldn't this be "Any non-separator menu 
> item with no label..." ?

Fixed.


> 5) 4.11.3.3: "Context menus must not, while being shown, reflect changes 
> in the DOM; they are constructed as the default action of the show event 
> and must remain like that until dismissed."
>
> Why is this restriction in place?  It seems arbitrary to me.  Is it 
> imposing user interface guidelines or ?

It's common for UI frameworks to not allow menus to be changed on the fly, 
so it would be pretty difficult to implement changing a menu while the 
user is interacting with it.


> If a checkbox is checked while the menu is shown, doesn't that 
> constitute a change in the DOM (and surely the visual representation of 
> the menu should also update).

It does, but the menu won't be updated according to these rules. In 
practice, user interfaces don't in fact update context menus in real time 
like that, so I don't think it's a problem.


> Also, if this requirement is needed, it seems like a better phrase than 
> "must remain like that" is needed here?

Fixed.


> 6) Do we really need eight different ways to define commands?
> (4.11.4.1-8) I apologize that I haven't read through all 8 cases but
> it seems unnecessarily confusing on first skim (though I have no
> suggestions for improvement).

I think the short answer is "yes", but I'm certainly open to suggestions. 
Which should we cut?


> 7) 4.11.3.3: "User agents may provide means for bypassing the context 
> menu processing model, ensuring that the user can always access the UA's 
> default context menus.  For example, the user agent could handle 
> right-clicks that have the Shift key depressed in such a way that it 
> does not fire the contextmenu event and instead always shows the default 
> context menu."
> 
> It has been said before that the HTML5 spec will not be specifying UA 
> user interface requirements, but context menus seem to come dangerously 
> close to that.

The above is just an example suggestion, it's not a requirement.


> Are we saying that the context menu must be displayed on its own?

That's up to the UA.


> Could another example of this 'bypassing' be accomplished by a user 
> agent _appending_ the context <menu> to the UA's default context menu?

Yup.


> Or showing the context <menu> as a sub-menu of the UA's default
> context menu?

Yup.


> Neither of these two options appeal to me as a web app developer 
> (showing the UA's default context menu as a submenu of my context menu 
> is ok, I guess).  I'd much rather have more control over the context 
> menu contents and behavior.  It's what desktop applications and plugins 
> have had for years.  So wearing my 'web app developer' hat, I really 
> want this to be a requirement on UAs.

As you said above, it's really not something we can specify.


> 8) Has any browser made progress in actually implementing any of this? I 
> would love to have a cross-browser way of specifying context menu items 
> but I just have no idea how far away that is, realistically.

I'm not aware of any implementations yet.

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

Received on Sunday, 18 October 2009 07:32:56 UTC