I will focus on this when T243996 and T32405 are out of the way.

I don't agree that this is a dupe of T67147; it's at best a sub-task, surely?

convenience

Sometimes you're up against the template expansion limit (see our pathological pages of course), or the template isn't structured to support easy input... never mind finding the supporting template.

Community is [...] supported with moving styles

This deserves a task all to itself because you have the pain points like hlist. See also T228604: Clean up party of Mediawiki:Common.css at Wikimania 2019 and I think I've had some commentary in a few other places.

Is this task as is titled ("Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles") a desire for-WMF only wikis, or something that should affect all wikis that use MobileFrontend outside of WMF wikis? If it's the latter, I have to disagree with this approach.

Even if most of the styles are specific to templates, we have common styles in place for tables. Just as we have with class="wikitable", we have other common themes and sets of styles for cell alignment and similar, which are used on plain wiki tables, and I don't want to use a replacement template for those css classes. I'm not sure if templatestyles is even supported in such scenario (using {| {{customtable}}" instead of {| class="customclass").

@Izno @Jdforrester-WMF @Ciencia_Al_Poder this task is very very far in the future - sorry to give the impression it was pending. As @Izno says the template styles adoption is a big blocker which is going to take time.

a desire for-WMF only wikis, or something that should affect all wikis that use MobileFrontend outside of WMF wikis? If it's the latter, I have to disagree with this approach.

This task was prompted by a question from @Krinkle to think about what I thought the future architecture of Mobilefrontend would look like. My answer was sustaining both MediaWiki:Common.css and MediaWiki:Mobile.css was not sustainable. The former in current form is not suitable for Wikimedia run wikis on mobile, but I could imagine a feature flag deciding whether Common.css is run or not (at least as part of an interim step).

MediaWiki:Mobile.css like many things in MobileFrontend was a workaround for an immediate complicated problem which is that MediaWiki:Common.css contains a lot of CSS that's redundant on mobile and a lot of CSS in general (enabling it on English Wikipedia for example almost doubles the amount of bytes shipped to users and delays the time it takes for every page to load).

Even if most of the styles are specific to templates, we have common styles in place for tables. Just as we have with class="wikitable", we have other common themes and sets of styles for cell alignment and similar, which are used on plain wiki tables, and I don't want to use a replacement template for those css classes

I don't think MediaWiki:Common.css is a good vessel for these sort of changes. Every time something is added to that place it adds bloat to every page. For example if you add 2kb of CSS for .customclass but only use that class on 1% of pages you are added 2kb of CSS to every page view (and this is what actually happens in practice with the .hlist class). I think we can provide better solutions for this use case that keep the power of the existing wiki without making the mistakes of Common.css. My feeling is that every time an editor is writing CSS outside the template namespace then they are working around a real problem in core that we should be giving native support for (likely in the parser).

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