[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Lachlan Hunt
lachlan.hunt at lachy.id.au
Wed Dec 14 14:59:52 PST 2005
Ian Hickson wrote:
> How about:
>
> <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.
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 outer menu makes the toolbar, the inner menu is a drop-down button on
> that toolbar.
That's fine, I like it better than using a new menubar element.
> 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? 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.
--
Lachlan Hunt
http://lachy.id.au/
More information about the whatwg
mailing list