W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: [whatwg] Object.observe()able properties on the web platform

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 25 Aug 2014 14:13:14 -0400
Message-ID: <53FB7CBA.4000800@mit.edu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC