Option 1: "Inline after the lead section" has some advantages.

1. It resembles the previous state and allows the menu to go back to its previous narrower form (now that it doesn't have to match widths with the ToC which needs to be wider). This will probably leave people that like narrow windows largely unaffected.
2. Yes, in that case, there's no floating ToC any more, but then if the window is that narrow, there's no room for one anyway.

Option 2: "Floating button with sidebar" - how accessible is this for people who say only use the keyboard for navigation? For narrow windows, which we're trying to address here, it creates a bit of a modality, where they're either in "TOC mode" or "reading mode" because you can't do both. Is this desirable?

In T306660#7878519, @alexhollender_WMF wrote:

@AlexisJazz collapsed sections is an option. can you expand on why you like it?

Chances are this is like the "invert mouse/joystick/controller stick" option in many games. For some people it's one way, for others it's the other. I started a straw poll on enwiki.

As for what I like about it: it's the only option that is somewhat useful. I simply barely use the TOC.

• If my screen is small an inline TOC just means more crap to scroll past, so option 1 is a bust.
• If my screen is small there's no room for a sidebar so option 2 is a bust. Also not a big fan of elements with a <s>fixed</s> sticky position. Fixed can be annoying to, but sticky AAAAARGH.
• Which leaves option 3. It doesn't scroll when you expand a section, so there's no disorientation. And the scrollbar is much smaller. But you do need a collapse/expand all button.

@AlexisJazz thanks for that comment. Also thanks for starting the straw poll — curious what people think.

@TheDJ if you have a moment could you add some thoughts here. Particularly curious about why you make your screen narrow, and whether or not the table of contents is useful to you when your screen is narrow.

I'm a bit confused as to why the ToC/sidebar has suddenly become so large. The size used in the prototypes seems much more natural on my screen (like https://en-toc.wmcloud.org/wiki/Moon). Now the content of the page is aligned at the right side of the screen, while the sidebar/ToC uses a lot of space on the left, also due to imo unnecessarily large margins. I am aware that the overall design will be improved at the end, but the proportions right now don't seem to make sense to me. And if I make my browser window smaller (which happens automatically whenever I use the browser tools to look at the HTML), in my eyes it is very weird that only the page content but not the sidebar becomes narrow. Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

In T306660#7881178, @XanonymusX wrote:

I'm a bit confused as to why the ToC/sidebar has suddenly become so large.

Can you please include a screenshot, as well as noting whether or not your browser window is zoomed in at all? What you see in production should match the prototype...

Well, the width of the sidebar is given in rem, as far as I can see, so there must have been a change in that (I compare with the previous state, as I had been testing the new ToC for a while already). I do not use any zoom for my browser window. The random example is from https://de.wikipedia.org/wiki/Kalifornischer_Wacholder.

Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

This is the big flaw with media queries and why many people have been pushing for container queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

In T306660#7881292, @Jdlrobson wrote:

Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

This is the big flaw with media queries and why many people have been pushing for container queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

Or find a reasonable good enough for everyone, which is actually what the en.wp main page does. Most styles are like that on en at least.

Container queries will be nice but will only help a limited subset since a) css-sanitizer isn't really maintained actively, and b) it implements new properties and values more to what is fully standardized and less to what browsers support, and c) we still have to care about older browsers.

hi @alexhollender_WMF, fwiw I'm partial to showing the two options (2 or 3) that enables some level of navigation without having to find the ToC again by scrolling to the very top.
Of the two, Option 2 is better at orienting the user as to where they are in the article (which I think was one of the findings from ToC user research?), and also closer to the non-narrow Desktop ToC design so in that respect could be less jarring for the case of when people are changing the screen to narrow on desktop.
However, I do find the position of the ToC menu button is a bit awkward/in no man's land, so perhaps earlier explorations you made where it was part of a sticker header (with the section header?) could be explored? Another earlier iteration that I was partial to was the literal "rail" with the dots (https://di-toc-floating.web.app/Vampire) which was good at satisfying the orientation aspect, but perhaps that is less accessible and a bit fussy in practice.

In T306660#7880755, @alexhollender_WMF wrote:

@TheDJ if you have a moment could you add some thoughts here. Particularly curious about why you make your screen narrow, and whether or not the table of contents is useful to you when your screen is narrow.

Ok, i make my screen narrow because I have a 27" screen. Because of that i often split the screen in 3rds or halves and everything in between that. Before the ToC I could make the page readable again by hiding the sidebar, but the ToC cannot be hidden. Partially this is a content problem as well, as infoboxes don't adapt to dimensions either, but it was a considerable change from before and also one that wasn't nearly as egregious as in prototype testing (the ToC there seemed much narrower ?)

