W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 06 Jul 2008 21:43:28 -0700
Message-ID: <48719EF0.7020001@sicking.cc>
To: John Resig <jresig@mozilla.com>
Cc: Doug Schepers <schepers@w3.org>, Webapps <public-webapps@w3.org>, Web APIs WG <public-webapi@w3.org>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>

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

John Resig wrote:
> 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" <schepers@w3.org>
> To: "Jonas Sicking" <jonas@sicking.cc>
> Cc: "Webapps" <public-webapps@w3.org>, "Web APIs WG" <public-webapi@w3.org>, "Daniel Glazman" <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-
> 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
Received on Monday, 7 July 2008 04:44:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC