Bug Tracker

Opened 5 years ago

Closed 5 years ago

Last modified 4 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 5 years ago by mikecapp

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

comment:2 Changed 5 years ago by addyosmani

  • Cc dmethvin added
  • Component changed from unfiled to traversing
  • Priority changed from undecided to low
  • Status changed from new to open

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 5 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 5 years ago by dmethvin

  • Resolution set to invalid
  • Status changed from open to closed

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

comment:5 Changed 5 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.

Version 0, edited 5 years ago by mikecapp (next)

comment:6 Changed 5 years ago by timmywil

  • Component changed from traversing to selector
  • Milestone changed from None to 1.8
  • Resolution invalid deleted
  • Status changed from closed to reopened

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 5 years ago by timmywil

  • Status changed from reopened to open

comment:8 Changed 5 years ago by timmywil

  • Owner set to timmywil
  • Status changed from open to assigned

comment:9 Changed 5 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 5 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 5 years ago by timmywil

  • Resolution set to duplicate
  • Status changed from assigned to closed

comment:12 Changed 5 years ago by timmywil

Duplicate of #9830.

comment:13 Changed 4 years ago by dmethvin

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