revert change from #13752 - tabIndex propHook's default value for non-focusable elements should be -1

[[email protected]…]

I'm a WAI-ARIA developer and this change removes important informations for us a11y aware developers. Already the description is of the "fixed" issue shows, that here is something strange.

It says: An element, which is not focusable should return a tabindex of -1.

Well the spec about tabindex says the following (see: ​http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#sequential-focus-navigation-and-the-tabindex-attribute): If the value is a negative integer:

• The user agent must set the element's tabindex focus flag

Which means if the element has a negative value it is indeed focusable. Quite the opposite of your change!!! For us WAI-ARIA developers the, difference, between focusable, tabbable and not-focusable is quite important and jQuery's prop method returned the right values for HTML4 elements. Please see here: ​http://www.w3.org/TR/wai-aria-practices/#focus_tabindex

So it's quite easy:

If $.prop returns

• a value, which is 0 or higher, the element is focusable and has tab navigation
• a value, which is smaller as 0, the element is just focusable
• a value which is undefined/null, the element is neither focusable nor tabbable.

The current change removes those important informations.

[m_gol]

timmywil, will you look into it?

[dmethvin]

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

[markelog]

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.

[anonymous]

@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?

[markelog]

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 recive 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/

[anonymous]

@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')