16425 2012-03-18 23:08:22 +0000 MutationObserver::observe/disconnect should return mutationobserver itself 2012-11-22 21:55:01 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 bugs annevk jonas mike Ms2ger rafaelw waldron.rick www-dom public-webapps-bugzilla oldest_to_newest 65718 0 bugs 2012-03-18 23:08:22 +0000 This was discussed and somewhat agreed end of September. Allows one to do observer.disconnect() .observe(node1, {...}) .observe(node2, {...}); 65720 1 annevk 2012-03-18 23:27:00 +0000 We have implemented this pattern in no API whatsoever to date. It was a conscious omission. 65721 2 bugs 2012-03-18 23:28:51 +0000 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.) 65769 3 jonas 2012-03-19 19:33:43 +0000 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. 65778 4 Ms2ger 2012-03-19 21:30:36 +0000 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). 65781 5 jonas 2012-03-19 22:10:08 +0000 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? 65783 6 annevk 2012-03-19 23:35:54 +0000 You generally need a good reason for doing something, not for not doing it. 65785 7 jonas 2012-03-20 00:34:59 +0000 The good reason would be that it makes it much easier to observe several parts of the DOM. 65786 8 bugs 2012-03-20 00:51:13 +0000 "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, {...}); 65787 9 jonas 2012-03-20 00:54:50 +0000 Though it means that you can avoid the temporary: (new MutationObserver(callback)) .observe(node1, {...}) .observe(node2, {...}) .observe(node3, {...}); 78611 10 annevk 2012-11-21 21:28:26 +0000 Once ECMAScript adopts this pattern we can consider it. (See also bug 13681 comment 5.) 78612 11 rafaelw 2012-11-21 21:57:41 +0000 What would "once" look like? Object.freeze/preventExtensions/etc... are already spec'd to return the object. 78613 12 annevk 2012-11-21 22:17:19 +0000 Well, e.g. Map.set() returns undefined. Maybe that's what design by committee looks like? 78614 13 rafaelw 2012-11-21 22:21:47 +0000 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. 78615 14 annevk 2012-11-21 22:27:57 +0000 Okay, raised: http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html 78666 15 waldron.rick 2012-11-22 21:55:01 +0000 FWIW, the new Object.observe API has recently been updated to return the target object.