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 ????

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.

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.

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

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

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.

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.

In T195946#4243058, @TheDJ wrote:

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.

In T195946#4243305, @Anomie wrote:

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.

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.

@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?)

In T195946#4245163, @Jdlrobson wrote:

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

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