[juicy-tile-list]: Reordering elements does not reorder focus

[miyconst]

If input/select/a controls were reordered by priority property, then tabindex should also be applied.

It looks ugly when focus jumps from the bottom of a form to the top or to some other place.

@warpech, @tomalec any thoughts?

[tomalec]

Good point, is there a way to set it without digging into tile DOM?

[miyconst]

There is a tabindex html attribute, but it works for focusable elements only. http://www.w3schools.com/tags/att_global_tabindex.asp
So we have to set value for each input, select, a and other focusable elements, but I don't like this way. A juicy-tile may contain multiply inputs, even more, an input may be added after we set tabindex value.

Other way is to catch tab button on keydown event and navigate to the "next" element, which might be difficult to calculate, because each tile may contain several focusable elements or another juicy-tile-list with its own order of children elements.

And the third way which I like the most, is to actually reorder the DOM. I understand, that it causes a lot of other issues, but for tabulation this would be the best.

[warpech]

I think the easiest way (not fighting against the browser) would be to overwrite the value of the tabindex attribute for all elements where tabindex makes sense.

It would mean recursively walking the layout setup tree from top to bottom in index order and incrementing a variable, then applying value of that variable as tabindex.

[miyconst]

How to deal with the dynamic elements? Rerun entire code on each DOM change? Also there are some focusable elements outside of the editable part of layout?

[warpech]

Yeah, that would suck, especially when we switch the role of layout editor to become only a CSS generator :(

Then we may need to do it in JavaScript. First clear the value of the [tabindex] attribute on all elements, then select all input, select, a, [tabindex] and apply a value calculated by sorting them based on the actual top, left position.

We cannot move elements in DOM, because they might rely on a particular order in their scripts.

[miyconst]

Yes, looks like so. The question is how do we know when the DOM was changed and we have to re-apply tabindex value?

The MutationObserver comes to mind:
https://developer.mozilla.org/en/docs/Web/API/MutationObserver

But it may cause performance issues for big pages, not sure about that, need some testing.

[tomalec]

advise from Extreme Clean Solutions Departament: ;)
Maybe we should rise an issue in CSS Grid spec similar to flexbox one https://lists.w3.org/Archives/Public/www-style/2014Dec/0235.html, as CSS grid is so far in Chrome and it's not too mature, there is a change to get it into spec ;)

[warpech]

Nice idea to solve it on spec level! Unfortunately not a single response to this message in the mailing list :(

Also, from proposal to spec to implementation that would take at least a year even in the most agile conditions.

[warpech]

MutationObserver seems slow to me...

We could detect Tab press by window keydown event (useCapture), then call preventDefault() and move focus to next element in the display order. I cannot find a JS library to find a next element in display order, but maybe we can write that as a standalone lib.

[miyconst]

How to determine which element is the "Next"?

This example demostrates, that same visual layout may have different focus behaviour.
https://jsfiddle.net/p1c9azvo/2/

[warpech]

We would need to choose one but make it configurable per juicy-tile-list.

Left-to-right, then top-to-bottom (case 1 in think above) seems better for me, but both will fail in RTL writing systems. Correct way would be to have 4 options:

• LTR (row-wise)
• LTR (column-wise)
• RTL (row-wise)
• RTL (column-wise)

[miyconst]

We may choose whatever we like, but this will be a limitation for app designers. Lets say we have a long form of fields and the focus should go from top to bottom. Some of the fields in bottom may appear after user input.

Then, the app designer decides, that there are too many free space left, and wants to put this long form in two columns.

[tomalec]

There is a 'direction' property on every container/group already, and we could use it.
(rightDown, downRight,... - theoretically we have 8 directions of packing/alignment)

[warpech]

Yeah, I agree this should be the same direction.

juicy-tile-list creates this problem by moving stuff on screen, so it should be solved at the level where juicy-tile-list is inserted and loaded with the setup.

[tomalec]

Right now I would see solutions:

Proposed solutions

1. Hope, vote, shim for support of CSS Grid / flexbox display-order affecting tab-order.

   Pros:

   1. Cleanest solution possible

   Cons:

   1. Least likely to happen,
   2. There were votes to reject such behavior in flexbox already,
   3. Proposed flexbox solution was to use nav-index which may not get here soon (see below),
   4. CSS Grid spec and implementation seems stale.

2. Apply something like tabindex scope, or nav-index to every juicy-tile in Shadow DOM. So the order of navigation between tiles would be given by us together with visual order, and content distributed inside tiles would behave according to this order.

   Pros:

   1. Veeery clean solution

   Cons:

   1. nav-index support in browsers,
   2. nav-index support in spec - was already removed, and it's hard to track the progress of re-implementation,
   3. nav-index support for Shadow DOM in browsers,
   4. nav-index support for Shadow DOM in spec may not fit our needs,
   5. nav-index support for Shadow DOM in spec will probably get removed as well([Shadow]: inappropriate reference to CSS3-UI nav-index spec in focus navigation order (bugzilla: 28079) WICG/webcomponents#88),

3. Rearrange tiles in Shadow DOM (in DOM tree itself, not via attribute, nor style)

   Pros:

   1. At least it breaks DOM order, structure only in Shadow, not in light DOM

   Cons:

   1. Performance overhead of moving stuff around DOM,
   2. Mutation observers, attachedCallback'a hell,
   3. Cannot be done by CSS only - Separate to different responsibility layers to improve performance juicy-tile-list#28,
   4. Order of Shadow DOM insertion points (<content> tags) may not affect tab order at composed tree ([Shadow]: Focus navigation in distributed content WICG/webcomponents#103, https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415), and nav-index may not help (see above)

4. Apply tabscope/tabindex-scope/nav-index attribute to tiles in Light DOM

   Pros:

   1. At least it does not break light DOM structure

   Cons:

   1. Those features are not yet in spec,..
   2. and not likely to get there soon, if at all,
   3. It overwrites tabscope applied in Light DOM by the user,
   4. Cannot be done by CSS only - Separate to different responsibility layers to improve performance juicy-tile-list#28,

5. Abandon entire juicy-tile-list (-grid, -flexbox) beauty, and rearrange tiles in Light DOM

   Pros:

   1. Will work for sure

   Cons:

   1. Even bigger, performance overhead of moving stuff around DOM,
   2. Even and deeper mutation observers, attachedCallback'a hell,
   3. Cannot be done by CSS only - Separate to different responsibility layers to improve performance juicy-tile-list#28.

External reading

Related flexbox discussions:

• https://bugzilla.mozilla.org/show_bug.cgi?id=812687
• https://readable-email.org/list/www-style/topic/flexbox-tab-index-recommendation
• https://lists.w3.org/Archives/Public/www-style/2012Jul/0109.html
• https://wiki.csswg.org/spec/css3-flexbox/accessibility?s[]=nav&s[]=index

Tab/nav-index/tabscope related issue in SD spec:

• [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation (bugzilla: 27965) WICG/webcomponents#86
• [Shadow]: inappropriate reference to CSS3-UI nav-index spec in focus navigation order (bugzilla: 28079) WICG/webcomponents#88
• [Shadow]: Focus navigation in distributed content WICG/webcomponents#103
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415

Nav-index:

• https://wiki.csswg.org/ideas/nav-index
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=23960

[tomalec]

Bad news, for 3.iv : https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415 3. seems non-doable as well

BTW, maybe we can move that issue to the <juicy-tile-list> repo?

[warpech]

Sure, can you move it? Manually or with the tool https://github.com/google/github-issue-mover

[tomalec]

This issue was moved to Juicy/juicy-tile-list#32