On 11-03-13 08:20 AM, Marcin Cieslak wrote:
Daniel Friesenlists@nadir-seen-fire.com wrote:
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout I have some plans for a new way of laying out skins in a new skin system.
The key changes being; The creation of new region block handling in the system (default skins typically just including a standard body region and messages region) to replace newtalk, sitenotice, the jsmessage div, bodytext, catlinks, and dataAfterContent (used by flaggedrevs, smw, and other extensions). And changes to what types of navigation we support and how dominant the location of the toolbox is.
This new layout and system will likely be done using a planned xml/html based template syntax. http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_template http://www.mediawiki.org/wiki/User:Dantman/Skinning_system#xml.2Fhtml_templa...
Did you see Zope Page Templates
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx
There is even a PHP implementation out there (TAL).
It's a consistent and mature system (I still prefer tagsoup-like templating, but that has obvious disadvantages).
I did look over TAL. However the data template based nature of TAL would likely result in the ugly use of __get and friends to achieve the same efficiency of not loading pieces we won't use in a skin. And I do believe TAL's syntax is much harder for non-tal users to pick up right away than the syntax I'm looking at. And now that I think about it, I have a feeling TAL is incompatible with most of those advantages of the xml syntax, I probably couldn't apply them and we'd be back in the same spot.
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Skin_examination I would also like to eventually eliminate our three skins using the legacy system (Nostalgia, Standard/Classic, Cologne Blue). They don't "properly" use our SkinTemplate system and require another 930+ lines of code dedicated to their support, full of code duplication which repeatedly gets in the way of new features because we insist that any change we make to the ui should be backported to also work with legacy code.
That depends whether you want to change people or the system. I happened to survive a whole Monobook era on either Standard, Simple and finally settled down on Nostalgia due to its unique feature of having dropdown list of specialpages (I use [[Special:Specialpages]] a lot). Then switched to Vector with some reluctance, but finally accepted it.
If you plan to have a new, pretty and universal templating system for the skins, please do try to accommodate those as a challenge.
It is also worth looking at some non-MediaWiki supplied skins, like one of my almost favourites Beagle (http://beagle-project.org/skins/beagle-skin.tar.gz, that one builds on QuickTemplate/Monobook I think) but you fill find many others. It could be interesting to see those that depart from the typical MediaWiki look (you know, that thing that makes you type "Special:RecentChanges" in the URL bar :)
Not to mention the ever-recurrng subject of the mobile site :)
//Marcin
Structurally nearly every QT/MB based skin I see is not really any different from being MonoBook from the pov of skin engine development, they're really already catered to because that's pretty much the only kind of skin that our current skin system is designed to facilitate. I "am" looking at supporting drastically different structures of skins, eg: the kind you see on baseswiki.org ones with different types of navigation that don't fit within the limited capability of our MediaWiki:Sidebar obsessed navigation model. The kind of skin I bet plenty of businesses trying to adapt MW and personalize it are dying to do. I'm also trying to take into account: Wysiwyg style web builders made to export cms skins and trying to ensure the skin system doesn't drift into a region where they can export to other engines but MW is too fundamentally odd they can't export to it effectively. The ability to create skins without an extra blob of php code for each skin, essentially the ability to create an extension that provides skins from arbitrary sources like the database or on-wiki pages. And take into account template languages and there php exec capabilities and attempt to ensure it's possible to create a baseline majority of skins out of pure-tpl in a way that wiki farms could allow users to upload entire custom skins without fear of script injection vulnerabilities on the farm.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]