Skip to main content

Bug Tracker

Side navigation

#5301 closed bug (invalid)

Opened September 28, 2009 11:31AM UTC

Closed November 14, 2010 03:25PM UTC

Last modified June 14, 2011 02:06PM UTC

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)
Change History (5)

Changed November 14, 2010 03:25PM UTC by dmethvin comment:1

resolution: → invalid
status: newclosed

You're expecting a precedence in selector strings that isn't there.

only returns an element if the last element has value of "foo".

Changed June 13, 2011 05:51PM UTC by mikecapp comment:2

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:

Changed June 13, 2011 06:31PM UTC by timmywil comment:3

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).

Changed June 13, 2011 06:47PM UTC by mikecapp comment:4

@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.

Changed June 14, 2011 02:06PM UTC by timmywil comment:5

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.