- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 7 Nov 2010 14:05:35 -0500
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.
Received on Sunday, 7 November 2010 11:05:35 UTC