Table of contents
- 1. Basics
- 1.1. Sections, paragraphs, and newlines
- 1.2. Text formatting and styles
- 1.3. Transformations
- 1.4. Links
- 1.4.1. Signing edits
- 1.4.2. External links
- 2. Tags
- 3. [edit]
- 4. Conventions
- 4.1. Code formatting
- 4.1.1. Tabs and intending
- 4.1.2. Syntax highlighting
- 4.2. HTML Elements
- 4.1. Code formatting
- 5. Force ignore of wiki markup
- 6. Other references
- 6.1. MDC-specific
- 6.2. External
- How to help: contents
- Lists
- Documentation wishlist
- Editing/review to do list
- Migration list
- Guides
- Getting started
- Writer's guide
- How to document Mozilla
- Writing interface reference documentation
- Page naming guide
- Disambiguation pages
- Localizing MDC
- Copyrights and licensing
- References
- MDC formatting guide
- Custom CSS classes
- Custom templates
- External redirects
- Needs redirect
The following is an MDC-specific guide reflecting our current "best practices" for formatting and layout of articles in this wiki. This material is subject to change, so these are recommendations rather than hard-and-fast rules.
If you need to do something that goes against these guidelines, feel free. Just try to stick to these guidelines as much as possible.
If you have any questions about the guidelines, contact Eric Shepherd, or ask on the #devmo IRC channel at irc://irc.mozilla.org.
Also, if there's anything you need to know that isn't covered by these guidelines, try reading the MindTouch Deki User Manual.
Basics
Sections, paragraphs, and newlines
To start a new section, choose the appropriate heading level from the Format menu in the toolbar. Typically we suggest that if you need more than three or four levels of headers, you should seriously consider breaking up your article into more, less deeply-nested, articles. You can then link those articles together [manually].
Use heading levels in decreasing order
<h1> >
<h2> >
<h3>, without skipping levels.
<h2> and "Heading 2" produces an
<h3>, etc. The "Title" format is what produces an
<h1>, but the page title is auto-generated for each page, so you rarely need to change it. In most cases, start with "Heading 1" as the top level.Pressing the enter (or return) key on your keyboard starts a new paragraph. If you wish to simply insert a newline, you can do so by holding down the shift key while pressing enter.
Text formatting and styles
Most formatting options that you may need are offered in the editor toolbar that appears when you enter edit mode. The second row on the toolbar offers buttons for boldface, italic, underlining, strikethrough text, and so forth. You can hover over the buttons with your mouse cursor to see a tooltip explaining each.
The third row offers additional formatting options. The Style menu lets you choose among several predefined styles we frequently use. Most of these are fairly obvious in purpose.
You should use the "Code (inline)" style for function names, variable names, and method names. Method names should have a pair of parentheses after them, like this: doSomethingUseful(). For entire lines (or multiple lines) of code, you should instead choose "Formatted" from the "Format" menu in the toolbar. See Transformations below for information on how to apply syntax highlighting.
The Format menu offers additional formatting options, including headers and the "Normal" and "Formatted" styles. Normal is typical body text, while Formatted causes the transformation menu to come into play.
Transformations
Transformations allow you to specify a formatting technique to apply to Formatted text. For example, consider the following code sample:
int foo(char *bar) {
int l = strlen(bar);
printf("Length of string %s is %d\n", bar, l);
return l;
}
That's a pretty basic code sample, and isn't very appealing to look at. By using the Formatted format, we can then apply a syntax highlighting transformation to it (in this case syntax.cpp for C++), resulting in:
int foo(char *bar) {
int l = strlen(bar);
printf("Length of string %s is %d\n", bar, l);
return l;
}
This makes it easy to refer to, for example, the fact that line 3 of the sample uses the printf() standard C library function.
Links
You can insert links using the Insert/Edit Link tool. This calls up a dialog that provides a user interface for either manually typing in the destination for the link (whether local on MDC or on another site) or browsing or searching the site to find the article to which you wish to link.
The link editor provides the ability to easily find not only the page to which you'd like to link, but the individual section within it as well if you prefer. It also makes it easy to insert links to images and other files.
Signing edits
You can sign your edits. Entering three tildes in a row inserts your username with a link to your user page. Entering four tildes in a row inserts your username as well as the date and time of your edit. This is particularly helpful on Talk pages. For example:
Sheppy (three tildes)
and
Sheppy 19 Aug 2008 (four tildes)
External links
Linking to external sites is done in exactly the same way as for in-wiki pages. You simply type the full URL for the link in the link editor dialog. For example: Visit the Mozilla Project web site.
http://mxr.mozilla.org/comm-central/find?string=package-manifest\.in is mistaken for an internal link, while http://mxr.mozilla.org/comm-central/find?string=package-manifest%5C.in works correctly. This is true even if the link is edited in the source view.You can also simply embed the URL into the body of your text: http://www.mozilla.org/.
We also provide a template that makes it easy to link to bugs in Mozilla's Bugzilla database:
{{Bug(322603)}}
results in:
For WebKit bugs, you can use this template:
{{Webkitbug("322603")}}
results in:
Tags
Every page in the wiki should be tagged. To add tags, simply click "Add and edit tags" in the tags list at the end of the article. Tags will autocomplete as you type. Each article may have as many tags as appropriate. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.
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 superceded, 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()}} template to put a prominent banner on the topic.
- Archive: Use for content that is technically superceded 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 may eventually be moved into an archive sub-tree and/or hidden in search results.
[edit]
Conventions
This section documents conventions that are used for marking up different types of content.
Code formatting
These are guidelines to formatting your sample code for consistency's and clarity's sake.
Tabs and intending
You should use two spaces per tab in all code samples. Code should be intended cleanly. 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);
Syntax highlighting
You should apply syntax highlighting to code samples longer than 2-3 lines or so. Use your best judgement.
To apply syntax highlighting, apply the Formatted format to your code sample using the editor's toolbar, then choose the language from the Transformations menu. Or, if you prefer to work in source mode, add the following attributes to the <pre> tag for your code sample:
<pre function="syntax.xxxx" class="deki-transform">
We have syntax highlighter options available for every language we commonly use on MDC, including:
- HTML (syntax.html)
- CSS (syntax.css)
- JavaScript (syntax.javascript)
- SVG (syntax.xml)
- XML (syntax.xml)
- C++ (syntax.cpp)
You can also render SVG inline by applying the "Svg" transformation to it.
Disable line numbers:
To disable the line numbers add the following code directly behind the language code: {code:$, gutter:false}:
<pre function="syntax.xml{code:$, gutter:false}" class="deki-transform">HTML Elements
- Element names
- Use the HTMLElement template, (e.g., {{HTMLElement("title")}}), which creates a link to the page for that element. 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 template (e.g., {{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages. (Use the htmlattrxref template (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. E.g.: When the type attribute of an
<input>element is set toemailortel... - 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.
Force ignore of wiki markup
If you need a particular piece of wiki markup to be ignored by the parser, simply use the "plain" CSS class, like this:
<span class="plain">'''this wiki markup will not be interpreted'''</span>
'''this wiki markup will not be interpreted'''
Other references
MDC-specific
- Custom CSS classes defined for all MDC pages.
- Custom templates created for use on MDC, with explanations.
- MDC policies and guidelines:
- If you're not sure how to name your page, see Page naming guide.
- MDC:Disambiguation

