Pure CSS approach:

@media (narrow) {
  .mf-section-0 {
    display: flex;
    flex-direction: column;
  }
  .mf-section-0 > * {
    order: 1;
  }
  .mf-section-0 > table.infobox + p {
    order: 0;
  }
}

A hybrid approach would add an mf-lead-paragraph class to the DOM to replace the complex selector above, or even provide a separate wrapper for the infobox and lead.

A CSS solution would be more consistent on wider devices, and also avoid the confusing reordering when loading the visual editor.

Can we actually apply this to the contenteditable surface? I would expect it to behave weirdly or crash outright when navigating with arrow keys, or inserting another node between these two elements.

arrow keys

Arrow keys on mobile? :) Seems like an edge case, but we should definitely test for potential weirdness.

Tested locally - it appears to be mostly sensible in cursoring between and selecting across paragraphs. Obviously you need to cursor up from the lede paragraph to get to the infobox, but given cursoring is an edge case on mobile I'm not too worried about that.

The bigger problem in VE is that we remove all the section wrappers, so we'd have to apply display:flex to the whole document which is quite a big CSS intervention. By default it breaks all floating (although scoped to mobile width, there shouldn't be any floating happening) and stretches tables (although this can probably be fixed?).

In T223116#5181840, @Esanders wrote:

Arrow keys on mobile? :) Seems like an edge case, but we should definitely test for potential weirdness.

I guess it's uncommon, but I'm not sure if it's an ignorable edge case, maybe it is… I was thinking of things like:

• https://ux.stackexchange.com/questions/99077/why-are-there-no-arrow-keys-on-most-mobile-on-screen-keyboards
• https://www.greenbot.com/article/3187838/gboard-update-brings-text-selection-mode-and-resizing-to-android-keyboard-app.html

Oh, to be clear, I've not tested anything I'm talking about here, so I might be wrong about everything.

A CSS solution would be great, but I remember we did consider this back in the early days and there were quite a few of edge cases that were considered deal breakers, browser support (its much better now though) and concerns around performance (potentially unfounded) .

This also reminds me MobileFrontend needs an ADR to help us keep track of why decisions get made. Possibly we can make one retroactively as part of this re-evaluation?

As for accessibility, keyboard shortcuts work with flex box, however can be a little jarring as the tab order doesn't reflect the visual order (I was wondering on another project I work on if this is actually a problem but didn't reach any conclusions > https://github.com/internetarchive/openlibrary/issues/1963 ).

Browser seems to be pretty good now, covering most of our support browsers: https://www.caniuse.com/#search=flex

Cursoring works fine, I'm sure it "breaks" tab order slightly, but that is a small price to pay.

there were quite a few of edge cases that were considered deal breakers

That might rule out the pure CSS solution, but the one where we and a class or two to the lead paragraph and/or infobox should be able to produce the same results.

T225936 has been fixed with a different approach, I don't think we're planning to work on this soon.