Skip to main content

Bug Tracker

Side navigation

#10096 closed bug (duplicate)

Opened August 19, 2011 01:57PM UTC

Closed November 05, 2011 06:25PM UTC

Last modified January 30, 2012 03:14PM UTC

Matching of implicit 'value' attributes has changed

Reported by: mikecapp Owned by: timmywil
Priority: low Milestone:
Component: selector Version: 1.6.2
Keywords: Cc: dmethvin
Blocked by: Blocking:
Description

http://jsfiddle.net/mikecapp/rjyRx/

We had a

filter("[value=]")

applied to an input element, where the empty 'value' attr being tested for was often implicit. This worked in all tested browsers in 1.4.2. It doesn't work in FF/Chrome in 1.6.2, or as far back as 1.4.4. (Don't know about 1.4.3; jsfiddle doesn't offer it.) It still works in IE7/8, or if the empty value is explicit.

(I wouldn't say this is a regression per se, since I suspect we were accidentally relying on undefined behaviour. But it broke our app, so I thought I'd flag it in case anyone has a "whoops, didn't mean to do that" moment.)

Attachments (0)
Change History (13)

Changed August 19, 2011 06:48PM UTC by mikecapp comment:1

Implicit values in 1.4.4+ don't work in IE9 either

Changed August 22, 2011 05:46AM UTC by addyosmani comment:2

cc: → dmethvin
component: unfiledtraversing
priority: undecidedlow
status: newopen

Confirmed, however I'm not entirely sure this behaviour has been defined or documented so it's difficult to say whether we really want to support this. I can't imagine many cases where others may wish to use filter("[value=]"), but CC'ing dmethvin for a second opinion.

Changed August 22, 2011 11:06AM UTC by mikecapp comment:3

Filtering for an empty value is definitely useful - we do it in several places, for different reasons. It's the *implicit* value that I suspect puts this in the realm of undefined behaviour.

Changed October 13, 2011 04:18AM UTC by dmethvin comment:4

resolution: → invalid
status: openclosed

Definitely need quotes there, so it was just a coincidence it worked before.

Changed October 13, 2011 09:26AM UTC by mikecapp comment:5

_comment0: Quotes are irrelevant - changing the filter to [value=''] produces exactly the same results. The explicit/implicit distinction in this issue is about the presence/absence of a value attribute in the markup.1318498019430111

Quotes are irrelevant - changing the filter to [value=""] produces exactly the same results. The explicit/implicit distinction in this issue is about the presence/absence of a value attribute in the markup.

Changed October 13, 2011 01:27PM UTC by timmywil comment:6

component: traversingselector
milestone: None1.8
resolution: invalid
status: closedreopened

QSA retrieves the attribute, but IE6/7 retrieves the property. This will be consistent when the value attrHook is removed (meaning it will work the way it does in Chrome/FF).

Changed October 13, 2011 01:27PM UTC by timmywil comment:7

status: reopenedopen

Changed October 13, 2011 01:27PM UTC by timmywil comment:8

owner: → timmywil
status: openassigned

Changed October 13, 2011 01:43PM UTC by dmethvin comment:9

Sorry, I misunderstood the original issue. However, I don't think the hook is going to fix the real problem, is it? That is, <input /> does not match input[type="text"] or input[type] or input[type=""] because querySelectorAll requires an explicit attribute:

http://jsfiddle.net/uEyhf/4/

Changed October 13, 2011 01:51PM UTC by timmywil comment:10

I don't think that's related here. The behavior of Sizzle will match QSA for the value attribute when the value attrHook is removed. type has other issues.

Changed November 05, 2011 06:25PM UTC by timmywil comment:11

resolution: → duplicate
status: assignedclosed

Changed November 05, 2011 06:25PM UTC by timmywil comment:12

Duplicate of #9830.

Changed January 30, 2012 03:14PM UTC by dmethvin comment:13

milestone: 1.8