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

[Maciej Stachowiak]

On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:

On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers <schepers@...> 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.

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.

Regards,

Maciej

[Doug Schepers-3]

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@...
>> <mailto:schepers@...>> 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

[Maciej Stachowiak]

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

[Anne van Kesteren-2]

On Tue, 20 Oct 2009 23:07:47 +0200, Doug Schepers <schepers@...> wrote:
> 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.

If a legacy implementation has a bug adding a new feature only introduces  
the chance of more bugs, it won't actually solve them nor will it help  
authors support the legacy implementation.


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

You can request other data than XML using XMLHttpRequest. I don't think  
this should be of concern to us.


--
Anne van Kesteren
http://annevankesteren.nl/

[Jonas Sicking-2]

On Tue, Oct 20, 2009 at 2:07 PM, Doug Schepers <schepers@...> wrote:

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

Comment nodes are fairly rarely used. A webpage that doesn't want to
worry about if comment nodes are going to be included in .children or
not can simply avoid using comment nodes in those parts of the DOM.
And an implementation that simply wants to iterate over all child
elements can simply check for comment nodes and skip them as
appropriate. And in the case where you're only looking for a certain
set of element names, you don't even need to make extra effort to skip
comments.

Has any vendor actually expressed a preference in implementing a new
.childElements property over simply using .children? Has web
developers? It seems like Garrett did express a preference in not
reusing .children, but that is the only person I've heard that
feedback from. All other feedback I've received has been to ask us to
implement .children as a list of child elements.

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

I think a simple NodeList should suffice. It's mostly by accident that
Gecko uses HTMLCollection for .children and .getElementsByTagName().
I'd be prepared to change that to simply using a NodeList and see if
that breaks any content, I expect it not to.

/ Jonas

[John Resig]

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

That's not completely true - if a code base were to make use of
.children for efficiency it would probably write code like the
following:

var getChildren = (function(){
  var div = document.createElement("div");
  div.innerHTML = "<!--div-->";
  if ( div.children && div.children.length === 0 ) {
    return function(elem){
      return elem.children;
    };
  } else {
    return function(elem){
      var ret = [], child = elem.children || elem.childNodes;
      for ( var i = 0, l = child.length; i < l; i++ ) {
        if ( child[i].nodeType === 1 ) {
          ret.push( child[i] );
        }
      }
      return ret;
    };
  }
})();

That way they'd have one clean function for .children in browsers that
handle it nicely and another for ones that don't.

In comparison, the following is a sample of the code that would need
to exist to use .childElements

var getChildren = (function(){
  if ( document.documentElement.childElements ) {
    return function(elem){
      return elem.childElements;
    };
  } else {
    return function(elem){
      var ret = [], child = elem.children || elem.childNodes;
      for ( var i = 0, l = child.length; i < l; i++ ) {
        if ( child[i].nodeType === 1 ) {
          ret.push( child[i] );
        }
      }
      return ret;
    };
  }
})();

In the end, not much of a change - at least not enough to warrant a
completely new property. (Note: The above code aggregates an array of
DOM elements, it's likely that you would want to avoid the extra loop
in a high performance situation. Also, elem.children ||
elem.childNodes is used to get a minor perf boost in IE, since it'll
have to search through less nodes. Also, if .childElements did exist
it's likely that some code bases would start to have an if (
childElements ) {} else if ( children ) {} else {} - which wouldn't
make a ton of sense if IE never implements the new property.)

--John

[Brian Kardell]

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

Why only in this particular case? :)  As a rule that seems like sound
guidance.  If it's implemented everywhere, shouldn't you have to make
a pretty compelling case for it _not_ to be included in an official
standard?



On Tue, Oct 20, 2009 at 1:42 PM, Maciej Stachowiak <mjs@...> wrote:

>
> On Oct 18, 2009, at 4:14 AM, Jonas Sicking wrote:
>
> On Sun, Oct 18, 2009 at 12:12 AM, Doug Schepers <schepers@...> 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.
> 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.
> Regards,
> Maciej
>

[Maciej Stachowiak]

On Oct 20, 2009, at 8:03 PM, Brian Kardell wrote:

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.

Why only in this particular case? :)

I didn't say "only"...

 As a rule that seems like sound
guidance.  If it's implemented everywhere, shouldn't you have to make
a pretty compelling case for it _not_ to be included in an official
standard?

I agree. The reason I phrased it as I did was to contrast with my previous remarks. The "children" attribute should be part of a standard, even though it creates what I think is a poor design pattern (mix of previous/next and indexed access to the same collection).

