Help:Markup reference

This page is within the userspace of Zuleika. The plan is first to improve it and then to move it, to "Help:Markup reference" or similar. After the move, it may of course be edited and improved by any Camera-wiki.org editor who is sufficiently well-informed and careful. And no doubt various improvements will be possible. In the meantime, it’s editable by Zuleika, and by specific invitation. Other editors are most welcome to make suggestions for it; these suggestions can be placed in User talk:Zuleika/Junkyard.

This is an intermediate-level reference guide to the technical aspects of writing articles. It concentrates on telling you how to format articles in the way you wish. But there’s also some guidance on what to do. If you’re a complete beginner, make sure to look first at Editing. If you’re experienced, this page may answer some remaining questions; but for comprehensive information please see the recommendations made within various sections and also the links listed below under “Further reading”.

The content here primarily involves special markup for MediaWiki, the software behind not only Camera-wiki.org but also Wikipedia (for which it was created) and many other wikis. If you’re experienced with one of these other wikis, you should find that almost all of what follows tells you what you already know. And if you aren’t, then although what’s below may tax your patience, you’ll be able to apply it elsewhere too.

The page is likely to seem alarmingly long. The authors don’t know why people will want to consult it and have therefore tried to provide all the information that anybody might want. Its first author (chronologically speaking) confesses that until he wrote this he never remembered how to construct tables (and had to look it up every time) and that 90% or more of his edits use only a small subset of what's explained below.

Code in general

Now that the very basics (paragraphs, etc) are out of the way, some general notes here about code may help: they’ll avoid either misunderstandings or repeated explanations below.

By 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 Camera-wiki.org.)

XHTML markup

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, which take the form of <XYZ> and </XYZ> respectively. So: code for the start of italics, then what is to be in italics, then code for the end of italics. The principle is general; and thus for example first code for the start of a table, then the content of the table, then code 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 because MediaWiki uses XHTML, a paragraph must be explicitly closed 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 not. So it’s better to stick to XHTML.)

Not all XHTML tags can be used for editing. Those that are used 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 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) <XYZ> . . . </XYZ>; (ii) <PQR /> — of XHTML, but that aren’t XHTML. (Examples of the two are REF and REFERENCES respectively; use of both is necessary 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 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”.

Nesting

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>.

Attributes

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.
• Each value should be in double quotation marks.
• 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.

CSS

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 that’s available to the editor of a wiki. It’s added to a tag via the “style” attribute: the value of this 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.
• 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” above, the order is fixed.)
• Within each declaration, a space after the colon is optional.
• 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.

Templates

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

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).

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, add one colon : at the very start of your comment.

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)

Think of an article as having a hierarchy of organization. Any longer article benefits from subdivision by headers.

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”.

There follows a table of contents, which the software has generated automatically. For Pearlette, 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 double equals signs: ==Second generation: hinged back==. The latter is one stage below this, and uses a pair of treble equals signs: ===1933 model===. They’re not numbered: the numbering is generated automatically for the table of contents. (For more on tables of contents, see below.)

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.

For more, see Section (Wikipedia).

Page ingredients

Table of contents

When the number of headers (see above) within a page goes over three, this automatically triggers the generation of 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 in double underlines:

• Adding __TOC__ somewhere in a page forces generation of 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-wiki.org.)

Images

Camera illustrations are the life-blood of Camera-wiki.org. 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.

Lists

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.

*This
*That
*The other

produces

• 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.

#This
#That
#The other

produces

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):

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

produces

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

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

Tables

There’s no escaping it: creating tables in Camerawiki.org is rather complex. There are three reasons for this:

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. Even moderate elegance 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. Please do try to follow the first part at least. And remember: lesser minds than yours have been here before, and have mastered tables!

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 like a conventional table nor is easy to understand as a table. 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:

{|class="wikitable"
! Header 1
! Header 2
|-
| row 1, cell 1
| row 1, cell 2
|-
| row 2, cell 1
| row 2, cell 2
|}

Here’s what this means. Each of the following necessarily starts 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. (We’ll see this at work next, when we look at captions.)

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

{|class="wikitable"
| row 1, cell 1 || row 1, cell 2
|-
| row 2, cell 1 || row 2, cell 2
|}

Caption

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:

{|class="wikitable"
|+ 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

So much for the basics of tables. Now we’ll proceed. If what follows looks alarming, don’t worry, because you don’t have to know it. You can instead leave a request in the talk page of the particular article for somebody else to come along and make this or that improvement.

Merging cells across columns and rows

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

model	IA	IB	IC	IAS	ICS	IBS
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 show what is where):

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

(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.)

