[value=0] selector causes "property-based jQuery.fn.attr('value') is deprecated"

[JorisDebonnet]

I have to admit I'm not entirely sure this is a bug, but it feels like one.

I have this in my code:

object.siblings("[name=taskid]:not([value=0])")

Reasoning: I want to select the input with name 'taskid', but only if its value is not 0. There are also other siblings that are not inputs, but I expect it to filter first on [name=taskid] and then on :not([value=0]. And even if I say [value=0], I'd expect jQuery to only test the value attribute if it's actually present.

jQuery Migrate throws the property-based jQuery.fn.attr('value') is deprecated warning because of those non-input siblings. Is it right in doing so? It was quite confusing at least: I needed quite some time to finally figure out it was that selector causing the warning.

Actually I suppose jQuery Migrate can't really help it, because it's jQuery making the call from within its selector engine. If you say I should report this in the jQuery bugtracker, I'll go over there instead! I just came here first because I don't get any warnings, errors or unexpected behavior when jQuery Migrate is not running (alongside jQuery 1.9).

[dmethvin]

Do you have an example of the markup? Are any of the siblings inputs or other elements that have both value properties and attributes?

[gibson042]

The warning should go away if you explicitly limit your selector to input elements: input[name='taskid']:not([value='0']). I've updated the warning messages documentation to comment on selector best practices in this case.

This isn't really a bug, though, in either jQuery proper or jquery-migrate—quite the opposite. jQuery 1.9 fixes a long-standing bug qua feature that had the value property standing in for the value attribute. In other words, changing the value of a form control changes which selectors it matches in jQuery<1.9, a situationally-sensitive inconsistency between Sizzle/jQuery and native querySelectorAll. We included a patch (and corresponding warning) in jquery-migrate because the behavior is so deep and so long-standing that we know developers are relying on the old (incorrect) behavior.

In your particular case, it's not clear if you intend to match by attribute (initial value) or property (instantaneous value). If the latter, you'll want to use code like object.siblings("input[name='taskid']").filter(function() { return this.value !== "0"; }) instead of a pure selector.

[JorisDebonnet]

Here's an example: http://jsfiddle.net/qWs3f/2/

But the difference between property and attribute is not really my point: the issue lies with the... non-inputs, that don't have a value attribute (or property). So 'the problem' is that a warning is generated when a selector filters by [value], while elements are present in the set that can't have this, such as <p>.

I realise it's silly to request a value for non-form elements, but my main point was that I received a warning for the .attr('value') command, while "all I was doing was use a selector" :)

By the way, I tried changing the selector into input[value=...], but that doesn't seem to make a difference (see http://jsfiddle.net/qWs3f/3/).

The warning messages documentation indeed covers that issue now, but it's just currently not very intuitive when one would first encounter that warning in a selector case.

[gibson042]

@JorisDebonnet, non-input elements can have value attributes and properties; there just aren't any built-in semantics for them. And it's meaningful (critical, in fact) to warn any time we return a value property that can potentially differ from the value attribute we should be returning.

I'll look into the warning not going away for input[value=…] now, though.

[gibson042]

• The bad: prefixing your selector with "input" doesn't help because .siblings sends a seed set to Sizzle, bypassing many optimizations that we would otherwise make
• The ugly: you are selecting by property instead of attribute, which will not work in jQuery 1.9 without the migrate plugin
• The good: the proper way to select by property is with a filter function, which works all the way back to jQuery 1.0 and will not throw any JQMIGRATE warnings: http://jsfiddle.net/qWs3f/4/