- After the page is visible for about 2.5 seconds, something happens that makes the first paragraph under "Candidature process" wrap differently: the text "2015" goes from being on the same line as "September 16" to being on the next line.
- Half half a second later, the watch star is rendered (which would probably cause the page title to reflow if it was very long -- didn't test that) and the placeholder in the search bar appears (see also T126825: Sections on mobile views jumps around after load (FOUC)). 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.
- Shortly after that, the TOC appears and pushes everything down
|mediawiki/extensions/MobileFrontend : master||Avoid repaints for table of contents|
|mediawiki/extensions/MobileFrontend : master||Insert ToC placeholder only when `MinervaTOC` output page property is `true`|
|mediawiki/extensions/MobileFrontend : master||Avoid repaints for table of contents.|
|mediawiki/extensions/MobileFrontend : master||Restore margin bottom for ToC|
|Resolved||TheDJ||T126877 Collapsible table breaks anchor linking|
|Resolved||phuedx||T126836 TOC causes flash of unstyled content when viewing MobileFrontend page on desktop|
- Mentioned In
- T133303: Verify table of contents fix in production
T126877: Collapsible table breaks anchor linking
- Mentioned Here
- T133302: Improve intermediate loading state for table of contents
T133303: Verify table of contents fix in production
rEMFRed6b92a49a84: Localisation updates from https://translatewiki.net.
T126825: Sections on mobile views jumps around after load (FOUC)
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.
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.
we can solve this flashy problem with a structured chrome like that.
being said that, it sounds like a big change and more thought.
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.
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.
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 with lead section
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.