User:Dantman/Skinning system

Defined areas
MediaWiki's SKinTemplate system has several defined areas. ie: Areas which are expected to be part of a skin and generally have a similar pattern across multiple skins. Some of these are good defined areas for skins, some result in limitations in the ability to skin MediaWiki in the desired way.

body area
tagline:

undelete:

subtitle:

bodytext:

catlinks:

content_actions / content_navigation
content_actions / content_navigation define the primary navigation related to the page. They are usually expressed as tabs above the page in de-facto wiki style. Originally these were defined inside content_actions as a array. Vector then re-implemented, or rather duplicated the whole content_actions code locally to create a new version which was categorized. This new version has been merged back into SkinTemplate and unified with content_actions to create a single standard that works with both formats. The vector hooks are used when building build the new content_navigation, and the old content_actions hooks are completely gone, instead content_actions is now built by folding content_navigation's arrays into a single array, with a 'redundant' key for things like "Read" to indicate they should be discarded when folded.

Bug: Legacy skins have a hack inside them that is still hardcoding a call to the old SkinTemplateTabs hook.

Goals?:
 * For now the categorization is probably good enough. There might be a more free form way to do this, but that needs more thought.
 * We have a hardcoded 'class' key which contains things like 'new selected', if possible it would be MUCH better to define these standard attributes as keys themselves instead of classes and merge them into classes later. So that extensions can hook these in a much better way.
 * We have a 'redundant' key that causes tabs like 'read' to be discarded when content_navigation is folded into content_actions. On the todo is also something like an 'after' key. Some tabs may have a good location inside categorized menus and whatnot, however when folded to a single array they don't get placed in the optimum place. An 'after' key would be used to reorganize them to a location right after another key in the array.

logo
Our wiki logo setup simply defines one url. $wgLogo defines the location of the logo. In SkinTemplate a 'logopath' key is directly set from $wgLogo, we have a Skin::getLogo which simply returns $wgLogo, which is used by a logoText which is called by SkinTemplate and simply set as part of a 'logo' key. However modern skins appear to only use logopath in building their own logo box.

Right now the logo set by $wgLogo is expected to be sized at something around 150x150px, absolute maximum 155x155px. This is not hardcoded into the system, but rather every skin we have made was built with a logo area of this size, and it's become a de-facto standard as the only logo size we have. Skins which don't like the size of this logo region are either forced to compromise their design in order to fit the standard logo region in them or they are forced to define a hardcoded or non-standard method of configuration for the skin's logo.

Goals:
 * Define some way for multiple logo sizes to be configured in LocalSettings.php, skins should be able to make a logo call defining what size their logo region is and MW should give them the best fit logo size it can find.

copyrightico / poweredbyico
These two pieces formerly defined the copyright and poweredby icons. These have been deprecated in favor of footericons.