@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).