We were considering something like this for an A/B test but never as a final production-worthy state. I worry that short-term solutions have a habit of becoming long-term solutions, so I am pretty concerned about this plan.

• This would significantly add to the HTML size for all page views as it would mean two tables of contents in every single page view. It would also add 1kb to render-blocking CSS which impacts the first paint and load additional unnecessary JavaScript to deal with the collapsible behavior of the existing table of contents.
• It will also create a lot of challenges for editors as the table of contents is currently tied to various decisions around layout (https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Feedback_on_ToC_functionality touches on this somewhat). If the table of contents is in a predictable state it will be much easier for them to work around editorial decisions. I worry that by having 2 table of contents to think about we'll end up with situations like the longstanding #coordinates issue.
• On low resolutions, we already know this to be a bad experience, as it can considerably push down the article on long articles, making them a bad experience which is why we hide the table of contents on mobile.

. For now, as a short term solution, we've decided

I don't think I was involved in this decision. If so, I'm sorry for somehow missing this.

What problem are we solving and for which users exactly? As far as I see, the only users that will be impacted by this change are users who resize their browser. Users on mobile devices using Vector will not be impacted as we don't enable the viewport tag so the skin does not adapt to the device. What use case is there for seeing the table of contents in a small resized window?

In T300975#7694545, @Jdlrobson wrote:

What problem are we solving and for which users exactly?

Problem: With the table of contents on the side of the article, as your screen gets smaller there is less and less room for the article (see the original task, T298898, for more context). At around 1000px the article is quite squished.
Which people: this is for anyone with a browser window less than 1000px wide.

On low resolutions, we already know this to be a bad experience, as it can considerably push down the article on long articles, making them a bad experience which is why we hide the table of contents on mobile

Right, this is not the preferred solution. However until we can collapse the sections (T298898) we need to do something for these people.

@Jdlrobson @ovasileva where are we at with this?

I haven't managed to get into this because of my vacation. I'm hoping to focus some time on this next week.

So I've been thinking through this and I've come to the conclusion that there is no way of doing this without living with some long term technical debt. Given the desired and preferred end goal is T298898 I decided to spend some time rethinking a way to make that possible. I think I've found one.

With that in mind, pending developer approval on T298898 I suggest we decline this task and focus our energy there.

Olga to check in with Jennifer whether this would impact the A/B test

Change 777889 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/skins/Vector@master] Force legacy TOC to render at lower resolutions

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

hi @alexhollender_WMF cc @ovasileva @Jdlrobson

I thought I was clear but now I am confused by the 2nd ToDo in the ticket description:

While the A/B test is disabled AND table of contents is present in the sidebar AND at lower resolution THEN legacy table of contents should be hidden

"at lower resolution" presumably means below 1000px (desktop breakpoint)

What should be visible when the new TOC feature is enabled and the A/B test disabled for all viewports below 1000px?

In T300975#7839449, @cjming wrote:

What should be visible when the new TOC feature is enabled and the A/B test disabled for all viewports below 1000px?

Confirmed with @Jdlrobson that until we have more data, no TOC (neither legacy nor sticky sidebar) should be visible in this case.

And we will confirm about breakpoint during design review - erring on tablet (pre-existing) for the time being.

Change 777889 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Force legacy TOC to render at lower resolutions

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

✅ AC1: While the A/B test is running at lower resolutions where the table of contents is currently hidden, force the display of the legacy table of contents regardless of which bucket the user is in

✅ AC2: While the A/B test is disabled AND table of contents is present in the sidebar AND at lower resolution THEN legacy table of contents should be hidden