I do like having a ToC, but it is secondary to content.

Part of this seems to be that the prototype actually has a different overall margin of the page. The left margin in production is almost three times that of the prototype i think?

Exactly, thanks for the direct comparison! I really don’t understand what the reason for the new width and the unnecessary margins is. When I had first seen it on the beta cluster, I thought it was just a temporary design problem.

In T306660#7881292, @Jdlrobson wrote:

This is not a new problem, we already had this issue as people write responsive rules with legacy Vector in mind which work differently on Minerva. Unfortunately, the only way to support all skins is to have different breakpoints for different skins (I remember hitting this problem when working on the English Wikipedia main page)

There is a way around this of course:

1. Hard code the breakpoint for each skin for all css that needs to adapt
2. Or probably easier use classes for different content layouts, then use media queries and https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia to apply those classes to the content. (layout jump possible though)

@TheDJ thanks for the comparison. I think with a few small changes we can get the space back...the screenshots below are from a 1120px wide browser window:

updated prototype: https://di-toc-with-menu-above.web.app/Butterfly
more info in T307004

I'm in a similar situation to TheDJ. I constantly used tiled windows, both on a 14" laptop screen, and a 24" desktop screen. This results in windows that are between ~750px to ~1200px wide.

Overall, I think it would be helpful to re-evaluate the quantity of margin and padding for various elements, and [waves hands magically!] make them responsive. I.e. At steadily smaller window sizes, it would be great if the margins and padding steadily reduced to almost zero.

[Caveat: I don't know how much browser-performance load this adds? E.g. I've got 8 copies of w:en:Moon open (plus other stuff) and everything is getting sluggish when I resize any of them... I don't know if that's related though.]

E.g. I've been using these 2 custom CSS files, to try to 'fix' it for myself. These were working well for the last few months, at all screen sizes, in both vector and vector-2022, and with the vector-2022 sidebar expanded and collapsed.

• https://github.com/quiddity-wp/wikimedia-style-tweaks/blob/master/new-vector-max-width.user.css (major changes)
• https://github.com/quiddity-wp/wikimedia-style-tweaks/blob/master/new-vector-whitespace.user.css (minor tweaks)

It even worked well at sub-700px window-widths, as I previously had the #mw-panel {position: absolute !important} invoked 100% of the time, so the uncollapsed sidebar just became an overlay when I needed it.

