Re: childElements, childElementCount, and children

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.


Received on Tuesday, 20 October 2009 21:12:07 UTC