This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14354 - Rename append/replaceChild/insertBefore(<some text>) to appendText, replaceWithText, insertTextBefore
Summary: Rename append/replaceChild/insertBefore(<some text>) to appendText, replaceWi...
Status: RESOLVED INVALID
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-02 10:31 UTC by Olli Pettay
Modified: 2011-12-17 14:45 UTC (History)
5 users (show)

See Also:


Attachments

Description Olli Pettay 2011-10-02 10:31:15 UTC
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.
Comment 1 Aryeh Gregor 2011-10-02 19:42:42 UTC
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.
Comment 2 Anne 2011-10-02 20:54:13 UTC
FormData.append(), XMLHttpRequest.send(). Are there methods not overloaded like this?
Comment 3 Olli Pettay 2011-10-02 21:12:25 UTC
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?
Comment 4 Anne 2011-10-03 11:04:40 UTC
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.
Comment 5 Boris Zbarsky 2011-10-03 11:39:00 UTC
> 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.
Comment 6 Anne 2011-10-03 11:52:56 UTC
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.)
Comment 7 Boris Zbarsky 2011-10-03 12:00:21 UTC
> 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.
Comment 8 Cameron McCormack 2011-10-11 05:37:13 UTC
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.
Comment 9 Anne 2011-10-19 06:51:22 UTC
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.
Comment 10 Anne 2011-12-17 14:45:42 UTC
The change in comment 0 was reverted. If anything else needs to happen please file a new bug.