Re: Element Nodelist - ISSUE-6 (was: ElementTraversal progress?)
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 public-webapps@w3.org, 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
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 public-webapps@w3.org, 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
Re: ElementTraversal progress?
Followup to webapps group please (reply-to set for this mail) On Mon, 02 Jun 2008 23:56:22 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. ... In mozilla we would actually even implement the .childElementCount property by keeping a hidden childNodes list internally. But that might be specific to the mozilla implementation. Indeed, it seems from discussing it that it would. Checking back with the implementor at Opera, we would prefer to leave the spec as it is for now, and if necessary write another, even smaller spec that offered the node list functionality if you really want it. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: ElementTraversal progress?
Charles McCathieNevile wrote: Followup to webapps group please (reply-to set for this mail) On Mon, 02 Jun 2008 23:56:22 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: On Sat, 31 May 2008 01:05:44 +0200, Jonas Sicking [EMAIL PROTECTED] I wanted to implement the ElementTraversal spec for the next release of firefox (after FF3). However last I heard there was still an outstanding issue of if we wanted to have .childElementCount unsigned long or if we wanted a .childElements NodeList. I guess Doug will pipe up soon, but as I understand things from him he thinks it makes sense to leave the spec as is. Opera, Ikivo and BitFlash are known to have implementations that are believed to be conformant to the current spec. ... In mozilla we would actually even implement the .childElementCount property by keeping a hidden childNodes list internally. But that might be specific to the mozilla implementation. Indeed, it seems from discussing it that it would. Checking back with the implementor at Opera, we would prefer to leave the spec as it is for now, and if necessary write another, even smaller spec that offered the node list functionality if you really want it. 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? / Jonas
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