Regards,

Maciej

[Robert O'Callahan-3]

On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak <mjs@...> wrote:

I agree. The reason I phrased it as I did was to contrast with my previous remarks. The "children" attribute should be part of a standard, even though it creates what I think is a poor design pattern (mix of previous/next and indexed access to the same collection).

It might be worth adding annotations to the spec to say "this API is terrible, do not use" and "this API is terrible, do not follow its design".

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Maciej Stachowiak]

On Oct 20, 2009, at 8:22 PM, Robert O'Callahan wrote:

On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak <mjs@...> wrote:

I agree. The reason I phrased it as I did was to contrast with my previous remarks. The "children" attribute should be part of a standard, even though it creates what I think is a poor design pattern (mix of previous/next and indexed access to the same collection).

It might be worth adding annotations to the spec to say "this API is terrible, do not use" and "this API is terrible, do not follow its design".

Are there any DOM Core methods where those notes would not apply? :-)

 - Maciej

[Brian Kardell]

@deprecated ? :)

On Tue, Oct 20, 2009 at 8:22 PM, Robert O'Callahan <robert@...> wrote:

> On Wed, Oct 21, 2009 at 4:15 PM, Maciej Stachowiak <mjs@...> wrote:
>>
>> I agree. The reason I phrased it as I did was to contrast with my previous
>> remarks. The "children" attribute should be part of a standard, even though
>> it creates what I think is a poor design pattern (mix of previous/next and
>> indexed access to the same collection).
>
> It might be worth adding annotations to the spec to say "this API is
> terrible, do not use" and "this API is terrible, do not follow its design".
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

[Boris Zbarsky]

On 10/20/09 11:25 PM, Maciej Stachowiak wrote:
>> It might be worth adding annotations to the spec to say "this API is
>> terrible, do not use" and "this API is terrible, do not follow its
>> design".
>
> Are there any DOM Core methods where those notes would not apply? :-)

Node.parentNode is mostly ok.  ;)

-Boris

[Simon Pieters-3]

On Tue, 20 Oct 2009 23:07:47 +0200, Doug Schepers <schepers@...> wrote:

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

No, with childElements, authors would always have to check for support for  
childElements, because of older versions of IE, Opera, WebKit, and Mozilla  
not supporting it at all, and fall back to children, and check to see if  
Comment nodes are included, because of the large marketshare of older  
versions of IE.

It seems simpler to me to just use children and check to see if Comment  
nodes are included if one cares about old versions of IE.

Also note that getElementsByTagName includes comment nodes in IE. Should  
we thus invent a new getElementsByTagNameWithoutCommentsInIE?


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

I wouldn't worry about the name of the collection. It's not the first time  
Web APIs have the wrong names (consider innerHTML, XMLHttpRequest,  
XMLSerializer, which all support both HTML and XML at this point), and it  
would be a bad move to duplicate all of them just to get nice names when  
there's no strategy of getting rid of the old names, since the result  
would just be duplicated APIs and more bugs overall.

--
Simon Pieters
Opera Software

[Simon Pieters-3]

On Tue, 20 Oct 2009 23:11:31 +0200, Maciej Stachowiak <mjs@...>  
wrote:

> DOM4 Core needs to start by deleting stuff before adding stuff IMO.

I agree. The Web DOM Core draft deletes a bunch of stuff from DOM3 Core  
(included in comments in the source markup of the draft).

As for adding new features, I think we should wait and see how js  
libraries solve any problems that authors have in practice before  
extending DOM Core.

--
Simon Pieters
Opera Software

[Laurens Holst-3]

Op 21-10-2009 12:27, Jonas Sicking schreef:
> Comment nodes are fairly rarely used. A webpage that doesn't want to
> worry about if comment nodes are going to be included in .children or
> not can simply avoid using comment nodes in those parts of the DOM.
> And an implementation that simply wants to iterate over all child
> elements can simply check for comment nodes and skip them as
> appropriate. And in the case where you're only looking for a certain
> set of element names, you don't even need to make extra effort to skip
> comments.
>    

I really really don’t get what the benefit is of using .children over
.childNodes if you still have to filter on node type for .children.

If you have so much control over the DOM that you can dictate that there
be no comment nodes (e.g. when the DOM is dynamically created through
script or off a template), by the same argument you can also dictate
that there are no white space text nodes, or access the DOM with indexes
that take their locations into account. Thus, again, there is no benefit
of .children over .childNodes.

~Laurens

--
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com