[whatwg] Ignore min and max if min > max

[Scott González]

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 at 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.   `._.-(,_..'--(,_..'`-.;.'
>