Aryeh Gregor wrote:
On Fri, Sep 25, 2009 at 1:19 AM, Tim Starling tstarling@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.
I think it makes sense to provide some way to modify the DOM after the base skin is finished making HTML. Some things can be done with CSS, but you don't want to be making heavy use of #id:after{content:"..."} to add in some advertising or analytics HTML. And some modifications are quite arcane, like reordering boxes by switching them from ordinary floats to carefully constructed absolute positioning.
You can do DOM manipulation in PHP, I just thought that using a more restricted language might help avoid some of the migration issues that keep coming up.
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.
The template engine libraries are slow, and PHP with embedded HTML (like MonoBook) leads to code which is scary from a security perspective due to the difficulty of reviewing the many echo statements. And it doesn't solve the problem, because you end up with migration issues when you need to add more items to the output or change the existing items in some fundamental way.
I mentioned the fact that Wordpress accelerates loading by moving scripts to the bottom of the page, I didn't mention that it only works for properly maintained skins since many Wordpress skins don't call the correct footer function.
-- Tim Starling