@Nirzar, what treatment do you think this should be given?

Personally I would lean towards 1) or 3) (with a preference for 1 since 3 counters are attempts to drive HTML size down) and 4 on the longterm. Thoughts?

My exact thoughts. I dont exactly know the drawbacks of three so i would prefer it over one. but if @Jdlrobson
thinks 3 is going a step back in performance then lets go with 1.

on four
While working on the Native iPad layout sometime back i was thinking about using the real estate on desktop for persistent TOC which is sticky on desktop. you can jump through parts of articles on right and read on left.

Rough mock

we can solve this flashy problem with a structured chrome like that.
being said that, it sounds like a big change and more thought.

we can even try keeping that div sticky on right side and keeping some padding maybe. it could be a totally a css hack :)

Presently, infoboxes render at the right side on tablet/desktop Minerva. Therefore, I think collapsing it is the sensible thing to do, as opposed to the rather awesome looking persistent TOC. @Nirzar would you be able to spare some time to furnish a layout for the collapsed TOC that also takes into account the page action bar introduced for language switching?

I suppose in the case there is only one section following the TOC it's okay to reserve the space to avoid reflow on tablet/desktop, yet just not show the TOC.

I think we're working from the presumption the collapsed box would always fit on one line. It's unclear to me this is always the case, although it's highly likely given the screen dimensions of eligible device widths fitting the mod - perhaps a review of the QQQ by the engineer who implements this would be helpful anyway.

Looking at articles like the current POTUS where the non-expanded TOC would mean a bigger gap in textual article content (the user would be panning down past the infobox to get to the main content). I don't know that there's a simple way to deal with this. But, for non-gigantic infoboxes, I don't know if this is all that big of a deal. I just wanted to note as much.

@Jdlrobson yeah let me give it more thought. specifically the stub articles fallback for something like this. but it will improve reading experience of mobilefrontend on desktop 10 folds.

In the recent user research we did for the apps, a persistent TOC drawer (a way to get around the article) had really positive feedback.

Change 279562 had a related patch set uploaded (by Jdlrobson):
WIP: Avoid repaints for table of contents.

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

Uploading the "TOC flash on desktop using minerva" video so that I can link it in the patch:

The above patch fixes the FOUC on mobile, but not on desktop. Should we keep the task open until the issue is fixed on desktop minerva?

Desktop Minerva is not a thing (officially). The issue with desktop is tracked in https://phabricator.wikimedia.org/T130632

Strange, the title of this very task is about desktop.

Change 279562 merged by jenkins-bot:
Avoid repaints for table of contents.

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

Moving back to To Do as, per @bmansurov, the FOUC isn't fixed in $width > 1000px – is that what y'all are talking about when you say "desktop"?

In T126836#2202665, @phuedx wrote:

Moving back to To Do as, per @bmansurov, the FOUC isn't fixed in $width > 1000px – is that what y'all are talking about when you say "desktop"?

That's a good catch. I was talking about ?useskin=minerva without toggling the mobile mode.

I stand corrected (but remain confused/horrified…)

We talked about this after standup and we agreed that this is as done as necessary.
We may want to talk about mobile/desktop Minerva/Vector during the offsite around a campfire with flashlights underneath our chins.

On http://en.m.wikipedia.beta.wmflabs.org/wiki/Headings note how close the toc is to the first heading:

The margin-bottom on .client-js .toc-mobile has been removed. It shouldn't have been.

Change 283256 had a related patch set uploaded (by Bmansurov):
Restore margin bottom for ToC

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

Change 283256 merged by jenkins-bot:
Restore margin bottom for ToC

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

@Nirzar can you sign off from the design perspective? http://en.m.wikipedia.beta.wmflabs.org/wiki/Barack_Obama
Looks good to me.

Empty table of contents appear on small stub pages :(
http://en.m.wikipedia.beta.wmflabs.org/wiki/Related_test?mobileaction=stable

Change 283575 had a related patch set uploaded (by Bmansurov):
Insert ToC placeholder only when MinervaTOC output page property is true

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

@bmansurov Lot's of tests broken ^

I've reverted the original patch to allow us more time to look at this given the issues we've hit with it.
https://gerrit.wikimedia.org/r/283634

Change 283645 had a related patch set uploaded (by Phuedx):
Avoid repaints for table of contents

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

Change 283575 abandoned by Bmansurov:
Insert ToC placeholder only when MinervaTOC output page property is true

Reason:
The original patch has been reverted. https://gerrit.wikimedia.org/r/#/c/283634/

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

283575 fails to build and there's a couple of inline questions from @bmansurov.

Comments dealt with, 283645 Jenkins now green.

Change 283645 had a related patch set uploaded (by Jdlrobson):
Avoid repaints for table of contents

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

With 283645 checked out I see the following:

Edit

✔ There's not a FOUC
✖ There's a lot of whitespace at the , rather than a visual indication that the TOC is there but momentarily disabled

In T126836#2217473, @phuedx wrote:

✖ There's a lot of whitespace at the , rather than a visual indication that the TOC is there but momentarily disabled

To be clear, I think that this is a great improvement. However, I do think that @Nirzar should take a separate design pass at a page on a slow connection and see if he has any thoughts on the matter.

Change 283645 merged by jenkins-bot:
Avoid repaints for table of contents

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

In all of the following, I used Google Chrome's network throttling facility to emulate a "regular 3G" connection. The details of the connection are mostly irrelevant, only that it introduced a significant delay in the loading of the mobile.toc module thereby exasperating the issue.

Desktop width (viewing an imported version of 2024 Summer Olympics page)

Emulated iPhone 6

Emulated iPad

Emulated iPad with lead section

Similar testing was done during the review of 283645, including with real devices, but the above were recorded while running MobileFrontend at ed6b92a.

Adding to Reading-Web-Sprint-72-Ninety-nine-problems-but-Nirzar-aint-one so that we remember to verify this in production.

At the same time, the section headings are styled: they get a chevron on the left and an edit pencil on the right. Again, I suspect this could cause long section headings to reflow.

There's no reflow in long section headings in mobile, tablet, or desktop sizes. If the Resource Loader supports the UA, then containing elements for the chevron and the edit pencil are visible while the assets are loading/the modules are initialised.