Re: childElements, childElementCount, and children

Hey-

Maciej Stachowiak wrote (on 10/20/09 4:42 PM):
>
> On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:
>
>> On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers <schepers@w3.org
>> <mailto:schepers@w3.org>> wrote:
>>> So, rather than dwell on an admittedly imperfect spec, I personally
>>> suggest
>>> that we urge WebKit developers to implement .children and
>>> .children.length,
>>> in the anticipation that this will be in a future spec but can be
>>> useful to
>>> authors today.
>>
>> They already do. Which casts some amount of doubt on Maciejs argument
>> that it was too performance heavy to implement in WebKit. :)
>
> What I said way back in the day (about childElements) was this:
>
> "I suggest leaving this out, because it's not possible to implement
> both next/previous and indexed access in a way that is efficient for
> all cases (it's possible to make it fast for most cases but pretty
> challenging to make it efficient for all). This is especially bad
> with a live list and an element whose contents may be changing while
> you are iterating.
>
> If all you care about is looping through once, writing the loop with
> nextElementSibling is not significantly harder than indexing a list."
>
> I stand by that remark. It is indeed hard to get both indexed and
> previous/next access efficient in all cases. Of course, we are not going
> to let that stop us from interoperating with de facto standards, and we
> do our best (as for other kinds of NodeLists and HTMLCollections), but
> I'd rather not have new APIs follow this pattern.

I got similar feedback from mobile vendors, who had not optimized live 
lists, so I think Maciej's point was valid for the design constraints of 
Element Traversal.

Where we now take the idea of an element-node-based API is another matter.


> In this particular case, I think anything that's implemented in all of
> the major browser engines should be an official standard, not just de facto.

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

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

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

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