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: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 28 Aug 2014 20:39:50 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <b3bd4e677359453eb5a604ec58c87003@BLUPR03MB344.namprd03.prod.outlook.com>
It's not input.value and the like that I hear folks repeatedly clamor for, it's CSS state changes on an element that they most often want. These are the sorts of things that are super-hard, if not impossible to catch with MutationObservers, and Object.observe wouldn't help either. For example, please notify me when my background-color changes... this can happen for dozens of reasons, most of which are very hard to detect unless you hook all mutable CSS entrypoints.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Monday, August 25, 2014 11:13 AM
To: public-script-coord@w3.org
Subject: Re: [whatwg] Object.observe()able properties on the web platform

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...


Received on Thursday, 28 August 2014 20:40:23 UTC

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