Comments on: JavaScript and Selectors

By: Meredith Borstadt

Meredith Borstadt — Wed, 03 Feb 2010 04:50:56 +0000

Excellent blog. You have brought in a new devotee. Please maintain the great writings and I look forward to more of your newsworthy updates.

By: Ann Birret

Ann Birret — Fri, 15 Jun 2007 13:09:57 +0000

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

Lee, ChihCheng — Sat, 02 Sep 2006 17:03:52 +0000

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

liorean — Tue, 27 Jun 2006 21:05:26 +0000

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(n^x) 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(n²) 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

hax — Tue, 20 Jun 2006 06:02:33 +0000

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

Jeff Schiller — Fri, 16 Jun 2006 17:43:08 +0000

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

Dustin Diaz — Thu, 15 Jun 2006 16:21:20 +0000

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

Mike McNally — Mon, 15 May 2006 21:08:49 +0000

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

Patrick Corcoran — Mon, 15 May 2006 17:45:08 +0000

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.

By: Erik Arvidsson

Erik Arvidsson — Mon, 15 May 2006 17:08:28 +0000

Very good points indeed.

There is a huge need for testing if a node matches a selector. I think releasing a spec without that would be a huge oversight.

What about relative expressions? In CSS Selectors everything is relative to the document. For example how would we use this to get all the children elements of an element?

I think we could generalize the event attachment case even more. We could have an object that gets called whenever a node is inserted, modified or removed which causes a match. Basically, during the style resolution, we do callbacks to a javascript object.

var sel = new Selector(‘.foo’);
sel.addEventListener(‘match’, f, true); // or non EventTarget interface
sel.addEventListener(‘unmatch’, g, true);
sel.watchMatch(document);

where the relatedTarget would be the node that started to match. This would require that the item keeps track of matching nodes, which like you said, I doubt that browsers do. However, letting the browser do this for us might save some time and make this less buggy/more efficient… and this case is simpler because the selector text is known. It would still be useful if we only had ‘match’ but then all apps would have to duplicate all this code over and over and over.