Talk:Separating skins from core MediaWiki

Jon's comments

I am agnostic to whether all skins should be moved out of core (and to whether MediaWiki should ship with a default skin), but I think the fact that skins live in core leads to bad practices. Going through the process of moving CologneBlue and Modern out of core I am shocked about how much rebasing I have had to do. The fact that we are making changes to CologneBlue and Modern in 2014 (Gerrit #I999b97) seems broken - our skins should be much more resilient to change and it should be possible to leave a skin untouched without it breaking.

You claim that you will not be "rewriting the Skin and SkinTemplate classes." although I really think you should be more ambitious and should revisit this idea. I think you have a good chance here at making our skin infrastructure less a mess. Ideally a skin should just be given a bunch of data e.g. the history url, the talk page url, the sections, the section edit link urls, the text of the page, the page title that it can create HTML markup for and apply a skin to e.g. take a lot of logic out of the skin itself. If we can get to a goal where skin designers only have to think in terms of HTML and CSS I think this is a wonderful place to be.

Also I wonder if somehow your work here could fold nicely into this other proposal - User:Jack_Phoenix/A_modern,_scalable_and_attractive_skin_for_MediaWiki_(GSoC_2014_proposal) - maybe Jack's new skin could be built and aid the decisions of the new skin infrastructure built out by you?

I'd be interested in mentoring this, if what I am saying above is of interest and inline with where you think we should take the skin system. Also note, by the start of this project there will be only 2 skins in core - Monobook and Vector. I'd suggest you limit yourself to refactoring these, whilst maintaining backwards compatibility for the older skins. Jdlrobson (talk) 18:47, 21 March 2014 (UTC)

Yeah, CologneBlue is a little… special. :( Changes like the one you linked should not be necessary for better-done skins.

Having a simpler, cleaned up skin system is a tempting prospect, but a) it limits skin developers a bit (which might be often a good thing, but if our current system was like that, it'd make projects like Jack's skin proposal all but impossible), so we might want to do it in addition to the current one and b) would be a rather large undertaking by itself, assuming you'd want to do it properly and consult everyone interested (an RFC would probably be in order). Given that changes like these usually either move at glacial pace or end up annoying a lot of people, I'd rather limit the scope of this project. (But I am nevertheless interested in working on that some day, or even if parallel if I have the time – it looks like plugging external template engines into SkinTemplate is doable even now.)

Jack and I have already chatted about this briefly, and we could probably work together to settle on the way to do skins (it looks like we agree on the important points already), have Jack's skin done in that particular way, and possibly get it bundled in the tarball in the end (if the tarballing-related part of my proposal works out).

I'd appreciate if you could mentor this project, especially since we seem to agree on a lot of things here :) I commented on your CologneBlue and Modern changes, I'm prepared for both possibilities (their staying in core for now or getting moved out) and I'll probably want to bring them both up to par in both cases. Matma Rex (talk) 12:35, 24 March 2014 (UTC)

I think you need to addess SkinTemplate problem and dependency on special structures in the code first. Moving skins out of the code somewhere to the extensions is really secondary. I think relationship OutputPage/SkinTemplate/the-way-UI-gets-generated-and-can-be-skinned is a real issue here, not core vs. extension problem.  « Saper // talk »  16:23, 5 April 2014 (UTC)

@Saper: Honestly, I think they are both problems and both have a somewhat similar severity. I'd prefer to first address the one that we can address reasonably neatly without bludgeoning backwards-compatibility. :) Matma Rex (talk) 16:58, 5 April 2014 (UTC)

Mentors

Looking this proposal in Google Melange, I still see no mentors assigned. One mentor is required to consider any proposal (Jdlrobson, please "Wish to mentor" if you wish to mentor). Two mentors are expected for a project like this that requires changes in MediaWiki Core. At least Trevor Parscal and Krinkle are going to have strong opinions about this plan and its patches. One of them (or someone they designate) should be officially in, regardless of the informal support that other +2 contributors might provide. PS: also, I would feel better about this proposal if there would be an explicit acknowledge from the related maintainers. MatmaRex is one of the maintainers, but still. I'd rather don't rely on assumptions now, only to see how patches get stuck in Gerrit discussions when it comes the time to push them to Core.--Qgil (talk) 17:23, 26 March 2014 (UTC)

@Qgil: Jon said he's bonked the appropriate button on Melange, can you confirm? I chatted with Krinkle (very) briefly about an early draft of this and he seemed to generally like the idea (and I actually implemented some of his advice on the proposal already); I haven't been able to get ahold of Trevor yet :( Jon is hunting down some mentors, and I have a backup plan ;) in case no one is willing/available to co-mentor this project. Matma Rex (talk) 23:45, 26 March 2014 (UTC)

Yes, Jon has signed up as mentor already. However, we would prefer to have two mentors, for the reasons explained above, and because it is a general requirement in our outreach programs. The time to sync with Krinkle and Trevor publicly is now. Please don't make me read long threads to deduce whether we have consensus about this plan or not.  :) --Qgil (talk) 05:04, 27 March 2014 (UTC)

Any progress finding a second mentor, getting an official opinion from the maintainers?--Qgil (talk) 18:17, 31 March 2014 (UTC)

@Qgil: Yep, Ori's agreed to mentor this as well. This is taking me longer than it should for the same reason why skinning is such a neglected area – everybody who would work on this is deathly busy with WMF things, and I'm not exactly able to walk up to somebody's desk and poke them… If by "maintainers" you mean "Timo and Trevor", then that's also a problem for the same reason – both are apparently okay with the idea though, I'll ask them to write a few words here. Matma Rex (talk) 18:57, 31 March 2014 (UTC)

This work seems sensible so long as it remains well scoped. If redesigning the skin system from scratch is a prerequisit activity, than this work should be reconsidered. However, so long as this work can be done as a preparatory step in the eventual redesigning of the skin system I fully support it. Trevor Parscal (talk) 20:43, 31 March 2014 (UTC)

Manual:Skin configuration

Doesn't this need updates? --Nemo 16:58, 8 August 2014 (UTC)

@Nemo bis: Yes. I just updated it. Matma Rex (talk) 17:14, 9 August 2014 (UTC)

Sensible defaults?

Looking at bugs Bug 68332 - Create a tiny fallback skin to use when no proper skins are present, Bug 70222 - Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available right after installation and gerrit change 156440 there is certainly a need for the fallback built-in skin to be working automatically anywhere.  « Saper // talk »  00:33, 31 August 2014 (UTC)

I don't understand. The error you're seeing is, in fact, part of the fallback skin. The fallback is definitely working as intended. Matma Rex (talk) 13:35, 31 August 2014 (UTC)