Page MenuHomePhabricator

Allow editors to style main page's differently from other pages for performance and to allow creativity (e.g. MediaWiki:Mainpage.css)
Closed, DuplicatePublic

Description

The Hindi and Russian Wikipedia and Wikivoyages communities have built/are building main pages that are drastically different from other pages built is via MediaWiki:Common.css. The downside of this is that various unused styles are shipped to every single page of the site.

If you take a look at https://en.wikivoyage.org/wiki/MediaWiki:Common.css you'll see the majority of rules here relate to the main page.

Recently, the reading web team had to introduce MediaWiki:MobileMainPage.css to allow styles to ship on the mobile version of the main page to support a change by the Hindi Wikipedia community. Our hope was to quickly deprecate this (T195813) but with T195905 it seems like we are in danger of making this a defacto standard in MobileFrontend.

Rather than have yet another example of a mobile specific change, I'd like to see this change in core if we do need to support it.

The problem is that many of these Main page designs, touch elements outside the content area - concrete examples we have seen so far are:

  1. changing the background color
  2. hiding interface elements e.g. edit link/heading

This means TemplateStyles cannot be used (see T162379)

It seems like all projects would benefit from having a separate interface page to control styling the main page.

Possible solutions

  • T162379 is resolved by special casing the main page.
  • Introduce MediaWiki:Mainpage.css
  • Forbid changes outside the content area and standardise these changes as being skin specific.

Strawman specification for MediaWiki:Mainpae.css

This is just a proposal - other solutions welcomed

  • Content inside MediaWiki:Mainpage.css would be treated as CSS.
  • Content inside MediaWiki:Mainpage.css would be loaded on both mobile and desktop for the MainPage only.
  • If Main page is localised, styles will be loaded on the localised wiki page name
  • To allow editors to test designs it should be possible for MediaWiki:Mainpage.css to load on certain draft pages. Potentially this should be all subpages e.g. "MainPage/draft"
  • Content inside MediaWiki:Mainpage.css will not be loaded on any pages outside the Mainpage.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 30 2018, 9:11 AM
TheDJ added a subscriber: TheDJ.May 30 2018, 1:43 PM

I dont get it. We have mediawiki:common.css, mediawiki:mobile.css AND mediawiki:Minerva.css (or is it MinervaNeue??)

Between the 3 of them, and the page specific body calss, they cannot find a page where adding like three lines of css is enough to target the elements that cannot be targeted using templatestyles? What are they building ????

stjn added a comment.May 30 2018, 1:45 PM

Mobile.css is loaded via JavaScript and therefore would look detrimental to end-users if CSS would load a lot later than the page itself. Common.css doesn’t load for mobile users, but is usable for desktop, yes. Don’t know much about how exactly Minerva.css loads.

MediaWiki:Mobile.css is loaded via JavaScript to avoid loading a large amount of unnecessary render blocking styles (last time I checked it added a 1s to first paint). Long term the plan is to remove this altogether and rely on template styles.

Right now, MediaWiki:Common.css is too large to add to mobile. Most of the styles don't make sense there.

The styles being added by Russian+Hindi need to be render blocking. We have MediaWiki:MobileMainPage.css to load styles on the main page that are render blocking.

Mobile case aside, and looking at examples like Wikivoyage's MediaWiki:Common.css, it seems like it would be extremely useful to separate main page CSS from normal CSS given these pages tend to be extremely different - just as we separate styles for special pages from normal pages.

TheDJ added a comment.EditedMay 30 2018, 2:21 PM

Why don't we include Minerva.css as render blocking on mobile ? That seems to make much more sense to me. Especially as these are mostly skin specific changes.

Mobile case aside, and looking at examples like Wikivoyage's MediaWiki:Common.css, it seems like it would be extremely useful to separate main page CSS from normal CSS given these pages tend to be extremely different - just as we separate styles for special pages from normal pages.

I'd say some people are just doing some things wrong. The most I can find for English Wikivoyage that is truly main page specific, which cannot be achieved with template css is:

body.page-Main_Page #siteNotice { 
       display:none; 
} 
/* Don't display some stuff on Main Page */
body.page-Main_Page #deleteconfirm,
body.page-Main_Page #t-cite,
body.page-Main_Page #footer-info-lastmod,
body.page-Main_Page.action-view #siteSub,
body.page-Main_Page.action-view #contentSub,
body.page-Main_Page.action-view h1.firstHeading {
    display: none !important;
}
/* Coding for new Main Page END */
/* Hide title on Main Page */
body.page-Main_Page h1.firstHeading {
  display: none;
}

The rest can all be moved into template styles. I don't see why that is not perfectly valid to have in a global CSS (preferably Minerva.css as it can be skin specific). There is a limit to the amount of optimisation that is practical. We are far better off, giving people a performance grade that is visible in MediaWiki:Common.css or MediaWiki:Minerva.css than further complicating the landscape of styling. There is only so much we can and should do to protect people against themselves.

MediaWiki:Mobile.css is loaded via JavaScript

This essentially makes it pointless and removes it's analogy with MediaWiki:Common.css. Kill it with fire.

Mediawiki:Minerva.css

This thing isn't loaded at all on the mobile target is it ? Is that intentional, historical ? what ?

Once we special case the main page, it's just waiting until the next special case that people request, because that is what always happens. An exception for the main page makes little sense to me, and you might as well turn it into an array of { page => page.css} exceptions with a more generic configuration name.

