It seems to me like the bug is that the content is not centered when the sidebar is collapsed, rather than that the content shifts to make room for the sidebar when the sidebar is expanded.

Unable to reproduce on Win11/Chrome. But clearly happening in your gif.

It should not, like pages with a ToC.

I don't completely understand this. On https://fr.wikipedia.org/wiki/Conf%C3%A9rence_de_Kreuznach_(19_d%C3%A9cembre_1917) if I click "hide" on table of contents and collapse the sidebar doesn't the same behaviour happen?

It seems to me like the bug is that the content is not centered when the sidebar is collapsed, rather than that the content shifts to make room for the sidebar when the sidebar is expanded.

• On pages without a max width e.g. Recent Changes this is expected as the article grows in size.
• In articles with a max width, if you view the article on a screen resolution less than max width e.g. 900px, the article will shift and expand in size.
• In large resolution monitors, the content area will be at max width, andot grow in size, but obviously, the collapsing of the sidebar will make it centered. I can't remember exactly if that was an intentional decision, but I do remember some people complaining about the gutter on the left. I'm also not sure why this is a problem - what issue does it actually cause for you from a reading/editing perspective ? (thanks in advance for the context)

In T316465#8198466, @Jdlrobson wrote:

I don't completely understand this. On https://fr.wikipedia.org/wiki/Conf%C3%A9rence_de_Kreuznach_(19_d%C3%A9cembre_1917) if I click "hide" on table of contents and collapse the sidebar doesn't the same behaviour happen?

Yes! Apologies for that and I have added that scenario in the task description.

In large resolution monitors, the content area will be at max width, andot grow in size, but obviously, the collapsing of the sidebar will make it centered. I can't remember exactly if that was an intentional decision, but I do remember some people complaining about the gutter on the left. I'm also not sure why this is a problem - what issue does it actually cause for you from a reading/editing perspective ? (thanks in advance for the context)

To me, the problem is the small position shift of the content area when expanding/collapsing the sidebar, as showed in the gif. I personally consider this as an unwanted visual glitch which should be addressed, and I guess some people will have the same complaints. What's your opinion?

Thanks for clarifying! The glitch doesn't bother me personally, as it refocuses the content, but I'm not sure it's something we thought about deeply.

If we want to change that as you've suggested, I think one thing to consider is how complicated it will be to fix and maintain that fix.

@Diskdance the reason why that is happening is because when a page does not have a TOC (or when the TOC is collapsed), we center the content on the page.

content centered at max-width	video showing content remaining centered as page width decreases

We looked into positioning the content in such a way that would avoid the shift you are pointing out. This would mean that we're basically blocking off the space for the main menu (even when it's collapsed), which results in the content not being centered. This doesn't make much of a difference when the window is wide, but becomes more noticeable, and makes the page look quite imbalanced, at smaller resolutions:

window width: 1727px	window width: 1388px

I believe the good news is that when we implement an updated grid (see T298198), the width of the main menu would be dynamic, and the shift will no longer happen. I've made a note to include the capability of a pinned main menu into the latest grids prototype (https://dsg-grid-2.web.app/Moss) so that I can double check on that.

How would you feel about closing this task as Declined?