Page MenuHomePhabricator

[EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:Minerva.css
Open, Needs TriagePublic

Description

NOTE: Mobile.css will be removed by the end of 2024 (timeline to be updated later).

MediaWiki:Mobile.css was added to MobileFrontend as a replacement for MediaWiki:Common.css

Many projects use MediaWiki:Mobile.css. However many of the rules there are redundant and necessary on mobile domain given the mobile HTML is different from desktop and many of these wiki pages result from copying and pasting from Common.css. Mobile also provides opinionated rules on how horizontal lists should render. Many of the rules only apply to a handful of pages. For instance the hlist template is not needed on all pages yet CSS for it is loaded everywhere.

As a workaround (which quite frankly is a bad workaround) we load this CSS via JavaScript (See T190083)

Now that TemplateStyles exists there is no reason to use MediaWiki:Mobile.css other than 1) convenience (e.g. it's easier to add a class hlist to an element then to find and use a template) and 2) style the UI e.g. change the header color - Minerva doesn't want support this right now and if we do want to support that better more scoped solutions exist.

Gadgets provide a better solution for scripting than Mobile.js

An additional issue here is that MediaWiki:Mobile.css is loaded for all skins on the mobile domain commonly used as if it is MediaWiki:Minerva.css which means if T173527 is ever resolved, other skins will look very broken. For this reason, MediaWiki:Minerva.css should be restored to support skin-specific customizations

What about MediaWiki:Minerva.css

To make the mobile site behave more consistently with the desktop site, in T359488 we made MediaWiki:Minerva.css render blocking. Since MediaWiki:Mobile.css is poorly documented, not render blocking and often used inappropriately we will sunset its usage.

While we could run a bot to move Mobile.css to Minerva.css it is a good opportunity to provide better guidance for communities using it in damaging ways.

As part of this move we are likely to expect a performance hit on certain projects which have large Mobile.css pages.

Proposal

Proposal is as follows

  • Mitigate performance problems that might arise from communities migrating CSS from Mobile.css to Minerva.css - provide better guidelines on how to use.
  • Migrate suitable code to MediaWiki:Minerva.css (we should not migrate all styles here!)
  • Blocking problems in TemplateStyles that are blocking wider use of template styles are fixed T162379
  • Community is notified and supported with moving styles to appropriate stylesheets shipped with TemplateStyles or MediaWiki:Minerva.css
  • MediaWiki:Mobile.css and Mobile.js is removed from the site and associated configuration wgMFSiteStylesRenderBlocking.
NOTE: MediaWiki:Common.css and Common.js will not be loaded in their place ($wgMFCustomSiteModules will continue to be provided for sites where that makes sense). Once this task is completed, it would be a good idea to create a ticket discussing the long term technical vision for that configuration option.

Related Objects

Event Timeline

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.

Jdlrobson renamed this task from Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles to [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles.Apr 10 2020, 6:49 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson awarded a token.
Jdlrobson renamed this task from [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles to [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:inerva.css.Fri, Mar 15, 9:32 PM
Jdlrobson updated the task description. (Show Details)
stjn renamed this task from [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:inerva.css to [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:Minerva.css.Sat, Mar 16, 12:08 PM

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?

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

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

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.