- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Fri, 18 Nov 2011 17:47:36 +0100
- To: <www-dom@w3.org>, "Anne van Kesteren" <annevk@opera.com>
Do we really need "before" and "after"? There's a clear risk that someone write a code like "myelement.firstChild.after(...)" and that the code throws a null-ref exception at runtime if (exceptionnaly) myelement was empty. I much prefer myelement.insertAfter and insertBefore, because they deal with such cases nicely. And because the name are more understandable. Beside that small concern, I really like all the other additions. -----Message d'origine----- From: Anne van Kesteren Sent: Friday, November 18, 2011 2:02 PM To: www-dom@w3.org Subject: Improving the DOM; rev 2 Before: http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0140.html I forgot to explain before that we do not want to expose these methods where they do not make sense. The current DOM has that, but I do no think that is a particularly good design, and it is not a design we have used elsewhere in the platform. Java and its casts are not a concern for the platform. It seems however people do not want to restrict these methods so far you get limitations. Taking that into account I think this is the API you end up with: union ContentNode = DOMString Node; Document / DocumentFragment / Element prepend(ContentNode...) append(ContentNode...) DocumentType / Element / CharacterData before(ContentNode...) after(ContentNode...) replace(ContentNode...) remove(ContentNode...) The next question is whether we should impose restrictions on these methods at the IDL or method implementation level. E.g. appending a DocumentType to Document can be fine, but appending it to Element is never fine. Also currently you know that appendChild(DocumentFragment) on an Element is going to work. With these vararg methods you do not, unless the arguments are restricted at the IDL level, or otherwise at the method implementation level. I no longer feel strongly where we do this, but I believe Ojan had some concerns with respect to performance. As to what these methods return, we should probably go with chaining. I'm not a big fan, but it seems to be what all the cool kids are doing these days, and the cost is negligible. -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 18 November 2011 16:48:23 UTC