[whatwg] Implementation issue: step mismatch handling for <input type=range>

[Ian Hickson]

On Thu, 17 Jan 2013, Jonathan Watt wrote:
>
> I'm working on implementing <input type=range> for Gecko and have 
> encountered what I believe to be an issue in the spec.
> 
> Step 1 of the algorithm to find the "step base":
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero
> 
> says "If the element has a min content attribute...to the value of the 
> min content attribute...". Should this not talk about "minimum" rather 
> than "min content attribute"? It would otherwise seem to give bad 
> results in the case of <input type=range>, which has a default minimum 
> of zero (a default minimum makes sense in the case of type=range, since 
> an unbounded slider would be impossible for a user to interact with). 
> Consider for example:
> 
>   <input type=range value=-1 max=1 step=3>
> 
> As it stands, the current spec text says that the "step base" is -1 
> (from the 'value' content attribute), the 'minimum' is zero (from the 
> default minimum), the 'maximum' is 1, and the step is 3.

Right.


> As a result, an implementation would seem to be directed to enter an 
> infinite loop applying the paragraphs beginning with "When the element 
> is suffering from an underflow..." and "When the element is suffering 
> from a step mismatch..." in:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29

First the element is suffering from an underflow but not a step mismatch, 
so the user agent must set the element's value to a valid floating-point 
number that represents the minimum (0).

Now the element is suffering from a step mismatch but not an underflow, so 
the user agent must round the element's value to the nearest number for 
which the element would not suffer from a step mismatch, and which is 
greater than or equal to the minimum, and, if the maximum is not less than 
the minimum, which is less than or equal to the maximum.

There's no such value. This isn't an infinite loop, but it is indeed an 
error. Fixed, by adding "if there is a number that matches these 
constraints", which means that the value now ends up at 0 and remains 
suffering from a step mismatch.


> If the step base considered the 'minimum' instead of the 'min' content 
> attribute, then the step base would be zero, and thus the value would 
> settle at zero.

Right, but that would be highly unlikely to make sense, because it would 
mean the value the author set was an invalid value. You shouldn't be 
forced to specify the minimum if you're already specifying a step and a 
value and the default minimum of zero is adequate.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'