#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: |
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.)
Change History (13)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Cc: | dmethvin added |
---|---|
Component: | unfiled → traversing |
Priority: | undecided → low |
Status: | new → 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 12 years ago by
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
Resolution: | → invalid |
---|---|
Status: | open → closed |
Definitely need quotes there, so it was just a coincidence it worked before.
comment:5 Changed 11 years ago by
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.
comment:6 Changed 11 years ago by
Component: | traversing → selector |
---|---|
Milestone: | None → 1.8 |
Resolution: | invalid |
Status: | closed → 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 11 years ago by
Status: | reopened → open |
---|
comment:8 Changed 11 years ago by
Owner: | set to timmywil |
---|---|
Status: | open → assigned |
comment:9 Changed 11 years ago by
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
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
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
comment:13 Changed 11 years ago by
Milestone: | 1.8 |
---|
Implicit values in 1.4.4+ don't work in IE9 either