Writing style guide

To present documentation in an organized, standardized, and easy-to-read manner, the Mozilla Developer Network style guide describes how text should be organized, spelled, formatted, and so on. These are guidelines rather than strict rules. We are more interested in content than formatting, so don't feel obligated to learn the style guide before contributing. Do not be upset or surprised, however, if an industrious volunteer later edits your work to conform to this guide.

If you're looking for specifics of how a given type of page should be structured, see the MDN page layout guide.

The language aspects of this guide apply primarily to English-language documentation. Other languages may have (and are welcome to create) style guides. These should be published as subpages of the localization team's page.

For style standards that apply to content written for sites other than MDN, refer to the One Mozilla style guide.

Basics

The best place to start in any extensive publishing style guide is with some very basic text standards to help keep documentation consistent. The following sections outline some of these basics to help you.

Page titles

Page titles are used in search results and also used to structure the page hierarchy in the breadcrumb list at the top of the page. The page title (which is displayed at the top of the page and in the search results) can be different from the page "slug", which is the portion of the page's URL following "<locale>/docs/".

Title and heading capitalization

Page titles and section headings should use sentence-style capitalization (only capitalize the first word and proper nouns) rather than headline-style capitalization:

• Correct: "A new method for creating JavaScript rollovers"
• Incorrect: "A New Method for Creating JavaScript Rollovers"

We have many older pages that were written before this style rule was established. Feel free to update them as needed if you like. We're gradually getting to them.

Choosing titles and slugs

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should just be a word or two.

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

Creating new subtrees

When you need to add some articles about a topic or subject area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using some macros we've created.

For example, consider the JavaScript guide, which is structured as follows:

• JavaScript/Guide - Main table-of-contents page
• JavaScript/Guide/JavaScript Overview
• JavaScript/Guide/Functions
• JavaScript/Guide/Details of the Object Model

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

Sections, paragraphs, and newlines

Use heading levels in decreasing order: <h2> then <h3> then <h4>, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the Next, Previous, and PreviousNext macros.

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the Shift key while pressing Enter.

Don't create single subsections -- you don't subdivide a topic into one. It's either two subheadings or more or none at all. 

Don't have bumping heads, which are headings followed immediately by headings. Aside from looking horrible, it's helpful to readers if every heading has at least a brief intro after it to introduce the subsections beneath.

Text formatting and styles

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into #mdn and ask for help.

Code sample style and formatting

Tabs and line breaks

Use two spaces per tab in all code examples. Indent the code cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

if (condition) {
  /* handle the condition */
} else {
  /* handle the "else" case */
} 

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
       || class.YET_ANOTHER_CONDITION ) {
  /* something */
}

var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
                           .createInstance(Components.interfaces.nsIToolkitProfileService);

Inline code formatting

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names (this uses the <code> element). For example, "the frenchText() function".

Method names should be followed by a pair of parentheses: doSomethingUseful(). The parentheses help differentiate methods from other code terms.

Syntax highlighting

Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the <code> element. Select the appropriate language from the language list button (the one with the two code blocks), as seen in the screenshot to the right. This will insert a preformatted code box with line numbers and syntax highlighting for the chosen language.

The following example shows text with JavaScript formatting:

for (var i = 0, j = 9; i <= 9; i++, j--)
  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);

If no appropriate language is available, use ("No Highlight" in the language menu). This will result in code without syntax highlighting:

x = 42;

Syntax definitions

If you want to insert a syntax definition, you need the related class manually. To do that click the "pre" button first, then enter the syntax definition. When that's done, switch to the source mode by clicking the "Source" button. Scroll to the inserted <pre> block and add class="syntaxbox" to it. This will give the syntax definition a special formatting distinguishing it from normal code.

Blocks not referring to code

There are a few use cases where a <pre> block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a <pre> without class. Those cases include things like tree structures:

root/

    folder1/
        file1

    folder2/
        file2
        file3

To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.

Styling HTML element references

There are specific rules to follow when writing about HTML elements. These rules produce consistent descriptions of elements and their components. They also ensure correct linking to detailed documentation.

Element names

Use the HTMLElement macro, which creates a link to the page for that element. For example, writing {{HTMLElement("title")}} produces "<title>". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).

Attribute names

Use bold face.

Attribute definitions

