Fix/clarification for tabindex section

[patrickhlauke]

• corrects what is presumably an accidental omission/typo (non-interactive elements forced into being focusable do not fire click as result of, say, ENTER key)

[edit] removed second commit, split out to separate PR

[patrickhlauke]

/cc @stevefaulkner

[chaals]

LGTM - and tested in FF/Yandex to be stupidly sure

[patrickhlauke]

Note that apparently the omission of "not" is not a typo/oversight, but intentional (though the behavior is not actually implemented in user agents it seems) whatwg/html#1952 (comment) - worth holding off on merging this until some clarification?

[chaals]

I suggest that since removing "not" reflects reality, we do this, open an issue for the desirable behaviour and note that in the spec...

[patrickhlauke]

@chaals one issue i see here as well is that, at least according to the thread in whatwg, the preceding sentence supposedly already says that it will fire click

An element that has its tabindex focus flag set but does not otherwise have an activation behavior defined has an activation behavior that does nothing.

Now I admit that my own reading of this seemed to suggest that, basically, that sentence does mean that click isn't fired...maybe i'm just not reading it right?

[patrickhlauke]

i.e. does "an activation behavior that does nothing" mean that nothing happens if i press enter, or does it mean that click IS fired but no other default action happens in the browser? (i guess i should explicitly ask again over in the whatwg thread for this)

[travisleithead]

I think we may instead want to put an at-risk flag around the Activation section which indicates the spec-fiction that when activated, and element will dispatch a click event. Then we can track it later for CR-entry and pull it/change it, if implementations haven't caught up..

[patrickhlauke]

@travisleithead as this is going a bit beyond my intended "here's a quick change that surely was a typo" level of complexity, mind if this gets assigned to somebody with a tad more spec experience? (I have no idea about at-risk flags etc)

[patrickhlauke]

I'll split out the non-controversial commit as a separate PR

[chaals]

@patrickhlauke as noted the text suggests that the click will be fired, but will result in nothing happening. Which isn't how reality works, so we should change the text until it says what happens - ;(

[chaals]

@travisleithead I'm not sure there is a lot of controversy here. Changing browsers to start firing an extra event on fairly common things seems really risky, so much as I wish (and wished for the last couple of decades) they had already done what the spec asked, I doubt I would wish for that now.

So I am more inclined to just axe the spec-fiction and start thinking about smart ways to solve the problem that will work.

[travisleithead]

This PR has diverged from its original intent. The forked PR was accepted. I filed #653 to track another fix. Closing this to keep the noise down.