Comments on: JavaScript and Selectors http://web-graphics.com/2006/05/12/javascript-and-selectors/ Web development concerns, usually revolving around implimentation of designs into graphics, CSS, and HTML. Thu, 24 Jul 2008 06:54:55 +0000 http://wordpress.org/?v=2.5 By: kredyt http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-31008 kredyt Tue, 18 Mar 2008 14:57:48 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-31008 Thanks for link form my site to you. thanks for really great article. Greetings Thanks for link form my site to you.
thanks for really great article. Greetings

]]> By: Londi http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-30993 Londi Tue, 18 Mar 2008 09:55:51 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-30993 Thank you for the good articles have helped me a lot. Thank you for the good articles have helped me a lot.

]]> By: Ann Birret http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-14123 Ann Birret Fri, 15 Jun 2007 13:09:57 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-14123 Thanks for this really interesting post. It appears really helpful for me. I would like to ask you if I could translate it and include it in our page, also with link to your page. Alternatively I would like to put link to your page on my section with interesting articles. If it would be possible to put this link on my page please email me. One more time thanks for really great article. Greetings Thanks for this really interesting post. It appears really helpful for me. I would like to ask you if I could translate it and include it in our page, also with link to your page. Alternatively I would like to put link to your page on my section with interesting articles. If it would be possible to put this link on my page please email me. One more time thanks for really great article. Greetings

]]> By: Lee, ChihCheng http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-773 Lee, ChihCheng Sat, 02 Sep 2006 17:03:52 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-773 Bug report: If use UTF-8 charset, the tooltips will die. for example, search the: BubbleTooltips.html file, and change: charset=iso-8859-1 -> utf-8 then , the ToolTips will not work. Bug report:

If use UTF-8 charset, the tooltips will die.

for example, search the: BubbleTooltips.html file, and change:

charset=iso-8859-1 -> utf-8

then , the ToolTips will not work.

]]> By: liorean http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-351 liorean Tue, 27 Jun 2006 21:05:26 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-351 <p>Jeff: XPath potential algorithmical complexity is higher than selectors. Selectors matching can always be done unidirectionally, which is not true for XPath. So, selectors can be optimised harder than XPath. XPath has a worst case algorithmical complexity of O(<var>n</var><sup><var>x</var></sup>) for any value of <var>x</var>. I'm not sure what the worts case algorithmical complexity of selectors might be, but given what I know about <code>NodeList</code> traversal, I'd say O(<var>n</var><sup>2</sup>) sounds likely.</p> <p>If you want to find elements matching a group of selectors in a given document: You can always go from the root, testing the first sequence of selectors in each selector towards the document root element and queue up testing that sequence of simple selectors against all elements in it's subtree. In case of a match, queue up testing the next sequence of simple selectors on the subtree of the matching element, excluding elements dependent on what combinator was used. This way, the traversal doesn't have to visit any node more than once. If the last sequence of simple selectors in one of the selectors matched, then the matching element is added to the list that is to be returned.</p> <p>If you want to find out whether a given element matches a certain group of selectors, you do it the opposite way. You test the element against the last sequence of simple selectors, and then you traverse backwards, towards the root, testing elements dependent on what combinator was used, until you've either run out of elements to test or you have found a match to the first sequence of simple selectors. If you have found a match, you abort the traversal and return <code>true</code>. If you have run out of elements to test, you return <code>false</code>.</p> <p>When I said that you only have to visit any given node once, I didn't take certain pseudo class, pseudo element or negation simple selectors into account. Either the testing for these can be done traversing backwards on each node, or it can be moved from the simple selectors testing into the traversal subtree exclusion by the code generator.</p> Jeff: XPath potential algorithmical complexity is higher than selectors. Selectors matching can always be done unidirectionally, which is not true for XPath. So, selectors can be optimised harder than XPath. XPath has a worst case algorithmical complexity of O(nx) for any value of x. I’m not sure what the worts case algorithmical complexity of selectors might be, but given what I know about NodeList traversal, I’d say O(n2) sounds likely.

If you want to find elements matching a group of selectors in a given document: You can always go from the root, testing the first sequence of selectors in each selector towards the document root element and queue up testing that sequence of simple selectors against all elements in it’s subtree. In case of a match, queue up testing the next sequence of simple selectors on the subtree of the matching element, excluding elements dependent on what combinator was used. This way, the traversal doesn’t have to visit any node more than once. If the last sequence of simple selectors in one of the selectors matched, then the matching element is added to the list that is to be returned.

If you want to find out whether a given element matches a certain group of selectors, you do it the opposite way. You test the element against the last sequence of simple selectors, and then you traverse backwards, towards the root, testing elements dependent on what combinator was used, until you’ve either run out of elements to test or you have found a match to the first sequence of simple selectors. If you have found a match, you abort the traversal and return true. If you have run out of elements to test, you return false.

