This is a MediaWiki code design discussion; people uninterested in MediaWiki's guts can safely ignore it.
So, I think one of the big questions third-party admins have is how to skin MediaWiki. Right now, it requires writing some PHP code. I'd like to float some suggestions for how we can make our skin architecture a bit easier for everyone.
In MediaWiki 1.5, I think we should re-focus our Skin classes specifically on *HTML generation*. I think we should keep the name "Skin", just because it's hard not to, but I think we should steer away from using server-side PHP code to do layout design.
Instead of having skin classes for them, I think we should use alternate CSS stylesheets to provide the "look-and-feel" differences -- Monobook, Nostalgia, Standard, and Cologne Blue, as well as future look-and-feels. Hopefully, if we can make this transition, we can open up the process of skinning MediaWiki to people with more CSS/(X)HTML experience than PHP chops, and get more/better-looking/easier-to-use skins. Admins who want to have "branded" styles for their sites could do so with CSS.
To support browsers that can't handle CSS styling (I think lynx is the only one in wide usage that is in this category, but there may be others), we should provide another HTML generation class on the server to make very simple, style-free HTML.
Extensions -- hopefully third-party extensions -- could provide HTML generation from PHP template systems like PHPTal, Smarty, etc. *I* wouldn't use them, but for folks who are really into these templating system, there'd be an option. There may also be call for a skin subclass to generate table-based layout for HTML 3.0-era browsers.
Lastly, I think we should push most of the business logic of skins up to the root class. By this I mean stuff like: figuring out whether or not to show admin function links, or links that should only be shown for articles, or links that should only be shown for logged-in users, or whatever.
Historically this has been replicated in each skin class, but in recent versions there's been some consolidation. It would be great to finish this process and get all this code into one spot in the root skin class. I think the PHPTal/SkinTemplate mechanism -- one function per logical "menu" (nav urls, personal urls, etc.) returning an array of arrays, each one representing a link -- is the best system here.
Attached is a rough class diagram to illustrate these ideas. To summarize:
* Abstract class "Skin" provides a framework and supports business logic for determining which links are shown, etc. * SkinBasic gives rock-bottom, dead-simple HTML. * SkinTemplate is the most-used, default HTML generator. It allows an alternation between multiple CSS stylesheets, and generates the kind of high-quality HTML (or XHTML if the browser is capable) to make CSS-styling simple and useful. * SkinPHPTal and SkinSmarty are third-party HTML-generation classes that use those templating systems. There could be other such classes; they're only on the diagram to illustrate that we want skins to be able to handle this kind of subclassing.
Now, we're awful close to something like this already; I think the SkinTemplate class in 1.4, with some changes for handling multiple alternate CSS stylesheets, is a really good "default" class. Although it's not a requirement, the other HTML generators could use the same stylesheets as long as they generate similar HTML.
The main drawbacks with this kind of system are:
1. We won't have pixel-identical versions of Nostalgia, Standard, and Cologne Blue. I don't think this is a huge problem. 2. Folk wisdom that "Nostalgia makes HTML that can be read in lynx" would become untrue. 3. We have a couple of classes that vary by the user's preferences (SkinBasic versus SkinTemplate), and a couple that vary by the sysadmin's preferences (SkinTemplate vs. PHPTal, Smarty, ...). 4. It's not clear how to allow different stylesheets. There's a good way here: http://www.alistapart.com/articles/alternate/
I realize we're in a release cycle and 1.5-timeframe discussions are somewhat distracting, but I've been thinking about this and figured it was worth discussing while I still had it in my brain.
~ESP