Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#13552 closed bug (notabug)

Custom Pseudo Selector fails if name starts with "eq"

Reported by: ttkaminski@… Owned by:
Priority: undecided Milestone: None
Component: selector Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:


See this jsfiddle. http://jsfiddle.net/hCzUd/

If you create a pseudo selector and the name of it starts with "eq" then it does not behave as expected. Every element of the DOM gets passed to the selector function. eg.

$.expr:?.eqXYZ = $.expr.createPseudo(...)

simply changing the name to "esXYZ", then everything works as expected. Seems like the tokenizer bug?

Change History (5)

comment:1 Changed 6 years ago by gibson042

Component: unfiledselector
Resolution: notabug
Status: newclosed

We make no guarantees about which elements get passed to a custom pseudo function, only that we will honor its return value for excluding elements from the final matched set: http://jsfiddle.net/hCzUd/1/

But for the record, there is currently a performance penalty if your custom pseudos is prefixed with a standard positional pseudo (even|odd|eq|gt|lt|nth|first|last), the effects of which you are observing here.

comment:2 Changed 6 years ago by ttkaminski@…

Please make a note of this in the documentation here:


comment:3 Changed 6 years ago by gibson042

The return result from this function should be a boolean (true if the element matches the selector, false if not).

What would you have us change?

comment:4 Changed 6 years ago by ttkaminski@…

I'd like to see the documentation to include:

"Note: Custom pseudo functions prefixed with standard position pseudo (even|odd|eq|gt|lt|nth|first|last) may incur a performance penalty. In general, there are no guarantees on which elements are passed to the custom pseudo function (ie. elements passed to function may not match the given selector)."

Can you explain why this is the case? Is it an optimization in jQuery or just on oversight?

comment:5 Changed 6 years ago by gibson042

It is axiomatic that elements passed to the function may not match... the purpose of the function is to help find out.

As for the reason why custom pseudos prefixed with a positional selector might hurt performance more than those that aren't: positional selectors need special processing, and we check for their presence with a regular expression before tokenization to skip it if possible (or at least start with a small seed set for non-positional matching). Anything that looks positional doesn't get the benefits.

Honestly, I'd recommend using the .filter( fn )method instead of defining a custom pseudo, if that would work for your purposes.

Note: See TracTickets for help on using tickets.