On Fri, Sep 25, 2009 at 11:41 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
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.
Adding content is no problem. Just provide a bunch of places where
arbitrary HTML can be injected by configuration. The particular cases
of Analytics and ads should be cross-skin anyway, and currently you'd
be best off doing them using hooks (that's how I do Analytics on my
wiki). What are use-cases for *skins* being able to alter the HTML
output, at anywhere near the level of precision provided by XSLT?
And some modifications
are quite arcane, like reordering boxes by switching them from
ordinary floats to carefully constructed absolute positioning.
That's true, yes. Later versions of CSS look like they'll provide
saner ways to do things, but we're a ways off from being able to use
any of those yet. (The advanced positioning stuff in CSS3 isn't even
close to finished AFAIK, let alone widely implemented.)
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 don't think there's any way to entirely avoid migration issues.
You'd have migration issues with XSLT too, the same way we have
JavaScript that breaks when we add a wrapper div or reorder some
things. The best you can do is localize the damage, so things only
break if they changed that exact bit of HTML.