W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Re: childElements, childElementCount, and children

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 20 Oct 2009 14:11:31 -0700
Cc: "www-dom@w3.org list" <www-dom@w3.org>
Message-id: <ED3180C0-97D5-4779-BE63-DDA11AD9C13E@apple.com>
To: Doug Schepers <schepers@w3.org>

On Oct 20, 2009, at 2:07 PM, Doug Schepers wrote:

>
> Agreed, which is why I've started off DOM4 Core as I did.

DOM4 Core needs to start by deleting stuff before adding stuff IMO.  
That being said, it's good to have this idea recorded.

>
> 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.

I'd be pretty hesitant to add an API that's almost identical to a pre- 
existing one. I think in this case the transition cost is probably  
acceptable, but testing would help us know with more certainty.

>
> 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.

Is there any problem with HTMLCollection other than the interface  
name? In nearly all code, the interface name doesn't matter. Renaming  
the interface is not a very compelling reason to add duplicate API.

Regards,
Maciej
Received on Tuesday, 20 October 2009 21:12:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT