User:Dantman/Skinning system

Right now a lot of the skin system improvements are improvements, not rewrites of the system. With the exception of the attempt at killing the previous-generation base "Skin" system so that we only have the SkinTemplate system. There are however some faults with the SkinTemplate system. The template has various areas where it is not consulted on what the markup should look like. Helpers are nice, but when the entire generation of the category box markup is hardcoded in the skin class and not defined by the template that is supposed to be defining markup... that doesn't look right. Improvement for now, but creating a 3rd generation skin system that defines the separation between skin area logic and markup template logic much better is in order. A number of these pieces actually shouldn't be set as keys and then passed on to the template. The template should be much more involved in defining what areas there are in the skin, and asking for things. The fact that the template does not ask for things and is instead given a bunch of predefined keys is what causes limitations like skins not being able to easily say "I don't have a standard sidebar, however I have a classic website style of header tabs that need the ability for the user to customize them."

Improvements
Tabbed areas: We appear to have some pages with a dedicated tab area. Internally we have one on Special:Preferences, though the MW bugzilla's custom theme styled after our skins has it too. And I can't say it's not a ui piece that special pages built by extensions won't have any reason to want to copy. We should make this ui piece more easy to utilize and style.

New skin system

 * /Page icons and page subtext/
 * /Regions/
 * /New skin layout/
 * /Templates/
 * /Link lists rewrite/
 * /Customization/
 * A possible example of how Vector might be implemented
 * /Search/

custom / semi-standard link lists
Right now our only link list is the sidebar built from MediaWiki:Sidebar. The parsing code for this is hardcoded. Skins don't always work with this, skins can vary on what kind of navigation they offer, the most common being the sidebar, a single list of tabs in the header, or a multi-level navigation menu. Each of these has different restrictions and advantages, so they must be sourced from different lists. However to avoid skins endlessly adding more lists that can be shared we should define a standard message for each of the most common types of primary navigation. Skins can then come up with new custom ones only when they have an extra custom area that is not suited to the primary navigation and doesn't really make to much sense to share.

I have a partially finished ListMessageParser class lying around I should probably commit.

subskins
In consideration of sub-skins we may want to let skins define special blocks such as:

With a system like that, if a sub-skin defined a template it could use special mw:??? blocks to just override the contents of certain blocks.

Old ideas

 * /Template syntax/php
 * /Template syntax/xml/html template syntax
 * /Template syntax/Wiki-like template syntax/
 * /Template syntax/templates + php/