TheDJ added a comment.May 30 2018, 2:40 PM

another option would be extending the gadget system to allow them to be specific to certain pages. That too would make a LOT more sense than having a special exception called MFMobileMainPageCss

TheDJ added a comment.May 30 2018, 2:41 PM

@Krinkle definitely would like to see your / TechCom opinion here.

Deskana moved this task from Up next to External on the TemplateStyles board.May 30 2018, 2:42 PM

I agree, from a cursory look, that it seems undesirable to introduce additional style modules for styling of the main page. There are already more infrastructure components currently in production simultaneously that overlap and relate to this. We should work to reduce and improve those, instead of introducing more.

The main page is a fairly simple concept in MediaWiki and it is imho reasonable to expect that at least one (and ideally all) of TemplateStyles, Common.css, Skin.css (Vector/Minerva) or Mobile.css would be capable of targeting it.

Anomie added a subscriber: Anomie.

This seems to have nothing to do with TemplateStyles beyond noting that TemplateStyles can't handle use cases that involve changing things outside the page content area.

I have no idea why T162379: Decide which non-standard CSS properties to support in TemplateStyles is mentioned in here several times, since it has nothing to do with anything mentioned in here.

stjn added a comment.May 30 2018, 6:01 PM

Once we special case the main page, it's just waiting until the next special case that people request, because that is what always happens. An exception for the main page makes little sense to me, and you might as well turn it into an array of { page => page.css} exceptions with a more generic configuration name.

I don’t have an opinion on how it would be best to go around this, but I would say that the Main page customisations are pretty different from other ones since the main page historically has been customised by the communities in many different ways via CSS/JavaScript, and some features of this kind were previously moved to the site code (nstab customisation, for example). We don’t have the examples for other treatment of this kind, so it would be more natural to reject any other proposals.

This seems to have nothing to do with TemplateStyles beyond noting that TemplateStyles can't handle use cases that involve changing things outside the page content area.

Right. TemplateStyles is perfectly suitable for the customisations of the main page content (which is the majority of the use case described in this task). But there is till a handful of things commonly changed on the Main Page outside the content area (e.g. hiding the page-level heading). This should be done from a site-level stylesheet, such as Common.css, <Skin>.css, or Mobile.css

The problem there is that Mobile.css not loading in a blocking way. Which is a a separate issue unrelate to the main page that affects all site customisations. Including styles for infoboxes, citations, page notices etc. etc. See T67147 and T190083 about that.

Nirmos added a subscriber: Nirmos.May 30 2018, 9:42 PM

This task seems like a special case of the more generic T63007. I think it would be better to solve that task instead. If that task is solved, you have solved it for any page, not just the main page, and not just for CSS, but JavaScript too.

Krinkle added a comment.EditedMay 30 2018, 10:14 PM

@Nirmos That task is is about optimising (by conditionally loading) something that works (gadget loading).

The handful of lines for non-content styles for Main Page are not worth optimising for. Certainly not a blocker for this task (which is about allowing something that is allegedly currently not possible).

The example of JavaScript from T63007 is also convenience, not optimisation or new abilities. Conditionally loading of JavaScript is already possible by placing 1 line of code in a default gadget or other site-wide script.

For CSS that doesn't work because only the server can add loading of blocking stylesheets (JavaScript would be too l ate). The conditional loading of CSS is solved by using TemplateStyles (for content area), and for outside the content area it is not needed to be conditional and can be added to a side-wide stylesheet instead.

@Krinkle feels like there might be some overlap. https://ru.wikipedia.org/wiki/MediaWiki:Mobile.css has lots of rules for babel - but babel is not loaded on every page. I'm not sure there is a way to conditionally load additional styles in a similar way to skinStyles. Supporting skinStyles on wiki would also help the main page case, so might be worth considering.

The problem with MediaWiki:Common.css is that without discipline it's very easy for styles in there to be maintained and to work out what they relate to and when they should load. The approach here is very different one from core, which loads groups of styles as and when they are needed rather than unconditionally which results in lots of unused CSS.

If it's practical to get to a place where the styles in MediaWiki:Common.css are purely chrome (outside the content e.g. MediaWiki:UI.css) it feels like we are working towards the right solution, but I don't think we can given the babel example (can we?)

@Krinkle feels like there might be some overlap. https://ru.wikipedia.org/wiki/MediaWiki:Mobile.css has lots of rules for babel - but babel is not loaded on every page. I'm not sure there is a way to conditionally load additional styles in a similar way to skinStyles. Supporting skinStyles on wiki would also help the main page case, so might be worth considering.

You know that these styles are there only because of T178782. I can move it to TS if it will be necessary.

Schnark added a subscriber: Schnark.Jun 1 2018, 8:18 AM

T78418: Introduce MediaWiki:Mainpage.css has actually been discussed before and declined.

Vvjjkkii renamed this task from Allow editors to style main page's differently from other pages for performance and to allow creativity (e.g. MediaWiki:Mainpage.css) to d0baaaaaaa.Jul 1 2018, 1:06 AM
Vvjjkkii reopened this task as Open.
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from d0baaaaaaa to Allow editors to style main page's differently from other pages for performance and to allow creativity (e.g. MediaWiki:Mainpage.css).Jul 2 2018, 4:27 AM
CommunityTechBot closed this task as a duplicate.
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.