On Fri, Sep 25, 2009 at 11:41 AM, Tim Starling <[email protected]> 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.

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to