childElements, childElementCount, and children (was: [ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?)

Hi, Garrett-

Garrett Smith wrote (on 10/17/09 11:06 PM):
>
> It has been so long that I cannot remember (over 8 years since I even
> tried using that). It is a useless, pointless method that tells little
> about the result of calling, say: getAttribute("checked").
>
> I read Nicholas was struggling with that:
> http://www.nczonline.net/blog/2007/05/08/safari-lies/

The rationale I've heard for implementations reporting inaccurately is 
that features with too many "subfeatures" are ambiguous in how they 
should be reported (how do you report support for "UIEvents" if you 
implement some but not all event types defined for that interface 
module?).  I've tried to address this in DOM3 Events by allowing a finer 
granularity of feature strings [1].


> What is missing from Element Traversal API is a convenience property
> to get child elements.

Wholeheartedly agreed.


>There is a childElementCount. What is the
> purpose of childElementCount?
>
> One comment response from you (Doug Schepers):-
> |  While many uses of Element Traversal do not require this attribute, I
> |  speak from personal developer experience when I confirm that it is
> |  useful.
>
> Does not describe the problem that "childElementCount" solves, nor
> does it solve the problem of getting the childElements.

One use case is shown in the spec itself [2]; childElementCount allows 
the author to find out how many element children there are without 
looping through twice ().  Since there were strong objections to adding 
.childElements (as I originally suggested), I struck a compromise.


>Usage patterns
> for childElements are quite common; you want the elements, no text
> nodes, no comments; only elements. This problem is trivially solved by
> the one missing property: childElementCount.

I assume you mean childElements, not childElementCount.


> This is not the first time childElements has been requested and
> childElementCount has been questioned. it has been mentioned on
> various w3c lists, on comp.lang.javascript, and on ejohn.org, numerous
> times as far back as January 2008. That did not made it into the
> specification. Here are a few:

No, not the first time at all... and farther back than that, to March 
2007.  I believe the first time it was mentioned was when I first 
suggested the feature [3], back when I took over as editor (note, Chaals 
checked it in and sent the message [4] to the list with the open 
question, since I was busy at the time with my day job).

I readily admit that childElementCount would have been obviated by 
childElements.length.  I also agree that in a perfect world, 
childElements would have been included.  But some good arguments against 
it were made (by Björn Höhrmann [5], Maciej [6], and the JSR folks); one 
of the arguments from the mobile community was that such lists were too 
computationally and memory intensive for some of their devices, and that 
their code bases were optimized in a different direction.  Finally, this 
feature was quite old even when I took over the spec, and had been 
shipping on devices for over a year, so I didn't want to change it too much.

There was a lot of history to this spec, and a lot of discussion; if you 
read back through all of the email discussion and telcon/f2f minutes and 
spec revisions, back to when it was part of SVG Tiny 1.2, you may 
appreciate that there was no choice that was right for all stakeholders.

I suspect that I would make different choices now, but the climate at 
the time was to ship the spec as it was, and revisit it in v2... in the 
meantime, .children is implemented widely (IE, FF, Opera, but not 
Safari/Chrome), so I reckon that's what we will standardize, either in 
Element Traversal v2, or probably more sensibly in DOM4 Core/Web DOM Core.

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.


[1] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#feature-detection
[2] http://www.w3.org/TR/ElementTraversal/#example-3.2
[3] 
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/ElementTraversal/publish/ElementTraversal.html?rev=1.2&content-type=text/html;%20charset=iso-8859-1
[4] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0064.html
[5] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html
[6] http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0013.html


p.s.  More history for those who care:  I was tricked into editing this 
spec by Nandini from Sun, who had inherited the action from Robin 
Berjon, and who asked me to be her "co-editor" at a Web API WG F2F at 
MIT... little did I know at the time that I'd be the sole person to take 
the spec from the meager sketch Robin had left us with, through all the 
LC comments and into CR, and write the entire test suite on a sleepless 
flight to a TPAC in Mandelieu to get us to PR and Rec.  Nandini!!!!!! :)

p.p.s.  If someone ever asks you to write a spec, back away slowly, 
turn, and run the other way.

p.p.p.s.  Unless I'm the one asking you to do it, in which case it's a 
really rewarding experience, and I encourage you to accept the honor on 
the spot.  You will reap the gratitude of untold numbers of developers, 
all of whom respect your decisions.

p.p.p.p.s.  When expressing concern about the feature detection and 
extended feature strings of DOM3 Events, please start a new thread with 
the subject preface "[D3E]", and send it to www-dom.  Thanks.

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

Received on Sunday, 18 October 2009 07:12:36 UTC