[whatwg] Simple solution for select editable

[voracity]

Ian Hickson wrote:

> 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.

In legacy UAs, there's no way around this if you want to achieve the same 
purpose as select editable functionality _without_ javascript. With javascript, 
you can make sure the user enters something into only one fields.

For WF2 UAs, either <select editable>, <combo> or <fieldset> can be defined to 
transmit _either_ "thing" _or_ "thing_new" but not both. However, if WF2 UAs 
need to submit both, that wouldn't hurt, since the blank one can be transmitted 
as blank --- if both are blank, the user obviously didn't select anything. This 
isn't hacky --- there's no other way around it (I describe why later++).

> 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.

Well, <combo> doesn't have that problem (it's like the <object> tag interacting 
with <embed>). <select editable> with repeat=0 doesn't have that problem either 
(it's like using display:none to show content to legacy non-CSS browsers). I 
can't comment on <fieldset>, because I'm not entirely sure how it works.

> 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.

++I'm not sure this can be avoided, since there are many cases where the server 
needs to know when the user has entered something new. For example, a select is 
populated from a database table, where the primary key column fills the option 
values and a name column fills the option text. If the user types something new, 
the server needs to know a new record needs to be created. This is _especially_ 
true if the initial select only showed a subset of all the available records. 
I'm sure there are other examples.

> 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.

I'm not sure that's possible. If the items in the select are just general 
suggestions (for possible entry strings), then that is ok. But if the items in 
the select are specific items that the user needs to select (that may have 
associated value attributes) or if the user needs to create a new entry, legacy 
UAs will be very broken.

actually, this suggestion is more like an autocomplete field where the 
probability that the user wants to enter something new is comparable to the 
probability that the user wants to choose something old.

While that is a good field to have, I also want a field where the probability of 
choosing something old is close to 1, while entering something new is of low 
probability (possibly even 0).

Otherwise, I would still have to resort to writing brittle, mostly platform 
dependent controls.

> 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.)

Conditional comments? <!--#if !WF2--> I don't like these kinds of things either, 
because there is little incentive to use them. What's more, there's even less 
incentive to test the code/markup that appears in the tags properly.