Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Tue, 21 Feb 2012, Jonas Sicking wrote: On Tue, Feb 14, 2012 at 10:05 PM, Ian Hickson i...@hixie.ch wrote: 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. The fact that a feature is easy to implement should carry very little value. It does. But it's not zero value. We shouldn't add features unless they are going to be used. I'm personally very unconvinced that this feature would be used enough to warrant adding it to the spec and implementing it in browsers. I reach the opposite conclusion, but I agree that it is a judgement call for which we have as yet insufficient information to be confident one way or the other. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Tue, Feb 14, 2012 at 10:05 PM, Ian Hickson i...@hixie.ch wrote: 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. The fact that a feature is easy to implement should carry very little value. We shouldn't add features unless they are going to be used. I'm personally very unconvinced that this feature would be used enough to warrant adding it to the spec and implementing it in browsers. / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: 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 think he meant datalist. datagrid was axed quite some time ago and hasn't made a reappearance that I know of. 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. 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. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Tue, Aug 2, 2011 at 1:30 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: 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 think he meant datalist. datagrid was axed quite some time ago and hasn't made a reappearance that I know of. 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. 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. 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. 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. frameset is another good example where the far most common use of the fallback mechanism was to deliver the wholly unhelpful Your browser doesn't support frames message. I talked this over with Mounir some more. 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'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. 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. It seems to me that if we looked at any other feature with this small set of sites that we expect to use it (sites that are ok with imperfect rendering and which target browsers with javascript turned off), and for such a short period of time (only until datalist is supported in all major browsers) we would not add such a feature. I'm all for having a sensible upgrade path, but I think we have that anyway, which is simply that users will have to type the value. / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Sun, Jul 31, 2011 at 11:45 AM, Jeremy Keith jer...@adactio.com 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. 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. / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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. 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. That seems like a better solution than one that for all eternity adds browser code complexity both to do a deep search for option elements when building the list for datalist, and that requires walking the parent chain whenever submitting form controls. It doesn't seem that bad. Surely code for both of those is so widely used in a browser that both of those operations are basically one-liners. It's easy to implement is the worst reason ever to add a feature. / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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. 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. That seems like a better solution than one that for all eternity adds browser code complexity both to do a deep search for option elements when building the list for datalist, and that requires walking the parent chain whenever submitting form controls. It doesn't seem that bad. Surely code for both of those is so widely used in a browser that both of those operations are basically one-liners. It's easy to implement is the worst reason ever to add a feature. It's not the reason to add the feature. I'm just saying that browser complexity in this case isn't a reason to _remove_ the feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
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. 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. / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: 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 think he meant datalist. datagrid was axed quite some time ago and hasn't made a reappearance that I know of.
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: 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 think he meant datalist. datagrid was axed quite some time ago and hasn't made a reappearance that I know of. 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. 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 / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking jo...@sicking.cc 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. 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 If we are removing the select fallback feature we should also change the way you find option elements for a datalist element I think. That should be aligned with select: A child element search rather than a descendant element search. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, Jul 29, 2011 at 5:17 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking jo...@sicking.cc 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. 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 If we are removing the select fallback feature we should also change the way you find option elements for a datalist element I think. That should be aligned with select: A child element search rather than a descendant element search. Indeed! / Jonas
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 31 Dec 2010, Mounir Lamouri wrote: On 12/31/2010 03:20 AM, Ian Hickson wrote: On Fri, 24 Sep 2010, Mounir Lamouri wrote: I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. I do not understand that the select inside the datalist should not be invalid but why it *has* to be barred from constraint validation? Adding the required attribute to the select element in that case would be stupid and useless. The other way to make the select element invalid would be by calling .setCustomValidity(). Is there a real use case that require calling .setCustomValidity() in batch? Even if, can't we rely on the authors not calling .setCustomValidity() on elements that should not be invalid? We already do that for non-displayed elements, don't we? You should take into account that this requirement force the UA to check the entire parent tree to prevent a situation that can happen in various other ways. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On 12/31/2010 03:20 AM, Ian Hickson wrote: On Fri, 24 Sep 2010, Mounir Lamouri wrote: I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. I do not understand that the select inside the datalist should not be invalid but why it *has* to be barred from constraint validation? Adding the required attribute to the select element in that case would be stupid and useless. The other way to make the select element invalid would be by calling .setCustomValidity(). Is there a real use case that require calling .setCustomValidity() in batch? Even if, can't we rely on the authors not calling .setCustomValidity() on elements that should not be invalid? We already do that for non-displayed elements, don't we? You should take into account that this requirement force the UA to check the entire parent tree to prevent a situation that can happen in various other ways. -- Mounir
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 24 Sep 2010, Mounir Lamouri wrote: I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Why children of datalist elements are barred from constraint validation?
Hi, I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. Thanks, -- Mounir
