List (in type=grid mode) supports navigable elements inside of cells. Historically the elements were required to be marked with the navindex attribute, rather than using the standard tabindex.
This has proven too brittle due to complications when the cell content is not part of the Renderer subclass template but instead comes from somewhere dynamic, like an XHR request. Also, relatedly, complications when cell content is dynamically changed (added, removed, hidden, or shown).
This change is to:
Replace the navindex attribute on contained elements with the standard tabindex, or implied tabindex in elements like <button>, <input>, etc.
Remove Renderer#updateFocusableChildren(), in addition to getFirst(), getLast(), getNext(), getPrev().
Handle keystrokes like tab programmatically, at the time of the keystroke.
Change tabbing behavior when grid navigation is disabled (previously called "actionable mode") to loop around the focusable elements in a single cell, rather than the entire table. Note that https://www.w3.org/TR/wai-aria-practices/#gridNav_focus lists a few options for tab handling, and this is one of them.
Regarding performance, there is a tradeoff. This should increase performance at page load (i.e. when the table is created), in exchange for adding code for handling keystrokes. I think it's a win.
This should also address #608, and maybe #329, #500, and #678.
List (in
type=gridmode) supports navigable elements inside of cells. Historically the elements were required to be marked with thenavindexattribute, rather than using the standardtabindex.This has proven too brittle due to complications when the cell content is not part of the
Renderersubclass template but instead comes from somewhere dynamic, like an XHR request. Also, relatedly, complications when cell content is dynamically changed (added, removed, hidden, or shown).This change is to:
navindexattribute on contained elements with the standardtabindex, or impliedtabindexin elements like<button>,<input>, etc.Renderer#updateFocusableChildren(), in addition togetFirst(),getLast(),getNext(),getPrev().tabprogrammatically, at the time of the keystroke.Regarding performance, there is a tradeoff. This should increase performance at page load (i.e. when the table is created), in exchange for adding code for handling keystrokes. I think it's a win.
This should also address #608, and maybe #329, #500, and #678.