CSSWG Spec Markup

This page will eventually document the CSSWG's spec markup and serve as a manual. Currently it is serving as a scratchspace.

The style sheet that implements most of our special markup has a master on dev.w3.org.

The CSS specs use lists in a variety of ways:

• as logically belonging to a paragraph (sometimes as a continuation of the last sentence in the previous paragraph, which may or may not continue in the next paragraph). (example)
• as a paragraph-level structure (example). This is the most common.
• as a higher-level structure that contains paragraphs. (example, example)

Definition lists in particular have several uses

• They are used to define CSS values. (example) These should be marked up with <dt>, <dfn>, and <code>, but are often missing one or the other.
• They are used for defining other terms, e.g. in a glossary. (example, example) These should use <dfn> also.
• They may be used in some other random applications for which the structure is appropriate ( need to track down examples).

Paragraph, heading, and list margins and spacing should be designed in a way that appropriately handles these structures.

CSS specs use a variety of inline markup:

<code class=property>

for CSS property names

<code class=css>

for abitrary CSS snippets and CSS values

<dfn>

for the defining instance of a term, whether in a <dl> or in a paragraph. Must be easily scannable

<i>

for instance-of-term; this auto-links to the defining instance, if there is one in the spec. These are used very very frequently in some cases (example, example) so their styling should not be distracting.

<a>

for other kinds of cross-linking

<em> and <strong>

used per HTML5 (but are fairly uncommon); default styling should be fine

<var>

for variables in mathematical or syntactical formulas

Specs use tables for data. In some cases, we have some very complex table structures, which should be styled appropriately. Writing modes and Text have some good examples: (simple table, super-complex table, common-complexity table, another example)

We also use tables for indices, like the full property index and the selectors overview.

The CSSWG uses some colored boxes to delineate special types of information.

<div class=“example”>

Examples are non-normative and relatively self-contained. They often, but not always, illustrate a normative definition immediately before the example. They might contain only text; text and code; text and a figure; text, some code, and a figure; or several repetitions of these. They need to be clearly delineated so that readers can tell that the text is non-normative. They are also things authors like to scan for.

<div class=“figure”>

Like examples, figures are also used to illustrate the normative text (and in some cases are used in informative sections like examples and notes, too!) They usually come with a caption and must have alternative text for non-sighted readers. (examples inside examples, Writing Modes is full of examples)

<table class=“propdef”>

Propdef tables contain the critical information for a property definition. They must be easily scannable. (example, consecutive-boxes example)

<span class=“note”>, <p class=“note”>, <div class=“note”>

Notes are non-normative sentences (inline) or paragraphs (or multi-paragraphs) that help explain the implications of some normative text. It needs to be clear that they are not normative, but they also should not jump out of the text, as they are not something to scan for but a continuation of the normative discussion. example

<pre class=“prod”>

These <pre> boxes are typically normative; they unambiguously define the syntax of a feature in code. They often contain a <dfn> defining a grammar production that is reused later. (example, example)

<span class=“issue”>, <p class=“issue”>, <div class=“issue”>

Issues are notes from the editor to reviewers. They document areas that need more feedback, and explain problems that are as-yet unresolved in the specs. They are used in Working Drafts: CRs and beyond are not supposed to have issues.