Page MenuHomePhabricator

Floating ToC "shunts" article text away at large zoom levels
Closed, ResolvedPublicBUG REPORT


List of steps to reproduce (step by step, including full links if applicable):

What happens?:

  • Until a certain limit is reached (where the ToC disappears altogether), the ToC dominates most of the screen making the main text pushed off to the right

What should have happened instead?:

  • The floating ToC should be more "accommodating" to high zoom levels. It should likely not zoom as much, hide itself sooner, or be able to be disabled altogether as this behavior is inconvenient for some.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:

  • This is in response to a note brought up on #wikipedia on IRC; the user in question specifically wished for a method of disabling the floating ToC, which doesn't seem currently possible. The portion of interest is as follows, posted here with their permission. (Note the ticket that I linked is incorrect and is for the sticky header, not the floating ToC)
[11:31:47] <peirik> I would like to register a complaint about the new Vector skin: the new, floating, left-aligned table of content panel is ruining my otherwise delicious Wikipedia experience. Please revert this change at your earliest convenience. That is all. Thank you.
[11:34:50] <perryprog> peirik, that'd be due to I had personally assumed there was an option to disable it but I don't see one anywhere...
[11:43:18] <peirik> perryprog: Hm, I dont know. I should say I dont mind the sticky header at all. My feud is with the table of contents panel - which is forcing the rest of the (previously centered) page content to the right when a certain zoom level is applied (which I need because my eyes are old and shitty).
[11:43:40] <perryprog> Oh that's not good :/
[11:45:28] <perryprog> yeah, I see that same issue.
[11:46:52] <peirik> One would think some simple responsive CSS rules could fix it quite easily though :/

image.png (1×2 px, 1 MB)

Note: Related and possibly duplicated by T306660 and T306904.

Event Timeline

peirik mentioned on IRC that this does look good, as do I agree. Eventually we'll have a longer-term solution from T306660 but the new 1000 px threshold does seem sufficient to close this issue for now. (Leaving open in case QA needs to do something first?)

Looks good in production, resolving

Screen Shot 2022-05-11 at 10.00.29 AM.png (1×955 px, 504 KB)