Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)

Discussion:

John Resig

2008-07-07 02:31:37 UTC

I just want to note that most browsers implement the .children child element NodeList (all except for Mozilla-based browsers, at least). I suspect that building upon this existing work would lead to especially-fast adoption.

--John

----- Original Message -----
From: "Doug Schepers" <***@w3.org>
To: "Jonas Sicking" <***@sicking.cc>
Cc: "Webapps" <public-***@w3.org>, "Web APIs WG" <public-***@w3.org>, "Daniel Glazman" <***@disruptive-innovations.com>
Sent: Monday, June 23, 2008 7:23:47 PM GMT -05:00 US/Canada Eastern
Subject: Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)

Hi, Jonas, Daniel-

http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0214.html
Which no one replied to.
If you implement the HTML DOM you should already have code that not only
filters out elements, but even filters out elements of a specific name.
Seems like that code should be reusable?

For an HTML UA, yes, that makes perfect sense. But there is concept of
that in SVG, for example, so for an SVG-only UA that would still be an
additional implementation (and memory) cost.

I intend to make a make a separate spec that also provides a nodelist
for Element nodes, so we won't be losing the nodelist feature, just
deferring it (and not for long, at that). Those UAs which want to
implement both Element Traversal and Element Nodelist can do so; those
that don't yet aren't burdened with implementing Element Nodelist
(though as devices mature, I'm sure they'll want to do both).

The other issue at stake here is the coordination between W3C and JSRs.
While this doesn't have a direct impact on desktop browser vendors, it
does affect the current mobile Web sphere, where Java is widely
deployed. The better aligned the JSRs can be to core W3C technologies,
the more robust the entire Open Web Stack is for content developers and
users. This is important enough that it is worth a small amount of
extra standardization effort to facilitate that.

I will create an Element Nodelist specification right away, and if it is
approved to go forward (and I don't see why it wouldn't be, since there
is considerable support), I am confident that this would not slow down
deployment in desktop browsers, and so authors should be able to use it
in the same timeframe as Element Traversal. I hope this resolves your
issue satisfactorily.

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

Jonas Sicking

2008-07-07 04:43:28 UTC

Permalink

Isn't .children more like document.all in that you can dig out elements
with a specific id and/or specific name? I.e. isn't it more than just a
plain NodeList of all child elements?

/ Jonas

Post by John Resig
I just want to note that most browsers implement the .children child element NodeList (all except for Mozilla-based browsers, at least). I suspect that building upon this existing work would lead to especially-fast adoption.
--John
----- Original Message -----
Sent: Monday, June 23, 2008 7:23:47 PM GMT -05:00 US/Canada Eastern
Subject: Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)
Hi, Jonas, Daniel-

For an HTML UA, yes, that makes perfect sense. But there is concept of
that in SVG, for example, so for an SVG-only UA that would still be an
additional implementation (and memory) cost.
I intend to make a make a separate spec that also provides a nodelist
for Element nodes, so we won't be losing the nodelist feature, just
deferring it (and not for long, at that). Those UAs which want to
implement both Element Traversal and Element Nodelist can do so; those
that don't yet aren't burdened with implementing Element Nodelist
(though as devices mature, I'm sure they'll want to do both).
The other issue at stake here is the coordination between W3C and JSRs.
While this doesn't have a direct impact on desktop browser vendors, it
does affect the current mobile Web sphere, where Java is widely
deployed. The better aligned the JSRs can be to core W3C technologies,
the more robust the entire Open Web Stack is for content developers and
users. This is important enough that it is worth a small amount of
extra standardization effort to facilitate that.
I will create an Element Nodelist specification right away, and if it is
approved to go forward (and I don't see why it wouldn't be, since there
is considerable support), I am confident that this would not slow down
deployment in desktop browsers, and so authors should be able to use it
in the same timeframe as Element Traversal. I hope this resolves your
issue satisfactorily.
Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

John Resig

2008-07-07 12:11:54 UTC

Permalink

Correct - .children also supports the automatic ID-expansion. Considering that this already provides the functionality that we're looking for it would be good to codify it into a specification.

I've been trying to promote getting this landed into Mozilla trunk - but perhaps not strongly enough:
https://bugzilla.mozilla.org/show_bug.cgi?id=418183

Although, considering the performance benefits that UAs have been able to get by implementing it, it seems worth the time to pull it all together into a specification.

--John

----- Original Message -----
From: "Jonas Sicking" <***@sicking.cc>
To: "John Resig" <***@mozilla.com>
Cc: "Doug Schepers" <***@w3.org>, "Webapps" <public-***@w3.org>, "Web APIs WG" <public-***@w3.org>, "Daniel Glazman" <***@disruptive-innovations.com>
Sent: Monday, July 7, 2008 12:43:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)

Isn't .children more like document.all in that you can dig out elements
with a specific id and/or specific name? I.e. isn't it more than just a
plain NodeList of all child elements?

/ Jonas

For an HTML UA, yes, that makes perfect sense. But there is concept of
that in SVG, for example, so for an SVG-only UA that would still be an
additional implementation (and memory) cost.
I intend to make a make a separate spec that also provides a nodelist
for Element nodes, so we won't be losing the nodelist feature, just
deferring it (and not for long, at that). Those UAs which want to
implement both Element Traversal and Element Nodelist can do so; those
that don't yet aren't burdened with implementing Element Nodelist
(though as devices mature, I'm sure they'll want to do both).
The other issue at stake here is the coordination between W3C and JSRs.
While this doesn't have a direct impact on desktop browser vendors, it
does affect the current mobile Web sphere, where Java is widely
deployed. The better aligned the JSRs can be to core W3C technologies,
the more robust the entire Open Web Stack is for content developers and
users. This is important enough that it is worth a small amount of
extra standardization effort to facilitate that.
I will create an Element Nodelist specification right away, and if it is
approved to go forward (and I don't see why it wouldn't be, since there
is considerable support), I am confident that this would not slow down
deployment in desktop browsers, and so authors should be able to use it
in the same timeframe as Element Traversal. I hope this resolves your
issue satisfactorily.
Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF