20490 2012-12-22 00:36:43 +0000 [Custom]: Things that mutate the DOM tree should queue observer records 2013-02-20 19:04:18 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED DUPLICATE 21063 P2 normal --- 17103 20684 1 bzbarsky dglazkov bugs wchen public-webapps-bugzilla oldest_to_newest 80518 0 bzbarsky 2012-12-22 00:36:43 +0000 "The element upgrade algorithm must not queue any observer records. " This isn't a reasonable requirement, because it makes mutation observers unreliable. The requirement should in fact be the other way: any DOM mutations MUST queue observer records. 81488 1 dglazkov 2013-01-16 17:52:17 +0000 There's been a similar discussion on bug 20397, starting with comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=20397#c7 81491 2 dglazkov 2013-01-16 18:24:58 +0000 I honestly just hate the whole http://parkour.mtv/webcomponents/spec/custom/index.html#dfn-element-upgrade, because it's very disruptive and unintuitive to a developer. Even less intuitive if we don't suppress mutation observers. "WTF just happened? I didn't do that!" would be a very common reaction to capturing some of those records. I wonder if the www-dom discussion (http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0075.html) will result in a specified behavior where a wrapper is exchanged for another one. Maybe we could piggyback to that behavior and swap wrappers (well, and prototypes in this case) instead doing a whole-hog renameNode? 81492 3 bugs 2013-01-16 18:34:28 +0000 MutationObservers must be reliable. One needs to be able to detect all the changes to DOM just using an observer so that the current state of DOM can be inspected using MutationRecords. Otherwise the whole MutationObserver API is rather useless. 81494 4 bzbarsky 2013-01-16 18:37:47 +0000 Switching wrappers won't change your localName, right? Does the current upgrade stuff do that? The text at https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-instantiation is completely silent on the question of what the actual DOM node created is like (e.g. its namespace, localName, attributes, etc, etc)... (As a side note, the first link in comment 2 is to some private network, looks like.) 81495 5 dglazkov 2013-01-16 18:46:28 +0000 (In reply to comment #4) > Switching wrappers won't change your localName, right? Does the current > upgrade stuff do that? The text at > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn- > custom-element-instantiation is completely silent on the question of what > the actual DOM node created is like (e.g. its namespace, localName, > attributes, etc, etc)... They will have identical localName. I need to firm the spec up on that (as you pointed out in bug 20489), but that's the intent. And the algo does copy all of the attributes. > > (As a side note, the first link in comment 2 is to some private network, > looks like.) Haha. That's my machine, sorry :) 81496 6 dglazkov 2013-01-16 18:48:44 +0000 (In reply to comment #3) > MutationObservers must be reliable. One needs to be able to detect > all the changes to DOM just using an observer so that the current state of > DOM > can be inspected using MutationRecords. > Otherwise the whole MutationObserver API is rather useless. The thing is, element upgrade is not something I _want_ the author to observe, the whole point of the operation is to substitute one DOM node for another with as few side effects as possible. That's why just switching wrappers seems better. 81497 7 bugs 2013-01-16 19:01:27 +0000 I don't quite understand how wrapper switching would help. well, I'm not sure what you mean with wrapper switching. Just tmp = NodeA->JSWrapper; NodeA->JSWrapper = NodeB->JSWrapper; NodeB->JSWrapper = tmp; ? 83415 8 dglazkov 2013-02-20 19:04:18 +0000 Pouring this over to bug 21063. *** This bug has been marked as a duplicate of bug 21063 ***