Help:Markup reference

Jump to: navigation, search

This is a reference guide to the technical aspects of formatting articles, using the MediaWiki software behind Beginners do not need to understand most of this: the simpler help page Editing covers the basics used in writing articles.

This article concentrates on telling you how to format articles in the way you want, but there’s also some guidance on what editors should want. The page may seem alarmingly long. It’s a reference, to be consulted when some more complex bit of markup may be required to achieve the desired result.

MediaWiki is the software behind not only but also Wikipedia (for which it was created) and many other websites. If you’re experienced with one of these, you should find that most of this page tells you things you already know. (If is your first exposure to wiki markup, then you’ll be able to apply what you learn here elsewhere too.)


The browser language preferences for's visitors are 58.6% English (as of March, 2012); with the next most common language being German, at 3.6% percent. Articles for should be in the English language, with the exception of brief phrases in other languages which can help identify items or illuminate terminology used by manufacturers. prefers to use the native spellings of proper names from other languages: See the note below on inserting accented characters.

US conventions for spelling and usage are familiar to the greatest number of site visitors (color, gelatin, aluminum, etc.), and in starting new articles these are preferred. (In the case of markup "align" tags, the US spelling center, rather than centre, is mandatory.) When editing existing articles, maintain consistency with the spelling and usage which predominates.

Code in general

Some general notes here about code may avoid either misunderstandings or the need for repeated explanations below.

The code that you type — whether directly or by using the edit buttons immediately above the edit window — is made up of XHTML markup, XHTML-inspired MediaWiki markup, other MediaWiki markup, CSS, and templates. We look at each in turn.

