Re: MutationObserver does not observe state changes

Sorry for being late to this party. I realize that I'm just recapping
what has already been stated here:

-DOM Mutation Observers are for observing tree state (parent/child
relationships, attribute storage and characterData values). That's it.
Form elements DO NOT reflect their "live" value back into attribute
storage (EVER). It's an unfortunate historical artifact that the
"value" attribute is really "defaultValue".

-Object.oberve is capable of directly observing *data*-properties of
JS objects. "Observing" an accessor has no meaning. It's up to the
implementation of the accessor to define what this means (and
Object.getNotifier(obj).notify() when it change). This is the same for
"domain" JS objects and for host objects.

-The fact that host objects sometimes appear to have data-properties
which are really values which are computed on the C++ side is also
unfortunate. I believe WebIDL currently requires that these properties
appear to JS to be accessors, but I happen to know that WebKit/blink
current do not abide by this (although we trying to get there).

-Broadcasting Object.observe changeRecords for all WebIDL properties
is a non-starter. That's simply never going to happen -- primarily for
performance reasons.

-MDV (like all other data-binding mechanisms) can't directly observe
form values changing -- they must register events and pretend they saw
the value change.

-The place we need to get to is that the form/input elements know how
to emit change records for properties which may be "bound" to JS heap
values. (e.g. input.value, input.checked, etc...)

On Wed, Jul 31, 2013 at 10:06 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/31/13 8:50 AM, Bradley Meck wrote:
>>
>> Right now we have the ability to set but not read internal state using
>> attributes.
>
>
> That's not quite right for your testcase.
>
> Right now, as long as the value is the default value setting the attribute
> (which sets the default value) also sets the value.  Likewise, reading the
> attribute, which reads the default value, reads the value.
>
> Once the value and the default value diverge, via the value being explicitly
> changed, setting and reading the attribute still sets and reads the default
> value (as reflected by the .defaultValue property or the behavior of
> reset()).  But the value no longer has anything to do with the default
> value.
>
> -Boris
>

Received on Wednesday, 31 July 2013 22:19:28 UTC