[whatwg] Simple solution for select editable

[Ian Hickson]

I will be going through all the recent feedback one e-mail at a time in
due course, but I just wanted to comment on something I've noticed that is
common to most of the "select editable"  proposals:

On Tue, 29 Jun 2004, Matthew Raymond wrote:
>
> I've come up with a simple solution that allows <select editable> to
> degrade gracefully in Web Forms 2.0. Just put the extra text box in a
> repetition template that has zero instances:
>
> <select editable="editable" name="thing">
>    <option>1</option>
>    <option>2</option>
>    <option>3</option>
> </select>
> <span repeat="template" repeat-start="0">
>    or you can type a new entry: <input type="text" name="thing_new">
> </span>
>
> In non-WF2 user agents, "editable" is ignored and the <span> is
> rendered, allowing the user to put a custom entry in the text box. In a
> WF2 UA, only the <select> is shown, but it's rendered as a combo box.
> (Finally something good comes out of this stupid template defect!)

In this example, as well as the <combo> proposal, and the <fieldset>
proposal, and several others, you have problems in both the legacy UAs and
the WF2 UAs.

For legacy UAs, there is no way to stop a user from picking an option from
the select _and_ typing an option, resulting in two values being submitted
to the server. The thing vs thing_new names don't really solve this since
the "thing_new" value might just be a space or other spurious input that
the user didn't intend to submit, as opposed to a real value.

For WF2 UAs and authors you have the problem of linking all these multiple
controls into one, especially in the context of graphical editors. If at
all possible we should avoid a situation where you can link a <select> and
text input together despite their being on opposite sides of the page.

IMHO, we should also avoid a situation where the legacy UAs can send the
data back using two or more different names, when the WF2 UA is given just
the one name.

There's probably also a good case to be made for requiring that the UIs be
effectively the same in legacy and new UAs (as opposed to having extra
fields in legacy UAs).

So what I'm leaning towards at the moment is a system whose fallback is
just a normal <input type="text">, with no dropdown, with JavaScript used
to provide legacy UAs with a dropdown, if they have JS.

However, since I agree that it would be nice to also have a way of doing
the fallback mechanisms that have been described in this thread, I think
we'll have to introduce some element in Web Apps that can be used to hide
content from newer browsers, somewhat like <switch> in SVG. I'm not sure
what the best way to do that is, though. (I never liked the <noscript>
concept, for one.)

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