So to me it seems much better to have a single instance that is shared as that creates less objects overall. If you did not ask for oldValue and it is there anyway, is that a big problem?

Different mutation observers (I'm not talking about possible transient observers) shouldn't share mutation records

...because different instances of MutationObserver may observe
different things.
One script library might observe only things X, and another one
things Y. those things shouldn't mix up.

WebKit shares records wherever possible to reduce the memory overhead of the feature. Given that all attributes are readonly, this doesn't seem very problematic (the worst that can happen is that the records become a side-channel for expando properties; Events already have this behavior).

As Travis rightly points out, the existing queueing algorithm would need one more loop to describe WebKit's behavior, since we at most create two records for a given mutation (one with an oldValue and one without).

It would be odd if script library A observing mutations without
oldValue would get oldValue. That would be even error prone:
scripts might rely on the data to not be there if they are not observing it.
So, records should be per observer.

If implementations want to share the internal data, that is ofc ok, but better
to not expose that to JS.

Adam is not suggesting exposing oldValue to observers that did not ask for it though. (The specification has that, and I don't think it's a big deal personally, but that can be changed.)

Well, that is even more strange.
In same cases observers might share records, in some case not.

Consistent APIs, please ;)

(In reply to comment #7)
> Well, that is even more strange.
> In same cases observers might share records, in some case not.
> 
> Consistent APIs, please ;)

I don't think developers are likely to care much about the identity of records, but I do think they care about the memory footprint of the browsers they work in.

For what it's worth, the old queueing algorithm specified WebKit's behavior with regard to identity (see "record" and "recordWithOldValue"):
http://www.w3.org/TR/2012/WD-dom-20120405/#concept-mo-queue-attributes

(not surprising, since I think I wrote that text).

(In reply to comment #8)
> I don't think developers are likely to care much about the identity of
> records, but I do think they care about the memory footprint of the browsers
> they work in.

I do care about API consistency. That is what is exposed to the web.
Also, I believe memory usage won't be a problem in this case.
Mutation records should be short living objects and created
only within one microtask, so by far the most common case is to have just
few mutation records queued.
And, implementations are free share the record instances behind the
scenes. Just create different JS wrapper for each observer. That can be done in a
quite cheap way, but is very much implementation detail.

I'm not clear what you think is inconsistent about different observers sharing mutation records.

Can you explain a bit more? I.e. which thing is inconsistent with which other thing(s)?

My inconsistency argument came from comment 6.
if A isn't expecting oldValue and B is and there are two
records, one with oldValue, one without.
The one without oldValue would be shared, the other one wouldn't.

In your example, neither are shared between A and B. A sees |record| and B sees |recordWithOldValue|.

But in general, both are shared. All observers who requested oldValue see the same |recordWithOldValue| and all observers who did not see the same |record|.

(In reply to comment #12)
> In your example, neither are shared between A and B. A sees |record| and B
> sees |recordWithOldValue|.
Why? Both observers should get 2 records. One record is with oldValue, one without. But A should never see record with oldValue, just similar record which
has empty old value.

I don't think so, but maybe we're talking at cross purposes. To make it more concrete:

<script>
var MutationObserver = MutationObserver || WebKitMutationObserver;
var div = document.createElement('div');
div.setAttribute('foo', 'foo');

function makeHandler(name) {
  return function handler(recs) {
    console.log('observer ' + name);
    console.log('count: ' + recs.length);
    console.log('oldValue: ' + recs[0].oldValue);
    if (recs[0].expando) {
      console.log('exando found');
    } else {
      recs[0].expando = 1;
      console.log('expando not found, and written');
    }
  };
}

var A = new MutationObserver(makeHandler('A'));
A.observe(div, { attributes: true, attributeOldValue: true });

var B = new MutationObserver(makeHandler('B'));
B.observe(div, { attributes: true });

var C = new MutationObserver(makeHandler('C'));
C.observe(div, { attributes: true, attributeOldValue: true });

var D = new MutationObserver(makeHandler('D'));
D.observe(div, { attributes: true });

div.setAttribute('foo', 'bar');
</script>

In WebKit this outputs:

observer A ---------
count: 1
oldValue: foo
expando not found, and written
observer B ---------
count: 1
oldValue: null
expando not found, and written
observer C ---------
count: 1
oldValue: foo
exando found
observer D ---------
count: 1
oldValue: null
exando found 

In Gecko this outputs:

observer A ---------
count: 1
oldValue: foo
expando not found, and written
observer B ---------
count: 1
oldValue: null
expando not found, and written
observer C ---------
count: 1
oldValue: foo
exando not found, and written
observer D ---------
count: 1
oldValue: null
exando not found, and written

That creates only one record (per observer). What I was thinking is more like
div.setAttribute('foo', 'bar');
div.setAttribute('foo', 'bar2');

...that is without setting attribute before creating observers.

I see. Thank you for clarifying. Yes, in that case in WebKit (and the original spec), the record(withoutOldValue) is delivered to A and B.

So your concern is that developers attempt to rely on records either always or never being shared?

(In reply to comment #17)
> So your concern is that developers attempt to rely on records either always
> or never being shared?
Right.

And I'd prefer never sharing because that just makes the API more coherent.
Records delivered for observer Foo are never delivered for observer Bar.
That way script libraries can rely on that no one can alter their
records (if they use expandos for example). 

And so far I haven't seen cases where memory usage of records is problematic.
They are (usually) short living tiny objects.
Feel free to prove this wrong with a real world use case :)

https://github.com/whatwg/dom/commit/b5d05659b682b2560af6c24e2e2cdbace82811d3

Looks good. Thanks for clarifying!