Use the htmlattrdef macro (e.g., {{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the htmlattrxref macro (e.g., {{htmlattrxref("attr","element")}}) to reference attribute definitions.

Attribute values

Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. For example: When the type attribute of an <input> element is set to email or tel ...

Labeling attributes

Use labels like HTML5 thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.

Latin abbreviations

In notes and parentheses

• Common Latin abbreviations (etc., i.e., e.g.) may be used in parenthetical expressions and notes. Use periods in these abbreviations, followed by a comma or other appropriate punctuation.
  • Correct: Web browsers (e.g., Firefox) can be used ...
  • Incorrect: Web browsers e.g. Firefox can be used ...
  • Incorrect: Web browsers, e.g. Firefox, can be used ...
  • Incorrect: Web browsers, (eg: Firefox) can be used ...

In running text

• In regular text (i.e., text outside of notes or parentheses), use the English equivalent of the abbreviation.
  • Correct: ... web browsers, and so on.
  • Incorrect: ... web browsers, etc.
  • Correct: Web browsers such as Firefox can be used ...
  • Incorrect: Web browsers e.g. Firefox can be used ...

Meanings and English equivalents of Latin abbreviations

Acronyms and abbreviations

Capitalization and periods

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

• Correct: XUL
• Incorrect: X.U.L.; Xul

Expansion

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

• Correct: "XUL (XML User Interface Language) is Mozilla's XML-based language..."
• Incorrect: "XUL is Mozilla's XML-based language..."

Plurals of acronyms and abbreviations

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

• Correct: CD-ROMs
• Incorrect: CD-ROM's

"Versus", "vs.", and "v."

The contraction "vs." is preferred.

• Correct: this vs. that
• Incorrect: this v. that
• Incorrect: this versus that

Capitalization

Use standard English capitalization rules in body text, and capitalize "World Wide Web" and "Web".

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER."

Contractions

Our writing style tends to be casual, so you should feel free to use contractions (e.g., "don't", "can't", "shouldn't") if you prefer.

Pluralization

Use English-style plurals, not the Latin- or Greek-influenced forms.

• Correct: syllabuses, octopuses
• Incorrect: syllabi, octopi

Hyphenation

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

• Correct: email, re-elect, co-op
• Incorrect: e-mail, reelect, coop

Gender-neutral language

It is a good idea to use gender-neutral language in any writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So for example, if you are talking about the actions of a specific man, usage of he/his would be fine, but if the subject is a person of either gender, he/his isn't appropriate.

Let's take the following example:

A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.

A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.

Both versions are gender-specific. To fix this, use gender-neutral pronouns:

A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.

You can use both genders:

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her Web cam.

making the users plural:

A confirmation dialog appears, asking the users if they allow the Web page to make use of their Web cams.

The best solution, of course, is to rewrite and eliminate the pronouns:

A confirmation dialog appears, requesting the user's permission for Web cam access.

A confirmation dialog box appears, which asks the user for permission to use the Web cam.

The last way of dealing with the problem is arguably better, as it is not only grammatically more correct but removes some of the complexity associated with dealing with genders across different languages that may have wildly varying gender rules. This solution can make translation easier for both readers and localizers.

Numbers and numerals

Dates

For dates (not including dates in code samples) use the format "January 1, 1990".

• Correct: February 24, 2006
• Incorrect: February 24th, 2006; 24 February, 2006; 24/02/2006

Alternately, you can use the YYYY/MM/DD format.

• Correct: 2006/02/24
• Incorrect: 02/24/2006; 24/02/2006; 02/24/06

Decades

For decades, use the format "1990s". Don't use an apostrophe.

• Correct: 1990s
• Incorrect: 1990's

Plurals of numerals

For plurals of numerals add "s". Don't use an apostrophe.

• Correct: 486s
• Incorrect: 486's

Commas

In running text, use commas only in five-digit and larger numbers.

• Correct: 4000; 54,000
• Incorrect: 4,000; 54000

Punctuation

Serial comma

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

• Correct: I will travel on trains, planes, and automobiles.
• Incorrect: I will travel on trains, planes and automobiles.

Spelling

For words with variant spellings, always use their American English spelling. In general, use the first entry at Dictionary.com, unless that entry is listed as a variant spelling or as being primarily used in a non-American form of English; for example, if you look up "honour", you find the phrase "Chiefly British" followed by a link to the American standard form, "honor". Do not use variant spellings.

• Correct: localize, honor
• Incorrect: localise, honour

Terminology

Obsolete vs. deprecated

It's important to be clear about the difference between the terms obsolete and deprecated.

Obsolete

On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.

Deprecated

On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.

HTML elements

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the <code> style. When you reference a given element for the first time in a section, you should use the HTMLElement macro to create a link to the documentation for the element (unless you're writing within that element's reference document page).

• Correct: the <span> element
• Incorrect: the span tag

Parameters vs. arguments

The preferred term on MDN is parameters. Please avoid the term "arguments" for consistency if at all possible.

User interface actions

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

• Correct: Click the Edit button.
• Incorrect: Click Edit.

Voice

While the active voice is preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

Wiki markup and usage

Links

Links are a large part of what makes a wiki a powerful learning and teaching tool. Below you'll find some basic information, but you can find a complete guide to creating and editing links on MDN in our editor guide.

We encourage you to create appropriate links among articles; they help improve navigation and discoverability of content. You can easily create links not only among pages on MDN (internal links) but also to pages outside MDN (external links).

There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing Ctrl+K (Cmd-K on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.

When deciding what text to use as a link, there are a few guidelines you can follow:

• Whenever a macro exists which will create the link you need, and you are able to do so, please do. Using macros to create links will not only help you get it right, but will allow future improvements to MDN to automatically be applied to your link.
• For an API name, use the entire string of the API term as written in your content. The easiest way to do this is to use the appropriate macro to construct a properly-formatted link for you.
• For a term for which you're linking to a page defining or discussing that term, use the name of the term and no additional text as the link's text. For example:
  • Correct: You can use JavaScript code to create dynamic applications on the Web.
  • Incorrect: You can use JavaScript code to create dynamic applications on the Web.
• Otherwise, when adding a useful link to prose, try to choose an action and object phrase, such as:
  • Correct: If you'd like to contribute to the Firefox project, your first step is to download and build Firefox.
  • Incorrect: If you'd like to contribute to the Firefox project, your first step is to download and build Firefox.

URL schemes

For security reasons, you should only create links that use the following schemes:

• https://
• https://
• ftp://
• mailto:

Others may or may not work, but are not supported and will probably be removed by editorial staff.

Page tags

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press enter (or return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

To remove a tag, just click the little "X" icon in the tag.

Tagging pages that need work

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

Tagging obsolete pages

Use the following tags for pages that are not current:

• Junk: Use for spam, pages created by mistake, or content that is so bad that it should be deleted. Pages with this tag are deleted from time to time.
• Obsolete: Use for content that is technically superseded, but still valid in context. For example an HTML element that is obsolete in HTML5 is still valid in HTML 4.01. You can also use the obsolete_header macro to put a prominent banner on the topic.
• Archive: Use for content that is technically superseded and no longer useful. If possible, add a note to the topic referring readers to a more current topic. For example, a page that describes how to use the Mozilla CVS repository should refer readers to a current topic on using Mercurial repos. (If no corresponding current topic exists, use the NeedsUpdate tag, and add an explanation on the Talk page.) Pages with the Archive tag are eventually moved from the main content of MDN to the Archive section.

SEO summary

The SEO summary provides a short description of a page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself.

By default, the first paragraph of the page is used as the SEO summary. However, you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

Landing pages

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

1. A brief (typically one paragraph) overview of what the technology is and how it's used. See Writing a landing page overview for tips.
2. A two-column list of links with appropriate headings. See Creating a page link list for guidelines.
3. An optional "Browser compatibility" section at the bottom of the page.

Creating a page link list

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

<div class="row topicpage-table">
  <div class="section">
    ... left column contents ...
  </div>
  <div class="section">
    ... right column contents ...
  </div>
</div>

The left column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (e.g., "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

The right column should contain one or more of the following sections, in order:

Getting help from the community

This should provide information on IRC channels and mailing lists available on the topic. The heading should use the class "Community".

Tools

A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".

Related topics

A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".

<<<finish this once we finalize the landing page standards>>>

Using, inserting images

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical. To include an image:

1. Attach the desired image file to the article (at the bottom of every article in edit mode)
2. Create an image in the WYSIWYG editor
3. In the WYSIWYG editor, in the drop-down list of attachments, select the newly created attachment that is your image
4. Press OK.

Other references

Preferred style guides

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

Preferred dictionary

For questions of spelling, please refer to Dictionary.com. The spelling checker for this site uses American English. Please do not use variant spellings (e.g., use color rather than colour).

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

MDN-specific

• Commonly-used macros on MDN, with explanations.

Language, grammar, spelling

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

• On Writing Well, by William Zinsser (Amazon link)
• Style: The Basics of Clarity and Grace, by Joseph Williams and Gregory Colomb (Amazon link)
• Common Errors in English
• English Grammar FAQ (alt.usage.english)
• Bob's quick guide to the apostrophe, you idiots (funny)
• Merriam-Webster's Concise Dictionary of English Usage (Amazon link): Scholarly but user-friendly, evidence-based advice; very good for non-native speakers, especially for preposition usage.
• English Language and Usage StackExchange: Question and answer site for English language usage.