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

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" <jonas@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>
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

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 12:12:37 UTC