* Daniel Friesen <lists(a)nadir-seen-fire.com> [Mon, 12 Sep 2011 02:48:35
-0700]:
On 11-09-11 04:56 PM, Rob Lanphier wrote:
> On Thu, Sep 8, 2011 at 11:04 AM, Daniel Friesen
> <lists(a)nadir-seen-fire.com> wrote:
>> Aye, there's absolutely no way HAML is going to fly with the
majority
of
> people building skins.
> Instead of "Why the hell do I have to insert all this junk just to
make
> my skin work right? I'm going back to
WordPress." kind of issue we
had
> before I cleaned up the skin system we'll
end up with a "What the
hell
>> is this syntax? I'm going back to Drupal." kind of issue.
> I'm curious what problem you're trying to solve. It sounds like
> you're trying to get people who are currently working on Wordpress
> skins or Drupal skins to work on MediaWiki skins instead, but to
what
end?
Rob
The "going back to <x>" part tacked on the end was more of a
joke.
I'm trying to solve the flaws in our skin system especially the ones
where our skin system is deficient compared to other theme engines
like
WordPress' and Drupal's. But also trying to
avoid repeating some of
the
same flaws in those skin systems. And taking our
differences into
consideration.
Basically trying to make the skin system compact yet flexible enough
for
someone to build whatever skin they're trying to
make, but without
piles
of unnecessary boilerplate, issues with new features
disappearing,
deficiencies in the skin system making something simple impossible
without implementing a bunch of functional level code like navigation
parsing into the skin itself.
Part of the plan is a new template based system:
- In a template system we can eliminate the <?php echo,
htmlspecialchars, $this->, and other pieces of unnecessary boilerplate
that builds up in a skin. (Rather than `<?php /*...*/
$this->data['nav_urls']['mainpage']['href']/* ... */ ?>`,
`{nav.mainpage}`)
- With context sensitivity and new template keys that understand more
about the data we can eliminate excessively long boilerplate needed to
insert a simple piece of text in a safe way (and make it easier to do
things safely than to accidentally introduce an xss vector).
- With a template the skin system can also understand what is used in
the template and alter the output as relevant to make older skins work
with new features. (eg: If we introduced a page-icons feature into
core
and added a new key to insert that where it best fits
in a skin we
would
have an issue where slightly older skins didn't
have it and when
someone
installed and used them a core feature wouldn't
function. But in a
template based system it's possible for the skin system to look at the
template, note that a location for pageicons is not defined, and
output
the pageicons into the title to put it in a common
location.)
Implicitly the plan also involves ditching the plain precomputed key
=>
value pattern we have. This pattern is the reason for
other
limitations,
like issues with having separate types of nav other
than the sidebar
without having to parse each and every one of them, even when not
used,
and having to extend skin calls with
$this->getSkin().
The most interesting thing I've heard about skin language was XSL with
C-like syntax, mentioned by Gregory Maxwell some years ago in this list.
I don't remember the link, maybe that one?
http://fdik.org/yml/yslt
http://www.xm.co.nz/ShoXS.htm
Dmitriy