This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"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.
There's been a similar discussion on bug 20397, starting with comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=20397#c7
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?
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.
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.)
(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 :)
(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.
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; ?
Pouring this over to bug 21063. *** This bug has been marked as a duplicate of bug 21063 ***