On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
On this point, I think we need:
* Easier management of non-PHP skins (i.e. CSS and images only)
* Automated CSS generation (per original post)
* Easier ways to modify the document structure, with less PHP
involved. XSLT?
* An interface in PHP that we can live with, so we don't feel obliged
to keep breaking it.
XSLT is a non-starter unless we want fatal errors (or at least the
skin completely breaking) on pages where we emit malformed XML. And
there always have been some of those, and probably always will be.
Probably even more significantly, XSLT is a programming language and a
rather obscure one. If we're going to make MediaWiki skins so hard to
make, we may as well stick with just requiring that they be in PHP.
The standard way to handle skinning in web apps, AFAICT, is to chop
the interface up into templates, and stitch them together at runtime.
Then skinners can modify the templates one by one, and on upgrade they
only have to merge changes for the templates they've changed. Which
is still a huge pain for even moderate customizations, as I can attest
from personal experience. But it has the advantage that skinners only
need to modify HTML and CSS, not PHP or XSLT or whatnot.
As it happens, most of the essential differences between skins can be
reproduced using only CSS, if you know enough CSS. I once personally
wrote, in about an hour, some CSS that made Monobook look almost
pixel-for-pixel identical to Modern, with no HTML changes. The only
problem is I didn't bother fixing IE, so it wasn't committable. I
don't think almost any reskin should need to change the HTML at all,
except maybe to add classes and such (which can be done in core). It
should only be necessary if you really want to change how the
interface behaves somehow (like having extra buttons), rather than
just how it looks.