CSS Syntax, Parsing, and Error Recovery

Basic

CSS is parsed before it can style anything

A CSS source file is text, but the CSS processing model does not reason about arbitrary characters as if every character were already meaningful syntax. CSS Syntax defines tokenization and parsing rules that turn source text into CSS constructs.

Tokens are the language building blocks

CSS Syntax defines token types such as identifiers, functions, numbers, dimensions, percentages, strings, hashes, delimiters, comments, and whitespace. Other CSS specifications then define how sequences of these tokens form selectors, declarations, property values, and at-rules.

1

.notice { margin: 1rem; width: 50%; }

?

Whitespace and comments are not styling instructions

Whitespace and comments can separate or annotate source without becoming declarations themselves. Some whitespace is significant to how tokens are formed, while comments are removed during preprocessing. Do not assume that visual formatting in a stylesheet maps one-to-one to the parsed structure.

1
2
3
4

/* The comment is not a declaration. */
.card {
  color: black;
}

A missing semicolon is not the same as a missing rule

CSS is designed to keep parsing when it encounters many kinds of malformed input. Error handling is part of the language model: a browser can discard an invalid component while continuing to process later source. This forward-compatible behavior is one reason CSS can evolve without requiring every older parser to understand every future feature.

Grammar ownership is distributed across CSS

CSS Syntax provides the general parsing machinery and value-definition conventions. Selectors defines selector grammar. Individual modules define the grammar of the properties and at-rules they introduce. This prevents the Syntax lesson from becoming a catalog of every CSS feature.

Syntax errors versus unsupported features

A parser can understand the general shape of a construct without being able to apply a feature that a particular implementation does not support. Curriculum examples should therefore distinguish malformed CSS from a valid feature that is outside a target implementation or still developing in the specification.

?

Specification status matters

CSS Syntax Level 3 is a Candidate Recommendation Draft in the W3C publication history. That status is different from a Recommendation, and developing CSS modules may have different maturity levels. The curriculum records those distinctions instead of presenting every draft feature as settled CSS.

Normative source: W3C CSS Syntax Module Level 3.

Quick check

If you can explain the path from source text to tokens to parsed CSS constructs, and why malformed input can be discarded without stopping the entire stylesheet, you understand the shared parsing model. Property-specific grammars remain with their defining modules.