First, let’s have “IBS” expand across what are now “blank1” and “blank2”, and “Fuji” expand all the way across to “blank13”. In XHTML (and 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”. Deletion is straightforward. In MediaWiki markup, you add any attribute to a cell in front of the pipe | character and any text. And so:

model	IA	IB	IC	IAS	ICS	IBS
variant	blank3	blank4	blank5	blank6	blank7	a	b	c
lens	Fuji							Rectar

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).

model	IA	IB	IC	IAS	ICS	IBS
variant						a	b	c
lens	Fuji							Rectar

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

All seems well (in a bunched-up kind of way). 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) centred.

The table above has cells that span columns and cells that span rows, but no cell that spans both. But 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. (As always with XTML tag attributes, their order doesn’t matter: either colspan then rowspan, or vice versa.) Here (for some fictional camera) is the result:

model	Hotei	Jurōjin	Fukurokuju	Bishamonten	Benzaiten	Daikokuten
variant						a	b	c
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

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 centring of a table in the page (or other element), see “Centring”, below
• for the positioning of tables so that text can go to their left or right, see “Floating left or right”, below
• for the centring 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:

• “Table” (Wikipedia).
• “Tables” (MediaWiki)

For more on CSS properties and values, numerous websites offer help; a good one is the “Style Master for CSS Tutorial” from Western Civilisation.

Other block elements

XHTML (like HTML) provides the DIV element for blocks of . . . anything. 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 — when the opening <div> is elaborated to <div attribute1="value1" attribute2="value2" ...> that it becomes useful. Below, we start to explore these uses; but here’s a simple introduction.

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

<div style="color:#000; background-color:#effff9;">
http://www.flickr.com/photos/14463685@N07/2971394599/in/pool-camerapedia/ http://farm4.static.flickr.com/3025/2971394599_6f86b9cd65_o.jpg<br />
Contarex I<br />
image by Howard Somerville<br />
(Image rights)<br />
</div>

produces:

Contarex I
image by Howard Somerville
(Image rights)

The greenish background shows the area covered by the DIV. (For an explanation of the colouring, 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 189 pixels wide.

The tiny blue graphic to the right showing an arrow emerging from a box isn’t obviously useful or even decorative. 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 anything that’s of class "plainlinks".

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

Contarex I
image by Howard Somerville
(Image rights)

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

Definitions

Definitions — presented separately, perhaps in a list — are only rarely of use here within Camera-wiki.org, and are not even used within the 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.

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 Camera-wiki.org 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:

3

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. What we need to do is suppress this significance, in one way or another. The first:

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

results in

3:2

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

Alternatively, knowing from “C0 Controls and Basic Latin” (within “Alan Wood’s Unicode Resources”) that the decimal number within Unicode for the colon character is 58, we infer that it can be represented by :, and write:

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

This has the same result:

3:2

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 for short string of characters), type it after “Enter string to convert” in “Unicode conversion” (within Brian Chandler’s “Imaginatorium”).

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

Character formatting

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

First, the apostrophes.

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

Use three apostrophes 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 [...]”.

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

Secondly, the XHTML tags (which are rarely needed). You mark the start of an area needing some change with <XXX> and you mark its end with </XXX> — though not “XXX” but instead one of “sup”, “sub” and “small”, as explained below:

For superscripted text: marketed as the "330<sup>D</sup>" in Europe brings “marketed as the "330^D" 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]”.

For underlined text: <span style="text-decoration:underline">XYZ</span> brings “XYZ”.

For struck out text: <span style="text-decoration:line-through">XYZ</span> brings “XYZ”.

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

Editors familiar with CSS can also use other declarations within <span style="[CSS declaration block]"> and </span>. (But with restraint, please!)

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

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.

For small agglomerations of images, the use of tables (described above) is acceptable. But tables are better avoided for anything large, as they tend to force a lot of scrolling in small browser windows. ???

Dimensions

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 everything that can be specified in pixels 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 here:

• 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, and it often brings the risk of ugliness or even illegibility in differently sized browser windows. In principle it’s better to leave height unspecified and let the browser do what’s best. If height is specified, then this should be accompanied by 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, not specified in the code, is pixels. This is XHTML markup.)

Margins

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

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.)

Centring

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 centre 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:205px; margin-left:auto; margin-right:auto">.

Contarex I
image by Howard Somerville
(Image rights)

Floating left or right

Contarex I
image by Howard Somerville
(Image rights)
[“floated left”]

