MDN Style Guide

  • Revision slug: Project:MDC_style_guide
  • Revision title: MDC formatting guide
  • Revision id: 320357
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment add info about landing pages

Revision Content

{{ MDCProjectPagesTOC() }}

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.

Note: As a general rule, if what you want to do can't be done using the WYSIWYG editor, you probably should look at other ways to do things.  The WYSIWYG editor covers nearly everything we recommend doing.

If you have any questions about the guidelines, contact Eric Shepherd, or ask on the #devmo IRC channel at irc://irc.mozilla.org.

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 {{ HTMLElement("h2") }} > {{ HTMLElement("h3") }} > {{ HTMLElement("h4") }}, without skipping levels. H2 is the highest level allowed, because H1 is reserved for the page title.

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 {{ anch("Transformations") }} below for information on how to apply syntax highlighting.

Note: The "Note" style is used to call out important notes, like this one.
Warning: Similarly, the "Warning" style creates warning boxes like this.

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 Preformatted format, we can then select the language for syntax highlighting in the popup next 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.

Note: If you copy and paste the formatted code sample above, it will include the line numbers, which is usually not wanted. To get a clean copy of the sample, click the view plain button above the code. This opens a window that contains the code sample with no line numbers, and you can copy and paste from this.

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)

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.

Note: External links aren't URL-encoded for you, even when using the Insert/Edit Link command, and in rare cases this might cause the software to treat an external link as if it was an internal link. For example, 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:

{{ Bug(322603) }}

For WebKit bugs, you can use this template:

{{Webkitbug("322603")}}

results in:

{{ Webkitbug("322603") }}

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.

Landing pages

Landing pages are pages at the root of a topic area of the site, such as our main CSS or HTML pages, for example. We have a standard format for these pages, which should generally be followed. They consist of three areas:

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

Writing a landing page overview

