Talk:New skins system

Previous page history was archived for backup purposes at Talk:New skins system/LQT Archive 1 on 2015-07-10.

Is this in any way related to Requests for comment/Redo skin framework? If not, it probably should be merged into there. :)

This page seems mostly focussed on:

• Remove skins that maintainers of MediaWiki don't want to maintain
  • This is mostly done at this point.
• Provide simplified installation mechanism (e.g. Special:Administration/plugins with GUI search, and one-click install/enable).
  • See Requests for comment/Distribution and deployment.

Is it possible to have MediaWiki structured in a MVC kind of way?

I find it extremely difficult to figure out where a lot of CSS attributes acutally come from, most aren't contained within .css files. It is a very strange structure.

What CSS attributes?

Please don't remove all the non-CSS-heavy skins! At least leave one "linear" one (probably Chick). Many people on low-bandwidth connections prefer these, and such folks probably wouldn't mind if things like AFT and WikiLove didn't work on them. And the accessibility benefits cannot be forgotten. The skin could be renamed "Minimal" or "Low Bandwidth" or "Classic" or "Accessibilitas" or something similar.

The claims about Simple, Chick, etc... being low bandwidth are complete FUD. Vector loads ~19.3KB of CSS while Simple loads ~11.9KB this is only around half the size, for all that loss of UI this isn't a significant enough bandwidth gain. Especially when you factor two things in. We load ~134.7KB of JS, this applies to every skin, including Simple. This means that while you manage to save 10 measly KB you've barely made any savings at all since you still have x13 that being loaded. And the other thing, is we have nice and aggressive caching. So no matter what skin you're using after you've downloaded the assets once you don't download them again. So there is no point to trying to micro-optimize like this.

As for the user who are in fact on low bandwidth connections. They should be using the mobile site, not a full fledged desktop skin. That's what it's for, small screened and low bandwidth clients.

And these skins have no accessibility benefits. Accessibility is supposed to be always-on. Jump links, flexible font sizes, etc... accessibility is something in the background that should be done for every skin. Skins like simple and chick don't improve accessibility. Moreover basic accessibility should NEVER be a user preference. A person should never have to create an account and login just to get accessibility. Accessibility should be built into the site default skin. The thought of these skins providing an accessibility improvement to MediaWiki are also FUD.

So skins who's entire rationale for existing is based on FUD have no business being in core.

Some people actually like to edit Wikipedia on low-bandwidth connections, which is currently not possible on the mobile site, so they need to change skin.

I personally think a scriptless skin should be provided. While MediaWiki:common.js, etc, would still be loaded, all the cruft like floating menus, extensions, edit toolbar, etc should not be loaded, to save more bandwidth. (sorry, I am the OP at a different IP)

The mobile site will eventually have editing and that point will end up moot (bug 30306). In any case as I have already explained simple/chick are not low bandwidth they offer no significant bandwidth savings. And any small fraction of savings you gain is mooted by the browser caching. So Simple and Chick still don't have a proper rationale to stay.

As for scriptless, if you don't wan't scripts then disable JavaScript. If it's not enabled then the browser doesn't download it.

As for the idea that we should offer a skin that loads stuff like commons.js but not other things. I should first point out that what you are describing is not a skin. It has nothing to do with this. All of those things are general features loaded in all skins by mw, not by skins. So what you are describing would really be a user preference that would apply to any skin, it's not a reason to keep skins like simple or chick around. In any case your idea will likely not save as much bandwidth as you think it would.

Firstly sizes. The total loaded on an empty cache is 154.3KB (4.3KB is a banner so you might as well make that 150KB). Common.js is 3KB. However site scripts depend on jQuery and our mediawiki JS libraries to function. Those libraries are 45.4KB. In other words even just including the most basic of necessities we already eat up 1/3 of what we load in total.

Another 1/3 is eaten up by a 50.1KB script. This script includes some things like ext.Experiments, article feedback, collapsible elements, and charinsert that you may consider unnecessary. But it also contains mw-jump, the placeholder shim, tabIndex, our core mw.Title, mw.Uri, mw.api, and mw.user libraries that other things depend on, the mediawiki.page.ready which is also a necessity, and also our ajax watch code. All that stuff of course is a mix of necessities, things that necessities depend on, and things like ajax watch. And I won't let you say that ajax watch isn't useful. Because ajax watch replaces an entire whole page load likely over 10KB alone with no caching, with a tiny script that gets browser cached and not re-loaded plus a 390B (not KB, pithy little bytes) api call. That script actually saves you bandwidth.

Simple search and collapsible navigation. The latter probably falling under your selection unnecessary stuff is a mere 5.6KB. Reference tooltips are a mere 2.3KB.

And of course after all this, bandwidth concerns are mooted by the fact that after the page view that 150KB of JS isn't loaded again. It's all cached in the browser. The only JS that is re-loaded is a tiny 4.3KB banner. So trying to micro-optimize is still pointless.

