Even after all our discussions, I don’t really get what are people supposed to do now about the very real need to introduce some render-blocking styles in their projects, other than ‘wait a hundred years until the communities become less stubborn’. There are many examples where the discussed CSS doesn’t affect ‘1% of pages’, but ‘80% of articles’. Right now, in those cases, there are redraws afterwards due to the bad way of how Mobile.css is loaded. There seems to be no strategy or research into dealing with this other than ‘try to nudge that code into TemplateStyles somehow, maybe that will be something, we don’t know for sure’. (As we’ve discussed in T243996.)

@stjn for your particular wiki and your render blocking issue I've suggested the config flag option if you feel your community needs it. The #PerformanceTeam hash tag can be utilised to get their advice on how impactful this would be given your projects existing Mobile.css. you can tag such a request with Wikimedia-Site-requests. I think enabling this module as render blockong should be done on a case by case basis. Sadly I don't have the bandwidth to do this right now.

That aside we need to become less dependent on mobilefrontend and simplify its responsibilities.

I agree this needs a strategy but I'd hope you'd agree that ideally the solutions are one of two:

• a world where templatestyles fulfils all our needs
• a world where mediawiki:common.css fulfils all our needs

The latter would be the intermediate goal here. It is a big problem which involves template writer/engineer collaboration which I'm sure has a solution but I don't know what is. To take another example task T32405 has been nudging communities softly for 4 years now to change their main page markup to be mobile friendly and so far that's not been fruitful. Meanwhile my team maintains a complicated legacy module of PHP which degrades site performance. The obvious solution is to change the main page but community consensus and motivating the community to take this seriously is a huge blocker there. The practical solution might be a hard deadline and eventually breaking it intentionally. Sadly not all editors are as responsive and helpful as yourself.

With respect to this task we have lots of time. This is not planned to happen any time soon. If you have any tips for how we might improve the collaboration between editors of templates/main pages and engineers I'd love to hear from you.

I'd be surprised if this hadn't been considered before (and even more surprised if there weren't technical issues I'm unaware of that make it unpalatable), but a potential method for deprecating MediaWiki:Mobile.css at least in the short term would be flags that could be used on styles in MediaWiki:Common.css to mark them as intended for mobile and/or mobile-only, something like /* @embed */ being used to tell ResourceLoader to embed the following object directly in the stylesheet, or /* @noflip */ being used to prevent directional CSS from being changed for opposite-directionality languages. The software (be that MobileFrontend, or ResourceLoader, or whatever else) would then generate a mobile stylesheet from Common.css by stripping everything without the flag, and in the case that mobile-only styles are supported/present, a nonmobile stylesheet with all the mobile-only styles would also be generated.

How is MediaWiki:minerva.css a replacement for MediaWiki:mobile.css?

Users can use multiple skins on mobile, as well as use minerva on desktop (even if MobileFrontend doesn't really like it for now), so this is not a solution for everyone.

The reason why MediaWiki:mobile.css is useful is the same reason why MediaWiki:common.css is useful: you don't have to duplicate styles for every skin or write a gadget, but especially so since there is no MediaWiki:skinname-mobile.css.

TemplateStyles is even worse as a replacement, because you either have to detect mobile devices with it (defeating the point of having MF) or have to make sure that the styles won't conflict with MediaWiki:common.css (if that's even possible) on desktop devices.