The overview for a landing page should be just a few sentences describing the topic area covered by the articles to which the landing page links. It shouldn't go into any detail; instead, its job is to help the reader quickly determine whether or not what they're looking for is likely to be found in this section of MDN. Start with a one or two sentence definition of the technology; for example: "Cascading Style Sheets, most of the time abbreviated in CSS, is a stylesheet language used to describe the presentation of a document written in HTML or XML." Then provide any further explanation that might be required simply to understand what the technology is used for.

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-hand 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 (for example "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 setence summary of the article in the corresponding <dd> block.

The right-hand 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 about 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".

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">
Note: Sometimes the WYSIWYG editor will remove empty carriage returns from code samples. To get around this, use Source view and paste your code between <pre> tags.

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 to email or tel ...
Labeling attributes
Use labels like {{ HTMLVersionInline(5) }} 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

External

{{ languages( { "fr": "Project:fr/R\u00e9f\u00e9rence_des_balises_wiki", "pt": "Project:pt/Refer\u00eancia_de_marca\u00e7\u00e3o_wiki", "ja": "Project:ja/Wiki_Markup_Reference", "zh-cn": "Project:cn/Wiki\u6807\u8bb0\u8bed\u6cd5\u53c2\u8003", "pl": "Project:pl/Opis_sk\u0142adni_Wiki" } ) }}

Revision Source

<p>{{ MDCProjectPagesTOC() }}</p>
<p>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.</p>
<p>If you need to do something that goes against these guidelines, feel free. Just try to stick to these guidelines as much as possible.</p>
<div class="note">
  <p><strong>Note:</strong> As a general rule, if what you want to do can't be done using the WYSIWYG editor, you probably should look at other ways to do things.&nbsp; The WYSIWYG editor covers nearly everything we recommend doing.</p>
</div>
<p>If you have any questions about the guidelines, contact <a href="/User:Sheppy" title="User:Sheppy">Eric Shepherd</a>, or ask on the #devmo IRC channel at <a class="link-irc" href="irc://irc.mozilla.org" rel="freelink">irc://irc.mozilla.org</a>.</p>
<h2 id="Basics" name="Basics">Basics</h2>
<h3 id="Sections.2C_Paragraphs.2C_Newlines" name="Sections.2C_Paragraphs.2C_Newlines">Sections, paragraphs, and newlines</h3>
<p>To start a new section, choose the appropriate heading level from the Format menu in the toolbar.&nbsp; 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.&nbsp; You can then link those articles together [manually].</p>
<p>Use heading levels in decreasing order {{ HTMLElement("h2") }} &gt; {{ HTMLElement("h3") }} &gt; {{ HTMLElement("h4") }}, without skipping levels. H2 is the highest level allowed, because H1 is reserved for the page title.</p>
<p>Pressing the enter (or return) key on your keyboard starts a new paragraph.&nbsp; If you wish to simply insert a newline, you can do so by holding down the shift key while pressing enter.</p>
<h3 id="Text_Formatting" name="Text_Formatting">Text formatting and styles</h3>
<p>Most formatting options that you may need are offered in the editor toolbar that appears when you enter edit mode.&nbsp; The second row on the toolbar offers buttons for boldface, italic, underlining, strikethrough text, and so forth.&nbsp; You can hover over the buttons with your mouse cursor to see a tooltip explaining each.</p>
<p>The third row offers additional formatting options.&nbsp; The Style menu lets you choose among several predefined styles we frequently use.&nbsp; Most of these are fairly obvious in purpose.</p>
<p>You should use the "Code (inline)"&nbsp;style for function names, variable names, and method names. Method names should have a pair of parentheses after them, like this:&nbsp;<code>doSomethingUseful()</code>. For entire lines (or multiple lines)&nbsp;of code, you should instead choose "Formatted"&nbsp;from the "Format"&nbsp;menu in the toolbar. See {{ anch("Transformations") }} below for information on how to apply syntax highlighting.</p>
<div class="note">
  <strong>Note: </strong>The "Note" style is used to call out important notes, like this one.</div>
<div class="warning">
  <strong>Warning:</strong> Similarly, the "Warning" style creates warning boxes like this.</div>
<p>The Format menu offers additional formatting options, including headers and the "Normal" and "Formatted" styles.&nbsp; Normal is typical body text, while Formatted causes the transformation menu to come into play.</p>
<h3 id="Transformations">Transformations</h3>
<p>Transformations allow you to specify a formatting technique to apply to Formatted text.&nbsp; For example, consider the following code sample:</p>
<pre>
int foo(char *bar) {
  int l = strlen(bar);
  printf("Length of string %s is %d\n", bar, l);
  return l;
}
</pre>
<p>That's a pretty basic code sample, and isn't very appealing to look at.&nbsp; By using the Preformatted format, we can then select the language for syntax highlighting in the popup next to it (in this case <strong>syntax.cpp</strong>&nbsp;for C++), resulting in:</p>
<pre class="brush: cpp">
int foo(char *bar) {
  int l = strlen(bar);
  printf("Length of string %s is %d\n", bar, l);
  return l;
}
</pre>
<p>This makes it easy to refer to, for example, the fact that line 3 of the sample uses the <code>printf()</code> standard C library function.</p>
<div class="note">
  <strong>Note:</strong>&nbsp;If you copy and paste the formatted code sample above, it will include the line numbers, which is usually not wanted. To get a clean copy of the sample, click the <strong>view plain</strong>&nbsp;button above the code. This opens a window that contains the code sample with no line numbers, and you can copy and paste from this.</div>
<h3 id="Links" name="Links">Links</h3>
<p>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.</p>
<p>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.&nbsp; It also makes it easy to insert links to images and other files.</p>
<h4 id="Signing_edits">Signing edits</h4>
<p>You can sign your edits.&nbsp; Entering three tildes in a row inserts your username with a link to your user page.&nbsp; Entering four tildes in a row inserts your username as well as the date and time of your edit.&nbsp; This is particularly helpful on Talk pages.&nbsp; For example:</p>
<p><a class="internal" href="/User:Sheppy" title="User:Sheppy">Sheppy</a> (three tildes)</p>
<p>and</p>
<p><a class="internal" href="/User:Sheppy" title="User:Sheppy">Sheppy</a> 19 Aug 2008 (four tildes)</p>
<h4 id="External_links">External links</h4>
<p>Linking to external sites is done in exactly the same way as for in-wiki pages.&nbsp; You simply type the full URL for the link in the link editor dialog.&nbsp; For example: <a class="external" href="http://www.mozilla.org/" title="http://www.mozilla.org/">Visit the Mozilla Project web site</a>.</p>
<div class="note">
  <strong>Note:</strong> External links aren't URL-encoded for you, even when using the <em>Insert/Edit Link</em> command, and in rare cases this might cause the software to treat an external link as if it was an internal link. For example, <code><span class="nowiki">http://mxr.mozilla.org/comm-central/find?string=package-manifest\.in</span></code> is mistaken for an internal link, while <code><span class="nowiki">http://mxr.mozilla.org/comm-central/find?string=package-manifest%5C.in</span></code> works correctly. This is true even if the link is edited in the source view.</div>
<p>You can also simply embed the URL into the body of your text: <a class="external" href="http://www.mozilla.org/" rel="freelink">http://www.mozilla.org/</a>.</p>
<p>We also provide a template that makes it easy to link to bugs in Mozilla's Bugzilla database:</p>
<pre>
{{Bug(322603)}}
</pre>
<p>results in:</p>
<p>{{ Bug(322603) }}</p>
<p>For WebKit bugs, you can use this template:</p>
<pre>
{{Webkitbug("322603")}}
</pre>
<p>results in:</p>
<p>{{ Webkitbug("322603") }}</p>
<h2 id="Tags">Tags</h2>
<p>Every page in the wiki should be tagged.&nbsp; To add tags, simply click "Add and edit tags" in the tags list at the end of the article.&nbsp; Tags will autocomplete as you type.&nbsp; Each article may have as many tags as appropriate.&nbsp; For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.</p>
<p>Use the following tags for pages that are not current:</p>
<ul>
  <li><em>Junk</em>: 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.</li>
  <li><em>Obsolete</em>: 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 <span class="nowiki">{{obsolete_header()}}</span> template to put a prominent banner on the topic.</li>
  <li><em>Archive</em>: 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 <em>NeedsUpdate</em> 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.</li>
</ul>
<h2>Landing pages</h2>
<p><strong>Landing pages</strong> are pages at the root of a topic area of the site, such as our main <a href="/en-US/docs/CSS" title="/en-US/docs/CSS">CSS</a> or <a href="/en-US/docs/HTML" title="/en-US/docs/HTML">HTML</a> pages, for example. We have a standard format for these pages, which should generally be followed. They consist of three areas:</p>
<ol>
  <li>A brief (typically one paragraph) overview of what the technology is and what it's used for. See {{anch("Writing a landing page overview")}} for tips.</li>
  <li>A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.</li>
  <li>An <strong>optional</strong> "Browser compatibility" section at the bottom of the page.</li>
</ol>
<h3>Writing a landing page overview</h3>
<p>The overview for a landing page should be just a few sentences describing the topic area covered by the articles to which the landing page links. It shouldn't go into any detail; instead, its job is to help the reader quickly determine whether or not what they're looking for is likely to be found in this section of MDN. Start with a one or two sentence definition of the technology; for example: "<strong>Cascading Style Sheets</strong>, most of the time abbreviated in <strong>CSS</strong>, is a <a href="/en-US/docs/DOM/stylesheet">stylesheet</a> language used to describe the presentation of a document written in <a href="/en-US/docs/HTML" title="The HyperText Mark-up Language">HTML</a> or <a href="/en-US/docs/XML" title="en-US/docs/XML">XML</a>." Then provide any further explanation that might be required simply to understand what the technology is used for.</p>
<h3>Creating a page link list</h3>
<p>The link list section of an MDN landing page consists of two columns. These are created using the following HTML:</p>
<pre class="brush: html">
&lt;div class="row topicpage-table"&gt;
  &lt;div class="section"&gt;
    ... left column contents ...
  &lt;/div&gt;
  &lt;div class="section"&gt;
    ... right column contents ...
  &lt;/div&gt;
&lt;/div&gt;</pre>
<p>The left-hand column should be a list of articles, with an <code>&lt;h2&gt;</code> header at the top of the left column explaining that it's a list of articles about the topic (for example "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <code>&lt;dl&gt;</code> list of articles, with each article's link in a <code>&lt;dt&gt;</code> block and a brief one-or-two setence summary of the article in the corresponding <code>&lt;dd&gt;</code> block.</p>
<p>The right-hand column should contain one or more of the following sections, in order:</p>
<dl>
  <dt>
    Getting help from the community</dt>
  <dd>
    This should provide information on IRC channels and mailing lists available about the topic. The heading should use the class "Community".</dd>
  <dt>
    Tools</dt>
  <dd>
    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".</dd>
  <dt>
    Related topics</dt>
  <dd>
    A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".</dd>
</dl>
<h2 id="Conventions">Conventions</h2>
<p>This section documents conventions that are used for marking up different types of content.</p>
<h3 id="Code_formatting">Code formatting</h3>
<p>These are guidelines to formatting your sample code for consistency's and clarity's sake.</p>
<h4 id="Tabs_and_intending">Tabs and intending</h4>
<p>You should use two spaces per tab in all code samples. Code should be intended cleanly. For example:</p>
<pre class="brush: js">
if (condition) {
&nbsp; /* handle the condition */
}&nbsp;else {
&nbsp; /* handle the "else" case */
} 
</pre>
<p>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.</p>
<pre class="brush: js">
if (class.CONDITION || class.OTHER_CONDITION&nbsp;||&nbsp;class.SOME_OTHER_CONDITION
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || class.YET_ANOTHER_CONDITION )&nbsp;{
&nbsp; /*&nbsp;something */
}

var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
                           .createInstance(Components.interfaces.nsIToolkitProfileService);
</pre>
<h4 id="Syntax_highlighting">Syntax highlighting</h4>
<p>You should apply syntax highlighting to code samples longer than 2-3 lines or so. Use your best judgement.</p>
<p>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 <code>&lt;pre&gt;</code> tag for your code sample:</p>
<pre>
&lt;pre <strong>function="syntax.xxxx" class="deki-transform"</strong>&gt;
</pre>
<div class="note">
  <strong>Note:</strong> Sometimes the WYSIWYG editor will remove empty carriage returns from code samples. To get around this, use Source view and paste your code between &lt;pre&gt; tags.</div>
<p>We have syntax highlighter options available for every language we commonly use on MDC, including:</p>
<ul>
  <li>HTML (syntax.html)</li>
  <li>CSS (syntax.css)</li>
  <li>JavaScript (syntax.javascript)</li>
  <li>SVG&nbsp;(syntax.xml)</li>
  <li>XML&nbsp;(syntax.xml)</li>
  <li>C++ (syntax.cpp)</li>
</ul>
<p>You can also render SVG inline by applying the "Svg" transformation to it.</p>
<h5 id="Disable_line_numbers.3A">Disable line numbers:</h5>
<p>To disable the line numbers add the following code directly behind the language code: <span class="nowiki"><code>{code:$, gutter:false}</code></span>:</p>
<pre>
&lt;pre function="syntax.xml<strong>{code:$, gutter:false}</strong>" class="deki-transform"&gt;</pre>
<h3 id="HTML.C2.A0Elements">HTML&nbsp;Elements</h3>
<dl>
  <dt>
    Element names</dt>
  <dd>
    Use the HTMLElement template, (e.g., <span class="nowiki">{{HTMLElement("title")}}</span>), 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., <code>&lt;title&gt;</code>).</dd>
  <dt>
    Attribute names</dt>
  <dd>
    Use <strong>bold face</strong>.</dd>
  <dt>
    Attribute definitions</dt>
  <dd>
    Use the htmlattrdef template (e.g., <span class="nowiki">{{htmlattrdef("type")}}</span>) for the definition term, so that it can be linked to from other pages. (Use the htmlattrxref template (e.g., <span class="nowiki">{{htmlattrxref("attr","element")}}</span>) to reference attribute definitions.)</dd>
  <dt>
    Attribute values</dt>
  <dd>
    Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. E.g.:&nbsp;When the <strong>type</strong> attribute of an <code>&lt;input&gt;</code> element is set to <code>email</code> or <code>tel</code> ...</dd>
  <dt>
    Labeling attributes</dt>
  <dd>
    Use labels like {{ HTMLVersionInline(5) }} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.</dd>