(As we’ll see, markup makes some use of single and double quotation marks. Both must be standard, and not as refined by a word processor: ', not  or ; and ", not  or . Do not use a word processor to prepare text for


XHTML is very similar indeed to the better-known HTML. Here’s an example: I read the <i>New York Times</i> this morning produces “I read the New York Times this morning”. Note the opening and closing tag (code), which take the form of <tag> and </tag> respectively. So: the opening tag for the start of italics, then what is to be in italics, then the closing tag for the end of italics. The principle is general; and thus for example for an entire table first comes the opening tag for the start of a table, then the content of the table, then the closing tag for the end of the table.

In HTML (no “X” in front), an opening <p> is all that’s needed for a paragraph, and <hr> is all you need for a horizontal rule. But in XHTML, a tag such as the former must also be explicitly closed (in this example, with </p>), and an “empty” tag must be explicitly closed with a slash: <hr />.

(Usually, the MediaWiki software effortlessly converts correct HTML into correct XHTML, but in certain situations it may fail to do so. So it’s better to stick to XHTML.)

Not all XHTML tags can be used for editing. Those that can be tend either to have keystroke-saving MediaWiki-specific alternatives or to be for unusual purposes. Indeed, of the XHTML tags mentioned in this section so far, none is routinely used for editing this wiki. (However, BLOCKQUOTE has no alternative; and an XHTML tag that is particularly useful is DIV, although this is not for the beginner.)

For tags that look rather more complex (with equals signs, quotation marks, etc), see “Attributes” below.

For more about XHTML, see “XHTML” (Wikipedia).

XHTML-inspired MediaWiki markup

MediaWiki has some tags that are modeled on one or other of the two patterns — (i) <tag> . . . </tag>; (ii) <tag /> — of XHTML, but that aren’t XHTML. (Examples of the two are <ref> and <references /> respectively; both are needed for footnoting.)

Other MediaWiki markup

The more common kind of MediaWiki-specific markup does not use either of these patterns but instead uses strings of characters that nobody would normally use for any other purpose (e.g. '', a pair of single quotation marks). And for the most part it puts them where they’d go if they were XHTML. So for example I read the ''Guardian'' yesterday produces “I read the Guardian yesterday”.


Whether tags are MediaWiki-specific or XHTML, they should be “nested” properly: if one tag opens and then another opens, then the second should close before the first one does. Wrong (“badly formed”): <b>''this</b>''. Right (“well formed”): <b>''this''</b>.


Many tags can have one or more attributes, suggesting some refinement to them. The pattern is <tag attribute1="VALUE1" attribute2="VALUE2" ...> . . . </tag>; for example, <div class="plainlinks" id="retinette"> . . . </div>. Note:

  • The closing tag is unaffected.
  • Attribute and value are linked by “=” (not “:”).
  • Each value is in quotation marks.[1]
  • Attribute–value pairs are simply separated by spaces (no semicolons, etc), and may be in any order: <div id="retinette" class="plainlinks"> . . . </div> is the same as the example above.

For the attribute style, see the section on CSS immediately below.


CSS (Cascading Style Sheets) is an addition to XHTML (or to HTML) that allows considerable freedom in suggesting the appearance of material. Although it can be added to web pages in various ways, of which “inline” is the most awkward and thus the least used, “inline” is the only way in which the editor of a wiki can add new styles. (Using the “class” attribute, the editor can also invoke styles already provided in’s external stylesheets.) It’s added to a tag via the “style” attribute, whose value contains the set of declarations. The pattern is <tag style="DECLARATION1; DECLARATION2; ..."> . . . </tag>. Each declaration in turn consists of a property followed by a colon and one or more values. For example, <div style="float:right; margin:0 0 10px 10px; padding:10px"> . . . <div>. Note:

  • The closing tag is unaffected.
  • The “style” attribute–value pair is like any other: it can be combined with one or more others, and in any order.
  • Property and value are linked by a colon “:” (not “=”). A space after the colon is optional.
  • If a property takes multiple values, these are simply separated by spaces. (For some properties, the multiple values may be in any order; for others, such as “margin”, the order is fixed.)
  • Declarations are separated by semicolons (and optionally spaces too) and may be in any order: <div style="padding:10px; float:right; margin:0 0 10px 10px"> . . . </div> is the same as the example above.
  • A semicolon may follow the last declaration, but it is not needed.

For more about CSS, see “Cascading Style Sheets” (Wikipedia). Numerous websites provide tutorials and reference guides; the “Style Master for CSS Tutorial” from Western Civilisation is particularly good.


There is some use of templates, added within double braces {{ . . . }}. Templates are specific to the particular wiki (here, to, so you should assume that any you may have encountered in any other wiki is unavailable here. The use of templates is explained below.


Characters on your keyboard

You should be able to type just about any character that’s on your keyboard, to have it rendered in the normal way. Exceptions are:

  • certain rarely used character combinations (such as pairs of single quotation marks)
  • the two inequality signs “<” and “>
  • (in certain unusual circumstances) the vertical line (or “pipe”) “|
  • (within attribute values) double quotation marks “"

The inequality signs will seldom be useful in the context of cameras; but perhaps some company will use one or other of these within a trademark. If you do ever need them, type &lt; and &gt; (which stand for “less than” and “greater than” respectively).

The vertical line, or pipe, is again rarely useful, and is unlikely to be troublesome outside tables. The workaround is &#124;.

Trouble with double quotation marks arises only in vanishingly rare conditions; but if they ever are problematic, the workaround is &quot;.

Characters not on your keyboard

As for all the characters that aren’t on most people’s keyboards and that are occasionally useful — áàäâāăãåą and more — you can do any of the following:

  • type them using the special keystroke combinations used by your computer's operating system
  • copy them from elsewhere and paste them
  • insert them via the “numeric character references” (eg &#333; for “ō”) or named “character entity references” (eg &uuml; for “ü”) that are standard in regular web pages

(On both numeric character references and character entity references, see also “Avoiding special effects”, below.)

Some useful characters are listed below.

Arithmetical symbols

  • &times; gives the multiplication symbol, in for example “6×9 cm”.
  • &minus; gives the minus sign, in for example “3 stops”.
  • &plusmn; gives the plus-or-minus sign, in for example “±2 EV”.
  • &frac14;, &frac12; and &frac34; give the fractions “¼”, “½”, and “¾”.
  • &sup2; and &sup3; give “²” and “³” respectively.
  • &micro; gives the “micro” prefix, “µ”. (The Greek letter “μ”, mu, is correctly separate in Unicode, and given by &mu;.)

Unit symbols

  • &deg;, &prime;, &Prime; for “°” (degree), “” (minute), “” (second)
  • &euro; for “” (euro), &#8355; for “” (French franc), &pound; for “£” (pound), &#8356; for “” (lira), &yen; for “¥” (yen)

For more, see “Currency Symbols”, within “Alan Wood’s Unicode Resources”.

Letters for German, French, and Japanese

Letters with diacritics: acute, grave, circumflex, diaeresis/umlaut, macron
&aacute; á &agrave; à &acirc; â &auml; ä &#257; ā
&eacute; é &egrave; è &ecirc; ê &euml; ë &#275; ē
&iacute; í &igrave; ì &icirc; î &iuml; ï &#299; ī
&oacute; ó &ograve; ò &ocirc; ô &ouml; ö &#333; ō
&uacute; ú &ugrave; ù &ucirc; û &uuml; ü &#363; ū
&Aacute; Á &Agrave; À &Acirc; Â &Auml; Ä &#256; Ā
&Eacute; É &Egrave; È &Ecirc; Ê &Euml; Ë &#274; Ē
&Iacute; Í &Igrave; Ì &Icirc; Î &Iuml; Ï &#298; Ī
&Oacute; Ó &Ograve; Ò &Ocirc; Ô &Ouml; Ö &#332; Ō
&Uacute; Ú &Ugrave; Ù &Ucirc; Û &Uuml; Ü &#362; Ū prefers to use the native spellings of proper names: not “Angenieux” but “Angénieux”; not “Voigtlander” but “Voigtländer”, and so on. French, German, and (usually in Hepburn romanization) Japanese have contributed a lot of names, book titles and so forth to Camera-wiki-org. If you have no more convenient way to add these characters, copy from the table.

For vowel letters with diacritics, see the table to the right. Also useful for these languages are:

  • Ligatures: &aelig; for “æ”; &AElig; for “Æ”; &oelig; for “œ”; &OElig; for “Œ”; &szlig; for “ß[2]
  • Cedilla: &ccedil; for “ç”; &Ccedil; for “Ç

Of course names in other languages should also be given precisely. (See for example “Saulutė”, an article on a Lithuanian light meter, the dotted final letter of whose name must be distinguished from the Lithuanian alternatives “e” and “ę”.)

Other combinations with diacritics (as well as letters not used for any of these languages) can be found in:

all three of which are within “Alan Wood’s Unicode Resources”. (Their order — Latin‑1 Supplement → Latin Extended‑A → Latin Extended‑B — is broadly that of increasing exoticism for English monoglots.)

People consulting may not know how to type the accented characters in the search box, so if you create a page with an accented character in the title, add a redirect from the unaccented name.

Greek letters

Greek letters have easily remembered character entity references: between the & and the ; is the name of the letter, spelled as is usual in English but with the first letter lowercase or capital for the lowercase or capital respectively.

For example, &theta; and &Theta; bring “θ” (lowercase theta) and “Θ” (capital theta) respectively.

Greek and Coptic” (in “Alan Wood’s Unicode Resources”) provides all the information needed.


  • &ndash; and &mdash; give “” (en dash) and “” (em dash) respectively. (The minus symbol is different: &minus;.)
  • &para; and &sect; give “” and “§” respectively.
  • &copy; gives the copyright symbol “©”. (Unicode does not provide a copyleft symbol.)

&nbsp; creates a non-breaking space, one that will not break over two lines; useful if (for example) you don’t want the “A” to be separated from the “Ikonta” in “Ikonta A”.

Don’t attempt to insert “soft” hyphens (hyphens only for end-of-line word division). For a non-breaking hyphen, use &#8209;.

For more characters, see:

both of which are within “Alan Wood’s Unicode resources”.

Character formatting

The way that text appears within a paragraph, list item, etc, can be altered via either MediaWiki-specific use of single quotation marks or certain XHTML tags, sometimes with CSS.

Use two single quotation marks in order to start italicizing and to end it: ''Asahi Camera'' brings “Asahi Camera”.

Use three single quotation marks in order to start boldface and to end it: The '''Bronica S2a''' was [...] brings “The Bronica S2a was [...]”.

And yes, boldface can be added to italics and vice versa; as a simple example (turning both on and off at the same place): The Japanese magazine '''''Asahi Camera''''' was [...] brings “The Japanese magazine Asahi Camera was [...]”.

( typically uses boldface at the very start of an article; it uses it only sparingly elsewhere. This page is of course unusual.)

XHTML tags are rarely needed.

For superscripted text: marketed as the "330<sup>D</sup>" in Europe brings “marketed as the "330D" in Europe”.

For subscripted text: marketed as the "<sub>A</sub>41" in Japan brings “marketed as the "A41" in Japan”.

For small text: <small>[not verified]</small> brings “[not verified]”. Small text is only very rarely needed.

For underlined text: <span style="text-decoration:underline">XYZ</span> brings “XYZ”. Underlining too is very rarely suitable, other than perhaps for transcribing inscriptions. Underlined text is harder to read, and easily confused with a link. You may also see <u>XYZ</u>; however, this mark-up is “deprecated” (i.e. obsolete and disapproved by W3C).

For struck out text: <span style="text-decoration:line-through">XYZ</span> brings “XYZ”. You may also see <s>XYZ</s>; however, this mark-up is deprecated. Again, striking out is very rarely needed, other than perhaps for quasi-deleting your own comment in a talk page after you have realized that its content was mistaken. (Normally, old comments should not be deleted.)

For code: Sign your comment with <code><nowiki>~~~~</nowiki></code> brings “Sign your comment with ~~~~”.

Editors familiar with CSS can also use miscellaneous declarations within <span style="[CSS declaration block]"> and </span> where appropriate.

For advice on when (rather than how) to use boldface and italics, see “Text formatting”, within Wikipedia’s “Manual of Style”.


For links from graphics, see Adding images.

Internal links

Link to another page, or to a different point within the same page, where doing so is likely to help the reader.

For example, when writing about a particular camera made by Nikon, link “Nikon” to the page about it (i) the first time that “Nikon” is mentioned in the article, (ii) at any point where Nikon, the maker, is discussed (rather than merely mentioned), and optionally also (iii) when “Nikon” is first mentioned in a section coming some way below any previous link to that same page.

Case (the capital/lowercase distinction), spaces, and such tiny distinctions as that between hyphen and en dash are all significant.

Linking to another page has a page titled “Pearlette”. The simple way to link to it is [[Pearlette]] (for “Pearlette”).

If it helps to link to this page but to use another name for it, this other name follows the title and the pipe character |: [[Pearlette|Konishiroku Pearlette]] (for “Konishiroku Pearlette”).

The case (capital versus lowercase) of the first letter doesn’t matter. has an article “Light meter”, but a link to [[light meter]] works for it: “light meter”.

What immediately follows such an internal link (and is not separated by a space, an apostrophe, etc) is visually “blended” into the link. Thus [[light meter]]s appears as a link to “light meters”, plural (“light meters”), but actually links to the title within the brackets.[3]

When followed by nothing at all, the pipe character | performs either of two tricks:

  • It hides title endings in parentheses: [[Semi Wester (postwar)|]] for “Semi Wester”.
  • It hides certain (although not all) namespace prefixes: [[Help:Adding images|]] for “Adding images”.

It also does both of these: [[Template:Japanese 6×6 TLR (A–L)|]] for “Japanese 6×6 TLR”.

Linking to a point within a page

Link to a given header within another page via [[ARTICLE TITLE#HEADER|TEXT]]. (Find the right form of the header by examining the URL as shown in your browser after you have clicked its title within the table of contents.)

For example, [[Olympus#Pen_Digital_.28micro_four_thirds.29|µ4/3 Pen]] for “µ4/3 Pen” — i.e. the section titled “Pen Digital (micro four thirds)” within “Olympus”.

Link to anywhere else by marking the point with an “id” attribute. Its value should start with a simple letter (A–Z, a–z), and should only include letters, digits (0–9), underlines and/or hyphens.) A paragraph can be marked by using the <p> tag for it: <p id="reconstruction">[paragraph here]</p>. A point with no structural significance can be marked by using the <span> tag: . . . but <span id="revival">in 1948</span> the company started . . ..

Linking to a point within the same page

Link to a point within the same page as you would link to a point within a different one, but skip the article title and instead simply start with #; for example, [[#Tables|Tables]] for a link to the section “Tables” within this page.

Rather than plain “(see above)” or “(see below)”, it’s helpful to write (see [[#Tables|below]]) — for “(see below)” — or similar.

Anticipating link rot

If a page within is later moved (renamed), an existing (or new) link to it under its former name should still work. So even after the article “Carl Flex” was moved to “Carlflex”, any link to the former (example) has has been automatically redirected to the latter.

However, if the title of a header within an article is changed, a link to the header will no longer work (and instead will send the browser to the top of the page). Therefore only link to a header within a page that already seems to have been edited to a stable state, and consider adding a hidden comment next to the target of the link, warning subsequent editors that it is a link target.

External links

Simply, for a link to a page outside, put within single (square) brackets: the URL followed by a space (no pipe character) and the page title: [ TLR Cameras Website] for TLR Cameras Website.

When adding an external link to a page deep within the hierarchy of another site, the best practice is to include both a "deep link" to the particular page, and a link to the site's home page (or the highest-level page which relates to photography). Why? First, this is a simple courtesy to webmasters who have provided valuable information; and it also lets wiki visitors recognize sites they are familiar with, to gauge their reliability.

Interwiki links work for some other wikis. For example, [[Wikipedia:Fujifilm]] brings Wikipedia:Fujifilm. Combination with a pipe and an alternative title works: [[Wikipedia:Fujifilm|Fujifilm (Wikipedia)]] brings Fujifilm (Wikipedia). Likewise, [[Commons:File:Perfekta_6x6_IMGP4292.jpg|Perfekta (Wikimedia Commons)]] brings Perfekta (Wikimedia Commons). There’s also a handy shortcut employing the pipe character: [[Wikipedia:Fujifilm|]] brings Fujifilm.[4]

For more on interwiki links, see “Interwiki” (MediaWiki).

Page organization

Paragraphs (and line breaks)

Single line breaks have no effect within paragraphs. To separate a paragraph from the previous one, insert a blank line between them (hit the Enter key twice).

If CSS is wanted, it’s possible to open a paragraph with <p> and end it with </p>.

Don’t attempt to indent the first line of a paragraph.

To indent a block quotation, start the block with <blockquote> and end it with </blockquote>.

There’s a convention whereby a comment in a talk page is indented further from the left than is the comment to which it’s a reply. For each level of indentation from the left, one colon : is added at the very start of the paragraph.[5]

For a simple line break, use <br />. (In normal body text this is unnecessary; however, it can help within captions and the like.)

Headers (section titles)

Any longer article benefits from subdivision by headers, which help to structure the article and also generate a table of contents.

There should be no header at the very start of an article. (Don’t add the header “Introduction”, “Preamble”, or similar.) Write a short paragraph (perhaps as short as a single sentence) and then insert the first header.

As an example of this in action, we’ll look at the article “Pearlette”. After the introductory paragraph, there follows a table of contents, which the software has generated automatically. Note within this table:

3 Second generation: hinged back
3.1 1933 model

and take a quick look at these sections. The former is the topmost level of classification; it was added with a pair of equals signs before and after: ==Second generation: hinged back==. The latter is one stage below this, and uses three equals signs: ===1933 model===.

Put a header on a new line, and start anything that follows it on a new line.

For a further level of subdivision, ====a third level==== (four equals signs on each side) can be used. And if even this is not enough, a fourth and a fifth level (with five and six on each side respectively) can be used too.

(As editors often discover by accident, a level higher than any of these can be achieved via a single equals sign on each side. Do not use this.)

For more, see “Section” (Wikipedia).

Page ingredients

Table of contents

When the number of headers (see above) within a page goes over three, this generates a table of contents. The table itself cannot be edited. Its generation should not normally be forced, moved or suppressed. However, this can be done, using one or other of two “magic words” (MediaWiki terminology), each enclosed by two underline characters before and after:

  • Adding __TOC__ somewhere in a page generates the table of contents at that point in the page.
  • Adding __NOTOC__ anywhere in a page suppresses generation of the table of contents anywhere in the page.

(The “TOC” template of Wikipedia does not exist in


Camera illustrations are the life-blood of But any image (typically a photograph, but perhaps a scan or diagram) must be added to a page in a very specific way, and with due consideration for its copyright status. All this is explained within “Adding images”.


There are two kinds of list, depending on whether the items are unordered (not numbered) or ordered (numbered). They are remarkably easy to produce: they don’t require an explicit beginning or end, and instead merely consist of a simple, unbroken series of list items. Each list item starts on a new line with either of two characters, and should be typed on a single line (it should not include a line break).

An unordered list is typically displayed with bullet points. It’s made with an asterisk * at the start of each line.

*The other


  • This
  • That
  • The other

An ordered list is typically displayed with Arabic numerals. It’s made with a hash mark # at the start of each line.

#The other


  1. This
  2. That
  3. The other

Lists may be nested, and in any combination: either an ordered or an unordered list may be nested within an item of either an ordered or an unordered list. An example (unordered within ordered):

#Postwar film
#*35mm and smaller
#*Larger than 35mm


  1. Prewar
  2. Postwar film
    • 35mm and smaller
    • Larger than 35mm
  3. Digital

Numbered lists do not need to begin with 1: Replace the first hash mark with <ol><li value="5"> for a list beginning with line number 5; start subsequent lines with <li> instead of a hash mark. The list must be finished with .

This may be useful when a list is interrupted by some explanatory text. The following shows an example, with a multi-level list:

# Cameras
#* Viewfinder cameras
#* Rangefinder cameras
#* TLR cameras
#* SLR cameras
# Lenses
#* Standard lenses
#* Wide-angle lenses
#* Telephoto lenses
break with text
<li value="3"> Flashes
* Bulb flashes
* Electronic flashes
<li> Tripods

gives this:

  1. Cameras
    • Viewfinder cameras
    • Rangefinder cameras
    • TLR cameras
    • SLR cameras
  2. Lenses
    • Standard lenses
    • Wide-angle lenses
    • Telephoto lenses

break with text

  1. Flashes
    • Bulb flashes
    • Electronic flashes
  2. Tripods

For more, see “List” (Wikipedia), but note that the Wikipedia template “Multi-column numbered list” does not exist in


Creating tables in is rather complex, for three reasons:

  1. XHTML markup for tables is rather complex, and the markup that editors have to use must allow conversion by MediaWiki into this XHTML markup.
  2. The simplest markup for tables leads to results that are so plain as to be hard to understand. Improving on this requires additional specifications.
  3. Tables usually benefit from specification of non-default positioning.

This section takes you through the process rather than just throwing the options at you.

The basics

Tables need to be explicitly opened and closed, and their contents must be written row by row. (Line breaks do matter.) Here’s a 3×2 example:

! Header 1
! Header 2
| row 1, cell 1
| row 1, cell 2
| row 2, cell 1
| row 2, cell 2

This produces:

Header 1 Header 2
row 1, cell 1 row 1, cell 2
row 2, cell 1 row 2, cell 2

Of course this neither looks much like a table nor is easy to understand as one. But a simple change will work wonders. If we replace the initial {| in the table above with {|class="wikitable", the result is:

Header 1 Header 2
row 1, cell 1 row 1, cell 2
row 2, cell 1 row 2, cell 2

Let’s take a slightly closer look at the markup for this. Here it is:

! Header 1
! Header 2
| row 1, cell 1
| row 1, cell 2
| row 2, cell 1
| row 2, cell 2

Here’s a key. (Each of the following must start on a new line.)

  • {| class="wikitable" ⇒ the start of a table of the particular class (in the CSS sense) “wikitable”
  • |- ⇒ the start of a row (optional for the first row, and here omitted for the first row)
  • ! [text] ⇒ a header cell
  • | [text] ⇒ a (regular) cell
  • |} ⇒ the end of the table

Although the table must be closed, a row does not have to be.

One minor short cut is often used: starting a cell by doubling the pipe character | or exclamation mark rather than preceding the single character with a line break.

Here then is another way to create the very same table as above:

| row 1, cell 1 || row 1, cell 2
| row 2, cell 1 || row 2, cell 2


A caption can be a useful addition to a table. On a new line immediately under the one that starts the table:

  • |+ [text] ⇒ the caption

Here then is how to create the table as above, but with a caption:

|+ This is a caption
! Header 1 !! Header 2
| row 1, cell 1 || row 1, cell 2
| row 2, cell 1 || row 2, cell 2

This brings:

This is a caption
Header 1 Header 2
row 1, cell 1 row 1, cell 2
row 2, cell 1 row 2, cell 2

Merging cells across columns and rows

It may be helpful or even necessary to merge cells across rows and columns: to have them span rows and columns. Here, from the article “Fujica Six”, is an example:

variant a b c
lens Fuji Rectar
aperture 4.5 3.5 4.5 3.5
shutter Lotus S.R. NKSZ S.R. NKS
max speed 200 500 200 500 200
flash terminal none 2-pin 1-pin 2-pin PC 2-pin
self-timer yes no yes no yes
release April 1948 August 1948 June 1949 August 1949 1949 1950
price in Japan ¥5,250 ¥6,200 [export] ¥5,250 [export] ¥6,200

Consider what’s near the top of it: from “model”, “variant” and “lens” at the left across to “IBS”, “c” and “Rectar” on the right. This consists of a grid formed by three rows and nine columns, within which a number of pairs of adjacent cells have been merged. Here’s how its construction might have started (but with “blankx” inserted to help the explanation below it):

model IA IB IC IAS ICS IBS blank1 blank2
variant blank3 blank4 blank5 blank6 blank7 a b c
lens Fuji blank8 blank9 blank10 blank11 blank12 blank13 Rectar

The three rows within this are:

! model !! IA !! IB !! IC !! IAS !! ICS !! IBS !! blank1 !! blank2
| variant || blank3 || blank4 || blank5 || blank6 || blank7 || a || b || c
| lens || Fuji || blank8 || blank9 || blank10 || blank11 || blank12 || blank13 || Rectar

First, let’s have “IBS” expand across what are now “blank1” and “blank2”, and “Fuji” expand all the way across to “blank13”. In XHTML (or HTML) terms, we want the cell that contains “IBS” to span three columns. This requires adding the colspan attribute to this cell, and deleting those that now contain “blank1” and “blank2”. In MediaWiki markup, you add any attribute to a cell in front of the pipe | character and any text.

Now for the rest. We want each of “IA”, “IB”, “IC”, “IAS” and “ICS” to span two rows. The rowspan attribute works analogously to the “colspan” attribute (although it is slighter harder to use because what is deleted is not adjacent to this cell in the source).

The rows are now:

! model !! rowspan="2" | IA !! rowspan="2" | IB || rowspan="2" | IC || rowspan="2" | IAS || rowspan="2" | ICS || colspan="3" | IBS
| variant || a || b || c
| lens || colspan="7" | Fuji || Rectar

which produces:

variant a b c
lens Fuji Rectar

(The reason why this small table, together with those that follow, is narrow is that nothing is forcing any column to be any wider than is necessary for the text that it contains.)

All seems well (if bunched up). The result is still too narrow for us for a full idea of what is going on here, but it’s sufficient to show that both “c” and “Fuji” are left-aligned whereas they’d look better (horizontally) centered.

The table above has cells that span columns and cells that span rows, but no cell that spans both. However, this is simply done: add both colspan and rowspan attributes to the cell at the top left of the rectangle that is to be merged, and delete the other cells. Here (for some fictional camera) is the result:

model Hotei Jurōjin Fukurokuju Bishamonten Benzaiten Daikokuten
variant a b c
flash terminal none 2-pin 1-pin 2-pin PC 2-pin
self-timer yes no yes

Here are the last two rows of this:

| flash terminal || colspan="3" rowspan="2" | none || 2-pin || 1-pin || 2-pin || PC || 2-pin
| self-timer || yes || no || colspan="3" | yes

More on tables

For refinements to tables:

  • for the centering of a table in the page (or other element), see “Centering”, below
  • for the positioning of tables so that text can go to their left or right, see “Floating left or right”, below
  • for the centering or other horizontal alignment of text within table cells, see “Horizontally aligning text”, below
  • for the vertical alignment of cell content (middle versus top), see “Vertical alignment”, below
  • for the coloring of cell backgrounds, see “Colors”, below

For more details on tables in wiki text, see:

Other block elements

XHTML (like HTML) provides the DIV block element for any purpose. And MediaWiki allows wiki editors to use this element.

An example of DIV used simply, with no attributes, would normally show no effect. It’s only when attributes are used that it becomes useful.

Here’s code for a very simple DIV, one that has been colored but has had nothing else specified.

<div style="color:#000; background-color:#effff9;"><br />
Welta Belmira<br />
image by Hans Kerensky<br />
{{with permission}}


Welta Belmira
image by Hans Kerensky
(Image rights)

The greenish background shows the area covered by the DIV. (For an explanation of coloring, see “Colors”, below.) The DIV extends all the way to the right simply because nothing is stopping it from doing so. The graphic itself is 240 pixels wide.

The tiny graphic to the right of the image isn’t obviously helpful. A CSS stylesheet (i) adds this graphic to every link where it’s not suppressed, but (ii) allows for its suppression in any link that’s a descendant (a CSS term) of any element that’s of class "plainlinks".

And so we specify the class and the width: <div class="plainlinks" style="color:#000; background-color:#effff9; width:240px;">. The result is:

This may give an inkling of what is possible; of which more below.


Definitions — presented separately, perhaps in a list — are only rarely of use here within, and are not even used within its Glossary. But if you do want them, here’s how to do them properly:

220 film
Similar to 120 film but effectively twice as long (and only usable with cameras designed specifically for it); allows 32 6×6 exposures; formally specified in ISO 732 (1991).

is achieved via

;220 film:Similar to 120 film but effectively twice as long (and only usable with cameras designed specifically for it); allows 32 6×6 exposures; formally specified in ISO 732 (1991).

Note (i) the semicolon ; at the start (and necessarily at the very start of the line), and (ii) the colon : separating term and definition.[6]

Avoiding special effects

You may be wondering how it is that this page is able to show all the code. (For example, if code shows how to create a table, why doesn’t it create the table right there and then?)

The answer is the heavy use here of one or other of two devices. One is the <nowiki> tag; the other is escaping particular characters. And these devices aren’t only useful in such minor and peripheral areas of as explanations of markup; they’re also useful in regular articles.

As an example, suppose we want to use the definitions markup (above) to create a definition for “3:2” (the aspect ratio). As we’ve seen, the pattern is (on a new line): semicolon, term to be defined, colon, definition. And so:

;3:2:An ''aspect ratio'' (q.v.) in common use in photography [...]

However, this brings us:

2:An aspect ratio (q.v.) in common use in photography [...]

The problem is of course that the first colon is misinterpreted as having special significance. We need to suppress this significance, in one way or another. The first way:

;3<nowiki>:</nowiki>2:An ''aspect ratio'' (q.v.) in common use in photography [...]

results in

An aspect ratio (q.v.) in common use in photography [...]

Alternatively, knowing (perhaps from one of the sources listed shortly below) that the decimal number within Unicode for the colon character is 58, we infer that it can be represented by &#58;, and write:

;3&#58;2:An aspect ratio (q.v.) in common use in photography [...]

This has the same result:

An aspect ratio (q.v.) in common use in photography [...]

For more on “nowiki” and other workarounds, see “Limiting formatting/escaping wiki markup” (Wikipedia).

To find the numeric character reference for any character (or the set of them for a short string of characters), type it after “Enter string to convert” in “Unicode conversion” (within Brian Chandler’s “Imaginatorium”).

For the numeric character references and (where they exist) character entity references of the characters on most people’s keyboards, see “C0 Controls and Basic Latin” (within “Alan Wood’s Unicode Resources”)

For more about “&#58;” etc (numbered), see “Numeric character reference” (Wikipedia); for more about “&#lt;” etc (mnemonic), see “Character entity reference” (Wikipedia).

Page element layout

Don’t try to force an article into a preconceived layout design of your own. However, it may help to design particular elements of a page.


Most attempts to improve on default design specify at least one dimension (width, margin, etc). Here we see how this is done.

Width, height, margin, padding, and border (all explained below) are among the very many CSS properties that take a dimension as their value, or as one of their values. Here’s an example, in which as much as possible is specified in pixels (“px”): style="width:200px; height:300px; margin:5px 10px; padding:5px; border: 1px solid #006.

Unless the value is zero, the unit must be specified. There’s no space between number and unit: not 5 px but instead 5px.

Although CSS provides a choice of nine units, three are sufficient for editing in

  • pixels (“px”)
  • percentage (“%”)
  • ems (“em”)

The meanings of the first and second of these should be clear. The size of an em varies with the font; once the width of the capital M, it now simply means the height of the font.

Specification of the height of an element is rarely helpful. It’s usually better to leave height unspecified and let the browser decide. If height is specified, then this should be accompanied by the CSS declaration overflow:auto, which will add a scrollbar if the height is inadequate.

For more on em and ex (and why we don’t bother with the latter), see Stephen Poley, “The CSS ex unit” (in Poley’s Web Matters); and for much more on units, see Jan Roland Eriksson, “Basic ‘old timers’ typesetting practices, ch.1” (in The Developer’s Archive). For more on width, height and overflow (as well as related properties such as min-width), see “Page layout properties” within the Western Civilisation Complete CSS guide.

(You may also see within the wikitext of some articles that elements have had their width or height specified with code such as width="100" height="200". The unit, which should not be specified in the code, is pixels. This is XHTML.)


Most attempts to improve on default design partly depend on margins: if margins aren’t specified, the result is ugly at best.

The margins around an element are specified via CSS.

We can use the “margin” CSS property for this. There are three ways of doing so:

  • A single value, for example margin:5px ⇒ this value for all four sides
  • Two values, for example margin:5px 10px ⇒ the first value for top and bottom, the second for left and right
  • Four values, for example margin:5px 10px 0 0 ⇒ the four margins in turn, clockwise from the top (so in this example top 5 pixels, right 10 pixels, bottom zero, left zero)

Alternatively, we can use as many as we wish of the CSS properties “margin-top”, “margin-right”, “margin-bottom” and “margin-left”; for example, margin-top:10px; margin-bottom:10px.

(For a margin-like buffer within the edge of an element, see “Padding and borders” below.)


By default, a table, DIV or similar is aligned to the left of whatever contains it (most likely the page as a whole, but perhaps a DIV or something else). We can move an element to the center by setting the value of its left and right margin to “auto”.

In the example below, the opening tag is <div style="color:#000; background-color:#effff9; width:240px; margin-left:auto; margin-right:auto">.

Floating left or right

To “float” an element means to let other elements (typically paragraphs of text) move up to one side of it. Here, we are simultaneously floating one element (a DIV) to the left and another to the right, and of course letting this text come between both.

For a div element to float, its opening tag must contain the CSS declaration float:left or float:right. The former floats the element to the left; the latter floats it to the right; other material is allowed to wrap around it.

By itself, floating an element does not ensure even a moderate degree of elegance in the result. The floated element should normally have a margin both beneath it and on the side (whether left or right) to which there may be text. The examples here each have ten-pixel margins specified for two sides.

The code of the opening tag for the left-floated DIV above is <div class="plainlinks" style="color:#000; background-color:#effff9; width:189px; float:left; margin:0 10px 10px 0">; that for the right-floated DIV is <div class="plainlinks" style="color:#000; background-color:#effff9; width:189px; float:right; margin:0 0 10px 10px">.

Perhaps the text you are reading now is between rather than below the two DIVs showing the Contarex. In order to persuade you that it will wrap below as well as beside the DIVs, we could have stuffed it with meaningless filler, but instead we invite you to reduce the width of your browser window and observe the result.

For more on floats (and clearing and related matters), see “Page layout properties” within the Western Civilisation “Complete CSS guide”.


Simply, “clearing” gets material to go under (rather than against) what’s “floated”; if nothing has been directed to float, there’s never a need to “clear”.

If something is floating to the right and there is space to its left, an element (paragraph, header, etc), will start to its left. To prevent this, you need to get the element to clear its left-hand side. You do this with the CSS declaration clear:left.

Inline CSS requires the style attribute, which in turn requires an XHTML tag. Wiki editors often use a “styled” line break for this: <br style="clear:left" />. To obtain this with fewer keystrokes instead type the substituted template {{subst:brl}}.

Likewise, if something is floating to the left and there is space to its right, an element (paragraph, header, etc), will start there. To prevent this, you need to get the element to clear its right-hand side. You do this with the CSS declaration clear:left. A common way to do this is with <br style="clear:right" />; which you can get by typing {{subst:brr}}.

Or you can prevent material from being on either side, by using the CSS declaration clear:both. A common way to do this is with <br style="clear:both" />; which you can get by typing {{subst:br}}.

For more on clearing (and floats and related matters), see “Page layout properties” within the Western Civilisation “Complete CSS guide”.

Other formatting


Hungary Poland Czecho-
MOM PZO Meopta

“Color” and “background-color” (necessarily so written) are CSS properties for the color of text and background respectively.

The format of the specification here is “#RRGGBB”: a two-digit hexadecimal[7] value for red, green and blue successively. At the extremes, “#ffffff” (the three colors at full blast) is white; “#000000” (none of any color) is black. (Case does not matter: “#af00bb” is the same as “#AF00BB”.)

The first line of code for the table floated to the right here reads {|class="toccolours" border="1" style="color:#000000; background-color:#eeffee; float:right; margin:0 0 10px 10px; border-collapse:collapse;". The table has a light green background thanks to “eeffee”: the first and the second “ee” mean a high level of red and blue respectively, while the “ff” in the middle means the maximum level of green.

You may encounter three-digit references; these are equivalent to six-digit references in which each of the three digits is doubled, so for example “#fc9” is the same as “#ffcc99”.

In order to find the values that will produce a color that you have in mind, see for example this page (at

Certain named colors are also possible; for a list arranged by color, see this page (also at

If either of “color” and “background-color” is specified, both ought to be specified. (Some people viewing may have set up their browsers to view text as bright against a dark background.)

Some websites talk of colors that are “web safe” for monitors that can only display 256 colors; this is no longer an issue. (By contrast, legibility is an issue.)

For more on the use of colors in the context of a wiki, see “Color” in Wikipedia’s “WikiProject Usability”.

Padding and borders

The padding of an element (typically a DIV) is the CSS concept for a kind of buffer between its content and its edge. (Compare margin, the space between the edge and anything outside.)

The image within the element (DIV) on the right here is 240 pixels wide. On all four sides the DIV has been given 3 pixels of padding. Quite aside from its border, in reality the DIV is now 246 pixels wide — but its width is nevertheless set at 240 pixels, because this is the way that CSS defines width.

A DIV may contain a DIV; and here a DIV with a 20 pixel left margin has been used for the caption.

Padding is specified analogously to margin. But it’s commonly identical on all four sides. Here it’s 3 pixels, so padding:10px.

When an element benefits from a border, this should almost always be uniform on all four sides. But for demonstration purposes the border in this example is “solid” on two sides, “dotted” on two; and two pixels wide on two sides, one pixel wide on two. For each side there are three variables: width, style, and color. Anything wider than two pixels rarely looks pleasant. There are various options for style, but those beyond “solid” and “dotted” rarely look pleasant. The color should usually be dark; a combination that often looks good is a much darker version of the background color within, or simply black. (Here, the background color and border color are f7f6fa and 006030 respectively.) So a typical border declaration would be border:1px solid #000000 (whose three values may be in any order).

On the rare occasion when this is helpful, any or all of “border-width”, “border-style” and “border-color” may be used instead of “border” or in addition to it.

Horizontally aligning text

Text can be aligned with the CSS property “text-align” and the value “left”, “right” or “center”. For example: text-align:center.

Here is the table from the article Fujica Six, but slightly abridged and with no specification of how the text should be aligned within each cell:

variant a b c
lens Fuji Rectar
aperture 4.5 3.5 4.5 3.5
flash terminal none 2-pin 1-pin 2-pin PC 2-pin
self-timer yes no yes no yes
release April 1948 August 1948 June 1949 August 1949 1949 1950
price in Japan ¥5,250 ¥6,200 [export] ¥5,250 [export] ¥6,200

How the text is aligned here will depend on the browser. Commonly, the content of table head cells (such as “model” and “IA” along the top) is centered (and in boldface), whereas that of the other table cells is left-aligned.

Centering (horizontally) within all table cells is easily done, by addition of the CSS declaration text-align:center; for the table as a whole:

{| border="1" cellpadding="2" style="margin:1em; text-align:center; border-collapse:collapse;"

The result:

variant a b c
lens Fuji Rectar
aperture 4.5 3.5 4.5 3.5
flash terminal none 2-pin 1-pin 2-pin PC 2-pin
self-timer yes no yes no yes
release April 1948 August 1948 June 1949 August 1949 1949 1950
price in Japan ¥5,250 ¥6,200 [export] ¥5,250 [export] ¥6,200

Although the leftmost column looks strange, the table as a whole is a fairly good approximation to what we want. So we retain text-align:center; for the table as a whole, but add the declaration text-align:left for any cell whose text should be left-aligned. For example, | style="text-align:left" | lens, for the result:

variant a b c
lens Fuji Rectar
aperture 4.5 3.5 4.5 3.5
flash terminal none 2-pin 1-pin 2-pin PC 2-pin
self-timer yes no yes no yes
release April 1948 August 1948 June 1949 August 1949 1949 1950
price in Japan ¥5,250 ¥6,200 [export] ¥5,250 [export] ¥6,200

It’s similar for DIVs and other elements. The opening tag of

is <div class="plainlinks" style="color:#000; background-color:#f7f6fa; width:240px; margin-left:auto; margin-right:auto; text-align:center; border:1px solid black; padding:1px">.

Vertical alignment

Hungary Poland Czecho-
MOM PZO Meopta
Hungary Poland Czecho-
MOM PZO Meopta
Hungary Poland Czecho-
MOM PZO Meopta

Vertical alignment is only likely to be at all worrisome within tables.

The CSS property “vertical-align” has numerous possible values, but “top”, “middle” and “bottom” are likely to be the most useful among them. (NB “center” is not an option.)

It may look better if the text in a row is vertically aligned to the top. In order to do this, simply replace the row-opening |- with |- style="vertical-align:top" (or, if a style attribute is already there, add the declaration vertical-align:top, using a semicolon to separate it from any other declaration).

Conversely, for vertical centering, do the same but with “middle” rather than “top”.

Like “text-align” (for horizontal alignment), “vertical-align” can be applied to individual cells too.

To the right are floated three small tables. The first does not use “vertical-align”; the second and third have |- style="vertical-align:top" and |- style="vertical-align:middle" respectively to start the first row. (Browsers are likely to display the first table identically to either the second or the third.)


After a factual assertion that a reasonable person might question, an opinion ascribed to somebody, or a quotation, add a source footnote. Also, peripheral or less important material that might try some readers’ patience can go into a footnote.

If the article is to have any footnotes, then there should be the single self-closing tag <references /> somewhere below the point from which the last of the footnotes is to be linked. It normally goes under (and indeed is the only text under) the header ==Notes==.

Write each footnote at the point in the main text from which there should be an index number. Insert <ref>[your text here]</ref>. This will lead to the automatic generation of an appropriate index number and a footnote saying this.

A given footnote may be pointed to from two or more places. In any one of these places — among which the first is best, as this aids subsequent editing — add the footnote in full, but with a name. (This should start with a simple letter [A–Z, a–z], and should only include letters, digits [0–9], underlines and/or hyphens.) Example: <ref name="perfekta66">[your text here]</ref>. Each of the other pointers to the same footnote is simply a self-closing tag with the same name: <ref name="perfekta66" />.

The actual content of the footnote is not moved within the editable text by any automatic process; only its position within the finished page is moved. Therefore if you wish to edit a footnote that is already in place, you have to do so by editing the section of the page from which the footnote is linked. For example, a footnote from here,[8] can be edited by editing this section (“Footnoting”), not the section below titled “Notes”.

When you’re editing any one section of an article from which there are footnotes, “Show preview” won’t give you a preview of these footnotes. There are two ways around this:

  • Take the option to edit the article as a whole, rather than the one section within it. (Of course you’re then free to limit your edits to this one section.)
  • Take the option just to edit the section, and in the edit window temporarily add <references /> to the end of it. The preview function will now show the footnotes too. (If any of these repeats a footnote defined elsewhere, you’ll get an error message. Ignore this.) When all seems well, delete <references /> and press the “Save page” button.

Common practice in has been to lump together all footnotes, from dry page references to learned digressions, under the single title “Notes” (or occasionally “References”). They may however be separated. It may at first seem somewhat pretentious to have two sets of footnotes for a single web page, but doing this can help the reader: if a page has many dry source footnotes, the reader may not bother to look at them, and will therefore miss the occasional interesting footnote.

If it does seem a good idea to separate the two kinds of footnotes, then here is how to do this:

  • Create “source” notes as described above.
  • Create “content” notes (which should be few) as described above; but for each have <ref group="XYZ"> rather than simple <ref>. “XYZ” here can be any one name that you wish (e.g. “n.”).
  • Have two section headers near the foot of the page, first “Notes” (for “content” notes), and then “References” (for “source” notes).
  • Place <references /> under the header “References”.
  • Place <references group="XYZ" /> under the header “Notes”.

For an example of a page in which notes are separated from references, see “Ofuna Six”.

For more on footnotes, see Footnotes, within Wikipedia’s “Manual of Style”. (However, the “Reflist” macro, described in that page and very widely used within Wikipedia, does not exist in

Footnoting McKeown's pages

When specifying a page number from McKeown's Cameras please use the template {{McKeown12}} to specify the 12th edition of this work—the latest version as of 2011. Page numbering of earlier (and one hopes, future) editions does not match this.


For more on categories, see Help:Categories.

Categorization adds ways in which articles can be found. In order to add a page to a category — or to categorize it, or to add the category to the page (each a widely-used way of expressing the same idea) — add a link to the category at the foot of the page. Thus in order to add “Luxette” to the category “German 4x4”, add [[Category:German 4x4]] to the foot of the former (but don’t touch the latter).

Within the category, the page that you categorize is normally listed according to its title (so “Luxette” will be under “L”). More often than not this is appropriate. But it’s sometimes better to force a different listing.

  1. Consider the Minolta SR-T 201. Within Category:Japanese 35mm SLR, it’s better listed among the Minoltas, under “M”. But if Category:Minolta SR mount has all the SR-mount Minolta models listed under “M”, the result may be difficult to use and certainly will be ridiculous. The solution is the combination of [[Category:Japanese 35mm SLR]] and [[Category:Minolta SR mount|SR-T 201]]: in the latter, “|SR-T 201” results in listing as if titled “SR-T 201”.
  2. Consider the article “Minolta” itself. It should certainly be listed within Category:Minolta, but where? Not lost under “M”, but instead at the top. The kludge for this is an asterisk after the pipe character: [[Category:Minolta|*]].
  3. Consider the article “Ōki”. While it's obvious to us humans that the initial “Ō” is some kind of “O”, this is not so for the MediaWiki software, which will put the former somewhere after “Z”. Therefore its links to categories are exemplified by [[Category:Japanese camera makers|Oki]], which lists it where it would be if the macron were not present.

Exceptionally, you may want to display a regular link to a category. If so, prefix a colon : to “Category”. Thus [[:Category:German 4x4]] renders “Category:German 4x4”.

Templates and transclusion

A template is a wiki page whose content is designed to be used as a module within other pages.

Templates are numerous and very varied; let’s start by introducing a simple one (one that’s short and has no variables). Insertion of {{Dechert Canon}} inserts “Template:Dechert Canon”:

Dechert, Peter. Canon Rangefinder Cameras 1933–68. Hove, East Sussex: Hove Foto Books, 1985. ISBN 0-906447-30-5.

There are two ways to insert a template: not only {{Dechert Canon}} (for transclusion) but also {{Subst:Dechert Canon}} (for substitution); note how “Subst:” appears in the latter.

With substitution, the content of the template is added to the article the first time the editor presses the “Save page” button. No subsequent change to template can have any effect on the page to which it has already been added.

Transclusion means dynamically including content from another location, content which later be independently edited. So with transclusion, the content of the template is added to the article only when the browser accesses the article. Thus what appears stays up to date with the template.

If the template is not expected to change, then substitution has the advantage of imposing a slightly smaller load on the webserver.

To understand how transcluding can help, let’s look at an example. Thanks to the Wayback Machine,[9] here is a February 2007 version of the article “Mihama Six”. At its top right is a template listing similar Japanese cameras. See the list of folding 6×6 cameras, which has 35 items. Again via the Wayback Machine, here is a January 2009 version. The number of folding 6×6 cameras has almost doubled. (Just for “A” and “B”, it has added Angel Six, Balm Six, Baron, Beauty Six [1950] and Beauty Six [1953].) Editors here have realized that yet more such cameras might be discovered and written up, so they have made sure that the template has remained transcluded rather than substituted, happy that the addition of a camera article to the wiki would require its addition in just one place (the template) in order that mention of it would be added to every article transcluding that template.

In order to link to a template (for example, within a talk page, in order to discuss its use), put the entire name in square brackets: [[Template:Dechert Canon]] renders “Template:Dechert Canon”.

Transclusion is not limited to templates: pages in other namespaces (other kinds of pages) can be transcluded too. However, in (unlike Wikipedia) it is very rare for the transclusion of any page other than a template to be needed or even desirable.

For more on transclusion and templates, see Transclusion, Template and Template namespace, all at Wikipedia. While reading these and other explanatory pages at Wikipedia, remember that templates often themselves employ other templates, and that the explanations there recommend the use of certain templates (such as the very humdrum “Tl”) that do not exist in


Hidden comments

Material between an opening <!-- and a closing --> is visible to anyone who edits the page but isn’t otherwise visible. (This is useful both for temporarily “commenting out” material that’s seriously flawed but that could later be fixed and for making certain kinds of comments for future editors — although most comments are better placed in the article’s talk page.)

Any material can be placed in a hidden comment, as long as it does not include a pair of hyphens. (An implication of this is that one comment cannot be nested in another comment.)


An edit to a talk page should be signed and dated (timestamped). This is done with four consecutive tildes: ~~~~. This produces both (a) a link to the editor’s user page (if this exists, otherwise a redlink to creating it) and (b) a date/timestamp.

Just three consecutive tildes produce (a) alone; five produce (b) alone.

Horizontal rules

Make a horizontal rule (line) by placing an unbroken set of four hyphens ----, and only these hyphens, on a line.

Alternatively, <hr /> does the same thing, and this can take the “style” attribute for CSS.

Space starting a line

The line you are reading now is a sample of

— it’s a sample of something that’s almost never wanted within monospaced lettering that won’t wrap. It’s achieved simply thanks to a space at the start of the line. Though here it’s of course deliberate, for demonstration purposes, more often than not it’s accidental. If your (normally-intended) text looks like this, check that you haven’t accidentally preceded it with a space.


  1. Unlike HTML, where they are usually optional. Again, the MediaWiki software will probably add them where necessary, but it may fail to do so.
  2. This “ß” is the Eszett or scharfes S of German, suitable for transcribing German inscriptions and so forth. Usually it is better simply rendered as “ss” within an English-language context. Do not use it for lowercase Greek beta “β”, which is instead rendered by &beta;.
  3. On rare occasion this “blending” isn’t wanted. It can then be suppressed via the <nowiki> tag. Thus although [[light meter]]ed appears as “light metered” (perhaps giving the misleading impression of an article about the process of metering), [[light meter]]<nowiki>ed</nowiki> appears as “light metered”.
  4. However, this seems buggy. Here in a footnote, [[Wikipedia:Fujifilm|]] brings [[Wikipedia:Fujifilm|]].
  5. This is a very dubious convention, as what it does is to insert XHTML whose meaning is specific to definitions, which of course are irrelevant. But it’s well entrenched.
  6. In various wikis, a line-starting semicolon is often used to create a quasi-header that will not appear in the table of contents. This is poor practice, as the line-starting semicolon triggers generation by the MediaWiki software of the header-irrelevant XHTML definition markup <dl><dd>...</dd></dl>. If you want such a quasi-header, simply use regular bolding (three single quotation marks) for it.
  7. Hexadecimal: base 16. The digits run 0–9, A, B, C, D, E, F.
  8. A footnote crying out to be edited and turned into something worthwhile.
  9. The reason why we point to the older examples at the Wayback Machine rather than here in is related to the template: that display of an old version here will show it with any templates as these are now, and not necessarily as they were at the time.

See also