So the only real replacement is Gadgets, except that MediaWiki:gadget-mobile.css will have almost the same issues that MediaWiki:mobile.css has (besides render blocking but that's irrelevant here).

Also what even are those "damaging uses of MediaWiki:mobile.css" that aren't an issue when implemented through MediaWiki:minerva.css or MediaWiki:gadget-mobile.css?

In T248416#9635550, @Archimedes5000 wrote:

Users can […] use minerva on desktop

…and if I do so, I expect it to work the same way as Minerva on mobile.

TemplateStyles is even worse as a replacement, because you either have to detect mobile devices with it (defeating the point of having MF)

There’s no such thing that mobile vs desktop. What are you interested in? Whether it has a touchscreen? Whether its primary input method is a touchscreen? Whether it has a small screen? (A 2020s tablet may well have a larger screen than a 1990s laptop.) How small? Yes, you need to detect whatever feature you actually depend on yourself. (However, as a stopgap solution, T299772 introduced the body class mw-mf that can be used in TemplateStyles, gadgets or MediaWiki:Minerva.css.)

In T248416#9655908, @Tacsipacsi wrote:

…and if I do so, I expect it to work the same way as Minerva on mobile.

That’s not how it currently functions though. You get Minerva without MobileFrontend hacks, not the mobile website.

In T248416#9659645, @stjn wrote:

You get Minerva without MobileFrontend hacks

The ever-decreasing number of MobileFrontend hacks. For example, AFAIR https://en.m.wikipedia.org/w/index.php?title=Main_Page&action=history and https://en.wikipedia.org/w/index.php?title=Main_Page&action=history&useskin=minerva used to look completely different. Now the only difference I see (with advanced mobile mode on) is that the tags are italic on desktop Minerva but not on mobile Minerva – which is exactly a style set in Common.css, so the difference comes from $wgMFCustomSiteModules. (I think $wgMFCustomSiteModules should also go away, but that’s another Phabricator task.) This task aims to decrease the number of MobileFrontend hacks by one.

This task aims to decrease the number of MobileFrontend hacks by one.

@Tacsipacsi has summarized this very well. I can confirm the current technical direction is to simplify MobileFrontend, eventually to one single function which is provide a mobile domain with a different skin. T109277 will drop the last special page override and T269499 should minimize the differences in HTML.

From a technical point of view regarding site styles and scripts, the long term goal should be making all skins behave the same and making sure gadgets and site scripts can run on all skins. The recent change to make mobile skins rendering their associated skin style e.g. MediaWiki:Minerva.css is a step in this direction. The last remaining difference is that mobile sites load MediaWiki:Mobile.css via JS and desktop sites load MediaWiki:Common.css.

That said, I think there may be some misunderstandings something about the current architecture. Hopefully the following notes will help:

• The main feature of MobileFrontend is to provide a different skin on a mobile device. For third parties setting up a new Wikimedia instance, this is the only reason it should ever be used. Everything else is does will eventually be upstreamed to core, templates or removed.
• Users cannot use multiple skins on mobile. If a user is using Vector or Monobook on their mobile phone, they are using the desktop domain and MediaWiki:Common.css will apply here, MobileFrontend will not. Only one skin can be configured with MobileFrontend. That skin has associated styles e.g. MediaWiki:Vector-2022.css would be the stylesheet associated if the Vector 2022 skin was defined as your MobileFrontend skin.
• MediaWiki:Mobile.css exists only for Wikimedia projects and has always been intended as an interim solution. All Wikimedia projects are configured to use Minerva skin and nobody can change their mobile skin. Most projects therefore treat MediaWiki:Mobile.css as if it was MediaWiki:Minerva.css.
• 3rd parties should use MediaWiki:Common.css on their mobile site as it is a solution specific to Wikimedia projects which have 10+ years worth of gadgets/templates that were written before mobile was a thing. Third parties need just need to set $wgMFCustomSiteModules = false. This removes MediaWiki:Mobile.css and MediaWiki:Mobile.js and makes skins behave the same.
• Wikimedia sites which have well maintained Common.css can consider switching Common.css on for mobile devices on their wiki providing they do due diligence to ensure that they are using Common.css responsibly (e.g. are managing it's size in a way that doesn't impact performance). Enabling MediaWiki:Minerva.css as render blocking is pushing us in this direction.
• There is no good reason why styles written in MediaWiki:Minerva.css shouldn't apply to both the desktop and mobile domains for Minerva. If you are using MediaWiki:Mobile.css for styles that apply to mobile Minerva but not desktop Minerva, the tool is being used incorrectly. Some people use the desktop domain on a mobile device for example.
• CSS in template styles should be written in a way that it applies to all skins in a responsive way. You can use media queries for screen resolution and supports queries to detect features such as "touch actions". It doesn't matter whether that CSS lives in MediaWiki:Mobile.css, MediaWiki:Common.css, TemplateStyles or a gadget, the same rules apply - write code once for all possible devices.
• TemplateStyles are scoped to the template they style. They take precedent over MediaWiki:Common.css. If you are having conflicts, you should consider using classes that do not conflict.

I am not sure what you mean about "detecting mobile devices".

Regarding performance, generally, yes communities can damage SEO/frontend performance using MediaWiki:Minerva.css or mobile gadgets and should have a good grounding in the topic of frontend performance. The reality is many projects are doing this and negatively impacting their projects. Making Mobile.js was supposed to add friction for communities to move towards templates, but it seems to be this approach has failed and initiatives such as T345960 would be better suited to improve this.

Hope this is helpful.

In T248416#9655908, @Tacsipacsi wrote:

In T248416#9635550, @Archimedes5000 wrote:

Users can […] use minerva on desktop

…and if I do so, I expect it to work the same way as Minerva on mobile.

I didn't expect that. I would have expected the skin to be adjusted for use on desktop devices.

In T248416#9655908, @Tacsipacsi wrote:

In T248416#9635550, @Archimedes5000 wrote:

TemplateStyles is even worse as a replacement, because you either have to detect mobile devices with it (defeating the point of having MF)

There’s no such thing that mobile vs desktop. What are you interested in? Whether it has a touchscreen? Whether its primary input method is a touchscreen? Whether it has a small screen?

Whatever MF uses to detect mobile devices.
I agree that there is no simple "mobile vs desktop" distinction since wikis should work well on any resolution, both with and without touch controls, but this is not what MF seems to be going for, as this can be done with a single responsive skin.

In T248416#9655908, @Tacsipacsi wrote:

(However, as a stopgap solution, T299772 introduced the body class mw-mf that can be used in TemplateStyles, gadgets or MediaWiki:Minerva.css.)

I didn't know about that, this explains how TemplateStyles and Gadgets can be an alternative.

In T248416#9678769, @Jdlrobson wrote:

Hope this is helpful.

Thanks, this explained a lot.
I have only one issue remaining:

In T248416#9678769, @Jdlrobson wrote:

• Users cannot use multiple skins on mobile. If a user is using Vector or Monobook on their mobile phone, they are using the desktop domain and MediaWiki:Common.css will apply here, MobileFrontend will not. Only one skin can be configured with MobileFrontend.

I don't think this is true, unless I misunderstand what "can" means here.
While there is no mobile preference for it, users can force a particular skin even on mobile (useskin url parameter), and in such situation MF works normally and provides mobile features.
I any case I don't think that the assumption that only one skin can be used on mobile should be kept in the future.

In T248416#9702465, @Archimedes5000 wrote:

I would have expected the skin to be adjusted for use on desktop devices.

Minerva is a mobile skin, no one will adjust it for use on desktop. It’s one thing that when used on desktop, certain mobile-specific adjustments don’t apply, but actively adjusting it for desktop use is another thing – one that won’t happen.

Whatever MF uses to detect mobile devices.
I agree that there is no simple "mobile vs desktop" distinction since wikis should work well on any resolution, both with and without touch controls, but this is not what MF seems to be going for, as this can be done with a single responsive skin.

The skin not being responsive is not the same as the content not being responsive. I’d love if Wikipedia had a responsive default skin (it already has a non-default one – Timeless), but if I get a completely different skin on mobile than on desktop, then I get a completely different one, that’s it, I’m not here because of the skin. However, I don’t want to read subtly different versions of an article on different devices, because I’m here because of the content, and because I’m not warned and a subtle difference doesn’t stand out. Subtly different content can even be a grounds for conspiracy theories (e.g. big tech or big pharma or whoever doesn’t want people to see those graphs, so they make them disappear on mobile).

This task still says "Mobile.css will be removed by the end of 2024 (timeline to be updated later)" at the very top of the description. Since this task is still open, I'm assuming this has not happened yet. Is there a new time window that this can be expected to occur?

In T248416#10554532, @SnorlaxMonster wrote:

This task still says "Mobile.css will be removed by the end of 2024 (timeline to be updated later)" at the very top of the description. Since this task is still open, I'm assuming this has not happened yet. Is there a new time window that this can be expected to occur?

It's running ate yes.
Nothing definite yet, but I'd hope by May 2025.

There are less than 93 instances of MediaWiki:Mobile.js that need to be migrated and 188 sites for Mobile.css.
Note these queries are imperfect as many of these pages are empty or simply redirect notices.

AIf your project is impacted I'd appreciate you letting the appropriate admins know about this ticket. This is inevitable, it's just a case of me finding the time to get this into tech news and commit to it.

This current plan makes Minerva.css a de-facto Mobile.css. The problem with this approach is that it brings a strong mobile/Minerva coupling. It makes Minerva on desktop domain unmanageable (too much code conflicts), and much worse, it closes the door to implementing additional skins on mobile. I think this would be a bad move in the long term.

As we are (rightfully) following the road of avoiding JS-loaded CSS, I think that, as a first step, we should simply make Mobile.css render-blocking.

This way, MobileFrontend would do two things:

• Choose Minerva skin.
• Do not load Common.js/css, and load Mobile.js/css instead. These Mobile.js/css could be thought as a trimmed down, "essential only" version of Common.js/css.

Note that MobileFrontend already does these two things currently.

Editors would have both Mobile.css and Minerva.css available, and considering the many peculiarities of Minerva, I think this two-file granularity is a must-have.

I have thought a lot about this, and this simple step would be a great move forward. And it's straightforward: ditch the JS-loading of Mobile.css, done.

As a next step, a true common file (between desktop and mobile) would be very helpful, as it would finally allow to drastically reduce code duplication, which would not be a luxury.

We would have:

• AllPlatforms.css/js, for the common code. (I haven't figured out a good name yet, "common" and "global" being already taken.)
• Desktop.css/js for additional code on desktop, and Mobile.css/js for mobile-specific code. MobileFrontend would remove loading of the former, and load the latter.
• Skin-specific files.

Simple, granular, convenient.

Note this granularity actually brings simplicity, and allows for refined code, in order to reduce payload size.

El T248416#10605265, @Od1n escribió:

This current plan makes Minerva.css a de-facto Mobile.css. The problem with this approach is that it brings a strong mobile/Minerva coupling. It makes Minerva on desktop domain unmanageable (too much code conflicts), and much worse, it closes the door to implementing additional skins on mobile. I think this would be a bad move in the long term.

I don't see this as an issue. You can switch to desktop mode from mobile, and use the skin of your preference from a mobile device (without MobileFrontend). It makes sense to write the skin.css and common.css for all devices, and then you automatically don't need "mobile.css/js" anymore. Actually, having a mobile specific css/js is what can be harming switching to a different skin for mobile.

Hence what I am suggesting as a next step: providing a true common CSS, for both desktop and mobile.

I know Common.css could be made loaded on mobile too. But I'm afraid it would be too much of a disturbance, considering how old the existing Common.css files are.

We already have too much headache here.

Hence proposing to create a new file (AllPlatforms.css, Everywhere.css, Ubiquitous.css…) and keep Common.css loaded on desktop only. Once everything has been sorted out (in a far future), we would still have the possibility to rename / repurpose files: Common.css for all platforms, Desktop/Mobile.css for platform specifics.

Indeed, AllPlatforms.css should be favored the most possible over Desktop/Mobile specific files, but these would be very helpful for the time being. We are still at a phase where Desktop and Mobile have to be, progressively, merged into AllPlatforms. And it's precisely because we currently don't have such a true common file that this process isn't going on.

Edit: I just figured out the name AllDevices.js/css. I really like that one. (Not as ideal as Common.js/css, but the name is already taken.)

Alternatively: Add right now Desktop.css/js files (so, they would be loaded the same as Common.css/js). Leave some time to editors. Then bite the bullet and load Common.css/js on all platforms.

(Edit: mmmm, no. I really don't think it would be a good plan. Way too much troubling to migrate for editors.)

tl;dr: 1) Ditch the terrible JS-loading of Mobile.css (for emphasis: keep this file). 2) Provide common files for desktop and mobile, we are awaiting for these files for way too long. 3) Relish the relief that is finally taking shape.

