- From: Erik Arvidsson <arv@chromium.org>
- Date: Mon, 3 Oct 2011 10:01:19 -0700
- To: Aryeh Gregor <ayg@aryeh.name>
- Cc: Olli@pettay.fi, Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, Robin Berjon <robin@berjon.com>, www-dom@w3.org
On Sun, Oct 2, 2011 at 13:10, Aryeh Gregor <ayg@aryeh.name> wrote: > On Sun, Oct 2, 2011 at 6:38 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: >> Why? Why couldn't there be separate method(s) which take string/array etc >> and keep the old appendChild etc as they are now (in DOM 3, not in latest >> DOM 4 draft) > > I concur with this. Reasons to prefer separate methods are > > 1) It's unclear to someone reading the code whether the argument is > interpreted as plaintext or HTML. If you do > node.appendChild('<div>'), is that supposed to append a text node or > an element? Separate methods named things like appendText or > insertTextBefore would be much clearer, and not much longer if at all. I don't think it is unreasonable to expect some knowledge here, especially as it is safe for the developer to do the wrong thing. I would have been opposed if the incorrect thing was unsafe which is the case where HTML markup is allowed. It is just as unclear to me with insertBefore. Insert what before what? Maybe we should rename that to insertChildNodeBeforeChildNode then? Sorry, I just think it is time to make things less verbose so the JS libraries can shrink. > 2) It's more consistent with other DOM APIs -- overloading on argument > type is rare in the DOM. What examples are there currently? The DOM was created for Java in an era when XML roamed the earth. At some point we need to bury our dinosaur skeletons and move on. It is extremely common in JS and especially in jQuery (which in my opinion takes it too far). > 3) It allows easier feature-testing: 'appendText' in Node.prototype > instead of having to try it and see if it throws. (Not that this is > something likely to be feature-tested much.) Behavior testing is nothing new. There are lots of places today where presence of a property is not sufficient. > 4) It allows the argument to behave like a real string argument, with > anything passed to it cast to a string, instead of throwing. > JavaScript is weakly typed, and authors are not used to distinguishing > much between 42 and "42". This one is important. JS devs are not used to do alert(value.toString()) nor innerText = value.toString() (Yes, they are unaware of textContent but that is a different problem). This point (and to be defined NodeList/Array support) prevents me from jumping up and down celebrating. -- erik
Received on Monday, 3 October 2011 17:02:04 UTC