- From: Scott González <scott.gonzalez@gmail.com>
- Date: Wed, 31 Jul 2013 08:38:15 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>
It's been a while since I read the spec, but I can say that the behavior in jQuery UI is in line with Hixie's response. We do nothing to adjust the user-specified min/max/step, but never allow changing to a value that doesn't fit in the specified range. If you specify a max lower than the min, any value you try to set will be converted to the max. I was actually expecting to see us return the min in this case, just because the sanitization process starts at the min. On Tue, Jul 30, 2013 at 7:13 PM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 17 Apr 2013, Mounir Lamouri wrote: > > > > Currently, the specification seems to take care of min > max by simply > > making the element suffering from a value underflow such as a value > > overflow. Also, <input type='range'> has a special behaviour in that > > situation. However, if you try different implementations, the behaviours > > when min > max a widely different and generally speaking, such context > > can create pretty broken UI: a slider that can't move, a number spinner > > that doesn't allow changing the number's value, etc. > > > > I believe that having a special behaviour when min > max would be > > appropriate here. Basically, the min and max attributes should be > > ignored in that situation. That means that the element's 'minimum' and > > 'maximum' should be ignored in that situation unless there is a 'default > > minimum' or a 'default maximum' (which would be used). > > > > Adding this to the specification would help having a decent fallback > > when the attributes are broken instead of broken form controls. > > > > FWIW, Chrome's implementation of <input type='range'> seems to simply > > ignore min and max when min > max. Opera doesn't show any UI in that > > case. > > Generally speaking, we define the behaviour when the markup is bogus, but > we don't go out of our way to make it useful, for two main reasons: first, > it's hard to tell what is useful when the information we have is known to > be wrong (did they get them backwards? Did they omit a digit in the "max" > value? Did they put the decimal in the wrong place on the "min" value?), > and two, by having useful behaviour we make it much less likely that > errors will be caught (it's easier to catch a bug if users can't enter any > valid data at all, than it is if the error checking is just disabled). > > Are we sure we really want to go down this path? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 31 July 2013 12:38:48 UTC