User:Netoholic/Avoid dynamic templates

Template messages allow certain standard text to be included on many pages, usually with the idea of providing a feature which is standard across many pages. Many templates include use of parameters, which change some aspect of how the template is displayed (ex. the "name" in Template:Infobox).

Some templates have been designed such that the presence, absence, or content of parameters change not only the displayed text, but also dynamically alter the overall structure of the template (for example, hiding an entire "Infobox" row if a parameter is not defined).

While they can be useful and convenient, conditionals in templates should be avoided due to concerns that may not be immediately obvious: they require the template source to be overly complex, they discourage uniformity of template appearance across articles, there are no conditional methods built-into the software, and the present methods ("hacks") used to implement conditionals (via meta-templates or CSS) are both undesireable. The reasons listed on this page argue against using conditional templates.

Harmful effects

Complexity

Template source

(examples)

Articles

Long lists of optional parameters are a burden on authors, because often, one cannot simply copy the template call from one article to another. It's often true that new optional parameters get added over time, and those additions are only documented on the template's talk page.

Nonuniformity

The goal of any template is to present a uniformly structured appearance, often with some subtle content difference, particularly when using "Infobox" templates. So that information can be correlated between articles using any particular template, the structure should match as close as possible. By using conditionals to hide structure (such as row headings), readers can't expect to relate similar articles to each other and editors won't be able to see where information is needed.

This situation usually happens as a result of extra functions or information that has been added long afer the template is in wide use. Because people don't want to disrupt the look of older pages, they use conditionals to hide the structure. In this situation:

Decide whether it expected that the new feature or content is appropriate for all, or nearly all, the articles using that template. If not, then the content may be better suited for the article body, rather than the template.
Often, you can prepare for the change by first adding the new parameters and content to the articles first. These are hidden from view. Once complete, structure of the template can be updated, and is immediately reflected in the articles.
Rather than hiding the structure (row) around the new parameter, consider leaving it visible and setting a Parameter default (either to blank or something like "not available"). This allows future editors of the related articles to see where content needs to be filled in. By hiding such structures, often only the template editor is aware of it.

Use of conditionals for a short-term migration is acceptable, even convenient, but relying on it as a long-term solution is not.

Lack of native support

Currently, MediaWiki supports only one conditional mechanism -- the ability to describe a parameter default -- alternate text that is displayed if the parameter is not set. Wikimedia developers have expressed in interest in bringing some basic conditionals into the software, but it's unknown how they will be designed. It is probable that structures created today will break and require revision^Brion.

Undesireable methods

Several methods ("hacks") have been created to allow conditional expressions within templates, but each has its own limitations which make not avoiding them preferrable:

Template:Qif, and related templates -- these perform a wide range of functions, but the mechanism can only be used by resorting to nested templates. The template source code is often difficult to understand.
Wikipedia:HiddenStructure -- this makes use of CSS to hide text from view. Because this is handled by the browser, the hidden text is still sent to the client. It fails if CSS is disabled or not supported; such as on older versions of text browsers and screen readers.
Blank parameter (aka "Weeble") -- This method requires that each template call (on each article page) include a blank parameter ( {{template|if=|param=data}} ). Requiring this on every page using a template is hard to justify, and the template source code is often very hard to understand.

Alternatives

Evaluate - Look at what optional parameters are defined and see how many articles actually make use of them. If too few use it, perhaps it should be removed. If many use it, perhaps it should be a non-optional standard.
Specialize - It might be nice to have one template which can cover all contigencies, but that goal is often impossible. Sometimes, a subset of articles using a particular template can be split off onto a new one. If you create alternative templates, use an understandable naming convention and document all related templates so that they can be found easily . Specializing should be done in "giant leaps" - where the new page will clearly be used on a large number of articles.
- But don't overdo it - Creating more and more templates, to support narrow or minor differences, is a usage and maintenance nightmare. Be prepared, and willing, to re-merge templates in order to bring back uniformity and remove extraneous differences.
MediaWiki needs developers - Mechanisms that natively provide support for conditional expressions do not exist today. See m:How to become a MediaWiki hacker.

Still want to use them?

If you are considering using a conditional template, ask these questions:

Is the desired effect only achievable through a conditional requirement?
Will later editors understand how this works? On the other hand, will later editors understand the alternative method?

You should not use conditional statements in templates without good reason. If you do create one, be open to other methods which achieve the same end, and be prepared to trade functionality in favor of avoiding problem.