Apply block order by Flexbox order property

[aduth]

Fixes #544

This pull request seeks to implement an unfortunate but surprisingly reasonable hack to resolve iframe flickering of embed blocks using Flexbox's order property instead of natural DOM ordering. The default behavior of moving an iframe in a DOM results in the iframe being reloaded. The effect here is to never rearrange the DOM position but instead affect ordering through the order styling. From a user's perspective, there should be no difference.

See also:

• Iframe's reinitialise when moving down within a group of components facebook/react#858
• http://stackoverflow.com/a/8318401

Minimal proof-of-concept:

• Before: https://codepen.io/aduth/pen/QvpxwL
• After: https://codepen.io/aduth/pen/eWvKeW

Testing instructions:

Repeat steps to reproduce from #544, verifying that neither moving the embed up nor down results in a flickering reload of the iframe.

[ellatrix]

Works great! Really cool ✨

[youknowriad]

blockOrder is not being use in this component, shoud we move it the the connect of the VisualEditorBlock component?

[aduth]

blockOrder is not being use in this component, shoud we move it the the connect of the VisualEditorBlock component?

Yep! And in fact, the order prop is already specified in block.js's connect, so just need to remove this. See f86de14.

[jasmussen]

This is mindblowing. 💥

[aduth]

So there appears to be some accessibility implications on this, since tabbing will not respect order but instead the element occurrence in the DOM. My first thought was to provide a specific tabIndex correlating to the block's order as defined in editor state (see 290314c), but there are two issues here:

• Previously we used tabIndex="0" to define the block as focusable but leave it to the browser to determine order based on element position. Now that we're providing positive, non-zero numbers, we may be impacting focus order of other elements on the page (sidebar, admin bar, etc). This seems undesirable, or at least hard to manage.
• Tab behavior doesn't seem to always respect tabIndex if there's a focusable element as a descendent of the next element in the DOM.

To illustrate the second point, try the following steps:

• Move the last embed block up
• Select the text block before the embed block (starting "By shipping early")
• Press tab

Expected: Focus moved to embed block
Actual: Focus moved to list block

It's not clear to me why this is; I'm wondering if TinyMCE is hijacking the focus change. In my minimal proof of concept, it seems like tabbing should respect tabindex regardless of whether there are focusable elements in the element between.

[jasmussen]

So there appears to be some accessibility implications on this

Forgive me for asking what I know will sound somewhat silly; what if as soon as you press tab, after having rearranged boxes with the arrows, we actually reorder the markup and allow the repaint to happen? This is based on the assumption that people won't necessarily be tabbing around that often, and when they do a single repaint in the edgecases where necessary will be an okay tradeoff.

[aduth]

I don't know for certain that we have access to control the tabindex behavior on the fly like this, since it sounds like we'd need to intercept the tab key event, rearrange the DOM, then allow the key event to proceed with its default behavior.

[aduth]

Closing in response to accessibility concerns outlined at #544 (comment).

[jasmussen]

Thanks for trying.