Skip to main content

Bug Tracker

Side navigation

#13914 closed bug (notabug)

Opened May 20, 2013 07:54PM UTC

Closed May 24, 2013 05:11AM UTC

Last modified May 24, 2013 09:38AM UTC

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

Reported by: alexander.farkas@aperto.de Owned by:
Priority: blocker Milestone: 1.10
Component: attributes Version: 1.9.1
Keywords: Cc: timmywil, orkel
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (7)

Changed May 21, 2013 08:01AM UTC by m_gol comment:1

cc: → timmywil
component: unfiledattributes
priority: undecidedhigh

timmywil, will you look into it?

Changed May 23, 2013 07:19PM UTC by dmethvin comment:2

milestone: None1.10
priority: highblocker
status: newopen

Changed May 24, 2013 01:40AM UTC by dmethvin comment:3

cc: timmywiltimmywil, orkel

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

Changed May 24, 2013 05:11AM UTC by markelog comment:4

resolution: → notabug
status: openclosed

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.

Changed May 24, 2013 07:31AM UTC by anonymous comment:5

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

Changed May 24, 2013 08:17AM UTC by markelog comment:6

_comment0: 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/ 1369383614122680

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/

Changed May 24, 2013 09:38AM UTC by anonymous comment:7

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