- From: Malcolm Rowe <malcolm-what@farside.org.uk>
- Date: Tue, 15 Jun 2004 12:10:07 +0100
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