[2.0] No ticket: Simplification of tabindex hook

[markelog]

/cc @timmywil

[timmywil]

I wonder if we even need the propHook. The concept is right, but 2.0 browsers might have this covered.

[timmywil]

And technically, for the property, we should return -1 for unfocusable elements. We never really translated the attrHook to a propHook accurately, mostly for back-compat reasons. I think we can ditch that for both 1.x and 2.x.

[timmywil]

To be clear, -1 is the correct value for unfocusable and unset elements. Otherwise, we just return whatever was set, even if unfocusable. Therefore, I think we need a pull for 1.x and we should try removing the propHook completely for 2.0.

[markelog]

HTML5 spec "suggest" handful of elements that should have tabindex flag, but as long as i can tell none of the browsers exactly followed this suggestion. Say, tabindex input[type="hidden"] or a:not([href]) will give us 0, when it should be -1, this hook covers second case but not the first, and IE9/10 on unfocusable elements give tabindex property a 0.

There is still some browsers inconsistencies, are you sure you want to remove it, but not, say, add support for input[type="hidden"]?

[timmywil]

The suggestion you are referring to means that even if an element has negative tabIndex, browsers may still allow the element to be tabbable for keyboard-only situations. Unfortunately, you're right about IE. They do return 0 for unfocusable elements, so we should normalize that.

[markelog]

I meant paragraph

If the attribute is omitted or parsing the value returns an error

which for my understanding, means that for input[type="hidden"]-element, value of tabindex, if attribute is not there, should be -1, did i misinterpreted something?

[timmywil]

No, it should be -1. I just meant negative tabIndex doesn't necessary mean the browser won't allow focus in some situations, but that's not our concern.

[scottgonzalez]

I doubt anyone will come here and read your comment as a definitive source, but just to clarify: a tabindex of -1 doesn't prevent focus, it just indicates that the element shouldn't be part of the sequential focus navigation. Setting tabindex to -1 can indicate that an element which is not normally focusable should become focusable (UI's :focusable selector), but not be part of the sequential focus navigation (UI's :tabbable selector).

[timmywil]

@scottgonzalez: I think you're talking about the content attribute. The default value of the IDL for non-focusable elements is -1. However, what I was saying was that even negative values don't necessarily mean the element is not tabbable "if the user's only mechanism for moving the focus is sequential focus navigation."

Nevertheless, the issue at hand is that IE9 has a value of 0 for elements that are not focusable. I propose we return -1 for elements that do not have a tabIndex attribute and are not focusable, rather than undefined.

[scottgonzalez]

@timmywil Right, I know what you were saying. I just wanted to clarify for anyone following along because you used somewhat vague wording of "won't allow focus". I know you were talking about navigation, not explicit focus, but others may not have known.