- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 25 Aug 2014 14:13:14 -0400
- To: public-script-coord@w3.org
On 8/25/14, 1:17 PM, Rafael Weinstein wrote: > I'm supportive of this idea. I'd suggest starting with input.value This one is actually extra-fun from a performance standpoint. Right now, for a text input, there are two types of events. There's "change", which fires when the user is done typing and blurs the input. And there's "input", which fires on every keystroke. Neither one requires the implementation to supply either the old or new value. What this means in practice is that when the input takes focus you save the current value. On every keystroke you fire an "input" event. When the input loses focus you compare the current value to the saved value from when you took focus, and if the value changed fire a "change" event. The problem is that as you type the .value is changing with every keystroke. So if we did Object.observe for this one, that would mean that the above algorithm would change as follows: * Text inputs always store their current value. * On every keystroke, compute the new value, and if it's not the same as he current value send an Object.observe notification with the old and new value, then set the stored value to the new value. This is pretty suboptimal, because computing the value of a textarea is O(N) in length of the text (due to @wrap and so forth), so this automatically forces typing a character to be O(N) in the length of the text already in the textarea. Historically, things that cause typing a char to be O(N) in length of text mean super-laggy typing on things like wikipedia edit forms and other large textareas... -Boris
Received on Monday, 25 August 2014 18:13:41 UTC