@XanonymusX What is your screen dimension? I mean how big your screen is? I am not experiencing this problem as I probably have a bigger screen. Though I agree that Minerva skin should be responsive and compatible with all mobile devices.

Well, the iPod touch is supposed to be 1136*640 px (per https://www.apple.com/lae/ipod-touch/specs/ ); as I said, it is indeed the smallest screen size available to me, and I usually test everything on it.

With new notifications there’s another issue, apparently the “time stamp” is always hidden outside the right window border; however, here at least the screen size isn’t affected, so you can scroll sideways to see all.

The notifications (specifically .mw-echo-ui-notificationItemWidget-content-table) uses table layout, which is highly susceptible to viewport overflow due to long words, because table layouts have content dimensions take precedence over viewport restrictions. There is also some missing border-box statements where width:100% is used.

This seems like a place where at smaller resolutions we should be using flex box sizing.

I've previously indicated similar issues with the Recent Changes page and the Watchlist btw... T197065: New Filters for Edit Review: UI displays poorly when the window is narrow
On such narrow layouts, you need to think in wrapping rows and take lots of cues from bootstrap grid honestly, all this mucking about with relative positioning and table-cell etc is something you should do AFTER you have defined a proper wrapping row grid basis for the most narrow situations.

Now this is a very small subset, so the priority is low of course, but we really need to start inverting our design process from desktop to 'as narrow as we are willing to support' and then enhance per viewport breakpoint.

Every time we have to retroactively have to 'down design' a UI as Recent changes to mobile is just problematic in my opinion.

we really need to start inverting our design process from desktop to 'as narrow as we are willing to support' and then enhance per viewport breakpoint.

👏👏👏👏👏👏👏👏👏

Should we apply the fix in T356467 to just all buttons?

@Sjoerddebruin i don't think so. In general, you will want buttons to not wrap. However it might be wise to set them like that on screenwidths upto a certain size ?

In T237244#9773035, @Sjoerddebruin wrote:

Should we apply the fix in T356467 to just all buttons?

Hmm… Indeed, maybe we should.

(For context, the fix is overriding the OOUI white-space: nowrap with white-space: normal.)

I wanted to see why we apply nowrap in the first place, and found this old task: T93552: Buttons explode in narrow containers with the following screenshot:

That's a screenshot of the VisualEditor standalone demo (http://localhost/demos/ve/desktop.html). Here's how the same scenario looks now – the WikimediaUI theme handles wrapping button labels better:

I think it's worth trying to change this globally. It seems we improved how wrapped buttons behave, and these days readable rendering on mobile is much more important than it was in 2015 when that decision was made ;) Maybe some places will need to override it back, but I suspect it will be fewer than those currently overriding it the other way (https://codesearch.wmcloud.org/things/?q=white-space%3A+normal&files=css|less&excludeFiles=oojs-ui).

I'm trying it on myself as an experiment: https://meta.wikimedia.org/w/index.php?title=User:Matma_Rex/global.css&oldid=26746343

Testing too.

Effects on the notification page:

@matmarex please let me know how I can help once your experiment concludes!

I noticed some issues in the RC/watchlist filters interface too:

In both cases this is because the interface is built with display: table / table-row / table-cell, and the cells containing the buttons are set to 0 width and rely on the table layout to be shown. This can be implemented more easily with flexbox these days, and it shouldn't be a common problem.

Change #1032065 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/Echo@master] Simplify Special:Notifications layout using flexbox

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

Change #1032092 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Simplify RCFilters layout using flexbox

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

Change #1032092 merged by jenkins-bot:

[mediawiki/core@master] Simplify RCFilters layout using flexbox

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

With the experiment active, I also noticed a small issue in VE find-and-replace dialog:

Change #1032065 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Simplify Special:Notifications layout using flexbox

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

In T237244#9783122, @matmarex wrote:

I'm trying it on myself as an experiment: https://meta.wikimedia.org/w/index.php?title=User:Matma_Rex/global.css&oldid=26746343

I've noticed issues in some more places caused by my code:

DiscussionTools reply tool cancel dialog (in some languages only, screenshot is Russian):

TemplateSandbox interface while editing a template:

I'm now leaning towards declining this for OOUI – while a good idea in principle, we've already applied workarounds probably everywhere that needed them, it seems to break too many existing interfaces, and we're not really developing new code using OOUI that would benefit from the better defaults.

I suggested fixing the defaults for future code in Codex instead: T337865#9861972.