</dl>
<h2 id="Force_ignore_of_wiki_markup">Force ignore of wiki markup</h2>
<p>If you need a particular piece of wiki markup to be ignored by the parser, simply use the "plain" CSS class, like this:</p>
<pre>
&lt;span class="plain"&gt;'''this wiki markup will not be interpreted'''&lt;/span&gt;
</pre>
<p><span class="nowiki">'''this wiki markup will not be interpreted'''</span></p>
<h2 id="Other_references" name="Other_references">Other references</h2>
<h3 id="MDC-specific" name="MDC-specific">MDC-specific</h3>
<ul>
  <li><a href="/Project:en/Custom_CSS_Classes" title="Project:en/Custom_CSS_Classes">Custom CSS classes</a> defined for all MDC pages.</li>
  <li><a href="/Project:en/Custom_Templates" title="Project:en/Custom_Templates">Custom templates</a> created for use on MDC, with explanations.</li>
  <li><a href="/Project:en/How_to_Help" title="Project:en/How_to_Help">MDC policies and guidelines</a>:
    <ul>
      <li>If you're not sure how to name your page, see <a href="/Project:en/Page_Naming_Guide" title="Project:en/Page_Naming_Guide">Page naming guide</a>.</li>
      <li><a href="/Project:en/Disambiguation" title="Project:en/Disambiguation">MDC:Disambiguation</a></li>
    </ul>
  </li>
</ul>
<h3 id="External" name="External">External</h3>
<ul>
  <li><a class="external" href="http://wiki.mindtouch.com/User_Manual" title="http://wiki.mindtouch.com/User_Manual">MindTouch Deki User Manual</a></li>
</ul>
<p>{{ languages( { "fr": "Project:fr/R\u00e9f\u00e9rence_des_balises_wiki", "pt": "Project:pt/Refer\u00eancia_de_marca\u00e7\u00e3o_wiki", "ja": "Project:ja/Wiki_Markup_Reference", "zh-cn": "Project:cn/Wiki\u6807\u8bb0\u8bed\u6cd5\u53c2\u8003", "pl": "Project:pl/Opis_sk\u0142adni_Wiki" } ) }}</p>
Revert to this revision