14354 2011-10-02 10:31:15 +0000 Rename append/replaceChild/insertBefore(<some text>) to appendText, replaceWithText, insertTextBefore 2011-12-17 14:45:42 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED INVALID P2 normal --- 1 bugs annevk ayg bzbarsky cam mike www-dom public-webapps-bugzilla oldest_to_newest 57628 0 bugs 2011-10-02 10:31:15 +0000 Current draft allows adding new text nodes using appendChild(string param) etc. That is not only a bit misleading, since things like appendChild("<div>") doesn't do what one would expect, but it can also lead to other unexpected results if one does for example element.appendChild(anchorElement); One could assume that the href (stringifier) of anchorElement gets appended to element, or one could assume that the element gets appended. Both are perfectly fine interpretations, IMO. API shouldn't allow that, but should be clear what happens in each case. Also, I don't see any good reasons to re-use the same method names for doing something else than just inserting nodes. 57671 1 ayg 2011-10-02 19:42:42 +0000 Adding new methods does seem clearer than overloading existing ones. Is there any reason to overload here? Are there other methods in the web platform that are overloaded like this? One advantage of not overloading is it allows easier feature-testing -- you don't have to try calling it and see if it throws. 57672 2 annevk 2011-10-02 20:54:13 +0000 FormData.append(), XMLHttpRequest.send(). Are there methods not overloaded like this? 57675 3 bugs 2011-10-02 21:12:25 +0000 FormData and XHR methods aren't performance-vise hot. And even more importantly, is there any reason why append/replaceChild etc need to be overloaded, and new methods can't be created? 57695 4 annevk 2011-10-03 11:04:40 +0000 In Opera this would not be a performance hit. WebKit representatives seemed okay with it as well. Having additional methods is not at all JavaScript-like. 57697 5 bzbarsky 2011-10-03 11:39:00 +0000 > In Opera this would not be a performance hit. On this testcase: (function() { var d = document.createElement("div"); var d2 = document.createElement("div"); var start = new Date; for (var i = 0; i < 1000000; ++i) d2.appendChild(d); alert(new Date - start); })() Opera is about 4x slower than Gecko on my machine. Overloading wouldn't be a performance hit for us either if we were that slow. And we expect this to become much faster, so the relative cost of the overload stuff will be even higher. 57698 6 annevk 2011-10-03 11:52:56 +0000 I'm not really a benchmark expert but how is that testing appendChild() functionality? After the first time appendChild() could effectively be a no-op in that test if the implementation had some optimization check for that. (And WebKit appears a lot faster than Gecko on that test.) 57699 7 bzbarsky 2011-10-03 12:00:21 +0000 > After the first time appendChild() could effectively be a no-op > in that test if the implementation had some optimization check for that. Sure. Here's a version of the test test that doesn't have that problem: (function() { var d = document.createElement("div"); var ds = [ document.createElement("div"), document.createElement("div") ]; var start = new Date; for (var i = 0; i < 1000000; ++i) d.appendChild(ds[i % 2]); alert(new Date - start); })() or (function() { var d = document.createElement("div"); d.appendChild(document.createElement("div")); d.appendChild(document.createElement("div")); var start = new Date; for (var i = 0; i < 1000000; ++i) d.appendChild(d.firstChild); alert(new Date - start); })() which amusingly enough are much slower in WebKit; there is no real difference in Gecko or Presto. > (And WebKit appears a lot faster than Gecko on that test.) Sure. Is I said, we plan to make it a lot faster in Gecko in any case. I was simply commenting on your claim that there is no performance hit in Presto. 58033 8 cam 2011-10-11 05:37:13 +0000 We should (if we don't yet) have a constructor for Text. Then you can do e.appendChild(new Text("abc")); which ain't so bad. 58415 9 annevk 2011-10-19 06:51:22 +0000 I reverted this change for now. I do not think adding Text node specific methods is the way to go here. Adding a constructor for Text makes sense, but I'm not sure how it should work for Element. 61749 10 annevk 2011-12-17 14:45:42 +0000 The change in comment 0 was reverted. If anything else needs to happen please file a new bug.