On 11/7/10 2:05 PM, Aryeh Gregor wrote:
On Thu, Nov 4, 2010 at 8:55 PM, Boris Zbarsky<[email protected]> 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
