Could we use CSS ordering to re-order the lead paragraph? If not, what would the modern way be for hoisting the lead paragraph?

In T359002#9827020, @Jdlrobson wrote:

Could we use CSS ordering to re-order the lead paragraph? If not, what would the modern way be for hoisting the lead paragraph?

CSS order applies only inside a flex container (or a grid). I don't think it makes sense to make .mw-parser-output a flex container (and definitely not a grid), and even if you did you would have to guarantee that .infobox would appear as one of its direct children (which is a hard guarantee to make, but not impossible - the current transforms do some work to handle that). Users don't have the power to make this ordering either (TemplateStyles cannot target .mw-parser-output though I did file T271588: Add .mw-parser-output as a potential selector at one point, which has some other thoughts on what might happen with .mw-parser-output as flex container), so you would in perpetuity be carrying along this bit of technical debt (though in CSS rather than in the current transform). And you would have opened up a fun new CSS vandalism vector.

So then the next bit of thinking about it is with Parsoid's <section>ing, the lead section could be made a flex container I guess without too much pain. You still open the CSS vandalism vector this way, but it exists regardless due to TemplateStyles being able to touch the sections. Floating boxes lose their floatiness when they're a flex child, which is probably fine at the relevant resolutions to this problem, since this would just be in a media (possibly container) width query. And either way in this context you can even drop your own support for the flip-flop eventually since we can target the sections (and even the specific lead section I think?) in TemplateStyles.

Then you still have a problem, there are accessibility implications to a CSS reorder (which incidentally have led me to "when do I even use the property ever?!"). I do think in this context those are relevant questions. Someone screen readering on their phone is going to jump down to the infobox, up to the first paragraph, then jump to the second paragraph, which is not a great reading flow.

Other comments for other solution: A more holistic solution to the problem, like making infoboxes their own revision slot. (In any other software system, making the infobox not inline with the content would be the solution, that's just not one you have available today.) That would enable other uses like pulling it out of the page text entirely for wide screens (a la the Winter prototype). You might still need some transformations to get it to be friendly with the primary page content but you would have the full support of logic in the skin to do it. (Not sure if that's a plus or minus.)

But that's a lot more work in a lot more ways than just leaving a sleeping dog to lie.... I can't see another "modern" way which isn't what you've already got.

(I swear I've made some version of this comment already somewhere.)

Thank you!

Change #1038922 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[integration/visualdiff@master] Couple tweaks to the MFE config

https://gerrit.wikimedia.org/r/1038922

Change #1038922 merged by jenkins-bot:

[integration/visualdiff@master] Couple tweaks to the MFE config

https://gerrit.wikimedia.org/r/1038922

Addressing this issue is high-ish priority for CTT because we find that inconsistent treatment of the lead paragraph between legacy and Parsoid tends to have knock-on effects with positioning that then throw off visualdiff results all the way down the page. So basically we find it hard to discover any /other/ issues with the MFE+Parsoid rendering because the noise from the lead section drowns out everything else.

The patch by @ssastry's ( https://gerrit.wikimedia.org/r/1038922 ) tries to recreate the lead paragraph stuff within the visualdiff framework just to get our output closer together and minimize noise, but it doesn't really work well enough for us to proceed with visualdiff testing past that point. A better solution that ensured legacy and Parsoid matched would be very helpful to us.

Web team still needs to work out how to do this - there have been calls to change how this is implemented in T262093, and we want to reduce the amount of expensive HTML parsing we do on page views, so we think it is important to evaluate options as part of T366391 first, before committing to a solution.

For what it's worth, the new OutputTransform pipeline will (hopefully) maintain the document in DOM form throughout the transformation pipeline, eliminating the repeated HTML parsing steps. That's T347062: Create ContentHolder interface.

meeting notes: we estimated this as a 3 because although the CSS implementation seems straight forward, the usage of the * selector almost always has unintended consequences and the moving the content in CSS like this can have implications for a11y (e.g. tab order).

Bringing T277465: Apps: Hatnotes appear below paragraphs on many wikis to your attention, which illustrates one of the "gotchas" of lead paragraph hoisting to consider.

In T359002#10035618, @cscott wrote:

Bringing T277465: Apps: Hatnotes appear below paragraphs on many wikis to your attention, which illustrates one of the "gotchas" of lead paragraph hoisting to consider.

Yep we're aware of this. We have a plan and we'll cover this in a follow up ticket.

We are currently working on a hypothesis that will likely conclude that we should focus on getting section collapsing by default pixel perfect, given this is a blocker for Wikivoyage and this ticket is not.

The lead paragraph hoisting issues on Parsoid have been resolved without doing this task (see parent task). Should anything still be done, or should this be closed?