timmywil, will you look into it?

@orkel, thoughts? I'm trying to determine whether this should be backed out before we ship 1.10.0.

Because it's happens often, i assume there is confusion in understanding what is IDL attribute and what is HTML (content) attribute.

$.fn.prop returns value for IDL attribute (element property), which for "tabindex", according to spec:

Its default value is 0 for elements that are focusable and −1 for elements that are not focusable.

Therefore "undefined/null" value should never be returned by $.fn.prop, but value "undefined" should be (and it is) returned by $.fn.attr if HTML (content) attribute "tabindex" is not set – http://jsfiddle.net/KGspu/

I allow myself to close this ticket if someone is disagree - feel free to reopen it.

@orkel

I'm not confused about IDL attributes and you guys should know that. So no problem here. And again, I please you to read the spec more carefully.

I provided the WAI-ARIA table about the behavior of the tabindex above. Please only look at the two first colums (Tabindex Attribute and Focusable with mouse or JavaScript via element.focus())

This table says:

1. no tabindex attribute present -> default behavior ($.attr should return undefined and $.prop should return either 0 or undefined according to the default behavior of the element)

2. tabindex=0 -> focusable ($.attr and $.prop should return 0)

3. tabindex=1-32768 -> focusable

4. tabindex="-1" -> focusable ($.prop should return -1)

As you can see a tabindex with a negative value (especially "-1") is treated as **always** focusable by the spec. Your change in jQuery assumes the opposite. You also have quoted a spec without giving any reference. I already quoted the spec and provided a reference.

Again, there is a difference between the focusability of the following two different div elements:

<div tabindex="-1">I'm focusable[ by script]</div>

<div>You can't focus me</div>

jQuery always returned the right computed values here (-1 in first case and undefined in the second case) and now you want to change that, why?

Before, jQuery followed HTML4 specification which defined only handful of HTML-elements that support "tabindex" property, but HTML5 is redefined that.

$.fn.prop returns "-1" for most of elements with omitted "tabindex" property, but it does not mean those elements can receive focus.

You should not make the connection between "tabindex" IDL attribute and whether or not element can receive focus.

Reference is the same that provided by you – http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#dom-tabindex;

Once again - $.fn.prop returns property of the element, which is -1 for unfocusable elements just like it said in spec – http://jsfiddle.net/gf7ha/

@orkel

Ok, I see. You are right. Problem is only old jQuery behavior is much better to develope against. Now we have to make a doubble check using prop and attr.

Old:

$.prop(this, 'tabIndex') == null

New:

$.attr(this, 'tabindex') == null && $.prop(this, 'tabIndex') == -1

That is said, but we have a similiar problem with src/href in case we want the full path, but only in case it is defined. Assume the following markup:

<a href=""></a>

give me the full path, if href is defined and non-empty

var path = $.attr(this, 'href') && $.prop(this, 'href')