W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

[whatwg] Web Forms 2: Altenative to <select editable>

From: Malcolm Rowe <malcolm-what@farside.org.uk>
Date: Tue, 15 Jun 2004 12:10:07 +0100
Message-ID: <courier.40CED90F.000045CD@mail.farside.org.uk>
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 
Received on Tuesday, 15 June 2004 04:10:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC