Page MenuHomePhabricator

Help community migrate away from legacy Main page special casing
Closed, DuplicatePublic


MobileFrontend currently allows local wikis to serve an entirely different main page to mobile users. They can do this by marking certain elements for display with id attributes "mf-" or "mp-". When an element is found to be marked in this way it will be shown and all other elements will be hidden.

This is bad for several reasons:

  1. editors now maintain 2 versions of the main page.
  2. The mobile page is inferior in terms of functionality and the desktop page is inferior due to not working well on smaller displays.
  3. many mobile home pages look inferior and less colorful than their desktop counterparts as this mechanism provides a quick fix that usually has substandard results (compare desktop English Wikivoyage to mobile Wikivoyage for example) - why can't mobile have nice carousels too?
  4. the code is badly documented and not generic - it only works on the main page. we should develop/encourage generic tools that can be used on all pages (not just main page) for editors to use to make content mobile friendly
  5. first visitors of the main page will incur a small performance penalty. This will hit all logged in users.
  6. the different handling of the main page means additional testing is needed and main page only regressions are possible.
  7. the only way to get a mobile friendly main page is via the mobileview API. Other API requests will return the desktop format

Things that need to be addressed:

  • There is no reason for table based layouts in 2016 for main pages - similar displays can be realised using block elements and floating
  • with TemplateStyles it will be possible to have media queries which will allow identical content on both mobile and desktop screens.


Screen Shot 2016-06-24 at 12.17.31 PM.png (666×937 px, 80 KB)
Screen Shot 2016-06-24 at 12.17.21 PM.png (620×1 px, 687 KB)
Screen Shot 2016-06-24 at 12.18.37 PM.png (707×935 px, 277 KB)
Screen Shot 2016-06-24 at 12.18.52 PM.png (706×1 px, 480 KB)

Related Objects

Resolved tstarling
DeclinedBUG REPORTNone
Resolved Deskana
Resolved Whatamidoing-WMF

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson updated the task description. (Show Details)

They've been working on a responsive CSS-based redesign for a [well, many years,* but a renewed effort for the last] few months.

To see the design:

and then when you visit the usual Main Page you'll always be auto-redirected to the redesign version.

See/Join the Discussion at

and note the synopsis/announcement from yesterday at

See the mobile versions at

@Quiddity it looks great (on both mobile and desktop) what are the blockers there? This is much better than the current offering and shows the rest of the Main Page content :-O

@Jdlrobson I'm waiting for TemplateStyles to be deployed, but it has a major blocker in that it does not support media queries (see T135788), on which the new main page relies heavily. Other then that, I just have to ensure 100% consensus from the community :)

Aren't the blocking/blocked relationships of this task inverted? Is the idea fix problems first and then help communities migrate or the other way around?

This question is related to who should drive this task, Web-Team-Backlog or Community-Relations-Support. Are the first blockers to solve technical or social?

Also, since the priority of this task is Normal, is someone planning to work on it during October-December 2016?

Hi @Qgil they could be - the parent/subtask relationship in Phabricator UI is highly confusing to me.

The wikis that make use of this are:
It's not clear whether they need to make use of this or not. It would be a useful exercise to ask these communities (who edit the main pages) to comment on how the mobile experience is different from their desktop experience and if it needs to be. I don't know how to run such a survey and find the right people at such scale.

To take a concrete example:
Desktop main page when viewed on the mobile skin

is different from the mobile main page:

Are editors happy with this situation? What would help them manage the main page?

TemplateStyles being deployed (T133410) appears to be a blocker for some communities as was highlighted above but not all.

I don't think we are going to make any progress on this until that happens but I'd hope that will happen by the end of the year.

Qgil lowered the priority of this task from Medium to Low.Feb 7 2017, 2:33 PM

This seems to be currently a low priority.

(Sorry if question is silly, how -if at all- is this related to T164927?)

Thanks for asking! The main page is a page that would benefit greatly from TemplateStyles.
A while back we added a hack (wgMFSpecialCaseMainPage) to allow main pages to render nicely on mobile (it's documented here -

As a result various projects use a lot of additional wikitext markup to make their main pages work on mobile.

With TemplateStyles this mobile homepage formatting is obsolete and the reading web team will plan to remove this code.
Thus, the wikis should look to remove it and instead focus on updating their styles so they are no longer necessary. TemplateStyles is basically mobile formatting done the right way :)

Happy to chat over hangout in person if this helps understand the problem some more?

@Ckoerner, questions, thoughts, etc.? (Jon, I think I already attended a related meeting, thanks though.)

Corey reached out to me a bit a go and asked to do some research on how different communities manage their Main_Page. I did a little investigative work, but would appreciate hearing from actual folks who help with this process on their home wiki.

I haven't made much progress on this due to other priorities. Additionally it seems to me that a key component of successfully working with communities on this is the availability of TemplateStyles, which has yet to be deployed.

I think en: is, on the whole, amenable to breaking content out of layout tables. Even on en:Main Page, if the changes are invisible or too small to be noticed visually.

But hoo-boy if you try to move anything on en:Main Page around.

If I remember correctly, the 2016 attempt was doomed by a Lilliputian dispute over content order.


The choices were A) break content out of the table in TFA-DYK-ITN-OTD order, B) break content out of the table in TFA-ITN-DYK-OTD order, or C) do nothing and keep nesting layout tables three deep. Whether to break the table with DYK on top or with ITN on top was, for some editors and admins, worth going to war over, and that war claimed at least one significant casualty. Because the community couldn't agree between A and B, they defaulted to C, the choice nobody wanted.

Yes, emphatically, to what MattFitzpatrick wrote. I was part of the successful 2005 Enwiki main page redesign, and I've tried to help almost all the subsequent attempts to avoid the problems we ran into in every iteration since. -- TLDR: Do not mix together the many aspects of change, if at all possible - I.e. (1) backend decisions (tables vs CSS), should be addressed separately from (2) which content blocks are shown, and (3) what order they are shown in, and (4) using what aesthetics of design. -- I might be able to answer other specific questions, but there really are some stressful memories in there (for us collectively, and personally).
I agree with Matt that Enwiki is perfectly amenable to changing from tables to CSS, just don't change anything else at the same time.
If memory serves, there was a related design in the 2012 attempt at'er_Rabbit/sandbox.css and'er_Rabbit (deleted by user-request because of his frustration, but admins might be able to rescue the perfectly valid code) that merely changed tables to CSS.
Also I vaguely recall the 2016 attempt started off as just a table-replacement, but then veered off into "whilst we're changing things...." territory. Possibly there are older diffs at worth using.

I believe that Frwiki's recent (March 2017) main page overhaul was relatively successful. Details are at and the contact list at bottom suggests asking our colleague @Trizek ;-)

So a healthy approach would be to maybe break the work up into phases?

  1. Hey Wiki X, you should move away from tables to CSS. Here's some helpful information about how to do that, here's where you can go if you need help.

<some discussion and work, time passes>

  1. Great, now which content sections should appear on mobile? Have you heard of TemplateStyles?

<some discussion and work, time passes>

  1. Cool, cool. So, what order should they appear in?

<some discussion and work, time passes>

  1. Hey, it's me again. What do you think about the design of the Main_Page?


I and others in Russian Wikipedia have started to do some work on redesigning main page after TemplateStyles was deployed. Is there something we should know other than ‘get rid of mp- styles’?

A question related to this task: I am aware that a new interface page, MediaWiki:MobileMainPage.css, recently became available for Hindi Wikipedia. Is it going to be a global feature in the future? It definitely provides a little bit more freedom in customising a main page, but are there any downsides to using standard MediaWiki:Mobile.css page (if I wanted to have background greyed out on main page, like in hiwiki, for example)?

Thanks for asking! The main page is a page that would benefit greatly from TemplateStyles. They already contain lots of additional wikitext markup to make them work on mobile.

Nope mediawiki:mobilemainpage.css will definitely go away (as will mobile.css on the long term).

Getting rid of the mp- styles and ids is a great starting point. The goal would be to use the same logic as other non-mainpage pages. If you can create a main page inside a draft namespace youve done it (you may notice when copying and pasting the main page elsewhere it automatically breaks).

Ideally we would serve the exact same html and css on mobile and desktop. That would be a good target to strive for.

The downsides of using Mediawiki:Mobile.css is that it is not render blocking so can lead to flashs of unstyled content and it ships css to every single page even if the page doesnt need/ use those styles slowing down the first view. In mobile where performance matters much more, this is problematic, so long term we plan to remove this page altogether. Everything that can be done in mobile.css can also be done in template styles.

@stjn Cool to see the work happening on Russian Wikipedia.

Is there something we should know other than ‘get rid of mp- styles’?

Have you been using this page for reference?

If you find anything missing as you go along, please let me know. I think you're in the front of the pack with these changes and I think it would be great if other communities could learn from your experiences.

Everything that can be done in mobile.css can also be done in template styles.

Well.. almost anything. Template styles doesn't support vendor prefixes for instance and it's also harder to use it for styling things that are NOT template based (wikitable class for instance). And I foresee some problems with very large pages, which likely will trip their total bytes transclusion limit when we move all CSS into the pages (Not yet sure how to handle that). But it shouldn't be a problem for a limited case like a Main page.