In T248416#10605601, @Od1n wrote:

Alternatively: Add right now Desktop.css/js files (so, they would be loaded the same as Common.css/js). Leave some time to editors. Then bite the bullet and load Common.css/js on all platforms.

That Desktop.css/js already exists by having the (stable) .mw-mf class on the <body> of MobileFrontend page views (which I’ve already mentioned a year ago in T248416#9655908): body.mw-mf is mobile, body:not(.mw-mf) is desktop. Common.css can have the latter prepended to all selectors to practically become Desktop.css, Common.js can test for it.

(Edit: mmmm, no. I really don't think it would be a good plan. Way too much troubling to migrate for editors.)

WMF staff can do this migration across wikis (there’s quite some precedent for such migrations), only leaving the actual merging up to the wikis – which has no time pressure anymore.

Please ignore the comment you are quoting. Even myself couldn't figure out a way to migrate the files if that path were followed.

Currently, the Common.js/css are de-facto Desktop.js/css files, with decades of history.

The sane solution is really to add a new common set of files for all platforms (i.e. desktop and mobile). Repurposing existing files would be a nightmare, even worse than what we are already encountering.

It is already possible to make Common.x load everywhere, and it is very possible to make it reasonable for all skins, which is the real end game state. See e.g. T375540 for MW wiki and T375538 for en.wp. If your Common.x pages are thin enough and stewarded well (lowercase steward), file one of those tasks. (I've been meaning to poke Jon about the English one; since he's poked this one recently, I figure now is a good time to drop a reminder.) I spent quite a bit of time getting stuff into TemplateStyles, so the only diff for Common.css I needed was pretty minor and pertained most to infoboxes which are another target for TemplateStyles at the end of the day anyway. You also need to adjust Print.css which was a couple days of easy work diff). English Wikipedia didn't have anything in Mobile.js (and my view is that JavaScript should be sorted on a per skin basis anyway, using the gadget or user group systems as necessary) and Mobile.css just goes away this way (and whatever of Minerva.css can be trimmed).

If you're not at a point where you're looking at a Common.css page with fewer than 10-15k of text (and close to 6-7k with whitespace and comments stripped), you should probably work on that. Similar story for Common.js.

In T248416#10616809, @Od1n wrote:

Please ignore the comment you are quoting. Even myself couldn't figure out a way to migrate the files if that path were followed.

You may have got lost, but I described what the way is: prefix all rules with body:not(.mw-mf) until they’re sorted out. And if local interface admins don’t do that, staff can do it.

In T248416#10616870, @Izno wrote:

It is already possible to make Common.x load everywhere

I’ve forgot about this, that’s even better news!

Since there is a lot of confusion in this thread, trying to summarize.

As I mentioned in T248416#10584871 and earlier in this thread, the following is the plan:

• Site CSS/JS needs to be migrated to Minerva.js and Minerva.css.
  • There are less than 93 instances of MediaWiki:Mobile.js that need to be migrated and 188 sites for Mobile.css These need to be copied to Minerva.js and Minerva.css
  • per @Ciencia_Al_Poder rewrite for all devices using .mw-mf class if necessary. Please be sure to switch skin to Minerva on desktop to verify the code is working correctly.
• MediaWiki:Mobile.js will be removed as soon time allows.
• On long term the goal is to make MediaWiki:Common.(js|css) apply to mobile for wikis where this wouldn't be a performance concern (<3kb of render blocking CSS).
  • Projects can request this earlier if they meet the criteria
  • T340705 points to sites with existing performance issues and examples of how projects have improved this so far.

If you need help with this, please do not ping this task which has a lot of subscribers. Instead discuss on wiki or open a new phabricator ticket with the specific problem (as a subtask) you need help with. For questions about reducing your site JS/CSS feel free to ask on T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip