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 comment:1
Changed August 22, 2011 05:46AM UTC by comment:2
| cc: | → dmethvin |
|---|---|
| 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.
Changed August 22, 2011 11:06AM UTC by 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 comment:4
| resolution: | → invalid |
|---|---|
| status: | open → closed |
Definitely need quotes there, so it was just a coincidence it worked before.
Changed October 13, 2011 09:26AM UTC by 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 comment:6
| 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).
Changed October 13, 2011 01:27PM UTC by comment:7
| status: | reopened → open |
|---|
Changed October 13, 2011 01:27PM UTC by comment:8
| owner: | → timmywil |
|---|---|
| status: | open → assigned |
Changed October 13, 2011 01:43PM UTC by 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:
Changed October 13, 2011 01:51PM UTC by 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 comment:11
| resolution: | → duplicate |
|---|---|
| status: | assigned → closed |
Changed November 05, 2011 06:25PM UTC by comment:12
Duplicate of #9830.
Changed January 30, 2012 03:14PM UTC by comment:13
| milestone: | 1.8 |
|---|
Implicit values in 1.4.4+ don't work in IE9 either