Also I should mention that our long term goal should be to kill Common.js. Site scripts should eventually be compartmentalized into individual gadgets with proper dependency handling, etc... instead of all shoved into one page in the i18n system where it doesn't belong. So it becomes even harder to use the criteria of partial loading that you describe.

But just to finish up. Trying to save bandwidth by getting rid of css or js like this is pointless. It takes up hardly any bandwidth as we already optimize it and then it gets cached into your browser and you aren't loading it anymore. While on the content side, en.wp's homepage loads 111KB of image thumbnails. Visiting an article will likely land you on an article around ~100KB of HTML from all the text with an additional potential 500KB of thumbnails. In other words two simple page views of content you are actually aiming to see eat up more bandwidth than the all of the css and js you are trying to optimize away. That is how insignificant a savings you gain. And in return, you loose accessibility features, and piles of features that improve your experience on the website, whether you know that or simply take it for granted.

You may well take the righteous view, but a lot of people are going to disagree with you on Wikimedia wikis!

The bandwidth differences between the skins are negligible so my feeling is they are using Chick because it "looks cleaner" on tight spaced mobile devices than Vector. This could easily be fixed by making Vector's CSS more responsive, instead of maintaining support for legacy skins. I believe that the Athena project would address these concerns adequately. Athena hasn't been resourced by the WMF, but my gut says that all the mocks can be done with tweaks to Vector without creating an Athena skin, and I'd imagine the mobile team will be driving this effort sometime next year just out of the need to merge the mobile web code back into core.

I don't think we really need most of this part. Focused son-generic (ie: Non-Wikipedia-like) skins should not be packaged with the tarball. There are many different categories of focused skins and they will all be useful to only some groups of wikis. So we shouldn't be packaging things not generically useful into the tarball. Those skins should all be installed normally.

Btw, we also don't need to try including so many skins by default. Even WordPress — what appears to be the aim of a lot of these paragraphs – only bundles one single skin. So MonoBook/Vector/Modern are quite enough for the standard tarball.

My intended outcome of the "review" was indeed that we would package MonoBook in the tarball for all, and everyone could then pick others later. But this is still a decision/review - even if it's just you and me deciding.

My overview on our current skins:

• Nostalgia and Standard / Classic: These are ancient legacy skins. The legacy code necessitated by how they lay things out completely differently than how SkinTemplate does it actively interferes with skin development and adding new features and extensions that happen to add something as simple as a link somewhere in the UI. Hence these two should be completely purged.
• Cologne Blue: This one was a legacy skin. Though it's being fixed up so it no longer is one. However even though it's fixed doing so is necessarily done with the use of hacks. The design is outdated and not very fitting for a standard skin. And the inflexibility and incorrect use of core UI also make it not a fit standard skin. So my recommendation is to package this up into a standalone skin and offer it for download by anyone who wants it.
• MonoBook: MonoBook is out of date. The techniques it's based on have improved since back then. It is a usability burden because it still does things in ways we know are not friendly to readers (eg: Search bars should never be part of the sidebar like that). I wish people would stop using it on their wikis, period. Unfortunately there is probably still too much weight on MonoBook for us to turn it into a standalone skin so it'll probably stay.
• Modern: I'm unsure about this one. Some users seem to like it. It's attempt at being a MonoBook replacement was a failure though. I'm not sure if we could get away with turning it into a standalone skin.
• Vector: This one is our current default skin so naturally it says.
• MySkin: This one should just go. The idea of trying to create a custom skin this way is a failure. There is no base css included, so you have to re-implement things you should not be reimplementing. And it's based on MonoBook which is out of date and should no longer be the basis of any new design. And besides this MySkin is an act of hostility towards the user. Anyone curious enough to try enabling MySkin just to try it out will be met with a completely un-intuitive view and will struggle to return things to normal. So this should disappear asap.
• Chick: Chick is basically the only non-legacy vertical-only design. However it's not the best way to do that kind of theme and it is potentially confusing for the curious user who tries it out. I believe that Chick was introduced as a skin users could switch to when they use mobile browsers. However for that we are working on MobileFrontend. So I think Chick should become a standalone skin for whoever actually wants it.
• Simple: This one was introduced by some users who personally didn't want any skin clutter. Mostly under the pretense of it speeding things up. However with ResourceLoader's optimization and the fact that piles of JS are still loaded by default in skin this position is frankly highly debatable. And the desire to have no actual theme is a narrow power-user request. So I think this skin should no longer be included in the tarball and made standalone, but still installed in WMF wikis for those users obsessed with that pov.

The problem with killing off the older skins is that people well respond by tying formatting and templates far more tightly into whatever the current skin is. By supporting older skins you maintain an advocacy group (thats been around long enough to have some influence) for keeping such things at least vaguely skin independent.Geni (talk) 04:47, 28 October 2012 (UTC)

We still have at least 3 different standard skins. There is still plenty of skin variance to take into account. And even without it the advocating users aren't going to simply disappear, they don't exist just because we have other skins.

