User:Dantman/Skinning system/SkinTemplate 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.

page title

Our page title is fairly fine right now, <h1 id="firstHeading" class="firstHeading"><?php $this->html('title') ?></h1>. The addition of the class was a nice thing, we need to try switching more things to use reasonable css classes instead of id's. I do have some pipe dreams of letting extensions play well with skins that are designed in a way that plays nicely with having a list of multiple content areas of some sort. Classes get in the way of that less.

One notable thing over the years though has been title icons. A lot of wikis like to put icons on the right side of the title. This is usually done with some ugly css or js. There is a bug open (too lazy to find a link to it right now) on it, we should be defining an api to add icons to this area and making the skin include it.

body area

The current body area is a mix of hardcoded and freeform stuff.

tagline: The tagline is a hardcoded message. Right now <div id="siteSub"><?php $this->msg('tagline') ?></div> is used to insert it into the page.

subtitle: subtitle/contentSub is also semi-hardcoded <div id="contentSub"<?php $this->html('userlangattributes') ?>><?php $this->html('subtitle') ?></div></div> this time it is defined as a key in SkinTemplate.

undelete: The undelete subtitle appears to be tacked on as a hack. I expect it was added because someone needed to add the

newtalk: User newtalk notice. We may want to consider including this inside the subtitle helper, or perhaps not. If we do include it we should probably include a way to easily omit it as it's reasonable to want to put the user newtalk notice in a different location in a custom skin.

jumplinks: Can't say too much... accessibility is nice. This one seams to use hardcoded i18n messages, I think some people might confuse this when building skin though. This is located inside the content area in monobook because it sits near the very top of the page, there is no long navigation list before this. If a custom skin has navigation before the content area then these jump links should very well not be in the content area. I suppose in this case the hardcoded messages is the desirable behavior as different skins have different layouts and this will vary from skin to skin. It would probably be best if this was left out of helpers. Though educating skin developers on good web accessibility may be tricky. The location inside monobook is actually a little bit questionable. These jump links, or "skip links" as they are usually called, are for web accessibility, they are usually expected to be at the absolute start of the page, before any content of any sort. They exist for users tabbing through links and especially for blind users who would have to sequentially go through entire blocks of content, or entire navigation lists, to get to the next area, so they let them "skip" to another section of the page. However in monobook this sits in the content area below the page title and a bunch of subtitles, this may not be desirable.

bodytext: The body text of the page. Well, this one is a pretty much natural and a given. We have one block of text. This area also implicitly includes the print source footer, and the debug (eh?) html, I'm not sure quite what that part is, it's not the debug comment which is inserted before the end of the body. I may have some pipe dreams about being able to designate output in a little more structured way so a skin can decide "hey there is a better way to render this block (edit form, certain special page pieces, etc...) inside this skin" but those can come later, or later later...

catlinks: A standard category box...... BAH!!!, I'd like to kill this one. We use the same style box in all skins, it's basically hardcoded. This one is a restriction, skins should be free to style the category area however they want, and wherever they want, however many times they want, and without being required to override a method in the SkinTemplate class (Not the actual template, the root skin class right now, wrong place for template markup). (one of the reasons I hate the categoryhtml added to 1.17 which was better off not added).

dataAfterContent: This is a rather ugly way to do things. It seams to be a holdover from the old skin.

Goals:

• We should provide an abstract BaseTemplate helper method for inserting the (below the header) standard subtitles that can easily be called.
• We should probably consider fixing up the subtitle setup. Instead of adding a mess of hardcoded siteSub/tagline, contentSub/subtitle, undelete which are essentially nearly the same style of thing we should define a list of site subtitles, have each one define what class they are (sometimes site css likes to hide things like the tagline and redirect link on the main page, however we must make sure that we have a differentiating class so that we can make sure not to hide things like like undelete and diff related stuff which are important), and have a standard helper to simply iterate over the list and output it with proper styling. We may want to try doing away with some hardcoded id's.
• A helper method to simplify output of the standard bodyContent run we have here would be a nice idea.

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.
• Right now we have a variety of js which expects all skins to use the #ca- style of ids on the li, we should try fixing this to avoid restricting custom skins.
• 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.

search

Search area was traditionally inside the sidebar on monobook, vector has it in the upper right. Our search form is defined yet not defined. I've abstracted some of the buttons however it's best I abstract more of it, we still have to much boilerplate for a simple search box. The way vector has hardcoded some of it's fancy features isn't completely desirable either. We may want to setup the skin helpers in a way we can vary what box type is used skin by skin but still use the same helper.

I'm not quite sure what to think about our go vs. fulltext searching. Our interfaces that include the distinction aren't entirely desirable, they look ugly, hence people like the pure 'go' style search box. At the same time there are cases where go does not take us where we actually want, and we want to do a fulltext search instead. In these cases the pure-go search boxes get in the way. Search boxes also don't preload what we just searched, which may be desire-able for search tweaks in go results (html5 sessionStorage?, remember cookies are evil for this kind of thing, don't want cross tab pollution). My thought is we may want to go pure-go and have some sort of js inserted 'Is this what you were looking for? Would you like to try doing a full <search> for "<what you typed in>"?' message. Or we may want to consider the kind of search additions in things like Firefox's search box or ones on other websites, where there is a icon on the left side you open a dropdown for to select what type of search you are making. In this case it would allow users to switch from the default 'go' to a fulltext search.

sidebar

• Fault: The SEARCH, LANGUAGES, TOOLBOX addition was interesting, however it was not implemented in a way very flexible to new custom areas. And some skins don't even have these areas. I need to mull over this area a little more.
• Fault: Not every custom skin wants a sidebar the way we define. They may have areas like a header menu for navigation instead. Instead of this hardcoded sidebar we need a way to define customizable navigation areas, and account for the most common types (navigation sidebar with multiple boxes of one level links, a multi-level navigation hover menu, and a concise list of navigation tabs in the header, potentially a horizontal set of tabs with vertical hover menus (though this may be feedable by the earlier multi-level hover menu data)) we may also want to define a way for these areas to be hooked in by extensions wanting to simply define magic words to do things like expand #category-Foo# into a menu or set of links containing links to pages inside of the category "Foo". Primarily of all, it should be easy for custom skins to define various areas like these.

toolbox

• I improved this, but it needs more improvement, more though. It used to be completely hardcoded. I need to make some improvements that'll let me integrate this better into Monaco's dynamiclinks so that things like SMW's data browsing link don't disappear.

footerlinks

Footerlinks lists a number of keys do dump into a list in the footer. This is a little ugly due to legacy stuff. It would really be nice if what we were dumping was not a list of keys in the skintemplate. We should be able to just add things to the actual footerlinks array, hard keys in the skintemplate should disappear, and it should be flexible enough that we can actually add links extracted from a MediaWiki: message, which we can't do now cleanly because each footerlink requires a coresponding template key.

copyrightico / poweredbyico

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