When I said that you only have to visit any given node once, I didn’t take certain pseudo class, pseudo element or negation simple selectors into account. Either the testing for these can be done traversing backwards on each node, or it can be moved from the simple selectors testing into the traversal subtree exclusion by the code generator.

]]> By: hax http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-326 hax Tue, 20 Jun 2006 06:02:33 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-326 XPath doesn't have pseudo-class and pseudo-element, and the syntax of CSS selectors is refined so it is more straightforward to write and understand. Of couse there are sth XPath can do but CSS selector not, eg. query a parent node as the pattern of descendants. XPath doesn’t have pseudo-class and pseudo-element, and the syntax of CSS selectors is refined so it is more straightforward to write and understand. Of couse there are sth XPath can do but CSS selector not, eg. query a parent node as the pattern of descendants.

]]> By: Jeff Schiller http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-306 Jeff Schiller Fri, 16 Jun 2006 17:43:08 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-306 Out of curiosity, assuming XML nodes, is there anything that can be done using CSS Selectors that cannot be done with an equivalent XPath expression? Also, I'm not sure why you believe XPath would be slower, maybe I don't know enough about browser internals though... Out of curiosity, assuming XML nodes, is there anything that can be done using CSS Selectors that cannot be done with an equivalent XPath expression?

Also, I’m not sure why you believe XPath would be slower, maybe I don’t know enough about browser internals though…

]]> By: Dustin Diaz http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-298 Dustin Diaz Thu, 15 Jun 2006 16:21:20 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-298 I don't have much to say except for the fact that having selector support would just be way cool for JavaScript. Having seen the growing number of cases of people wanting "getElementsBySelector" and $$(selector) and...well the list goes on; it would be down right logical to just implement a feature like that within the language. I don’t have much to say except for the fact that having selector support would just be way cool for JavaScript. Having seen the growing number of cases of people wanting “getElementsBySelector” and $$(selector) and…well the list goes on; it would be down right logical to just implement a feature like that within the language.

]]> By: Mike McNally http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-179 Mike McNally Mon, 15 May 2006 21:08:49 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-179 I don't think there's much of a performance issue with selectors used for event listening, at least for events driven by mouse and keyboard happenings. The only time the set of listening nodes is interesting is the point at which an event actually happens. Currently the browser can determine whether a node it's visiting has a handler by simply checking a pointer. With selector-based registration, the browser would additionally need to match the nodes against the set of registered selectors. That doesn't seem so bad, as for any given page the number of such selectors shouldn't be that great, and the node vs. selector predicate would have to be fast anyway. It's not as if the browser has to check all the nodes on a page, because it knows already exactly what nodes to check for the event. As to the idea of selectors being implemented as native Javascript language elements, I don't see what good that'd do as there are no other language elements against which a selector makes sense. In general Javascript does execute in the context of a DOM, but those elements are themselves not part of the language spec per se. Thus it seems to me that definining the semantics for selectors requires references to things (like the way a node's parent is found) that are not part of the language per se, which seems pretty weird for a language element. I don’t think there’s much of a performance issue with selectors used for event listening, at least for events driven by mouse and keyboard happenings. The only time the set of listening nodes is interesting is the point at which an event actually happens. Currently the browser can determine whether a node it’s visiting has a handler by simply checking a pointer. With selector-based registration, the browser would additionally need to match the nodes against the set of registered selectors. That doesn’t seem so bad, as for any given page the number of such selectors shouldn’t be that great, and the node vs. selector predicate would have to be fast anyway. It’s not as if the browser has to check all the nodes on a page, because it knows already exactly what nodes to check for the event.

As to the idea of selectors being implemented as native Javascript language elements, I don’t see what good that’d do as there are no other language elements against which a selector makes sense. In general Javascript does execute in the context of a DOM, but those elements are themselves not part of the language spec per se. Thus it seems to me that definining the semantics for selectors requires references to things (like the way a node’s parent is found) that are not part of the language per se, which seems pretty weird for a language element.

]]> By: Patrick Corcoran http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-178 Patrick Corcoran Mon, 15 May 2006 17:45:08 +0000 http://web-graphics.com/2006/05/12/javascript-and-selectors/#comment-178 I agree that the current state of affairs with regard to DOM manipulation is wanting. But I don't really see the need to solve this problem by adding new layers of syntax and language extensions. That to me is overkill. If every problem were solved thus, JavaScript would ultimately end up as a worse syntactical mess than perl. (With all due respect to perl... :) The API needed to solve this problem is in my opinion a wrapper of utility classes. Create a DOMSelector object, write an interpreted library for it that works across all browsers today, and then let the browser manufacturers internalize and optimize that in native code, all voluntarily and in good time. I guess I just don't see the need to constantly formalize language extensions just to simplify the code of common design patterns. I agree that the current state of affairs with regard to DOM manipulation is wanting.

But I don’t really see the need to solve this problem by adding new layers of syntax and language extensions. That to me is overkill. If every problem were solved thus, JavaScript would ultimately end up as a worse syntactical mess than perl. (With all due respect to perl… :)

The API needed to solve this problem is in my opinion a wrapper of utility classes. Create a DOMSelector object, write an interpreted library for it that works across all browsers today, and then let the browser manufacturers internalize and optimize that in native code, all voluntarily and in good time.

I guess I just don’t see the need to constantly formalize language extensions just to simplify the code of common design patterns.

]]>