Bug Tracker

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#10096 closed bug (duplicate)

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:



We had a


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

Change History (13)

comment:1 Changed 12 years ago by mikecapp

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

comment:2 Changed 12 years ago by addyosmani

Cc: dmethvin added
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.

comment:3 Changed 12 years ago by mikecapp

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.

comment:4 Changed 11 years ago by dmethvin

Resolution: invalid
Status: openclosed

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

comment:5 Changed 11 years ago by mikecapp

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.

Last edited 11 years ago by mikecapp (previous) (diff)

comment:6 Changed 11 years ago by timmywil

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

comment:7 Changed 11 years ago by timmywil

Status: reopenedopen

comment:8 Changed 11 years ago by timmywil

Owner: set to timmywil
Status: openassigned

comment:9 Changed 11 years ago by dmethvin

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:


comment:10 Changed 11 years ago by timmywil

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.

comment:11 Changed 11 years ago by timmywil

Resolution: duplicate
Status: assignedclosed

comment:12 Changed 11 years ago by timmywil

Duplicate of #9830.

comment:13 Changed 11 years ago by dmethvin

Milestone: 1.8
Note: See TracTickets for help on using tickets.