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

[Aryeh Gregor]

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.

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

I can't speak for Google.  My original mail was ambiguous on this
point, but what I said in my last mail is what I was thinking of.

> 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?  If so, we can think about how to best avoid
script confusion.

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

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

"""
User agents may wait for a suitable break in the user's interaction
before queuing the task; for example, a user agent could wait for the
user to have not hit a key for 100ms, so as to only fire the event
when the user pauses, instead of continuously for each keystroke.
"""
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#common-event-behaviors

So I don't see how firing input events less often could break scripts,
given that one is fired eventually.  (Although it might be more useful
if input events fired every time the input changed by a single
character, including many events being fired for a large copy-paste.
But that's not how they're defined to work now.  Or do browsers
actually fire one input event per keystroke always, and the spec is
wrong?  How are input events handled on date-pickers?)

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

No, but nor is telling the user to do something that could be reliably
handled automatically (clamping an input value).  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.

On Fri, Nov 5, 2010 at 5:26 AM, Christoph Päper
<christoph.paeper at crissov.de> wrote:
> 1) hit backspace: user sees “20” with ‘0’ dimmed, because this is the minimal valid value starting with ‘2’ and also the last used valid value, .value is “20”

That sounds confusing.  I wouldn't know what the dimming means.