Compatibility tables

We have standardized the appearance of compatibility tables for our open web documentation; that is, documentation of technologies such as the DOM, HTML, CSS, JavaScript, SVG, and so forth, that are shared across all browsers.

In order to make it as easy as possible to create and maintain these tables, we have a set of templates to use, as well as the following copy-and-paste ready pre-built table you should use for all new compatibility tables.

Compatibility table etiquette

In a perfect world, any time someone updates a compatibility table, they'd research every browser and update new tables or rows in tables with the correct and latest information about every browser in the table. In reality, that's a lot to ask of many volunteer contributors and MDN contributors from other browser organizations (hi there and welcome, by the way!). If you're not able to add correct details for every browser, that's okay—but we do ask that you follow a couple of guidelines that will help make sure that information is added by later contributors.

• When you need to list multiple versions of a browser in a cell (for instance, the version in which something landed behind a preference, then the version in which it was enabled by default, please put them in oldest-version-first order, for consistency.
• Please don't simply paste {{CompatNo}} or {{CompatVersionUnknown}} for any browser for which you can't provide correct information. If you don't know the answer, please just put {{CompatUnknown}}. This puts a clear indicator into that browser's column that says that someone should find out the answer and add it. If you put any other value, it could get overlooked, resulting in developers being misinformed.
• Please don't just leave cells empty. This, too, is confusing, as it can look like you may be in the middle of updating the page. It leaves the table in an ambiguous state in which the entire table may be considered unreliable.

Compatibility table template

You should copy and paste all the following content into your article (first switching into the editor before copying), starting with the use of the {{CompatibilityTable}} template and including both of the following tables. The first table contains compatibility information for the desktop versions of browsers, and the second table contains compatibility information for the mobile versions. This should get you all the content, including the required <div> blocks.

Browser compatibility

Using the table

You should fill out the table with appropriate information for each browser, as known. Each cell should generally contain just the version numbers in which support was added or removed (or in which a prefix was removed), with an optional superscript in the form "[number]", with the corresponding note listed in numeric order below the table. Feel free to include in the notes links to appropriate additional documentation if needed or appropriate, and be sure to use the templates provided to help keep the look and feel of the version information consistent.

The important thing is to use the {{CompatibilityTable}} template and then have two <div> blocks, one with the ID "compat-desktop" and one with the ID "compat-mobile", each containing an appropriate table in the format shown above. The tables should use the class "compat-table" to achieve the correct style.

Templates to use in the compatibility table

In order to help standardize appearance, and let us more easily change the look and feel of the tables over time, we have a number of templates you should use in the table cells:

Template:CompatNo

Use {{CompatNo}} to indicate that the browser does not support the feature at all or only supports it when toggling a preference.

Template:CompatUnknown

Use {{CompatUnknown}} to indicate that the browser's support for the feature is not known. Hopefully someone who does know will come along and fill this in for you later!

Template:CompatVersionUnknown

Use {{CompatVersionUnknown}} to indicate that the browser has support for the feature but the earliest version of support is not known. Hopefully someone who does know will come along and fill this in for you later!

Template:CompatNightly

Use {{CompatNightly(browser)}} to indicate that the browser has support for the feature but only in nightly builds. Specify a keyword indicating which browser you're referring to, and the template will insert a link to nightlies for that browser if such nightlies exist.

• firefox / firefoxmobile
• chrome / chromemobile
• ie / iemobile
• opera / operamobile
• safari / safarimobile

Nightly links are currently automatically inserted for Firefox, Firefox mobile, Chrome, and Safari. Using CompatNightly for Opera currently provides a link to snapshot.opera.com, which doesn't necessarily offer nightlies but offers developmental snapshots.

Template:CompatGeckoDesktop

Use {{CompatGeckoDesktop(geckoversion)}} to indicate compatibility was introduced in the specified Gecko version on desktop Firefox; we have this special template for Gecko so we can let the template map Gecko versions to Firefox releases, given that they don't always correlate in obvious ways (and the relationship can change over time during development).

Template:CompatGeckoMobile

Use {{CompatGeckoMobile(geckoversion)}} to indicate compatibility was introduced in the specified Gecko version on mobile Firefox; we have this special template for Gecko so we can let the template map Gecko versions to Firefox releases, given that they don't always correlate in obvious ways (and the relationship can change over time during development).

Template:CompatChrome

Use {{CompatChrome(chromeversion)}} to indicate compatibility was introduced in the specified Chrome version.

For experimental features

Some features are prefixed with a vendor-specific name (such as -moz- or -webkit-) or are disabled by default when implemented before the specification is finalized. In order to call attention to the compatibility table in these cases, you should use {{SeeCompatTable}} at the top of the page. This generates a box explaining this situation, with a link to the compatibility table. The output looks like this:

This is an experimental technology
Because this technology's specification has not stabilized, check the compatibility table for usage in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future versions of browsers as the specification changes.

Add the version info and append the {{property_prefix(prefix)}} macro for prefixed features. For experimental features, which are disabled by default and can be enabled via a preference, add the {{CompatNo}} macro and a footnote below the table explaining how to enable the feature and mentioning the version that introduced the feature.

All templates are tagged with CompatTemplate.

Webkit specific tags

WebKitBug inserts a link to a bug in the WebKit bug database. This makes it easy for writers to add annotations to documentation to guide developers to information about things that are works in progress in WebKit. You use it like this: {{webkitbug(42)}}, and the result is “WebKit bug 42″, linked to the corresponding bug in the bug database.

See MDN for WebKit Writers for more details.

Adding a browser to the tables

We're in the process of building a new compatibility database system which will be seeded with information from these compatibility tables. The new system will automatically generate appropriate tables as needed. Unless you have information to share that's really important (such as to cover a major new browser), you should probably not bother to change existing compatibility tables. Note also that at present, if you want to add a column to the tables as displayed, you have to manually update each affected page's compatibility tables; this too will change with the new system. No launch date is decided upon yet; see the compatibility database project plan for details and status.

If you do decide to add the column, please insert it in alphabetical order.