[whatwg] Web Forms 2: Altenative to <select editable>
Malcolm Rowe
malcolm-what at farside.org.uk
Tue Jun 15 04:10:07 PDT 2004
Hi Ian,
I know you're working up to a 'snapshot' release soon (how does that differ
from a 'working draft', btw?), and so presumably you want to keep the draft
fairly stable for the moment, but I thought I'd mention something that
occurred to me a few days ago.
In an earlier draft of WF2, you presented a form control that allowed the
user to select one of a pre-defined set of options, or enter something
completely different: <select editable>. This control effectively reproduces
the drop-down combo listbox that Windows' users are familiar with.
You removed it from the draft, quite correctly, because it wouldn't be
backward-compatible with non-WF2 UAs -- a user on (f.e.) IE6 or Lynx would
be unable to enter a string of their choosing. This was a pity, because I
remember thinking that this was one of the more useful features of WF2 when
I originally went through it.
I notice you've now added it back, but with a restriction on preventing
<select editable multiple>, and with a suggestion to use JavaScript for
down-level support (popping an input box for 'other' options).
While I'm happy to see it return, I'm wondering whether what we're currently
proposing is the best way to achieve what we want. For example, JavaScript
isn't going to help me if I've got JavaScript switched off, or I'm on a
non-JS-supporting UA.
In these cases, I would be forced to enter a pre-selected value, which is
arguably worse than not giving me the pre-selected options in the first
place.
Also, as a designer, I now have to make a decision between using
'strongly-typed' input controls (<input type=email>) or providing a list of
hinted values (<select editable>). That's unfortunate, because a WF2-UA
might be able to provide quite nice, 'rich', input controls for various
types, and to me, the capability to provide 'autocomplete hints' should be
orthogonal with the capability to restrict the domain of input values.
I'd like to propose an alternate approach that solves the above problems,
although it isn't perfect by any means.
Add the 'data' attribute (maybe under a different name --
'autocompletedata'?) from the <select> element (section 6) to the <input>
element. WF2 UA's could retrieve the <option> elements from the target URL
and display them either using a drop-down combo box, or an
autocomplete-style drop-down, or whatever.
The disadvantages of this approach are the following:
* There is no way to specify the 'hinted' options inline.
* Realistically, a non-WF2 UA will not able to use the 'hinted' values.
* We'd need somewhere to put the <option> elements in the DOM, and it's not
clear where that would be.
A second possible alternative approach would be to specify the hinted values
inline in a delimited attribute (autocompletevalues="foo;bar;baz").
However, these approaches (using <input> rather than <select>) do have the
following advantages:
* Complete backward compatibility, even for UAs with no, or disabled,
scripting capability.
* You can provide 'hint' options for strongly-typed input controls, for
example, <input type=email data=...>
Thoughts?
Regards,
Malcolm
More information about the whatwg
mailing list