[whatwg] Forms-related feedback

[Mounir Lamouri]

On 20/11/12 22:51, Ian Hickson wrote:
> On Tue, 20 Nov 2012, Mounir Lamouri wrote:
>> > 
>> > Currently stepUp(n) and stepDown(n) are very basic methods. They more or 
>> > less do value += n * allowedValueStep; with n = -n; if stepDown() was 
>> > called. In addition of being pretty dumb, there are a lot of reasons why 
>> > they can throw.
>> > 
>> > At Mozilla, we think that the main use case for stepUp() and stepDown() 
>> > is to create a UI with spin buttons: clicking on the up arrow would call 
>> > stepUp() and clicking on the down arrow would call stepDown(). Such a 
>> > use case needs methods that do better than just adding n * 
>> > allowedValueStep. In addition, we think that throwing is very often a 
>> > bad idea and that should happen when the developer clearly did something 
>> > wrong.
>> > 
>> > So, we would like to change the stepUp()/stepDown() algorithm to match
>> > the following behaviour:
>> > - we only throw if the input type doesn't allow those methods or if
>> > there is no allowed value step;
>> > - if the value isn't a number (aka empty string), we should just exit
>> > the steps;
>> > - if the value is below the minimal allowed value and n is negative, we
>> > should exit the steps;
>> > - if the value is above the maximal allowed value and n is positive, we
>> > should exit the steps;
>> > - if the element is suffering from a step mismatch, and n is negative,
>> > the value should be changed to the next valid value. Otherwise, it
>> > should be changed to the previous allowed value;
>> > - newValue = value + n * allodValueStep;
>> > - if the newValue is below the minimal allowed value, the newValue
>> > should be equal the minimal allowed value;
>> > - if the newValue is higher than the minimal allowed value, the newValue
>> > should be equal the minimal allowed value.
>> > 
>> > Such a behaviour creates a real added value in stepUp() and stepDown() 
>> > that make those methods useful compared to simply do value += n * 
>> > allowedValueStep; and prevent throwing when there is no need to.
>
> Done, though I described it in a different way. (I hope it's equivalent.)

I think there are two behaviour that you seem to have described differently:
- in step 12, if you take the example page [1], setting the value to 21
and calling stepDown() should change the value to 20 and setting it to
19 and calling stepUp() should change it to 20. This how it is
implemented in Opera and Firefox and this how the Chrome's UI behaves.
As far as I understand the spec you wrote, those two examples would give
respectively 10 and 30.
- I believe that when the value is set to below min and n < 0, we should
not change the value. Same thing for value below max and n > 0. This is
the behaviour all UA currently have with stepUp() and stepDown()
(though, the previous spec was requiring that) and this is Chrome's UI
behaviour. I think that behaviour makes more sense UX-wise because going
down or up and having the value going the opposite way is just weird and
unexpected.

>> > [1] The only difference between Chrome's spin buttons behaviour and our 
>> > proposal is that when value is the empty string, it is setting value to 
>> > 0 and continue to the next steps (unless the 0 is below the minimal 
>> > allowed value and n < 0, in that case value=min). It might be 
>> > interesting to specify something better than "do nothing" if value="".
>
> I'm open to doing that too; what would you preference be?

Maybe if value isn't valid, we could have it changed to the step base or
|min + (max - min)/2| and exit the steps if stepDown() or stepUp() is
called. (I think even if stepDown(hugeNumber) is called, we should still
just set the value and do nothing else.)
I would tend to prefer step base mostly because it would know set it to
the default value if there is a default value. However, I think step
base is quite a bad solution for some types. Maybe we could use the
"default value" if there is such a concept for the type or the "step
base" otherwise?

[1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918

Thank you for the prompt change, Ian.

--
Mounir