Some of the assertions here sound incorrect.

installing a new skin is complicated and requires shell access, which excludes / unnecessarily makes life harder for some of our re-users; and

Skins don't require shell access like upgrades used to. They only require filesystem access. Which is basically the same thing needed for extensions. This assertion looks wrong.

contributing a new skin is essentially impossible except for those of us in the ivory tower of the Wikimedia Foundation.

Modern was introduced by river. He's a root but he is not part of the WMF. Additionally our old standard default skin for almost a decade MonoBook, was created by Gabriel Wicke who back then was just a volunteer.

So this assertion is wrong too. The problem here is not the WMF. It's that to create a good core-level skin you need two completely different skill sets; The ability to design a really good and at the same time really functional design. And a complete understanding of MediaWiki that allows you to make designs that perfectly fit with MediaWiki's features rather than the features of other CMS systems. And sadly, finding someone with those kind of skill sets is very rare. So it's very rarely that a skin good enough to be considered for core shows up. Since being a core skin means that the skin should both be generic enough to be useful to every wiki and also make absolute perfect use of the different things we output, with no room for hacks.

As I'm sure you can see, this is a draft. Feel free to correct it. :-)

Skins don't require shell access like upgrades used to. They only require filesystem access. Which is basically the same thing needed for extensions. This assertion looks wrong.

Sure. Fixed. But the comment still stands; requiring filesystem access is still inappropriate for a basic system administration task like skins. That extensions also need fixing is a known issue.

Modern was introduced by river. He's a root but he is not part of the WMF. Additionally our old standard default skin for almost a decade MonoBook, was created by Gabriel Wicke who back then was just a volunteer.

I am aware of our history; I was there. :-)

However, it is true that contributing a new skin to core has not been achieved in the past 5 years except by the Vector team, who were employed by WMF, and that when someone proposed on wikitech-l the inclusion of a new skin there was no process for them to follow that was acceptable.

Could you show me any topics where someone actually suggested a skin for core?

mailarchive:design/2012-September/000153.html and the subsequent discussion?

Erudite couldn't possibly qualify as a core skin. I was just to polite to actually start listing the issues.

It's "polite" to deliberately fail to answer someone when they ask what issues with their skin would need work before you would deign to let them include it? Your dictionary differs from mine.

It's not fixable.

Erudite is just a random WordPress skin duck taped up to work on MediaWiki. The base css itself comes from a WordPress theme which means a few things:

• The css itself doesn't even follow our coding guidelines. That's fixable but minor.
• The css is not based on our standard styles. They're not included at all so none of the standard styles you would expect to work on a standard skin are available.
• The design is css reset based. Usually a reset based design will completely break if you try to remove the reset. It takes a lot of work to fix it. But using a reset on a wiki skin has the potential to break site and user styles in the content.

Besides the css:

• The markup is problematic for a standard skin. Standard ids expected are not used so you can't target things with the same css. The navigation uses it's complete own classes and ids and discards other attributes we usually output. And you can see how it's not a MW skin. Content actions/tabs are entry-meta. Post and styles are scattered around. The sitename is a "blog-title". The tagline which is aimed at print output but sometimes stylized is a "blog-description" and always visible in an ugly-by-standard way.
• The design's typography and even overall design and layout is not generic. Fancy serif fonts are used. The first-letter style nor the fancy <hr> fit a generic theme. The placement of search and personal tools are also bad for a standard theme, but fitting of a theme for some random MW based site that likes the theme enough to use it as their default. And the placement of tabs like watch, history, edit, etc... is not fitting for a community edited wiki. The design carelessly uses <br>'s too.

But fundamentally there are two issues:

• The theme was not designed from the start as a MediaWiki skin. You cannot put MediaWiki content made to work on one of our standard skins and expect it to work as you would expect any standard skin to work. Even if you managed to fix this things fundamental to the design like the restricted page width would interfere with lots of existing wiki content. This is something detrimental to a standard skin but useful to a standalone skin.
• The theme by necessity is a navigation hack. It uses a horizontal bar instead of a sidebar menu. And to do this it hacks around with the sidebar navigation in a way that discards navigation that users have added and won't even work at all on some wikis. We do not have a standard way to handle horizonatal navigation. So until I rewrite the skin system and eliminate our dependence on MediaWiki:Sidebar for site navigation we can't accept any theme using horizontal navigation as a standard theme.

Some of the stuff looks out of date.

Before anything else, there's a new way to package up skins. It makes packaging skins up much more useful. I described it first in a tutorial:
http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/

And we're ready for people to start putting their skins into real repos instead of passing around out of date tarballs.

Skin developers can request a mediawiki/skins/{skinname} repo. And commit their skin to there. And they should be able to get the same — i18n (TWN might need some tweaks though) and support for new things — advantages that extensions in our version control have.

We also have a Skin: namespace ready and available on the wiki for skin pages.