W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] <input type=number> without keyboard editing

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 04 Nov 2010 20:55:09 -0400
Message-ID: <4CD355ED.6010703@mit.edu>
On 11/4/10 7:57 PM, Aryeh Gregor wrote:
> On Tue, Nov 2, 2010 at 9:58 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> This is difficult to do in practice.  Consider:
>>   <input type="number" min="20" max="50" value="20">
>> The user now wishes to input 30 instead of the default value of 20. What
>> steps need to be taken to do this, and how does the input control react to
>> those steps?
> The user backspaces twice

Hold.  You (and the Google folks) were talking about always clamping 
stuff as the user types, so the value is never invalid.  So the user 
hits backspace once, the value is 2, that's out of range, gets clamped 
to 20.

> IMO, unlike the Firefox
> preferences control behavior I mentioned, it shouldn't prevent you
> from typing anything, it should clamp onblur.

That's not what the Google folks wanted, nor what I read your previous 
mail as saying....

> Until blur, it should
> only expose the changed value to JS (.value, firing input events,
> etc.) when the current value is valid -- otherwise it should remain at
> the old value.

That might confuse scripts (and in particular x.value = x.value would 
actually change the visible value!).

> 1) Hit backspace, user sees "2", .value is "20", no input event fired

Not firing the input event would likely break scripts too...

> Trying to change the value that the user sees as they type it isn't a
> good idea in general, I think.

Yes, I agree.  Hence my example!

Presenting inconsistent state to script (see the value = value example 
above) is not a good idea either, though.

Received on Thursday, 4 November 2010 17:55:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC