MDN contribution changelog

This document provides a record of MDN content processes, constructs, and best practices that have changed, and when they changed. It is useful to allow regular contributors to check in and see what has changed about the process of creating content for MDN.

Multiple updates to the CSS style guide to reflect the move towards Markdown, and encourage authors to write HTML in a Markdown-compatible way.

• Note and warning boxes no longer have a separate <h4> heading for the title (e.g. <h4>Warning</h4> ). Instead, the first paragraph begins with title text, as shown: <strong>Note:</strong> and <strong>Warning:</strong> . Note that a space character is required after the closing </strong> tag/before the content).

  See our Guide to classes and styles used in MDN content guide for further information and syntax guides.

• The seoSummary class should no longer be used.

• The standard-table class should no longer be used. The styling provided by this class is now applied to tables by default (see https://github.com/mdn/mdn-minimalist/issues/680).

• The <details> element should no longer be used.

• The hidden, example-good, and example-bad classes used to be primarily for code blocks but could be used on other elements. Now they can only be used on code blocks.

Previously, the syntax blocks of JavaScript builtin and WebAPI methods that can be used in multiple different ways (i.e. various parameters are optional) were commonly written using BNF formal syntax notation. Most notably, square brackets were used to signify optional parameters.

This was problematic — many developers were confused by this, and it conflicts with valid syntax forms in other programming languages (e.g. [] is also an array in JavaScript).

As a result, going forward we are now writing multiple syntax forms of a method on separate lines inside the syntax block. See Syntax sections > Multiple lines/Optional paramaters for further information and examples.

Interface mixins in Web IDL are used in specifications to define Web APIs. For web developers, they aren't observable directly; they act as helpers to avoid repeating API definitions.

Previously we commonly defined a landing page for a mixin class itself, and put the defined members on subpages underneath it, before linking to those from the landing pages of the interfaces that implement those mixins. This was confusing for readers because mixins are spec constructs — you never access the defined members using the mixin classes. To avoid this confusion we've instead put the pages for members defined on mixins directly under the implementing class pages. For more details, see the guide page on how to write an API reference and the discussion leading to this change at mdn/content#1940.

Previously on MDN, note and warning boxes would be wrapped by <div> elements with note and warning classes, respectively. More often than not, their first paragraphs would start with a <strong>-wrapped note or warning text.

In January this changed — the class attribute should now include an additional notecard class, and the strong text is instead included in a heading at the top of the block.

See our Guide to classes and styles used in MDN content guide for further information and syntax guides.