Help:TemplateStyles

TemplateStyles is a tool to enable complex styling of templates without administrator privileges.

How does it work?
Editors can add  to a page and the contents of   will be parsed as CSS, sanitized and loaded on pages where the   tag is used (directly or by being used in a template that's being used in a page).

must have the   content model, which is the default for subpages in the Template namespace that end with. The recommended usage pattern is to store the styles for  under a subpage like.

If  lacks a namespace prefix, it defaults to the Template namespace. Thus, for example,  will load.

The  tag should be placed before the content that is styled, e.g. at the top of the template, to avoid a potential flash of unstyled content if the page is partially rendered while being loaded.

What problems does it solve?
Traditionally, there are two ways to style templates (or any other content): by using inline styles (that is, using HTML code and adding attributes like  to it) or by using certain special system messages such as MediaWiki:Common.css. Neither of those approaches work very well.

For inline styling:
 * There is no separation of content and presentation. In cases where the content does not come from a template (e.g. tables in articles), that will result in article wikitext that's unintelligible for most editors.
 * Since styles are mixed with wikitext, syntax highlighting and other forms of CSS editing support are difficult or impossible.
 * Styles have to be repeated for each HTML element they apply to, which results in lots of copy-pasting and code that is hard to read and maintain.
 * Style attributes are limited to a subset of CSS. Most importantly,  rules needed for responsive design do not work so it's impossible to make templates that work well over a wide range of screen sizes. Furthermore, inline styles take precedence over CSS stylesheets so user-, skin- or device-specific customizations become more difficult.

For system  pages:
 * Editing is limited to administrators, which is a major barrier to participation.
 * Editing restrictions cannot be lifted as there is no way to limit what CSS rules can be used, and some of them could be abused to track readers' IP addresses or even execute scripts in some older browsers.
 * Changes are impossible to test without saving first.
 * All stylesheets must be loaded on all pages (whether they actually use the page or not), which wastes bandwidth and makes debugging style rules harder.

TemplateStyles allows editors to associate style rules to specific pages, provides the full power of CSS stylesheets while filtering dangerous constructs, and works with preview/debug tools (such as TemplateSandbox) as expected. Lowering the access and maintainability barrier will hopefully result in more innovation in the way templates are visually designed, less maintenance overhead, and better adaptability to screen options (especially mobile devices which by now constitute half of Wikipedia pageviews).

Is it safe?
Yes! TemplateStyles includes a full-fledged CSS parser that reads, re-serializes and escapes all code and removes CSS rules which do not match its whitelist. The parser is sufficiently fine-grained to reject remote resources (such as background images) but allow local ones. CSS selectors are rewritten so that they cannot refer to elements outside article content. (Visually modifying areas outside article content by displacing parts of the article, e.g. via absolute positioning, is not prevented at this time. This is no change from the status quo, as such a thing was already possible with wikitext and inline styles.)

What CSS rules are recognized?
Currently, TemplateStyles accepts most CSS3 properties supported by one or more major browser (as of early 2017). Beyond simple rules,,  ,  ,   and  /  at-rules are also supported (with font-face restricted to fonts whose name starts with  , for security reasons).

Non-standard properties (including vendor prefixes) are not currently supported. See T162379 for plans.

What anti-abuse features are provided?
The design choice to store CSS in separate pages was made in part to make integration with the standard anti-abuse toolset easy. TemplateStyles CSS pages have their own content model so changes to them can be tracked or controlled with AbuseFilter, using the   variable.

How were the decisions around TemplateStyles made?
The idea of including CSS with templates was proposed and accepted in a request for comments. Technical details were pinned down in a second RfC and workflow details in a user consultation.

Who is working on TemplateStyles?
TemplateStyles was originally a project of the Wikimedia Reading Infrastructure team (preceded by exploratory work Coren did as a volunteer), then people moved around. It is now maintained by an ad hoc WMF team consisting of Dan Garry (product manager), Brad Jorsch and Gergő Tisza (developers) and Chris Koerner (community liaison).

Where do I report errors / ask for features?
Please use Phabricator and file tasks under the TemplateStyles component; you can use this link.

Where can I see it in action?
Right here. The content below is styled using template styles (see Template:Stylish and Template:Stylish/styles.css). The tables below use CSS that uses the  pseudo-class which cannot be used in inline CSS.

Another good use case is making templates responsive. "Responsive", in this case, means that elements dynamically grow, shrink, move around or become hidden depending on a device's features, such as height or width. Template:ResponsiveAmbox is a modified version of Template:Ambox that uses Template:ResponsiveAmbox/styles.css. The styles will hide the image to the left if the browser window is narrow enough. Here's an example:

Just like with the previous example, this cannot be done using inline styles.

The feature is currently enabled on the following Wikimedia sites.
 * test.wikipedia.org
 * wikitech.wikimedia.org
 * mediawiki.org
 * sv.wikipedia.org