Commonly-used macros

This page lists many of the general-purpose macros created for use on MDN. For additional how-to information on using these macros, see Using macros.

See Other macros for information on macros that are infrequently used, are used only in special contexts, or are deprecated.

MDN provides a number of link macros for easing the creation of links to reference pages, glossary entries, and other topics.

Link macros are recommended over normal HTML links because they are succinct and translation-friendly. For example a glossary or reference link created using a macro does not need to be translated: in other locales it will automatically link to the correct version of the file.

The Glossary macro creates a link to a specified term's entry in the MDN glossary. This macro accepts one required parameter and one optional parameter:

1. The term's name (such as "HTML"): {{Glossary("HTML")}} yields HTML
2. Optional: The text to display in the article instead of the term name: {{Glossary("CSS", "Cascading Style Sheets")}} yields Cascading Style Sheets

There are macros for locale-independent linking to pages in specific reference areas of MDN: Javascript, CSS, HTML elements, SVG etc.

The macros are easy to use. Minimally all you need to do is specify the name of the item to link to in the first argument. Most macros will also take a second argument allowing you to change the display text (documentation can be found at the links in the left-most column below).

• Bugs
  • bug allows you to link to a bug on bugzilla.mozilla.org easily using this syntax: {{Bug(123456)}}. This gives you: bug 123456.
  • WebkitBug inserts a link to a bug in the WebKit bug database. For example, {{WebkitBug(31277)}} inserts WebKit bug 31277.

Previous, Next, and PreviousNext provide navigation controls for articles which are part of sequences. For the single-way templates, the only parameter needed is the wiki location of the previous or next article in the sequence. For PreviousNext, the two parameters needed are the wiki locations of the appropriate articles. The first parameter is for the previous article and the second is for the next article.

• EmbedLiveSample lets you embed the output of a code sample on a page, as described in Live samples.
• LiveSampleLink creates a link to a page containing the output of a code sample on a page, as described in Live samples.
• EmbedGHLiveSample allows to embed live samples from GitHub pages. You can get more information at GitHub live samples.

There are templates for almost every large collection of pages. They typically link back to the main page of the reference/guide/tutorial (this is often needed because our breadcrumbs sometimes can't do this) and put the article in the appropriate category.

• CSSRef generates the sidebar for CSS reference pages.
• HTMLRef generates the sidebar for HTML reference pages.
• APIRef generates the sidebar for Web API reference pages.

optional_inline and ReadOnlyInline are used in API documentation, usually when describing the list of properties of an object or parameters of a function.

Usage: {{Optional_Inline}} or {{ReadOnlyInline}}. Example:

isCustomObjectRead only

Indicates, if true, that the object is a custom one.

parameterXOptional

Blah blah blah...

Non-standard

non-standard_inline inserts an in-line mark indicating the API has not been standardized and is not on a standards track.

Syntax

{{Non-standard_Inline}}

Examples

• Icon:

Experimental

experimental_inline inserts an in-line mark indicating the API is not widely implemented and may change in the future.

Syntax

{{Experimental_Inline}}

Examples

• Icon:

Deprecated

deprecated_inline inserts an in-line deprecated mark () to discourage the use of an API that is officially deprecated (or has been removed).

Syntax

{{Deprecated_Inline}}

Examples

• Icon:

These templates have the same semantics as their inline counterparts described above. The templates should be placed directly underneath the main page title (or breadcrumb navigation if available) in the reference page. They can also be used to mark up a section on a page.

• non-standard_header: {{Non-standard_Header}}

  Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

• SeeCompatTable should be used on pages that document experimental features. Example: {{SeeCompatTable}}

  Experimental: This is an experimental technology
  Check the Browser compatibility table carefully before using this in production.

• deprecated_header: {{Deprecated_Header}}

  Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

• secureContext_header. Should be used on main pages like interface pages, API overview pages, and API entry points (e.g. navigator.xyz) but usually not on sub-pages like method and property pages. Example: {{SecureContext_Header}}

  Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The AvailableInWorkers macro inserts a localized note box indicating that a feature is available in a Web worker context. You can use the argument notservice to indicate that a feature works in web workers except for service workers.

Syntax

{{AvailableInWorkers}}
{{AvailableInWorkers("notservice")}}

Examples