Bug Tracker

Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#5301 closed bug (invalid)

Unexpected selector precedence of attribute filter

Reported by: mikecapp Owned by: john
Priority: low Milestone: 1.4
Component: selector Version: 1.3.2
Keywords: precedence attribute Cc:
Blocked by: Blocking:


Not sure whether this a bug or an undocumented quirk, but it caught me out.

I would expect the selector "input:last[value=foo]" to find the last input in the context IF that input's value is "foo". If its value is anything else, I'd expect an empty result.

What the selector actually does is find the last input with a value of "foo", whether or not it's the last input in the context. In other words, it seems to be treated exactly the same as "input[value=foo]:last", which looks like a loss of expressiveness for no particular gain.

Attachments (1)

jq_last_attr_precedence.html (687 bytes) - added by mikecapp 11 years ago.
Minimal demo

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by mikecapp

Minimal demo

comment:1 Changed 10 years ago by dmethvin

Resolution: invalid
Status: newclosed

You're expecting a precedence in selector strings that isn't there. input:last[value=foo] only returns an element if the last element has value of "foo".

comment:2 Changed 9 years ago by mikecapp

I don't understand this "invalid" resolution. I'm not expecting a precedence that isn't there; I'm objecting to a precedence that is.

You say that input:last[value=foo] only returns an element if the last element has value of "foo". This is a) exactly what I wrote in the "expected behaviour" section of my report, and b) demonstrably NOT what jQuery is doing.

I've fiddlified the minimal demo: http://jsfiddle.net/mikecapp/ZU97P/

comment:3 Changed 9 years ago by timmywil

Priority: minorlow

The :last filter is a special case because it is always applied, well, last. I don't mean that sarcastically, but the attributes selector is applied to all inputs first regardless of the order in the string and I think this makes sense because otherwise the selector would be rendered somewhat pointless. last-child works differently and is always applied before the attributes selector, just like in css (:last does not have an equivalent css selector).


comment:4 Changed 9 years ago by mikecapp

@timmywil: since you changed the priority, did you mean to reopen this bug?

I can see the logic of your position from the implementation side, but from the user side it's inconsistent and surprising. To me, at least, and apparently to dmethvin as well.

comment:5 Changed 9 years ago by timmywil

No, I understand it may be confusing and it should be well documented, but order does not indicate the precedence in selectors, just the type of selector and in this case the consistency of :last is correct.

Note: See TracTickets for help on using tickets.