Hello,
I am currently rewriting the skin system. The aim is to provide our users to easily install a new skin.
I commited a big design change this night:
* Skin.php and SkinPHPTal.php stay in /includes/ as all skins depends on them.
* SkinCologneBlue.php, SkinNostalgia.php, SkinStandard.php, SkinWikimediaWiki.php + class calls in SkinPHPTal.php are moved under /skins/ directory.
My next steps other the next days will be to move /stylesheets/ and /templates/ in the skin directory and build the skin detector :o)
Once my code is finished, skin designer will just have to zip a tree like: / -- skinname.php // php class -- skinname.xml // PHPTal template -- skinname/ -- bla.css -- IEFixes.css -- picture*.png
Then a end user will just have to unzip the skin designer file to the /skin/ directory and the new skin will be available :o)
Ashar Voultoiz wrote:
Hello,
I am currently rewriting the skin system. The aim is to provide our users to easily install a new skin.
I commited a big design change this night:
- Skin.php and SkinPHPTal.php stay in /includes/ as all skins depends on
them.
- SkinCologneBlue.php, SkinNostalgia.php, SkinStandard.php,
SkinWikimediaWiki.php + class calls in SkinPHPTal.php are moved under /skins/ directory.
My next steps other the next days will be to move /stylesheets/ and /templates/ in the skin directory and build the skin detector :o)
Once my code is finished, skin designer will just have to zip a tree like: / -- skinname.php // php class -- skinname.xml // PHPTal template -- skinname/ -- bla.css -- IEFixes.css -- picture*.png
Then a end user will just have to unzip the skin designer file to the /skin/ directory and the new skin will be available :o)
$wgValidSkinNames is also auto generated by listing the content of /skins/ . The list of skins it detects is:
* Standard * Nostalgie * Cologne Blue * DaVinci * Mono * Chick * WikimediaWiki * MySkin * MonoBook
I am not sure they really looks ok, probably stylesheets aren't properly loaded. Given it's 5:30 am I will check that later with the stylesheets migration.
On Thu, 2004-09-02 at 03:49 +0200, Ashar Voultoiz wrote:
Once my code is finished, skin designer will just have to zip a tree like: / -- skinname.php // php class -- skinname.xml // PHPTal template
I think it would be desirable to be able to add more skins based on the same template easily, without re-adding the xml template or a class. A css/picture dir and the skin name added to an array could be enough.
The idea behind the heavy use of css was mainly to avoid having many templates, and to have a mainly structural xhtml that's as decoupled as possible from the actual appearance. Makes maintanance probably a bit easier and helps with future improvements to the caching system.
I fear that skin designers would be tempted to simply modify the xml if it was mandatory to add a per-skin template anyway.
But then, the caching scheme isn't implemented yet, so it doesn't matter that much currently. Could be hard to reverse though. I found it interesting to see that the website of the athens olympics was ESI-based as well, shows that it's not too exotic technology.
Gabriel Wicke wrote:
The idea behind the heavy use of css was mainly to avoid having many templates, and to have a mainly structural xhtml that's as decoupled as possible from the actual appearance. Makes maintanance probably a bit easier and helps with future improvements to the caching system.
While I applaud your efforts to de-couple, as you say, the document structure (XHTML) from the layout (CSS), I don't agree that we should expect, or even encourage, future skin designers from re-using the same XHTML. I can't speak for others, but I at least find it incredibly hard to make a website look the way I want with just CSS. For example, your XHTML pretty much hard-codes the category box to be at the bottom of articles; to move it up requires JavaScript, which can get extremely messy if you want to move loads of objects around and not just one. Not to mention wanting to move it outside the article div (turn it into a portlet, say).
I fear that skin designers would be tempted to simply modify the xml if it was mandatory to add a per-skin template anyway.
Nothing should stop them from doing so if they so wish.
But then, the caching scheme isn't implemented yet, so it doesn't matter that much currently. Could be hard to reverse though.
In that case, I'll object to any change that would require skins to use the same XHTML ;-)
Timwi
On Thu, 2004-09-02 at 19:49 +0100, Timwi wrote:
I fear that skin designers would be tempted to simply modify the xml if it was mandatory to add a per-skin template anyway.
Nothing should stop them from doing so if they so wish.
That's not what i was suggesting, i was merely lobbying against promoting this way of skinning as it has disadvantages further down the road, mainly with accessibility and caching.
But then, the caching scheme isn't implemented yet, so it doesn't matter that much currently. Could be hard to reverse though.
In that case, I'll object to any change that would require skins to use the same XHTML ;-)
Well, if you want to cache the entire page the xhtml has to be pretty much the same. If you're prepared to generate a new page for every skin you can go the easier route. Then you have to accept that it's not as fast to generate a page many times.
I've tried to move towards more caching in all skin- and pref-related changes i've done so far. Unfortunately enthusiasm for more caching has been very limited so far and it's not completely trivial to implement. No need to fight for something nobody wants. A bit sad nevertheless.
Gabriel Wicke wrote:
Well, if you want to cache the entire page the xhtml has to be pretty much the same. If you're prepared to generate a new page for every skin you can go the easier route. Then you have to accept that it's not as fast to generate a page many times.
Won't this problem go away once we can cache a parse tree? :-)
Gabriel Wicke wrote:
On Thu, 2004-09-02 at 22:33 +0100, Timwi wrote:
Gabriel Wicke wrote:
Won't this problem go away once we can cache a parse tree? :-)
No.
Oh, sorry, I was in the clouds when I wrote that. Of course we want to cache finished pages.
I was just thinking that once we have cachable parse trees, generating a page from it might not be as intensive and "bottlenecky" as currently.
Timwi
Timwi wrote:
Oh, sorry, I was in the clouds when I wrote that. Of course we want to cache finished pages.
I was just thinking that once we have cachable parse trees, generating a page from it might not be as intensive and "bottlenecky" as currently.
Here's a thought: * Have the article as XML (parse tree) * Have the skin layout as another XML (say, <topthingy><categories/></topthingy>) * Have the skin style as CSS * Profit! :-) (I mean, throw them together by parsing the skim XML tree, then "collapse" it by replacing <articlebody/> with the XHTML article)
Skin XML could contain things like <sysop> with optional parts for sysops (delete page etc.) which will be left out for non-sysops. Also, for specific things like background images, there could be <skin>backimage</skin>, where the "backimage" function of the skin class is called.
Magnus
On Fri, 2004-09-03 at 11:16 +0200, Magnus Manske wrote:
Here's a thought:
- Have the article as XML (parse tree)
- Have the skin layout as another XML (say,
<topthingy><categories/></topthingy>)
- Have the skin style as CSS
- Profit! :-) (I mean, throw them together by parsing the skim XML tree,
then "collapse" it by replacing <articlebody/> with the XHTML article)
Skin XML could contain things like <sysop> with optional parts for sysops (delete page etc.) which will be left out for non-sysops. Also, for specific things like background images, there could be <skin>backimage</skin>, where the "backimage" function of the skin class is called.
That's what esi usually does (see http://www.esi.org). Of course, the fewer parts a page is composed of the better the performance. 8 includes yield a performance of about 100 requests/ second on my laptop, about 1/6 of the plain page performance. The big advantage with this is the fact that the assembly happens on the squid, so potentially in France or wherever the closest squids are. Some ideas of how a page could be split up in esi includes are in html comments in early versions of xhtml_slim.pt, the may versions for example. This kind of caching doesn't require too much purge logic, while the next step- incorporating esi tags in the content and implementing parameter-less template includes this way- is more complex.
I'm willing to help implementing the first step if there's interest, not sure about the overall opinion on this.
Gabriel Wicke wrote:
On Thu, 2004-09-02 at 03:49 +0200, Ashar Voultoiz wrote:
Once my code is finished, skin designer will just have to zip a tree like: / -- skinname.php // php class -- skinname.xml // PHPTal template
I think it would be desirable to be able to add more skins based on the same template easily, without re-adding the xml template or a class. A css/picture dir and the skin name added to an array could be enough.
The idea behind the heavy use of css was mainly to avoid having many templates, and to have a mainly structural xhtml that's as decoupled as possible from the actual appearance. Makes maintanance probably a bit easier and helps with future improvements to the caching system.
I fear that skin designers would be tempted to simply modify the xml if it was mandatory to add a per-skin template anyway.
But then, the caching scheme isn't implemented yet, so it doesn't matter that much currently. Could be hard to reverse though. I found it interesting to see that the website of the athens olympics was ESI-based as well, shows that it's not too exotic technology.
Hello Gabriel,
My idea is to allow non-wikipedia site admin to create new skins easily and share them.
For wikipedia caching issue, we could set a skin white list / delete unwanted skins.
Ashar Voultoiz wrote:
My idea is to allow non-wikipedia site admin to create new skins easily and share them.
For wikipedia caching issue, we could set a skin white list / delete unwanted skins.
I am uncomfortable with the thought of having my skin deleted for some mere caching problems...
wikitech-l@lists.wikimedia.org