Talk:Requests for comment/Themes in core

I was hoping this would be in Phabricator, but since that doesnt seem to be happening just yet, wanted to record this question.

You define a theme as a "Variant of a skin in terms of colours, fonts, simple layout changes; specific to a given skin"

FWIW "simple layout changes;" doesn't sound like what I understand theming to be. The rest seem fair and something which could be done by changing a few LESS variables. It would good as part of this RFC to define a contract for what a theme can and can't do and scrutinize that.

The Theme approach of shipping different stylesheets doesn't seem like something we should encourage. I would argue that giving users more control of some underlying CSS/LESS variables would be a better approach here.

Layout changes aside, if a skin is making use of LESS variables in a skin stylesheet, rather than rewriting an entire stylesheet like the existing themes do, have you considered adding ResourceLoader support for using different LESS variables? e.g. Vector Deep sea.

My biggest concern with enabling themes in core, is it should have an opt-out. Personally I don't want to worry about different themes of Minerva and I'd want to opt out of this because maintainability. CSS is hard enough to maintain as it is, without having to worry about different stylesheets for every theme. If I do have to worry about them I'd be much comfortable if the theme was defined by tweaking some CSS variables I'd intentionally exposed - for instance it would be powerful to allow Minerva's header/color scheme to look yellow-ish in the case of MediaWiki.org

Man, I'm sorry, I didn't even see this because I was really only watching the phabricator task.

Yeah, we definitely want to move toward using underlying variables, but we can't always use only that (even if it's just two extra rules to fix something weird with the different borders, something it turned out was needed in timeless) - but as long as we keep the side stuff to a minimum, I think we're doing fine.

And yes, adding that proper RL variable support so it doesn't need to be skin-side is the next step, unless... do you have any idea how to actually implement that now? If we can jump right to that now, that is what I want, here, but as far as I understand it there is just no way to do that in an extension to begin with, hence why I want to merge what we have now into core so we can then move onto that. But if we can just do it all at once...

Hello,

For practical reasons, the TechCom requires all RfC's that are ready to be discussed to be (i) fully documented on phabricator (desc); and (ii) for the discussion to happen there too.

Is there a link to where this is documented?

Yes, at Requests for comment/Process.

From Requests for comment/Process:

You may also publish your proposal on mediawiki.org instead, as subpage of Requests for comment. If publishing on mediawiki.org, also create a Phabricator task that points to the mediawiki.org page from its description.

This is what I did. Is this documentation incorrect?

Oh, hmm, you're right, it seems that the Committee didn't update their documentation when that changed a few years ago, sorry.

There've been a few other RfCs done similarly over the past couple of years, with the main text of the RfC on mw.org, and task with only a small summary for actual tracking on phabricator, so I don't think the policy is quite that strict, whatever it is.

Mind you, if it would be better to have more of a summary on the task itself (someone else just replaced the existing task description with a link here, since it was pretty self-explanatory in the broad strokes from the name already), such that it can thus be better discussed there, that I could certainly understand - I'd rather prefer the discussion itself occur on phabricator as well. Could we perhaps get someone from the committee to actually clarify what is expected, however?

Well, Marko is on the Committee, and he started this thread in asking you to move it… :-)

Indeed, it hasn't been documented, but we are trying to institute a single place for RfC's so that it's clearer to people how and where to interact, but also to make it easy for TechCom members to follow all RfC-related changes. In order words, we trying to make some order :)

This is not to say that you have to move the document, you can copy/paste it onto the task, but if your proposal is ready to be discussed (which judging by your email to wikitech-l it is - thnx for sending it, btw!), we do require the text to be on Phabricator and for the discussion to happen there.

I'm sorry, this is ridiculous. We submitted this in december; you were the one who updated the task description for it on phabricator to only link here; you were the one who marked it as under discussion then, and left no comment that anything was wrong; and now it's wrong? Meanwhile you still haven't updated the documentation that I spent several weeks wading through to get an understanding of what was expected, so I'm still really not sure what you actually mean - documenting something and copying an entire wiki page into a task description are two very different things. Frankly, that also doesn't make a whole lot of sense - most of this page is just explaining the context; I really don't think phabricator is even an appropriate place for that in the first place? Now having that explanation here on mw.org, with a link and more of the proposed plan and the technical details on phabricator as the actual RfC might make a lot of sense, but you were the one who removed that, so... what exactly do you expect from me, here?

Please, please figure out the process before you expect anyone to follow it. Don't try to retroactively apply it, do introduce yourself so people actually have any idea who you are, and seriously, update the documentation. Some of us are not salaried and frankly don't really have the time to go running around in circles on this.

Like with skins adding skin-vector to the body, we should add theme-name to the body.

Agreed.

Apparently this was already the case and I wasn't looking at the right version.

Would there be a use for that ?

Yes, that is built into the extension and would be ported over.

It's usetheme, and yeah, it's useful for all the things useskin is.

So, for Extension:Themes I understand this approach, but for core, this is bad advice. Overloading another skin creates all sorts of problems with specificity and also with duplicate CSS that is unnecessary for many users. The right advice is that if you have a dark theme, you should have a light theme (and if you want to call that puppy default, then I don't mine), and the rest of the skin should only have CSS that is shared by both themes.

The fact of the matter is that if you're using CSS, you can use it as badly or well as you like, regardless. You see this presently in the implementations of responsive skins: some have separate styles for different resolutions using breakpoints (ideal), but many simply do full styles for one resolution and then only use the breakpoints to override those for others, or don't even use breakpoints at all (instead depending on mobile site, js, whatever). The problem is, for themes, the latter sort of appraoch is currently the only option.

This RfC is basically about adding the option to do a better job of it, allowing separate styles for each theme without having to override everything after the fact as is pretty much required using only an extension, but it won't guarantee devs actually do that, any more than having support for media queries guarantees devs actually use those well to implement responsive styles.