After the recent ToC change, the main 2 things that frustrate me sizing-wise (when I'm using my custom CSS) are:

• The sticky header not activating at smaller window sizes
• the ToC not being accessible at smaller window sizes.

TLDR:
I believe it is possible and reasonable (and desirable!) to have the ToC show up as a sidebar at sub-1000px widths, even down to 750px.
Below that size, I'd prefer either Option 1 or Option 2.
I'd strongly dislike Option 3 (collapsing sections) per my previous comments and essay/notes.

Examples:
Vector vs Vector-2022 (without skin-customization)

My normal setup on desktop (left window is ~900px wide)

Before/After my tweaks

before:	after:
before/after:

Just wanted to leave a comment with the current status from the team's side

1. We have increased the threshold for which the ToC currently hides to 1000px T306904: [ToC] Increase threshold for ToC collapsing to 1000px . This is a temporary fix until we decide what the optimum solution would be for narrow screens, the conversation around which will continue in this task
2. We are beginning the work on reducing the margins for screens between 1000px - 1200px, as per @alexhollender_WMF' s proposal above. We will track this in T307004: Fix spacing/margins for screens between 1000 and 1200 px and will probably have the implementation ready within the next few days
3. By the end of this week/early next week we hope to have clear next steps on our preference of the options within this task, which will provide a more permanent state for narrow screens.

Personally, I am leaning towards option 2 as it seems the most technically straightforward and it allows us to potentially introduce collapsing of the ToC throughout the experience. That said, as @alexhollender_WMF has pointed out, it might introduce some awkwardness when used alongside the main menu, as it would introduce a second collapsible menu with slightly different functionality

Related question at enwiki helpdesk: https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=1085520277#ToC_gone?

Option 3 (collapsible sections) doesn't exclude 1 (in-line ToC) or 2 (pop-up ToC). Minerva on tablet or phone-landscape widths has both 1+3.

iOS app uses variations of 2. On phone it's a slide-over and on tablet a slide-beside the content, both are full-height. But the mobile app has both a top and bottom bar to activate functions from.

We have site-nav, site-tools, page-tools, and page-toc, all of which we might want to be pop-over or pinnable. (Not to mention user functions.) I note Olga and Alex have also commented about having two collapsible menus on the left. How about some kind of mode selector across the top of the left and right side-bars? The side-bars themselves could be pop-up or fixed depending on viewport size and user pinning.

(Choosing between left and right for different items may be a separate discussion, but I'm picturing something where the left and right panels are containers, and the content sub-panels – ToC, nav, tools – each have a move-to-other-side option.)

Finally, I want to point out that floating/sticky elements on iOS are a problem. I have to drag-scroll the page some indeterminate amount to get the VE toolbar back after it scrolls away. And I managed to dissolve the adhesive from the sticky header in the Desktop Improvements Prototype 4. There mightn't be much you can do about that as a platform limitation, but I do hope we don't come to a point where Vector 2022 is not expected to function on mobile devices.

@XanonymusX @TheDJ @Quiddity @AlexisJazz two updates:

1. we've reduced the width of the table of contents and the surrounding space for screens below 1200px wide. will be in production soon, in the meantime you can check out: https://patchdemo.wmflabs.org/wikis/66a7113371/wiki/Paris?useskin=vector-2022&tableofcontents=1

2. we've got a prototype that makes the table of contents collapsible at any width, and also makes it available on smaller screens when you're scrolled down on the page (similar to option 2 in the task description), you can check that out here: https://di-collapsible-menus.web.app/Brown_bear

Thanks for mentioning this discussion @Jdlrobson. After the first shock for the change (the usual one) I have noted that it is difficult to navigate the article because we can't see the ToC after we have gone down. I proposed in T308032 to double the ToC, but yes, it may be tricky. We have to think in a way to show the ToC in the first sight, because [I DON'T HAVE DIRECT PROOF OF THIS] people normally is going directly to the section they want to read, and navigating down to find the ToC makes it more difficult.

The biggest UI problem I'm seeing with the TOC on vector-2022 is on narrower screens, there is a control to collapse the left sidebar, which should free up space - except all of that verticle space is still consumed by the TOC (or empty space for the TOC). Perhaps if it collapsed with the sidebar?

For the "Option 1" (Put the TOC inline) is there an existing css/js that can make this happen, or would it require development?

In T306660#7924711, @Xaosflux wrote:

The biggest UI problem I'm seeing with the TOC on vector-2022 is on narrower screens, there is a control to collapse the left sidebar, which should free up space - except all of that verticle space is still consumed by the TOC (or empty space for the TOC). Perhaps if it collapsed with the sidebar?

have you seen these tasks?

• T307004: Fix spacing/margins for screens between 1000 and 1200 px
• T307900: Collapse ToC into page title at narrow screens
• T307901: Add link that allows to hide/show the ToC manually on all screen sizes above 1000px

Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site. So a "solution" that makes Vector more like Minerva (e.g. collapsed sections) is exactly the wrong one. That would leave no escape, except logging in from every device, and every private tab, just to read a page.

In T306660#7932192, @suffusion_of_yellow wrote:

Something to remember: People using Vector on "narrow screens" are likely to be mobile users who dislike the (Minerva) mobile site.

@suffusion_of_yellow , no, that's not true. Narrow screen doesn't mean mobile screen. Vector (intentionally) doesn't define a viewport, so users there will never get a narrow screen. Users on a mobile device will continue to see the desktop site with a desktop viewport zoomed out like so:

In T306660#7932309, @Jdlrobson wrote:

@suffusion_of_yellow , no, that's not true. Narrow screen doesn't mean mobile screen. Vector (intentionally) doesn't define a viewport, so users there will never get a narrow screen. Users on a mobile device will continue to see the desktop site with a desktop viewport zoomed out like so:

I said "likely" not "certain". And I don't see a TOC on my phone (360x720, pixel ratio 3.0) in Vector-2022. My general point is that if the user scrolled down and clicked on that "desktop site" link, there must be something about Minerva that they don't like. So, as a general principle, y'all should try to make the skins not like each other. I am (now) pleased to see that you're not going to collapse the sections, for example.

Well, I think we should have designed in a mobile-first approach for the new vector skin. Making sections collapsible and adding a TOC popup button both in desktop are my preferred alternatives.

Remaining tasks are T311160 (Backlog) and T314579 (TODO). @ovasileva I don't think the former is a blocker?

In terms of blockers for resolving this task, I would say T314579: [ToC] Content should be centered when TOC is collapsed is a blocker and high priority. We can resolve without T311160: Add indicator that appears when TOC & page tools menu have been hidden