Contarex I
image by Howard Somerville
(Image rights)
[“floated 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 style="[declarations separated by semicolons]" (see “CSS” above), and one of these declarations must be 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">.

It may be that the text you are reading now is between rather than below the two pictures of cameras. In order to persuade you that it will wrap below as well as beside the DIVs, we could have made this explanation wordy (or stuffed it with meaningless filler. But rather than add yet more bulk, we invite you to squeeze 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.

Clearing

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 from happening, you need to get the element to clear its left-hand side. You do this with inline CSS, and specifically the declaration clear:left.

Inline CSS requires the style attribute, which in turn requires an XHTML tag. Partly because wiki text seldom requires these (for example, it’s rare for a paragraph in wiki text to be explicitly opened and closed), and partly out of habit, 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 from happening, 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" />; you can get this 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" />; you can get this 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

Colors

Hungary	Poland	Czecho- slovakia
MOM	PZO	Meopta

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

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

The first line of code for the particular 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 colour that you want, see for example this page (at W3schools.com).

Certain named colours are also possible; for a list arranged by colour, see this page (also at W3schools.com).

If either of “color” and “background-color” is specified, both ought to be specified. The reason is that some people viewing Camera-wiki.org may have set up their browsers to view text as bright against a dark background.

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

Padding and borders

Super Flex Baby
image by Rebollo_fr
(Image rights)

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 10 pixels of padding. Quite aside from its border, in reality the DIV is now 260 pixels wide — but its width is nevertheless set at 240 pixels, because this is the way that CSS defines width.

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

When an element benefits from a border, the border 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. Width is normally one or two pixels (anything larger rarely looks pleasant for our purposes). There are various options for style, but those beyond “solid” and “dotted” rarely look pleasant. The color should usually be dark; what 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 specification would be border:1px solid #000000 (in which the 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:

model	IA	IB	IC	IAS	ICS	IBS
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 that is used. Commonly, the content of table head cells (such as “model” and “IA” along the top) is centred (and in boldface), whereas that of the other table cells is left-aligned.

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

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

The result:

model	IA	IB	IC	IAS	ICS	IBS
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 CSS declaration text-align:left for any cell whose text should be left-aligned. For example:

|-
| style="text-align:left" | lens
| colspan="7" | Fuji || Rectar

for the result:

model	IA	IB	IC	IAS	ICS	IBS
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

Samocaflex II
image by Rebollo_fr
(Image rights)

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- slovakia
MOM	PZO	Meopta

Hungary	Poland	Czecho- slovakia
MOM	PZO	Meopta

Hungary	Poland	Czecho- slovakia
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.)

Links

For links from graphics, see Adding images.

Internal links

Link to another page, or to a different point within the same page, where a link seems useful.

For example, when writing about a 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

Camera-wiki.org 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. Camera-wiki.org 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.

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”.

Linking to a point within the same page

In order to link to a point within the same page, skip the article title and instead simply start with #; for example, [[#Tables|Tables]] for “Tables” within this page.

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

Anticipating link rot

If a page within Camera-wiki.org 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 worked (it has been automatically redirected to the latter).

However, if a 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, telling subsequent editors that they should only rename it if they do so with care.

External links

Simply, for a link to a page outside Camera-wiki.org, put within single (square) brackets: the URL followed by a space (no pipe character) and the page title: [http://www.tlr-cameras.com/ TLR Cameras Website] for TLR Cameras Website.

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.

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

Footnoting

After either a factual assertion that would benefit from being sourced to an authority, or an opinion or 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>XYZ</ref>. This will lead to the automatic generation of an appropriate index number and a footnote that reads “XYZ”.

A given footnote may be pointed to from two or more places. In any one of these places — among which the first is strongly recommended, as this position aids subsequent editing — add the footnote in full, but with a name. Example: <ref name="perfekta66">[content of note]</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, 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.)
• Edit the section, temporarily adding <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 Camera-wiki.org 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. “content”). (This “group="XYZ"” may be combined with “name="ABC"”, and in either order.)
• 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 Camera-wiki.org.)

Categories

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, 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 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 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: {{Subst:Dechert Canon}} (for substitution) and {{Dechert Canon}} (for transclusion); note how “Subst:” appears in the former.

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 the content of the template can have any effect.

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, here is a February 2007 version of the article Mihama Six. At its top right is a template listing similar Japanese cameras. Pay attention to 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 always known 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 will require its addition in just one place (the template) in order that mention of it is added every article containing 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”.

Creation of a template is beyond the scope of this page.

Transclusion is not limited to templates: pages in other namespaces (other kinds of pages) can be transcluded too. However, in Camera-wiki.org (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, you should be aware 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 Camera-wiki.org.

Miscellaneous

Hidden comments

Material written 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.)

Signing

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 Camera-wiki.org: monospaced lettering. 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 preceded it with a space.

See also

• Wiki markup, Wikipedia
• HTML in wikitext, Wikipedia
• Magic words, MediaWiki