Noting that this has also broken Wikipedia articles with wide equations, e.g. https://en.m.wikipedia.org/wiki/Trace_(linear_algebra)

These articles were already broken as they broke the viewport making Minerva sidebar forcing the browser to zoom out and add horizontal scroll to the entire article. This has long been documented on https://m.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis (add the noresize class)

Elements that are clipped on mobile are also broken on desktop site - they will overlap the sidebars at certain resolutions.

The Math bug is captured elsewhere and being dealt with separately.

This is a disappointing response. A horizontal scrollbar does not equal "broken". Content being cut off is absolutely, unambiguously, broken. Moreover, a horizontal scrollbar on the entire page has the advantage of allowing a mobile user to zoom out the viewport and get a better view of the wide content, and a horizontal scrollbar on an individual element doesn't.

Maybe this is unaesthetic or suboptimal by some subjective standard, but the solution is to evaluate better UI options on a case-by-case basis, not just immediately break things in a way that *actually breaks the user experience*. I guess everyone reading math articles should just guess how the equation ends.

Elements that are clipped on mobile are also broken on desktop site - they will overlap the sidebars at certain resolutions.

No, this is not true if an element is set to overflow the viewport only on Minerva.

The Math bug is captured elsewhere and being dealt with separately.

I assume that's this one: T201233

Thanks for filing this @Ioaxxere - I noticed this behaviour the other day but couldn’t work out what was causing it!

I’m boldly tagging this as a Regression; as it was previously possible to view the ends of overly wide elements by scrolling to the right, and it’s not possible to view the ends of these elements using Minerva on mobile anymore.

In the task description, @Ioxxere wrote:

If this change was intentional, I wish that it had been communicated better, seeing how it has caused some breakage.

+1; this breaking UI change should (IMO) have been communicated if it was intentional.

In T391781#10742215, @Ioaxxere wrote:

This is a disappointing response.

I’m afraid I have to agree.

A horizontal scrollbar does not equal "broken". Content being cut off is absolutely, unambiguously, broken.

Agreed — at least, there are different levels of "broken", and IMO ‘not being able to view the ends of wide elements at all on mobile’ is more broken than ‘the browser has horizontal scroll that can be used to view the ends of wide elements on mobile'. The latter is definitely not ideal, but I would respectfully say that IMO the most recent change has broken things for readers even further.

Something that (AFAICS) hasn’t yet been said is that this also breaks the usage of some (not-completely-mobile-friendly) MediaWiki special pages on mobile — e.g., if you go to https://en.m.wikipedia.org/w/index.php?action=edit&mfnoscript=1&title=Template%3AWide_image in a logged-out window, the "view and copy the source of this page" box extends the width of the screen. While such special pages should clearly be fixed to be more mobile-friendly, IMO this change to MinervaNeue that actively results in them being less usable on mobile is not the right step to take.

As a side note, I’d therefore propose to remove the Local-Wiki-Template-And-Gadget-Issues tag, as this is therefore not an issue limited to wiki-defined pages; and I’d argue that the current regression (of not being able to view the ends of wide elements at all on Minerva) hasn’t been caused by wiki-defined pages at all.

FWIW, I disagree with the move to 'Tracking' here, for a couple of reasons:

1. IIUC, if it's in the 'Tracking' column, this task will be more likely to stall/remain without action, due to not also being tagged with another (primary) codebase tag. (If this's been judged to only be a Local-Wiki-Template-And-Gadget-Issues task, then presumably it should be closed as invalid — as local wiki issues aren't usually tracked within Phabricator, and as this task wouldn't have a clear resolution criteria. I'd also personally disagree with that course of action, though.)
2. The change that this task is specifically taking issue with is a change that was made in the Minerva codebase itself.

I'm fairly confident there is enough momentum due to various problems that this will get some focus soon and a better more generalized solution for tables at the parser level. I've added it to the essential work project as I do think resolving this and the other related problems is important and the more examples we get the more priority it is likely to get at the project level.

I can provide examples where this is true when I get access to a computer.

BTW regarding this - an example is https://en.wikipedia.org/wiki/List_of_tallest_buildings_in_Chicago

• At 851px the table and panorama is clipped
  
• On desktop it overlaps the sidebar:

Neither are ideal.

https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/1153321 moves this rule to .mw-parser-output, with some discussion about additional changes ongoing at https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/1153321/comment/921f9af0_54f118fb/.

Change #1154095 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Allow large content to scroll on Minerva

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

Change #1154096 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] [POC] Allow content to "break" out of the viewport

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/3eeb523a4d/w/

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/154726e9b9/w/

Change #1154096 abandoned by Jdlrobson:

[mediawiki/skins/MinervaNeue@master] [POC] Allow content to "break" out of the viewport

Reason:

Patchdemo made.

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

Change #1154095 abandoned by Jdlrobson:

[mediawiki/skins/MinervaNeue@master] [POC] Allow large content to scroll on Minerva

Reason:

Patchdemo made.

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

Change #1165517 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/skins/MinervaNeue@master] Remove overflow-x: hidden rule from content area

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

Change #1165517 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Remove overflow-x: hidden rule from content area

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

So… I guess the implicit decision here is that we should allow the entire page to be scrolled horizontally?

Yes, I think that is a good idea!

From: matmarex <no-reply@phabricator.wikimedia.org>
Sent: tirsdag 1. juli 2025 23:03
To: Phabricator <no-reply@phabricator.wikimedia.org>
Cc: oeyand3@online.no
Subject: [Maniphest] [Commented On] T391781: How should skins behave when content isn't responsive (Minerva skin had a blanket overflow: hidden style on content area)

matmarex added a comment.

https://phabricator.wikimedia.org/T391781 View Task

So… I guess the implicit decision here is that we should allow the entire page to be scrolled horizontally?

TASK DETAIL

https://phabricator.wikimedia.org/T391781

EMAIL PREFERENCES

https://phabricator.wikimedia.org/settings/panel/emailpreferences/

In T391781#10965421, @matmarex wrote:

So… I guess the implicit decision here is that we should allow the entire page to be scrolled horizontally?

Looking at the commit message, it’s unclear to me whether it’s necessarily a final decision, so much as an interim step to deal with regressions caused by the previous change

Looking at the commit message, it’s unclear to me whether it’s necessarily a final decision, so much as an interim step to deal with regressions caused by the previous change

This seems very much interim decision to me.

So… I guess the implicit decision here is that we should allow the entire page to be scrolled horizontally?

This is not a good experience on mobile landscape mode / tablet. As demonstrated on this page pages with "large" tables or other elements break the viewport and the entire page is no longer "responsive" so basic actions like searching and edit become more difficult (I would suspect a high bounce rate if we were to collect data since the page looks broken). When using overflow-x scroll you localize the issue to just the content.

We should continue to explore options. The only feasible long term solution I see here is to change the HTML markup of tables to support being responsive by default.

{F65780597,size=full}