Inconsistent parsing of unquoted trailing spaces in attribute selector.

[sakimorix@…]

Attribute selector handling appears to be inconsistent between the collection factory and other operations like .is(~) and .find(~). Specifically, unquoted trailing spaces in an attribute value are handled differently in some instances.

As a quick example, <div id="xyz" foo="bar">-</div> will be matched by $("div[foo=bar ]") but $("#xyz").is("div[foo=bar ]") yields false. Similarly, $("#xyz").filter("div[foo=bar ]") yields an empty collection.

For a jsFiddle of the above, see: ​http://jsfiddle.net/9yDjA/

As one would expect, quoting the attribute value always results in the correct behaviour, regardless of how much leading or trailing space is around the value. And while it could be argued that unquoted trailing spaces are bad practice, IMO the real problem here is one of consistency: if a given selector matches an element, it should match in all cases and $(x).is(x) should never return false (provided x does not contain positional components and $(x) is not an empty collection, of course).

Either unquoted spaces (both leading and trailing) should be trimmed in all cases (meaning "div[foo=bar ]" should be interpreted as "div[foo='bar']"), or they should be made part of the value being tested (meaning "div[foo=bar ]" is interpreted as "div[foo='bar ']"). I would prefer the former as that is less likely to break existing code, but would gladly take the latter over the current (inconsistent) behaviour.

I've confirmed this happens on current v1.x releases, both stable (v1.10.2) and beta (v1.11.0b2).

[gibson042]

Confirmed. You must have been doing something very unusual to find this one.

[Richard Gibson]

Fix #14579: attribute selectors with trailing spaces after an unquoted value

Changeset: ed20e7c645064822f4070a0c60195e4bcdaba683

[anonymous]

Very unusual indeed. :)

Many thanks for jumping on this one so quickly!