W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

[whatwg] More stepUp() and stepDown() comments (was: Re: Forms-related feedback)

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Wed, 30 Jan 2013 18:35:45 +0000
Message-ID: <51096801.9020606@lamouri.fr>
To: whatwg@lists.whatwg.org
On 08/01/13 00:47, Ian Hickson wrote:
> On Wed, 21 Nov 2012, Mounir Lamouri wrote:
>> On 20/11/12 22:51, Ian Hickson wrote:
>>> On Tue, 20 Nov 2012, Mounir Lamouri wrote:
>>>>>
>>>>> 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(). [...]
>>>
>>> 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.
>>
>> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918
>>
>> - 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.
> 
> Done.
> 
> For this:
> 
>    <input type='number' min='10' step='10' max='21'>
> 
> ...if the value is 22 and you step up (with the UI), Chrome sets it to 21. 
> (Opera does nothing.)
> 
> Per spec, stepUp() now would leave this unchanged (like Opera).
> 
> (I tried to test Firefox but I couldn't get my build to show UI for 
> type=number. Not sure if I'm on the wrong channel or something?)

There is no UI. The feature is only enabled on Mobile for the moment.
Thus, as my initial email was saying, you can toggle a pref on Desktop
to use stepUp() and stepDown() our intent being to have the UI simply
relying on those methods (IOW, we want to dogfood the spec).

> Also, note that per the new spec if stepUp() or stepDown() are called with 
> an argument that isn't 1, it's ignored if the value isn't on a valid step. 
> So in the example above, if value=22 and you call stepDown(5), it only 
> goes down to 20, not 10. Is that ok?

Why? That is an arbitrary limitation. We could simply change point 6 to do:
"If value subtracted from the step base is not an integral multiple of
the allowed value step, then set value to the nearest value that, when
subtracted from the step base, is an integral multiple of the allowed
value step, and that is *more* than value if the method invoked was the
stepDown() and *less* than value otherwise.

*In all cases*, run the following substeps:
[...]"

I believe, this should just work. There is no technical reasons to have
this behave differently for |n|=1 and |n|>1. It will just create
confusion. Basically, the behaviour I'm describing for stepUp(2) would
be equivalent to calling stepUp(1) twice (which seems to be the sanest
behaviour).

> Also, if you call it as stepDown(-2), it goes down to 20, it's not left at 
> 22, because the argument is ignored and the method itself is used to 
> determine the direction if we're not on step. Is that ok?
> 
> Similarly, if you're at 10, and you call stepUp(1), it goes to 20, but if 
> you call stepUp(2), it stays at 10, because 30 is out of range (max 21). 
> Is that ok?

No, it should go to 20 too.

I think we should add a step between step 5 and step 6 that says:
"If value is less than minimum and stepDown() was invoked or if value is
greater than the maximum allowed value and stepUp() was invoked, abort
these steps."

Then, step 7 and 8 should be changed to:
"7. If the element has a minimum, and value is less than minimum, set
value to the minimum."
"8. If the element has a maximum, and value is greater than the maximum
allowed value, set value to the maximum allowed value."

I also believe we should define the "maximum allowed value" as:
"If an element has a maximum, its maximum allowed value is the maximum
if the maximum subtracted from the step base is an integral multiple of
the allowed value step. Otherwise, it is the nearest value that, when
subtracted from the step base, is an integral multiple of the allowed
value step and that is less than the maximum."

Those changes would make the following snippet work as expected:
data:text/html,<input type='number' min=-10 step=10 max=100 value=-100>

If you call stepDown() on this, you would expect that nothing happens
because there are clearly nothing that can be done. However, stepUp()
should clamp to the first allowed value.
In addition, it will make sure we clamp to the maximum allowed value if
we do stepUp(1000) instead of doing nothing.

Thanks,
--
Mounir
Received on Wednesday, 30 January 2013 18:36:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT