Re: childElements, childElementCount, and children

On Tue, 20 Oct 2009 23:07:47 +0200, Doug Schepers <schepers@w3.org> wrote:

> I don't feel too strongly about having both .children and  
> .childElements, but I do think that .children is a little problematic  
> for authors... they will always have to check to see if Comment nodes  
> are included, because of the large marketshare for older versions of IE,  
> while .childElements allows them to write simple, clean, efficient code,  
> which is the whole point of an element-based API.

No, with childElements, authors would always have to check for support for  
childElements, because of older versions of IE, Opera, WebKit, and Mozilla  
not supporting it at all, and fall back to children, and check to see if  
Comment nodes are included, because of the large marketshare of older  
versions of IE.

It seems simpler to me to just use children and check to see if Comment  
nodes are included if one cares about old versions of IE.

Also note that getElementsByTagName includes comment nodes in IE. Should  
we thus invent a new getElementsByTagNameWithoutCommentsInIE?


> I also prefer ElementCollection over HTMLCollection, especially for  
> environments where more XML is used.  I don't know if there are any  
> deeper issues that would advantage one over the other, but I think it  
> would be confusing to authors to collect non-HTML elements in something  
> labeled HTMLCollection.

I wouldn't worry about the name of the collection. It's not the first time  
Web APIs have the wrong names (consider innerHTML, XMLHttpRequest,  
XMLSerializer, which all support both HTML and XML at this point), and it  
would be a bad move to duplicate all of them just to get nice names when  
there's no strategy of getting rid of the old names, since the result  
would just be duplicated APIs and more bugs overall.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 21 October 2009 08:26:53 UTC