- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 20 Oct 2009 14:11:31 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: "www-dom@w3.org list" <www-dom@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 UTC