This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was discussed and somewhat agreed end of September. Allows one to do observer.disconnect() .observe(node1, {...}) .observe(node2, {...});
We have implemented this pattern in no API whatsoever to date. It was a conscious omission.
Ok. I don't care too much. I personally don't like that coding style at all (but one doesn't need to use that ugly style.)
Anne: "we haven't used this pattern anywhere else" is a terrible reason. Up until recently we also had never used dictionaries. I hope that there's a better reason that than, such as that it fosters bad development practices, that it's bad for performance, or that it can result in buggy code? Reopening since so far no good reason has been made.
AIUI, the plan was to wait for ES to provide something to address this pattern for *all* APIs, rather than trying to implement it just for a couple of new APIs. Returning self also prevents us from returning something meaningful (even though we currently don't in this case).
What would this look like to be API-wide? Are we talking about something like the now-defunct 'with' operator? Has anyone check with TC39 if that is in the stars at all before we rely on them?
You generally need a good reason for doing something, not for not doing it.
The good reason would be that it makes it much easier to observe several parts of the DOM.
"much" is quite strong word. var o = new MutationObserver(callback); o.observe(node1, {...}); o.observe(node2, {...}); o.observe(node3, {...}); is not much longer than var o = new MutationObserver(callback); o.observe(node1, {...}) .observe(node2, {...}) .observe(node3, {...});
Though it means that you can avoid the temporary: (new MutationObserver(callback)) .observe(node1, {...}) .observe(node2, {...}) .observe(node3, {...});
Once ECMAScript adopts this pattern we can consider it. (See also bug 13681 comment 5.)
What would "once" look like? Object.freeze/preventExtensions/etc... are already spec'd to return the object.
Well, e.g. Map.set() returns undefined. Maybe that's what design by committee looks like?
We recently changed the Object.observe/unobserve spec calls to return object, for consistency with Object.freeze/etc... I think there's a clear move in that direction.
Okay, raised: http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html
FWIW, the new Object.observe API has recently been updated to return the target object.