[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
ian at hixie.ch
Mon Dec 19 15:18:48 PST 2005
On Thu, 15 Dec 2005, Lachlan Hunt wrote:
> > <form action="redirect.cgi">
> > <menu type="commands">
> > <menu label="Select site...">
> > <select name="goto"
> > onchange="if (this.options[this.selectedIndex].value)
> > 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>
> > </form>
> Ignoring this abuse of select as a navigational menu which would be
> better handled with <a href>, that handles the following cases fine:
> * Legacy UAs, with script
> * Legacy UAs, without script
> * New UAs, with script
> But, because the button will be hidden, it doesn't handle new UAs,
> without script. They'll only be able to select the menu item, but
> nothing will happen.
Good point. (Though I still think scripting being optional is something
that will become less and less realistic as time progresses.)
> The original idea I posted in this thread was that selecting an option
> would implicitly activate the associated submit button and that scripts
> (if supported) could capture the onsubmit event and deal with it
> appropriately. The idea is somewhat like having an implied command
> attribute on the option elements pointing to the submit button.
The problem is determining when a <select> is a real <select> and when it
is one of these "autosubmit" <select>s. (I don't want to add an attribute
or something, because that would be almost legitimising this use.)
> > The <span></span> hides the <input> from the <menu>. The value=""
> > hides that <option> from the menu.
> What semantics does the span have in this case to make it do that?
None. What happens is that the semantics of <menu> are to only look at the
element's direct children (with some fudging around for <li>s). The <span>
is not special inside <menu>, so it (and its children) are ignored by the
menu generation code.
> I think an attribute on the button that says this is the default action
> to be performed when a menu item is selected and that it should not be
> rendered by default would be better.
Hmm. We could do that, true... <button> and <input> have so many
attributes already though... Hmm...
Hmm... how about this?:
<menu type="commands autosubmit"> <!-- <<<< -->
<menu label="Select site...">
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>
<span><input type="submit" value="Go"></span>
When a command is selected from a menu with type="autosubmit", and that
command has an associated form (i.e. it is an <input>, <button>, or
<option> whose 'form' DOM attribute is not null) then that form's
submission behaviour must be invoked after the command completes.
Top-level (not in menus) <menu> elements then act as follows:
type="commands": treat as toolbar
type="commands autosubmit": treat as toolbar, with autosubmit
type="declare autosubmit": hide, with autosubmit
other: treat as <ul>
When nested, the behaviour depends on the context. In a menu, if there is
a "label" attribute then it creates a submenu. In a toolbar, if there is a
"label" attribute then it creates a menu button. If there is no label
attribute then it is treated as if its contents were there instead of the
<menu>, but with an <hr> before and an <hr> after.
In addition, if "type" is either "autosubmit", "declare autosubmit", or
"commands autosubmit", then the submenu/menu part/menu button has the
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg