On Fri, 29 Jul 2011, Jonas Sicking wrote: > On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <i...@hixie.ch> wrote: > > On Fri, 29 Jul 2011, Jonas Sicking wrote: > >> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <i...@hixie.ch> wrote: > >> > On Mon, 2 May 2011, Jonas Sicking wrote: > >> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <i...@hixie.ch> wrote: > >> >> > > >> >> > <select> in a <datalist> is completely ignored for form submission. In > >> >> > fact, any form element at all in <datalist> is ignored for form > >> >> > submission. See the "construct the form data set" algorithm: > >> >> > > >> >> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set > >> >> > > >> >> > It's so that you can do things like: > >> >> > > >> >> > � <input ... list=options> > >> >> > � <datalist id=options> > >> >> > � � <select ...> > >> >> > � � � <option>...</option> > >> >> > � � </select> > >> >> > � � ...maybe other form controls here... > >> >> > � </datalist> > >> >> > > >> >> > Basically everything in the <datalist> except the <option> elements is > >> >> > for fallback in legacy UAs and is ignored in new UAs. > >> >> > >> >> Couldn't this be accomplished using a few lines of javascript? > >> > > >> > Not when scripts are disabled, no. > >> > >> The number of cases when a site can use this solution to get an > >> acceptable UI *and* care about supporting users with scripts disabled > >> *and* is planning to roll out support within the timeframe when there's > >> some support for HTML5 forms, but not enough to rely on it, is extremely > >> small. > > > > That's possible. The entire Web Forms 2 feature set is designed with this > > kind of fallback in mind, though. > > > > > >> My experience is that it's much more likely that people will use other > >> solutions until there is wide enough browser support to reliably use it, > >> and then use javascript as a fallback and not care about users with JS > >> disabled. And that goes even if we add this feature or not. > > > > If that's the case, we should probably rethink the entire design of the > > WF2 features, because maybe there's better ways to do things. > > I'd be very interested to hear how we would have designed things > differently under those constraints.
Well for example we could have just done <calendar> instead of <input type=date>, indeed we could have used a format other than text/html... > > Looking specifically at <datagrid>'s ability to fall back to <select>, > > I agree that it's not necessarily doing to be widely used, but given > > that it's so simple to support and provides such a clean way to do > > fallback, I really don't see the harm in supporting it. > > I haven't looked at <datagrid> yet, so I can't comment. I meant <datalist>, sorry. On Fri, 29 Jul 2011, Jonas Sicking wrote: > > Ah, well, then it definitely seems like we should get rid of this > feature. The harm is definitely there in that it's adding a feature > without solving any problem. I don't really understand what feature you mean. If you mean the fallback to <select>, I've actually wanted to use that on my own sites before, so I don't agree that it doesn't solve any problem. > For what it's worth, I'm not even convinced there is a problem. The > website can always let the <select> be submitted and ignore it on the > server if it contains a empty value, and then make the first <option> in > the <select> look something like <option value="">You can select a > prefilled value here</option> That's kind of ugly though. The spec's model is cleaner in this respect: the fallback <select> is just hidden entirely in modern UAs. I don't see why this would be a problem. On Sun, 31 Jul 2011, Jeremy Keith wrote: > > The way that datalist is currently designed (and implemented) is > exemplary. The fact that (by design) it allows authors to nest a select > element within it that shares the same option elements means that > authors can safely begin to use this new feature. > > I've written more about it here: http://adactio.com/journal/4272/ > > I'm trying (and failing) to understand why Jonas wants this feature > removed. On Mon, 1 Aug 2011, Jonas Sicking wrote: > > The reason is that I just don't think that sites will want to use it due > to not being able to get the rendering or functionality that they want. > > I must admit that you were able to construct a somewhat decent UI using > the current fallback mechanism, however I suspect that most sites will > want to use a jQuery constructed UI which displays much nicer. In fact, > I'd imagine that we'll see script libraries that implement the > <datalist> UI without any browser support for browsers which don't have > <datalist> support. > > I'll also note that even your demo doesn't require that the browser > doesn't submit the <select>. > > So carrying around this behavior for all eternity, when it's going to be > outdated in a few years once enough browsers support <datalist>, doesn't > seem worth the small benefit that it gains us right now. The behaviour is rather minimal. It just cuts off a branch of the tree from contributing to the form. I really don't see why this is an undue burden, even if we have it "for all eternity". On Tue, 2 Aug 2011, Henri Sivonen wrote: > > The current design solves the problem that the <datalist> feature needs > to Degrade Gracefully (and preferably without having to import a script > library). I think the solution is quite elegant and don't see a need to > drop it. On Tue, 2 Aug 2011, Jonas Sicking wrote: > > What's the purpose of a degrading mechanism if it produces a result > which is ugly enough that sites will not want to use it? It's not a goal > in and of itself to have a fallback mechanism. The goal is helping sites > deploy the feature. > > Looking at it some more, the example in Jeremy's blog post does in fact > not work that well since it adds "please choose..." and "Other" as > suggestions when the <datalist> is supported. This is likely not > acceptable for websites. This is easily addressed by adding value="" to those two <option>s. > <video> and <canvas> provide good data points. Both have fallback > mechanisms which are supposed to work without script. Yet in the far > most common case people don't use these fallback mechanisms since they > don't result in a rendering which lives up to their requirements. > Instead they use script based feature detection and deal with lack of > support by generating a wholly different DOM. > > I'd be very curious to know what percentage of sites that use <video> or > <canvas> support non-scripted fallback mechanism with a useable result. For <video>, the question is only really relevant if they support the scriptless case even when they don't have fallback. In the case of canvas, when there's no script the fallback is actually relevant regardless of whether canvas is supported, so it's a different situation. (The canvas fallback for when script is enabled is intended to be scripted.) > The current design of wanting fallback for <datalist> results in three > behavioral requirements: > > 1. Elements inside a <datalist> are not supposed to be submitted > 2. Elements inside a <datalist> are not supposed to be subject to > constraint validation > 3. When looking for <options> the search is recursive rather than just > looking at direct children of the <datalist> > > It's not clear what problem 1 solves. It makes the submission cleaner in the case where there is fallback. > It's easy for sites to ignore the value submitted for the <select> if > the contents of the <input> is non-empty. Same thing with 2, it's easy > to create fallback which works in all browsers by simply not adding any > constraint requirements. It's also easy to screw up both of these. Why require that authors get the subtlties right if we can just say it just works? > 3 does indeed provide some value in theory, though I'm still very > skeptical that anyone will use it and thus it will just be feature > bloat. Especially since I have yet to see a decent example of good UI > that can be created with it. It is however the easiest one to implement > at least in Gecko since we have a simple switch which allows to choose > between a deep or a shallow search. But as I've stated before, ease of > implementation is not a good reason to add a feature. But it's a reason not to avoid a feature if it is otherwise useful. In short, I agree that if the implementation cost was high here that we could compromise on this design and go with something less clean or with less graceful fallback, because it is true that many authors will not use this fallback feature. However, given that the cost is low, I don't see why we would remove the fallback feature. It's relatively simple, inobtrusive, and works. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
