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

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

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Sun, 7 Nov 2010 17:47:45 -0500
Message-ID: <AANLkTi=ZS7AWk6oTGCyUr8yqdrC9ZfXzRERedYC_z5ro@mail.gmail.com>
On Sun, Nov 7, 2010 at 5:28 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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?

Well, I'm not sure what the original poster wanted.  Unfortunately, he
stated his problems without giving reasons for why the described
behaviors were problematic, and didn't clarify subsequently.  It's
possible that he'd be fine with what I described, I don't know.  (Or,
rather, it's possible that the unnamed team in Google would be fine
with what I described.)

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

Interesting.  I've filed a bug:


> 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).

But is that a big deal with <input type=number>?  Very few sites must
be using it so far.  Plus, you're going to have to do something like
this with <input type=date> and friends, right?  When the user picks
the date, the whole value will have to change at once, with no
intermediate states.  And even with a number-picker, you're going to
have single state changes that are not equivalent to any one keypress
(e.g., incrementing from 9 to 10).  So scripts are going to get
confused regardless if they expect one input event to correspond to
one keypress.
Received on Sunday, 7 November 2010 14:47:45 UTC

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