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

[Boris Zbarsky]

On 11/7/10 2:05 PM, Aryeh Gregor wrote:
> On Thu, Nov 4, 2010 at 8:55 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> 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.
>
> In my idea, the submitted value is never invalid, but the value
> visible to the user can be invalid.

OK, that's explicitly NOT what this thread was about to start with.  The 
original poster wanted the value to never be invalid period, not just at 
submission time; this last is handled by form validation no matter what, no?

>> That might confuse scripts (and in particular x.value = x.value would
>> actually change the visible value!).
>
> Yes, it might confuse scripts.  That's a downside.  Do you agree that
> it's the right UI model to use in a hypothetical world where scripts
> don't exist, though?

Sure.  I also happen to think the original request that an invalid value 
never appear in the user-visible UI was silly, as a result.

> The input event is not guaranteed to be fired on every keystroke anyway:

Interesting.  I'm pretty sure I've seen pages that would break as a 
result...  I guess we'll see when a browser tries to do that.

> Or do browsers actually fire one input event per keystroke always

The browsers I've tested do.  But only one input event for a paste.

> No, but nor is telling the user to do something that could be reliably
> handled automatically (clamping an input value).

Sure.

> I'm not at all convinced that the latter is the least bad of the three.  A subpar UX
> counts for a lot more than the risk of breaking scripts, in my view.

The problem with breaking scripts is that it might cause a UA to not be 
able to ship the feature at all if it breaks existing content.  That's 
why the risk of breaking scripts is pretty important (my UA developer's 
hat on, etc).

-Boris