Nope mediawiki:mobilemainpage.css will definitely go away (as will mobile.css on the long term).
Everything that can be done in mobile.css can also be done in template styles.

Well, in TemplateStyles there’s no ability to add styling outside the content, and for a good reason (because otherwise it would be _page styles_ or something and it would have to have another level of security). In my mockup linked above I want to have entire main page background header-coloured, and that would not be available with just the CSS.

Another area where TemplateStyles would not suffice is hiding Minerva’s welcome message for logged users. Currently we hide the default main page header for them, but in the future layout I’d prefer to hide the Minerva message instead.

Have you been using this page for reference? If you find anything missing as you go along, please let me know.

Yes. Will do if that happens.


Can support what you said about vendor prefixes. Developing with TemplateStyles is very cutting-edge-centric as of now because of this.

@stjn Note: main page is already using templatestyles, you might want to use it as inspiration. (And i just converted it to no longer use the mobile frontend special casing: demo).

Another area where TemplateStyles would not suffice is hiding Minerva’s welcome message for logged users.

This doesnt sound like an appropriate use of template styles yes. Also hiding it on wiki seems inappropriate. If it's not useful Minerva should remove it. My feeling is that it's no longer needed anyway. This change predates Echo and was primarily to show users they were logged in given there were no other indications. @alexhollender given communities are removing this anyway do you think we should remove this altogether?

Thanks @TheDJ !
We could also start logging editor warnings where special casing is being used if that is helpful (please raise a bug if so defining what you need to know!).

As I’ve got the consensus about enabling the new main page, I want to ask more precisely: is MediaWiki:Mobile.css loaded with CSS or JavaScript? I’ve read something about the latter before, so I want to be sure that the new page design won’t flash for user after the initial page load (given that I did Hindi main page-like grey background for main page, see here on smaller page widths). Thanks in advance.

@stjn MediaWiki:Mobile.css loads via JavaScript and it shouldn't be used to serve styles on the main page as these styles are only needed by the main page. The most ideal and future proof solution here would be to make sure of TemplateStyles (which looks like it's enabled on Russian Wikipedia) - that way the main page styles will only get shipped on the main page and will not experience any flashes. Is there any particular thing stopping you from using TemplateStyles? Do you need any help?

The plan with Hindi Wikipedia is to migrate those styles to TemplateStyles (as they were needed prior to the deploy), but as with any migration is dependent on time and resources :/

TemplateStyles doesn’t have the access to ‘higher DOM’ and it was for a reason (since it is editable by everyone, albeit in Russian Wikipedia we have disabled that in the meantime). TemplateStyles don’t have the support of prefixed properties (see T162379) and don’t have the ability to modify the page on higher level than content (which is, ultimately, good for most pages, but in main page’s case it is not good since, for example, almost every project hides the title via Common.css right now).

I would guess that the most we can possibly do in the long term is to have some ‘common.css’ TemplateStyles pages that are editable only by sysops, but then they have to be developed pretty soon since I initially planned to have the new main page since 1 June :-/ Can we enable the same thing that is enabled in Hindi Wikipedia so that at least the background won’t flash on the page load (see the resulting variant for what might cause problems)?

The title and page actions are hidden by default on the mobile site anyway... (but you can't verify that in a draft page). I'm talking to @alexhollender about whether we can remove the heading for logged in users saying "Welcome Username" are there any other things that cannot be done that need to be ?

You can use MFMobileMainPageCss in the mean time, but do so at your own risk and with the knowledge this would only be a stopgap solution. I'm keen to get that removed from MobileFrontend asap (by end of July) and I'd rather not be blocked on migrating it from another project so the onus would be on Russian Wikipedia to ensure the main page doesn't break when the code is removed.

Thus, if we can invest time now identifying the issues with TemplateStyles/blockers I think that would be a good use of our time!

An alternative approach might be to ask for MediaWiki:MainPage.css to be in core instead (would require community consensus/maybe an RFC) as I can imagine that would be useful to non-mobile use cases too.

The title and page actions are hidden by default on the mobile site anyway...

I was talking more widely. In our case the thing we need is having background change from the get-go instead of after the page render.

Thus, if we can invest time now identifying the issues with TemplateStyles/blockers I think that would be a good use of our time!

The blocker here and in Hindi Wikipedia is that TemplateStyles can’t be used by its nature for styling outside of content. That’s why I would guess they did MobileMainPage.css in Hindi Wikipedia and that’s why we can’t use TemplateStyles for this in Russian Wikipedia (since every style gets prepended by .mw-parser-output and stuff like page background is not styleable with such selector).

Got it. Maybe having this in core would be a good idea...

Removing our team tag, feel free to ping us again when needed.