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" <[EMAIL PROTECTED]> To: "John Resig" <[EMAIL PROTECTED]> Cc: "Doug Schepers" <[EMAIL PROTECTED]>, "Webapps" <[email protected]>, "Web APIs WG" <[EMAIL PROTECTED]>, "Daniel Glazman" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > To: "Jonas Sicking" <[EMAIL PROTECTED]> > Cc: "Webapps" <[email protected]>, "Web APIs WG" <[EMAIL PROTECTED]>, > "Daniel Glazman" <[EMAIL PROTECTED]> > 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 > >
