There are a number of types of pages that are used repeatedly on MDN. This article describes these page types, their purpose, and gives examples of each and templates to use when creating a new page.
There are three broad categories of page types on MDN, though some page types fall into more than one category.
- Reference pages describe the details of something, and are organized according to the structure of the thing described.
- Guide pages describe how to do something or use something, and are organized based on the goals of the reader.
- Navigation pages exist primarily to provide links to other pages, usually about related topics.
To create new pages on MDN, you need to use GitHub — have a look at our content repo README for more instructions.
When creating a new page you can ensure that you've used the right page structure/contents by referring to one of our page templates — see the sections below. You can find the exact source code of each template (if you want to copy it) by following the "Source on GitHub" link at the bottom of each one. These page templates don't make much sense as published pages, but if you view their source code you'll see that they contain a lot of helpful comments, placeholders, and hints detailing how to fill in the missing information and create your page.
At the top of each template you'll find a section entitled Remove before publishing — this contains information on how to fill in the page title, slug, sidebar menu, and tags (e.g. information that doesn't actually appear in the body of the article). You need to delete this section after you've followed the instructions in it, before the page can be considered finished.
Sometimes you will come across old-style reference pages that look markedly different from the templates presented here. For example, old-style interface pages had all the interfaces' member details on a single page, and individual method/property/constructor/event listener pages didn't exist.
If you come across an old-style set of pages, we'd love for you to update them to the new style! However, we do appreciate that this could be a large amount of work. If the information to update is not too large, and you have some free time, by all means try updating it to the new style.
If the work is more significant, then you should consider a few factors when prioritizing the work:
- How out-of-date is the information?
- How low quality is the information?
- How popular is the feature? How sought after is the information?
We have defined a front matter key
page-type to clearly identify the type of MDN pages. The templates linked below indicate which
page-type values you should set for each page type.
For the complete list of page types see The page-type front matter key.
An API landing page provides an overview of what a particular API does, as well as links to the documentation for each of the interfaces, globals, functions, etc. offered by the API. It does not link directly to specific methods or properties within the API's classes, except in the context of the overview text. It is primarily a navigation page, but also functions as an at-a-glance reference page for the API.
There are some instances where multiple APIs exist that are distinct, and are defined in their own specifications, but they closely related and therefore would make sense to cover with a single API landing page. For example, the Generic Sensor API cover general sensor concerns, but more specific concerns are covered in other APIs such as Ambient Light Sensor, Motion Sensor, etc. In such cases, many of the high level concepts are the same, so it makes no sense to repeat those over multiple landing pages. In such a case, it would make more sense in terms of repetition and findability to cover them all under a single "Web sensors" landing page.
Note: Also known as an Interface landing page.
An API reference page lists all the methods, properties, events, and so forth that are members of a particular interface or class. It provides an overview of what the class or interface does or is used for, and gives links to the documentation for each of these members. It is more granular than an API landing page, which typically links to multiple API reference pages.
An API reference subpage is a child of an API reference page. It documents a single interface member in detail.
An HTML reference page lists all the attributes that are available on an HTML element, explains the element's purpose and usage, and provides examples, browser compatibility information, and other important data.
An SVG reference page lists all the attributes that are available on an SVG element, explains the element's purpose and usage, and provides examples, browser compatibility information, and other important data.
Every CSS module represents a CSS specification that provides support for certain features and implementations in CSS. For example, the CSS box model module represents the specification that describes the margin and padding properties that let you create spacing in and around a CSS box.
A CSS module landing page provides an overview of the features that the module provides and lists all the properties, data types, CSS functions, and so on offered by the module. When possible, the CSS module landing page provides a quick demonstration of what can be achieved using the properties of the module through an interactive example. The module landing page serves primarily as a navigation page, but also functions as an at-a-glance reference page for the module.
Some related properties and features that belong in other modules, but that are closely related to the functionality offered by the module you are documenting, can also be covered in a Related concepts section.
For example, the
<easing-function> data type and the
prefers-reduced-motion media query are not covered in the CSS animations module, but because they are closely related with CSS animations, it is a good idea to highlight them in the Related concepts section of the CSS animations module landing page.
A CSS reference page lists all the available syntax for a CSS feature such as a selector or property, and explains the feature's purpose and usage. It also provides examples, browser compatibility information, and other important data.
An HTTP header reference page lists all the available directives that an HTTP header can contain, and explains the header's purpose and usage. It also provides examples, browser compatibility information, and other important explanations.
A conceptual page is a guide page that explains or teaches something. Generally, if a page contains primarily prose, and doesn't fall into another page type, it's probably a conceptual page. An extended discussion of a topic might be spread across multiple conceptual pages, and linked using Next and Previous macros.
A glossary page contains a brief explanation of a term, topic, or concept. The first paragraph should be a simple, self-contained description of the term, no more than a couple sentences. This can be followed by links to further information in the See also section. If the page grows to more than a screenful or so, it's too long and should be converted to a conceptual page. See How to write and reference an entry in the glossary for more details.
A landing page serves as a menu, of sorts, for its subpages, and is therefore primarily a navigation page. A landing page layout is typically used for the root page of a tree of pages about a particular topic. It opens with a brief summary of the topic, then presents a structured list of links to its subpages, and optionally, additional material that be useful to the reader.
The list of subpages can be generated automatically using the templates
LandingPageListSubpages. However, in more complex cases, the list may need to be created (and maintained!) by hand.