[bugsliker]

- tabindex=0 doesn’t affect ordering, does it?

- why do you need to listen for events at the document level?

not that i disagree with the article, but some arguments didn’t seem right.

[thyristan]

> - tabindex=0 doesn’t affect ordering, does it?

Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.

[pverheggen]

That's the same behavior as a <button> without tabindex, like the author is proposing.

It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.

[bugsliker]

I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this.

See this fiddle https://jsfiddle.net/483uqjnp/

(again, I do not condone building your own <button>, just pointing this out)

[brandonhorst]

This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[minitech]

tabindex=0 does sort naturally into the automatic tabindex order.

> So you are jumping through all the other tabindex elements

This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0.

Try it:

  data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>

[cferdinandi]

Hey, it's me, the original author!

The issue isn't with tabindex=0 specifically, but fucking with tabindex in general. People go down that path, and start putting that shit on everything, like it's Frank's Red Hot.

And in my experience, the same folks who use div's instead of button's are the ones who don't know better and start throwing tabindex around.

"why do you need to listen for events at the document level?"

Not events generally, keydown events specifically, which do not fire on child elements of the document.

[pverheggen]

Not sure about that, MDN's example shows keydown being attached to an element.

https://developer.mozilla.org/en-US/docs/Web/API/Element/key...

[kyle-rb]

Hi, good premise overall, but there are just a lot of little things that are off.

- It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>.

- Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused.

- "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option.

- Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway.

- The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.

[susam]

> Not events generally, keydown events specifically, which do not fire on child elements of the document.

Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected.

https://susam.net/quickqwerty.html

https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty....

Nice article, by the way!