Hi, Jonas, Daniel-
Jonas Sicking wrote (on 6/23/08 2:03 PM):
What about the issue I raised here:
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
