One of the things I believe we're missing from our skin system is a template language. PHP embedding is excessively verbose, and it makes it impossible to contemplate letting users upload skins at whim in a farm scenario. There are also other things we can't do with php that we can do with a template language, such as preprocessing the template and extracting information about the skin that would've required extra config, and using that as an advantage that lets us keep backwards compatibility based on what a skin has left out while adding new features (eg: adding a pageicons area, but detecting old skins that don't have these and instead automatically combining it with the title key).
As I see it a good template language for us would need to have the following requirements: - No evalable php in the syntax. Such a thing would nearly preclude the safe-skins only scenario. - We should be able to analyze a template; ie: The syntax should not be one that prevents us from knowing beforehand what 'region' tags are in a template, or if say a 'pageicon' key is omitted. - The syntax should be context sensitive; I don't want to see anything where we're explicitly html escaping, url encoding, etc... the syntax should understand whether it's in a html context, an attribute, a href, class, even a inline url(). ie: The syntax and markup must mingle together and be dependent on each other. - The syntax must support calling back to the host rather than requiring all the data pre-generated up front. Being able to call back is an absolutely necessity for the i18n system, and it's also necessary because I intend to have things like other forms of navigation than the sidebar, and we wouldn't want to pre-parse every single one of those when a skin will typically only use one. (This precludes XSLT without even needing to debate whether the language is powerful or clean to use.)
I've already looked over all the existing template languages I could find and found none satisfactory. So in essence what I'm asking here is NOT for people to look for a template library to use, but for ideas on the best template language syntax we can implement for our purposes.
XSLT is already out. And our parser is so complex we would never want to run it on each page, the syntax is also excessive for these purposes, and it can't be analyzed easily either so the suggestion to use WikiText for the template syntax is out too before anyone suggests it.
This is the template language I've been thinking of for awhile: http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_template It fulfills the requirements, though it could use some small tweaks, eg: I might want to rethink the mw:header, mw:content, and mw:icon which aren't first-level things. But my biggest problem with it, is I never included a plan on how to let you do things like omit the login/logout/createaccount links from personal_tools and instead make them button-styled links located elsewhere. The best idea I could come up with was to include the functionality of WikiScripts/Lua/JS or whatever the language that we decide to include into our WikiText templates to deal with Tim's regrets on creating parser functions.
So, I'd love to see other peoples ideas on the best syntax for our skin system. Or ideas or comments on how to fix the problem with the syntax I came up with.
I wrote a node.js module, which could easily be ported to PHP, which uses DOM on the server to pre-process HTML, acting on some specific tags and resulting in clean HTML output. This only works for HTML, so I don't know about your requirements of being able to do this in inline CSS as well, but it's an approach that may work well with MediaWiki. I'm using JSDom in JavaScript right now, and this code works on the client as well, but PHP's HTMLDocument could work too.
The concept is similar to, and based on my jquery.localize plugin, just a bit more powerful. I think it could be extended to support a variety of other features.
Example:
<html> <var:attr set="lang" from="user.lang"></var:attr> <tpl:define as="foo"> <msg:text from="hello"> fallback for missing message <msg:param from="name"> var:textfallback for missing variable</var:text> </msg:param> </msg:text> </tpl:define> <var:go to="user"> <tpl:apply from="foo">fallback for missing template</tpl:apply> </var:go> </html>
There are some other features, but that's generally how it works. Tags in the tpl, msg and var namespaces are handled specially. tpl is a way to define and apply snippets of HTML with preprocessing instructions. msg is a way to grab messages from the localization system, and supports parameters. var is a way to act on a data structure, like a JavaScript plain object or PHP array.
I think the "magic" way of knowing to escape HTML could be applied as well I suppose, rather than explicitly using :html and :text - I chose explicit because I think it makes it easier to review, magic goes unnoticed more easily.
Anyways, just offering up a possible idea - sounds like you have some really specific wants and needs, which may or may not really be common in mainstream MediaWiki development.
- Trevor
On Mon, Sep 5, 2011 at 11:27 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
One of the things I believe we're missing from our skin system is a template language. PHP embedding is excessively verbose, and it makes it impossible to contemplate letting users upload skins at whim in a farm scenario. There are also other things we can't do with php that we can do with a template language, such as preprocessing the template and extracting information about the skin that would've required extra config, and using that as an advantage that lets us keep backwards compatibility based on what a skin has left out while adding new features (eg: adding a pageicons area, but detecting old skins that don't have these and instead automatically combining it with the title key).
As I see it a good template language for us would need to have the following requirements:
- No evalable php in the syntax. Such a thing would nearly preclude the
safe-skins only scenario.
- We should be able to analyze a template; ie: The syntax should not be
one that prevents us from knowing beforehand what 'region' tags are in a template, or if say a 'pageicon' key is omitted.
- The syntax should be context sensitive; I don't want to see anything
where we're explicitly html escaping, url encoding, etc... the syntax should understand whether it's in a html context, an attribute, a href, class, even a inline url(). ie: The syntax and markup must mingle together and be dependent on each other.
- The syntax must support calling back to the host rather than requiring
all the data pre-generated up front. Being able to call back is an absolutely necessity for the i18n system, and it's also necessary because I intend to have things like other forms of navigation than the sidebar, and we wouldn't want to pre-parse every single one of those when a skin will typically only use one. (This precludes XSLT without even needing to debate whether the language is powerful or clean to use.)
I've already looked over all the existing template languages I could find and found none satisfactory. So in essence what I'm asking here is NOT for people to look for a template library to use, but for ideas on the best template language syntax we can implement for our purposes.
XSLT is already out. And our parser is so complex we would never want to run it on each page, the syntax is also excessive for these purposes, and it can't be analyzed easily either so the suggestion to use WikiText for the template syntax is out too before anyone suggests it.
This is the template language I've been thinking of for awhile:
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_template It fulfills the requirements, though it could use some small tweaks, eg: I might want to rethink the mw:header, mw:content, and mw:icon which aren't first-level things. But my biggest problem with it, is I never included a plan on how to let you do things like omit the login/logout/createaccount links from personal_tools and instead make them button-styled links located elsewhere. The best idea I could come up with was to include the functionality of WikiScripts/Lua/JS or whatever the language that we decide to include into our WikiText templates to deal with Tim's regrets on creating parser functions.
So, I'd love to see other peoples ideas on the best syntax for our skin system. Or ideas or comments on how to fix the problem with the syntax I came up with.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 06/09/11 08:27, Daniel Friesen wrote: <snip>
So, I'd love to see other peoples ideas on the best syntax for our skin system. Or ideas or comments on how to fix the problem with the syntax I came up with.
Can you possibly have a look at HAML? It is a basic language that makes HTML 'simpler' and allow variables, if, foreach : http://haml-lang.com/
It comes from the ruby on rails community but has an implementation in PHP : http://phphaml.sourceforge.net/ The page has an example :-)
Might be better than reinventing the wheel.
Another possibility will be to generate an XML document and apply a XSLT stylesheet on it. But I am not sure it will make things easier.
PS: CSS have a similar abstract language: http://sass-lang.com/
My main complaint with Haml and Sass are that they introduce yet another syntax, all while trying to simplify things. On the other extreme XSLT uses XML syntax, but can get pretty complex, usually unnecessarily so - it also introduces XPath, which some developers may not know.
Ideally we should find something in the middle.
- Trevor
On Thu, Sep 8, 2011 at 9:39 AM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 06/09/11 08:27, Daniel Friesen wrote:
<snip> > So, I'd love to see other peoples ideas on the best syntax for our skin > system. > Or ideas or comments on how to fix the problem with the syntax I came up > with.
Can you possibly have a look at HAML? It is a basic language that makes HTML 'simpler' and allow variables, if, foreach : http://haml-lang.com/
It comes from the ruby on rails community but has an implementation in PHP : http://phphaml.sourceforge.net/ The page has an example :-)
Might be better than reinventing the wheel.
Another possibility will be to generate an XML document and apply a XSLT stylesheet on it. But I am not sure it will make things easier.
PS: CSS have a similar abstract language: http://sass-lang.com/
-- Ashar Voultoiz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
It also isn't any better than the current state we're in for context sensitivity.
I already mentioned that XSLT isn't usable. It's not usable as a syntax, and it's not usable as a implementation technique for transforming syntax. We can't take calls back to handle things like i18n with it... The compatibility issues with it are also in a way worse than the other parts of xml in php. If all else fails parsing xml and doing transformations or compiling to php ourselves isn't all too hard. But XSLT? No way in hell will we try to re-implement xslt in basic php for compatibility without xslt installed.
sass is another story though, we're talking about templates here. But, the scss mode of sass is pretty much just css with enhancements so it might work to add support for it. As long as people don't go to overboard with it. We don't want to see people using the import functionality when we're handling concat in RL. And we don't want to see private mixins being used for vendor prefixes we should really be adding compatibility for shortcuts for into core RL. I'm not to keen on Compass that phamlp includes though. Their border-radius doesn't inspire confidence that they actually know what vendor prefixes are supposed to be used. I'd like to avoid enabling that portion of it.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 11-09-08 10:23 AM, Trevor Parscal wrote:
My main complaint with Haml and Sass are that they introduce yet another syntax, all while trying to simplify things. On the other extreme XSLT uses XML syntax, but can get pretty complex, usually unnecessarily so - it also introduces XPath, which some developers may not know.
Ideally we should find something in the middle.
- Trevor
On Thu, Sep 8, 2011 at 9:39 AM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 06/09/11 08:27, Daniel Friesen wrote:
<snip> > So, I'd love to see other peoples ideas on the best syntax for our skin > system. > Or ideas or comments on how to fix the problem with the syntax I came up > with. Can you possibly have a look at HAML? It is a basic language that makes HTML 'simpler' and allow variables, if, foreach : http://haml-lang.com/
It comes from the ruby on rails community but has an implementation in PHP : http://phphaml.sourceforge.net/ The page has an example :-)
Might be better than reinventing the wheel.
Another possibility will be to generate an XML document and apply a XSLT stylesheet on it. But I am not sure it will make things easier.
PS: CSS have a similar abstract language: http://sass-lang.com/
-- Ashar Voultoiz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
It has the benefit that simple things are simple, but you can create complicated things because it's a full programming language.
Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a language, is it? ________________________________________ From: wikitech-l-bounces@lists.wikimedia.org [wikitech-l-bounces@lists.wikimedia.org] on behalf of Russell N. Nelson - rnnelson [rnnelson@clarkson.edu] Sent: Thursday, September 08, 2011 2:18 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system
How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
It has the benefit that simple things are simple, but you can create complicated things because it's a full programming language. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It's over complicated for our needs, and we really don't need another full featured language to learn and parse. It's like saying everyone should learn ruby so we can do skins in it.
On Sun, Sep 11, 2011 at 12:05 PM, Russell N. Nelson - rnnelson < rnnelson@clarkson.edu> wrote:
Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a language, is it? ________________________________________ From: wikitech-l-bounces@lists.wikimedia.org [ wikitech-l-bounces@lists.wikimedia.org] on behalf of Russell N. Nelson - rnnelson [rnnelson@clarkson.edu] Sent: Thursday, September 08, 2011 2:18 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system
How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
It has the benefit that simple things are simple, but you can create complicated things because it's a full programming language. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The *syntax* is simple. You can eliminate "unnecessary" primitives. ________________________________________ From: wikitech-l-bounces@lists.wikimedia.org [wikitech-l-bounces@lists.wikimedia.org] on behalf of John Du Hart [compwhizii@gmail.com] Sent: Sunday, September 11, 2011 12:12 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system
It's over complicated for our needs, and we really don't need another full featured language to learn and parse. It's like saying everyone should learn ruby so we can do skins in it.
On Sun, Sep 11, 2011 at 12:05 PM, Russell N. Nelson - rnnelson < rnnelson@clarkson.edu> wrote:
Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a language, is it? ________________________________________ From: wikitech-l-bounces@lists.wikimedia.org [ wikitech-l-bounces@lists.wikimedia.org] on behalf of Russell N. Nelson - rnnelson [rnnelson@clarkson.edu] Sent: Thursday, September 08, 2011 2:18 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system
How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
It has the benefit that simple things are simple, but you can create complicated things because it's a full programming language. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- John _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Sep 8, 2011 at 11:04 AM, Daniel Friesen lists@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
On 11-09-11 04:56 PM, Rob Lanphier wrote:
On Thu, Sep 8, 2011 at 11:04 AM, Daniel Friesen lists@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().
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
* Daniel Friesen lists@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@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
On Mon, Sep 12, 2011 at 2:48 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On 11-09-11 04:56 PM, Rob Lanphier wrote:
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?
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.
I guess I'm asking for the most important user stories, since trying to be all things to all people is almost certainly going to fail. Is the most important user (to you) an individual English Wikipedia account holder who wants to switch away from the default theme, or a MediaWiki administrator who wants to align the look-and-feel of their Wordpress blog with their MediaWiki install? Do you imagine that the person who creates the next great MediaWiki theme is someone who is a CSS expert, or more of a programmer?
This thread spurred a small conversation in the office over lunch today. I won't speak for the group, but the conclusion I reached from that conversation was that a more achievable and immediately solvable problem to tackle would be to improve the ability to customize skins purely from CSS. That is, create a new skin that makes it really easy to move blocks of content (navigation elements, etc) around and customize their appearance. I would love to see some alignment of other theming systems with our own, so that we can potentially attract theme experts from other projects to port their existing themes to MediaWiki.
Rob
On 11-09-12 04:23 PM, Rob Lanphier wrote:
On Mon, Sep 12, 2011 at 2:48 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On 11-09-11 04:56 PM, Rob Lanphier wrote:
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?
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.
I guess I'm asking for the most important user stories, since trying to be all things to all people is almost certainly going to fail. Is the most important user (to you) an individual English Wikipedia account holder who wants to switch away from the default theme, or a MediaWiki administrator who wants to align the look-and-feel of their Wordpress blog with their MediaWiki install? Do you imagine that the person who creates the next great MediaWiki theme is someone who is a CSS expert, or more of a programmer?
The focus of improving the skin system is naturally the latter. Letting someone with a MediaWiki install and a design take the two of them and make them usable as one.
"the next great MediaWiki theme" is a non-goal. If we were going for the great skin to replace Vector which replaced MonoBook, we'd just put it in core. I'm trying to eliminate the problems in the way of people easily adopting MediaWiki and giving it their look as they can easily with other engines. That's the purpose of a skin system, just about anything else you could shove into core without an extensible skin system.
This thread spurred a small conversation in the office over lunch today. I won't speak for the group, but the conclusion I reached from that conversation was that a more achievable and immediately solvable problem to tackle would be to improve the ability to customize skins purely from CSS. That is, create a new skin that makes it really easy to move blocks of content (navigation elements, etc) around and customize their appearance. I would love to see some alignment of other theming systems with our own, so that we can potentially attract theme experts from other projects to port their existing themes to MediaWiki.
Not interested in a pure-CSS skin there's plenty of things that are impossible to do from css. There's no way we'll see a new innovative skin if it's stuck with the same kind of markup we've been using. All we'll see is more MonoBook clones like 90% of the existing MediaWiki skins are.
I only need to bring up one of the biggest problems I've noticed. Our navigation. We only support the sidebar navigation within our skin system. Any skin that uses navigation that doesn't fit within that very narrow form of navigation needs to completely re-implement message parsing or hardcode stuff. Practically every client design I've seen -- and I'm talking about real designs, for real organizations picking up MediaWiki -- has had a header navigation. BASESwiki uses one, the CCA Wiki design I'm currently turning into a skin uses one, just about every site I've seen us working on for clients has had one, and nearly every WordPress theme I've seen uses that type of navigation menu.
There's no way you can switch between sidebar navigation to header navigation in pure css.
Rob
On 13/09/11 01:23, Rob Lanphier wrote:
Do you imagine that the person who creates the next great MediaWiki theme is someone who is a CSS expert, or more of a programmer?
Ultimately, it should be someone with none of those skills.
I like how blogspot.com let you move around the boxes, change the colors with two clicks and add "widgets" easily.
On 11-09-13 11:23 PM, Ashar Voultoiz wrote:
On 13/09/11 01:23, Rob Lanphier wrote:
Do you imagine that the person who creates the next great MediaWiki theme is someone who is a CSS expert, or more of a programmer?
Ultimately, it should be someone with none of those skills.
I like how blogspot.com let you move around the boxes, change the colors with two clicks and add "widgets" easily.
There's no way the next great MediaWiki skin is going to be built by someone who can't write css+html or hire someone to convert a mockup into a skin and instead uses a ui based tool to build a skin.
Trust me on that, my day job is essentially building a tool to allow designers to build websites and cms themes without touching css or html. And I have about 3 years of experience that tells me that even if I implement my ideas for v4 such a tool will always have an upper limit to it's capabilities that stops it from being usable to create the most interesting new skins.
wikitech-l@lists.wikimedia.org