- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 7 Nov 2010 17:47:45 -0500
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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11253 > 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