- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 29 Jun 2004 15:44:14 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 June 2004 08:44:14 UTC