Hi all,
MediaWiki's skin system has been quite a mess for some while. I decided to try rewriting it and you can see the end result on [1]. It's quite a big patch, which is why I want to encourage all developers to test it and report (or maybe even fix? :) any and all issues they stumble across. There is also an example extension on [1] which I've been wanting to do for a long time but which hasn't been possible with the old skin system. To be exact, it was partially possible, as I noted on the MediaWiki.org page, but the implementation was too buggy to be put live on any site IMHO.
What does this patch change exactly? When writing a new skin, you no longer need to override SkinTemplate and write a class that utilises QuickTemplate, you can just extend Skin class directly. Old SkinTemplate-based skins will however continue functioning. I wrote a couple things about writing a new skin with this new system on MediaWiki.org[2], feel free to check it out.
There are some changes which may cause problems, though. For example, SkinTemplateToolboxEnd and MonoBookTemplateToolboxEnd hooks both take two arguments instead of one and the hooks are in Skin.php instead of SkinTemplate.php. I was also thinking that this could be a great opportunity to add some new hooks to Skin.php, besides the SkinAfterSidebar hook. See [3] for my thoughts about what could be improved.
I haven't ported Vector skin to use this new system because it's currently under development. Because this change is quite a big one, I thought that I'll commit it to SVN once MediaWiki 1.16 has been released so that it'll make into the 1.17 release.
What are your thoughts and suggestions for this new skinning system?
[1] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite [2] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Documentat... [3] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Notes_and_...
Thanks and regards, -- Jack Phoenix MediaWiki developer
2010/2/8 Jack Phoenix jack@countervandalism.net:
AWESOME! Someone finally took up this task :D
Why didn't you do this in a branch in SVN? That seems more convenient.
I haven't ported Vector skin to use this new system because it's currently under development.
Not any more, the Vector skin itself has been stable for months. All the usability work is currently done in the UsabilityInitiative extension.
Roan Kattouw (Catrope)
On Mon, Feb 8, 2010 at 3:58 PM, Jack Phoenix jack@countervandalism.net wrote:
Nice! Is it intended to produce byte-for-byte the same output as the current skin system? If so, it should be pretty easy to write something that automatically checks the output of a lot of pages in all skins with and without the changes, to verify that there are no errors.
On Mon, Feb 8, 2010 at 11:16 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
Ah, good to know. I must admit that Vector's code is a bit more complicated than your average skin's...currently the old, SkinTemplate-based Vector skin works, but it doesn't support fancy things like SkinAfterSidebar hook, for example. If you (or someone else from the usability team) would like to start rewriting it, feel free to! :-) On Tue, Feb 9, 2010 at 1:30 AM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
Not yet at least, the indentation/newlines aren't consistent yet. Then again, Brion removed some unnecessary whitespace in r55496 for JavaScript variables in <head>, so I dunno how important it is to have everything indented properly in the HTML output.
Thanks and regards,
On 2/9/10 10:58 AM, Jack Phoenix wrote:
I've been very busy with deployments, so I've been waiting to talk here, but I think that there are allot of considerations for a skinning system that I could help shed some light on when I get some time (maybe next week?). The Usability Initiative's last hard deadline is coming up, and then we will be taking a step back and looking at what needs to be fixed from an infrastructure standpoint, and the skinning system will likely come up. I'd love to help this work get a good head start and be built well, so that we don't just end up with one more skinning system.
I will try and correspond more on this and in more detail in the coming days.
- Trevor
On Tue, Feb 9, 2010 at 4:56 PM, Platonides Platonides@gmail.com wrote:
Since when do we support skins at all? We change them incompatibly on every release anyway. With any luck, we could cut back on that if we moved to a sane system, but I wouldn't block 1.16 on it. I wouldn't hold off on committing either, though, if it can be demonstrated that the skins' output remains byte-for-byte the same except whitespace.
On 2/9/10 4:07 PM, Aryeh Gregor wrote:
I see that there are 3 steps to achieving sanity in MediaWiki skinning.
1. Remove all skins other than Monobook and Vector. 2. Write a more ideal skinning system. 3. Port Monobook and Vector over to the new system.
Why only Monobook and Vector? 94%[1] of users on English Wikipedia are currently using one of them. They are both built on SkinTemplate, so porting will be a similar process. They are also different enough that they will effectively exercise the new system.
We also need to consider that a good general template class which any part of the MediaWiki can use for user interfaces would be a good thing to base this skin class on. This doesn't have to use any fancy syntax, just good old PHP in it's inline forms such as <?php if( $something ): ?>...<?php endif; ?> and <?php foreach( $things as $thing ): ?>...<?php endforeach; ?>. I have some code I've been playing around with that might be perfect for this.
In short, It's better to give users their choice of 3 decent skins than 10 crappy ones, and if we can make migration to the new system less painful, it's more likely to actually happen.
- Trevor
[1] English Wikipedia Skin Preferences
monobook 49.72% vector 44.16% modern 2.73% cologneblue 1.38% standard 0.73% chick 0.44% nostalgia 0.31% myskin 0.28% simple 0.24% amethyst 0.00%
On Tue, Feb 9, 2010 at 7:30 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I would certainly keep Modern and CologneBlue, which are still used by not an insignificant number of users. Furthermore, Modern is an ideal candidate for merging with Monobook, They're nearly identical in structure as it is.
Toss Standard and keep Simple. They're both a simplistic skin, retain the left sidebar, and Simple looks nicer. Same thing with Chick and Nostalgia (getting rid of the latter).
Amethyst doesn't exist anymore (which means there's just some straggling account with the preference still set), so it's a non-issue. MySkin is supposed to be a sample skin for users to customize, but more or less looks like Chick anyway and can be ditched IMHO.
-Chad
On 2/9/10 4:54 PM, Chad wrote:
Merging Monobook and Modern is actually a good point for one of my other ideas, which is to have themes for skins. In other words, same HTML generation, different CSS. Then Monobook and Modern could naturally be merged, Vector could have a different colored version, etc.
I'm not sure about the others, but less will be more here IMO.
- Trevor
On Tue, Feb 9, 2010 at 7:30 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Why only Monobook and Vector? 94%[1] of users on English Wikipedia are currently using one of them.
That means 6% aren't, i.e., ~700,000 users. That's actually much higher than I expected. It would be particularly silly to throw out Chick, Simple, and MySkin, since those differ from Monobook only in CSS.
I don't think we should get rid of any skins here if feasible.
The skins would only be more "decent" from a developer's perspective, not a user's perspective. I'm reluctant to agree that we should get rid of skins that people actually use in significant numbers (even 0.1% of 10,000,000+ is significant) when it will yield no substantial user-visible improvements. If the new system only includes Vector/Monobook/Modern at first, fine, but keep the old skins too -- at least we'll have only two skin systems instead of four. When someone feels motivated, they can port the old skins to the new system in some format. (It's okay IMO if they're not exactly the same, as long as they look similar enough.)
On Tue, Feb 9, 2010 at 8:35 PM, Trevor Parscal tparscal@wikimedia.org wrote:
I'd still be interested in seeing some differences between Vector and Monobook HTML that are necessary at all. There are a *lot* of small, seemingly gratuitous differences that could be wiped out, like:
* No <div id="globalWrapper"> or <div id="column-content"> * Two empty <div class="noprint"> at the top, also <div id="mw-js-message"> * Lots of extra comments like <!-- sitenotice --> <!-- /sitenotice --> * <div id="head"> instead of <div id="column-one">, and it has class="noprint"
and so on. These all make things harder to do and will force code duplication. Every id or element that exists in one skin but not another means it's that much harder to write portable scripts and styles. If we want more comments, or extra empty divs for JS to hook into (why not create those with JS like we do with jsMsg in wikibits.js?), then add them to *all* skins. And if Vector doesn't need globalWrapper or column-content, it can have them anyway but just not style them -- that doesn't hurt anything.
(These concerns all apply to Modern as well, which I also complained about when it was introduced.)
I'm also concerned by the fact that at least some (I haven't looked closely) of the Usability Initiative stuff seems to work only in Vector. For instance, apparently EditWarning doesn't work at all in non-Vector skins, although it's surely just as applicable. Skins should *only* be used to provide different visual appearance -- they should not be creating functional differences. Users should be able to choose which skin they prefer based on aesthetics alone, without having to sacrifice features to use their preferred skin.
2010/2/10 Aryeh Gregor Simetrical+wikilist@gmail.com:
EditWarning only working in Vector is a weird quirk that is indeed unnecessary. The other Vector-only modules, however, do stuff that's rather Vector-specific and need skin support (like collapsing tabs, enhancing Vector's search box, etc.).
Roan Kattouw (Catrope)
On 2/10/10 6:55 AM, Roan Kattouw wrote:
EditWarning works in any skin. It's only turned on on Vector because there was this concern that the "Read" tab would cause people to leave the edit page without thinking about their edits. I never agreed with this notion, but we added it in to appease those who did.
- Trevor
On 10 February 2010 14:45, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Main thing is to let people know on the larger wikis that a change to the skin engine is coming, and if they want ObscureSkin or PrimordialSkin they are heartily welcome to hack on the CSS. (I'd guess good web designers would be much easier to find than good PHP developers.) As long as people are warned and asked to help, it should avoid ruffled feathers on the part of the users.
(Hmm, wonder how easy it'd be to put a Nostalgia skin on Monobook ...)
- d.
Aryeh Gregor wrote:
Me too. And that's a good example of the things I'd like to have fixed before 1.16 so we can completely change the way some things were done on vector. Enough code had to be adapted (innecesarily) to vector on wikipedia now. Why force third users to vectorise if we are going to change it back?
On 2/10/10 3:50 PM, Platonides wrote:
Not all changes made in the HTML output of Vector were made arbitrarily or gratuitously as is being assumed here.
In i18n, you have to be careful about using the same message key in multiple places, because as the context changes in each of those places, the likelyhood of the message being ideal in all situations in all languages decreases. Similarly, relying on identical HTML structure and classification for dissimilar skins is a bad practice to keep scripts and hacks from having to be customized is a fatal mistake. Vector has a distinctly different approach to..
* Navigation structure - the namespaces, variants, views and actions are all separate lists * Right-to-left compatibility - lists are actually generated backwards in RTL modes (look at the personal tools in Monobook in RTL - it's not in the correct order, and in Vector it is, even on IE 5.5) * Search - it's not a portal anymore, it's part of the skin and it's in the top right which has many incompatibilities with layout assumptions made for other skins * Footer structure - Links to places and information like copyright notices are separate lists and rendered differently
These are not "gratuitous" changes in the UI, and the effects they have on the resulting HTML output aren't either.
What happened to column-one and column-content? Well, Vector doesn't layout the same way that Monobook does, and given that styles meant for those IDs were and would continue to be a problem. I took the oportunity to name them more sensibly, and avoided future issues of people putting things in global CSS that obviously belonged in Monobook.css. Look at the revisions to shared.css and you will see allot of things that were moved to skin-specific CSS files that should have never been in the global one.
As to the point of the two empty divs, they are absolutely used, and they are specifically noprint for good reason. The tags area actually:
<div id="page-base" class="noprint"/> <div id="head-base" class="noprint"/>
As for the tag: <div id="mw-js-message" style="display: none;"/> - this is used for the ajax watch and unwatch functionality and is also present on Monobook once you use it. The difference is simply that Vector provides it ahead of time. I didn't do that
Also, Why would you want to print the contents of the head? The printable version of Vector has been carefully crafted. If there's a noprint class somewhere, it's on purpose.
Finally, those comments are useful for debugging purposes. If they are offensive, they can be removed - obviously they have no other functional properties.
Furthermore, if you take a quick look at the revision history of Vector, you can see that we've done all we can to make things compatible with Monobook where it makes sense. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/Vector.php?view...
So, I hope that answers some of these questions. I'm glad to answer more.
- Trevor
On Wed, Feb 10, 2010 at 8:03 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Not all changes made in the HTML output of Vector were made arbitrarily or gratuitously as is being assumed here.
No one was assuming that. I pointed out several differences that *are* gratuitous, in that they do not provide any functional difference that should logically be related to users' skin choice. Either they're good and should be in all skins, or bad and should be in no skins, or they're neutral and may as well be in all or none just for consistency's sake. None of them has any reason to be present in one skin but not another.
Why? If the skins can be given identical (or nearly identical) HTML structure, then give it to them, and the scripts will work. Or some percentage will break, fine -- but you don't have to deliberately break all the rest too.
The only substantive differences I can spot here at a glance on localhost are that namespaces are their own list (is this actually necessary for some reason? surely the gap can be added with CSS somehow), and there's a "Variants" list which is empty (which is invalid HTML, incidentally). Plus a lot of stuff has different classes and id's for, again, no apparent reason.
Then why shouldn't all other skins be changed to do this too? This is a bug in Monobook, and you've only fixed it in Vector rather than in all affected skins. Why?
Such as? The HTML looks virtually identical in any case.
* Footer structure - Links to places and information like copyright notices are separate lists and rendered differently
The differences in appearance here look like they could be replicated in CSS without using different HTML for the two skins, offhand.
These are not "gratuitous" changes in the UI, and the effects they have on the resulting HTML output aren't either.
I haven't yet seen any case where a difference in the HTML is actually necessary to achieve some effect. There might be one or two, I'm happy to admit that, but there are sure a lot of differences that are *not* necessary, and those should be fixed.
What do you mean by this? Anyone who tries applying styles that affect the layout of one skin, to another skin, is obviously going to see their styles break one way or another. The problem will not be helped by changing the id's -- it will break either way. But changing id's will break scripts unnecessarily, too. And break styles that would happen to work across skins.
If we want to change id's to more sensible names, then why don't we do it in Monobook too? The only reason not to is that it would break scripts and styles -- but switching to Vector as default would do that anyway. (I don't think we should do this; I think Vector and all other skins should just use the silly old names for backward compatibility.)
Can you point to where this is actually a problem? I can point to very clear evidence that using different classes/ids across different skins is a problem. On enwiki there's a gadget: "Compatibility function to run scripts only tested on Monobook on the new Modern skin. Required for using Twinkle or Friendly (along with many other scripts) with the Modern skin." Look at the source code:
http://en.wikipedia.org/wiki/MediaWiki:Gadget-modernskin-thunks.js
If that doesn't indicate that changing IDs creates real problems that can be easily solved by just using the most similar ID in the original skin, I don't know what does.
Not to mention the lengthy list of skin-related commits that have to change four files at once because they're changing some HTML output. If you maintain separate HTML where not strictly necessary, any change to the similar HTML must be made in all relevant files. This is what we're trying to *avoid* with a new skin system.
I just looked briefly through every last revision ever made to shared.css since it was created in January 2007. I found exactly one that moved code from shared.css to skin-specific CSS:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/30734
Can you point me to all this other stuff that was moved out of shared.css? On the other hand, there are a *lot* that move code from skin-specific CSS to shared.css. That was the point of the file, in fact.
What are they used for? JavaScript? If so, why doesn't the JavaScript just create them when necessary, as jsMsg does? And what JavaScript is this that isn't useful for Monobook?
If it's better to provide it ahead of time, then all skins should. If not, not. (And it's not better IMO, it's needless clutter.) Why should there be any difference between skins here?
Monobook relies on
.noprint, div#jump-to-nav, div.top, div#column-one, #colophon, .editsection, .toctoggle, .tochidden, div#f-poweredbyico, div#f-copyrightico, li#viewcount, li#about, li#disclaimer, li#privacy, #mw-hidden-catlinks { /* Hides all the elements irrelevant for printing */ display: none; }
from commonPrint.css. If Vector had used #column-one instead of #head, it wouldn't need class="noprint" here. (As it is, it could just add #head to the list and ditch the class. Along with all the other places it uses class="noprint" -- that's most useful for user-added content, not interface elements.)
It's not a question of whether they should be removed or not. There's no conceivable way that they're useful in Vector but not in Monobook. They should be in both or neither.
The same goes for every single thing I pointed out. Some of them are good changes (like reordering lists for RTL), so those should be in Monobook too. Some of them are, IMO, bad changes (like adding empty elements that are only used as script hooks), so they shouldn't be in Vector either. But there is no reason for a *difference*.
So, I hope that answers some of these questions. I'm glad to answer more.
My basic questions is: how do you expect us to get rid of all the code duplication we have now if not by merging as much HTML-generating code as possible, and thereby also making the generated HTML the same where possible? The only sensible way for us to proceed is to have all skins output the same HTML, except where there's a *good* reason for a *difference*. Not just a good reason to do it one way or another, but a good reason to do it one way in one skin, *and* a good reason to do it differently in another skin. Anything else results in duplicated code and creates headaches for us and scripters alike.
On Tue, Feb 9, 2010 at 1:58 PM, Jack Phoenix jack@countervandalism.net wrote:
It's not, but it helps if you're checking that the output is the same. If only whitespace is changed, then diff -w | grep -v '^[-+]$' should work fine. If you've reordered anything, then it will be more tedious -- that's more likely to actually change semantics, so would have to be manually checked for correctness.
Jack Phoenix wrote:
Commit it to a branch, whether it's ready before or after the 1.16 branch point. We don't really want trunk to become instantly unusable after the branch, as developers dump all the experimental code into it that they've been saving up for the last few months.
I'd like to see a benchmark. Executing the skins is a large part of average CPU time due to the fact that it runs on parser cache hit, and the current Monobook is spookily fast compared to other solutions I have trialled, despite all the indirection.
-- Tim Starling
On Tue, Feb 9, 2010 at 6:58 AM, Jack Phoenix jack@countervandalism.net wrote:
Hi all,
...
Jack Phoenix
jack, I would suggest if you don't already have SVN access then to request it on wiki(1), Then if/when you get it create a (or ask someone to do it for you) branch and start working on and then more people can help and work on it at once.
(1). Commit access requests - MediaWiki -- http://www.mediawiki.org/wiki/Commit_access_requests
Already has commit access and is committing[1]
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/ashley
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of K. Peachey Sent: Thursday, February 11, 2010 6:36 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Skin system rewrite
jack, I would suggest if you don't already have SVN access then to request it on wiki(1), Then if/when you get it create a (or ask someone to do it for you) branch and start working on and then more people can help and work on it at once.
wikitech-l@lists.wikimedia.org