CSS構文モジュール レベル3

1. はじめに

この節は規範的ではありません。

このモジュールは、CSSスタイルシートおよびCSS構文を利用するその他のもの （例えばHTMLのstyle属性）の抽象構文と構文解析を定義します。

Unicodeのコードポイント（つまりテキスト）のストリームを、 CSSトークンのストリームへ変換するアルゴリズム、 さらにCSSオブジェクト（スタイルシート、規則、宣言など）へと変換するアルゴリズムを定義します。

1.1. モジュール間の関係

このモジュールはCSSスタイルシートの構文とパース処理を定義します。 CSS 2.1で定義されていた字句解析と文法を置き換えます。

2. CSSの構文の説明

この節は規範的ではありません。

CSS文書は一連のスタイル規則—文書内の要素にスタイルを適用する修飾規則—と、at-ルール—CSS文書に対して特別な処理規則や値を定義するもの—から構成されます。

修飾規則は、まず前置部があり、 その後に波括弧で囲まれた宣言のシーケンスが続きます。 前置部の意味は、その規則が現れる文脈によって異なります。 スタイル規則の場合は、 宣言が適用される要素を指定するセレクターです。 各宣言は名前、 コロン、宣言値の順に記述します。 宣言はセミコロンで区切られます。

p > a {
  color: blue;
  text-decoration: underline;
}

at-ルールはそれぞれ異なる構造を持ちますが、基本的な構造は共通しています。 まず「@」コードポイントで始まり、その後CSSキーワードとして名前が続きます。 一部のat-ルールは単純な文で、 名前の後にCSS値が続き、その動作を指定し、 最後にセミコロンで終わります。 他のものはブロックとなり、 名前の後にCSS値が続くこともありますが、 最後は波括弧で囲まれたブロックで終わります。 これは修飾規則と似ています。 これらのブロックの内容も、各at-ルールごとに固有です。 場合によっては宣言のシーケンスが含まれることもあれば、 追加のブロックやat-ルール、その他の構造が含まれることもあります。

@import "my-styles.css";

@page :left {
  margin-left: 4cm;
  margin-right: 3cm;
}

@media print {
  body { font-size: 10pt }
}

プロパティ名やat-ルール名は常に identシーケンスであり、 ident-startコードポイント、2つのハイフン、 またはハイフン＋ident-startコードポイントで始まり、 その後、0個以上のidentコードポイントが続きます。 CSS構文で用いられるものも含め、 任意のコードポイントを エスケープすることで含めることができます。

セレクターの構文はSelectors仕様で定義されています。 同様に、さまざまなCSS値の構文はValues & Units仕様で定義されています。 個別のat-ルールの特殊な構文は、それぞれの仕様で確認できます。

2.1. エスケープ処理

この節は規範的ではありません。

任意のUnicodeコードポイントは、identシーケンスや引用符付き文字列にエスケープして含めることができます。 CSSのエスケープシーケンスはバックスラッシュ（\）で始まり、以下が続きます：

• コードポイントで、16進数字や改行でないもの。 エスケープシーケンスはそのコードポイントに置き換えられます。
• あるいは1〜6桁の16進数字の後に、 オプションの空白文字が続くもの。 エスケープシーケンスは、その16進数字が示すUnicodeコードポイントに置き換えられます。 このオプションの空白文字は、16進エスケープシーケンスの後に「本物の」16進数字を続けるためのものです。

  値が「&B」のidentシーケンスは、\26 Bや\000026Bのように記述できます。

  エスケープシーケンスの直後の「本物の」スペースは2重にする必要があります。

2.2. エラー処理

この節は規範的ではありません。

CSSでエラーが発生した場合、 パーサはできるだけ少ない内容だけを破棄し、 通常どおりパースを続行できるようにします。 これは、エラーが必ずしもミスとは限らず—新しい構文は古いパーサにはエラーに見えるため、 言語に新しい構文を追加しても古いUAでスタイルシートが完全に壊れることを心配せずにすむようにするためです。

厳密なエラー回復動作はパーサ自体で詳述されていますが、 簡単な説明でも十分に正確です。

• スタイルシートの「トップレベル」では、 <at-keyword-token>はat-ルールの開始を示します。 その他は修飾規則の開始となり、 その前置部に含まれます。 これにより無効なセレクターとなる場合もありますが、CSSパーサの問題ではなく、最悪の場合セレクターが何も一致しないだけです。
• at-ルールが始まると、 パーサの観点からは無効なものはありません。 すべてat-ルールの前置部の一部となります。 <semicolon-token>に遭遇すると、at-ルールは即座に終了し、 開き波括弧<{-token>に遭遇すると、at-ルールの本体が始まります。 at-ルールは先に進み、ブロック（(), {}, []で囲まれた内容）をマッチさせ、 マッチされない、または他のブロック内にない閉じ波括弧<}-token>に遭遇すると終了します。 at-ルールの内容は、そのat-ルール独自の文法に従って解釈されます。
• 修飾規則も同様ですが、 セミコロンでは終了せず、 規則の前置部の一部として取り込まれます。 最初の{}ブロックが見つかると、 その内容は常に宣言リストとして解釈されます。
• 宣言リストを解釈している時、 どこかで未知の構文が現れると、現在構築中の宣言を破棄し、 セミコロン（またはブロックの終わり）まで先送りして、 そこから再び宣言のパースを試みます。
• スタイルシートが終了する時、規則・宣言・関数・文字列などが開いたままでも、 すべて自動的に閉じられます。 ただし、これによって無効になるわけではなく、 不完全なため文法照合時に破棄される可能性があります。

各構成要素（宣言、スタイル規則、at-ルール）がパースされた後、 ユーザーエージェントは期待される文法と照合します。 一致しない場合は無効となり、 UAによって無視され、 まったく存在しなかったものとして扱われます。

3. CSSのトークン化とパース

ユーザーエージェントは、本仕様で記載されたパース規則を用いて text/cssリソースから[CSSOM]ツリーを生成しなければなりません。 これらの規則を合わせて、CSSパーサと呼ばれます。

本仕様は、CSS文書のパース規則を定義します。 文書が構文的に正しい場合も、そうでない場合も対象です。 パースアルゴリズムの特定のポイントはパースエラーとされます。 パースエラーの処理方法は明確に定義されています。 このような問題が発生した場合、ユーザーエージェントは以下に記載された方法で動作するか、 そうしたくない場合は、最初に遭遇したエラーで処理を中止しなければなりません。

適合性チェッカーは、文書内に1つ以上のパースエラー条件が存在する場合、 少なくとも1つ以上のパースエラー条件をユーザーに報告しなければなりません。 また、パースエラー条件が存在しない場合は報告してはなりません。 複数のパースエラー条件が存在する場合は、複数報告しても構いません。 適合性チェッカーはパースエラーから復帰する必要はありませんが、 復帰する場合はユーザーエージェントと同じ方法で復帰しなければなりません。

3.1. パースモデルの概要

CSSパース処理への入力は、Unicodeコードポイントのストリームであり、 トークン化段階を経てツリー構築段階に渡されます。 出力はCSSStyleSheetオブジェクトです。

注: スクリプトをサポートしない実装は、 実際にCSSOM CSSStyleSheetオブジェクトを生成する必要はありませんが、 その場合でもCSSOMツリーは以降の仕様のモデルとして利用されます。

3.2. 入力バイトストリーム

スタイルシートをパースする場合、 トークン化段階への入力となるUnicodeコードポイントのストリームは、 ユーザーエージェントによって最初はバイトストリームとして認識されることがあります （通常はネットワーク経由やローカルファイルシステムから）。 その場合、ユーザーエージェントはこれらのバイトを 特定の文字エンコーディングに従ってコードポイントへ復号しなければなりません。

@charset "utf-8";

バイトからデコードされるCSSスタイルシートを参照する文書言語は、 そのスタイルシートごとに環境エンコーディングを定義でき、 他のエンコーディングヒントが使えない場合にフォールバックとして利用されます。

環境エンコーディングという概念は、レガシーコンテンツとの互換性のためだけに存在します。 新しいフォーマットや新しいリンク手段は、環境エンコーディングを提供すべきではありません。 そのため、より明示的な情報がなければスタイルシートはUTF-8がデフォルトになります。

注: [HTML]は <link rel=stylesheet> の環境エンコーディングを定義しています。

注: [CSSOM]は <xml-stylesheet?> の環境エンコーディングを定義しています。

注: [CSS-CASCADE-3]は @import の環境エンコーディングを定義しています。

3.3. 入力ストリームの前処理

入力ストリームは、 バイトストリームのデコード時にプッシュされたフィルタ済みコードポイントで構成されます。

4. トークン化

トークン化するには、コードポイントのストリームinputから トークンを消費し、 <EOF-token>に到達するまで繰り返し、 それぞれのトークンをストリームにプッシュする。

注: トークン消費アルゴリズムは1トークンずつ返すため、 必要に応じてパース中にコードポイントのストリームを 「オンデマンド」でトークン化することもできます。

トークン化の出力は、以下のいずれかのトークンのストリームです: <ident-token>, <function-token>, <at-keyword-token>, <hash-token>, <string-token>, <bad-string-token>, <url-token>, <bad-url-token>, <delim-token>, <number-token>, <percentage-token>, <dimension-token>, <whitespace-token>, <CDO-token>, <CDC-token>, <colon-token>, <semicolon-token>, <comma-token>, <[-token>, <]-token>, <(-token>, <)-token>, <{-token>, <}-token>。

• <ident-token>, <function-token>, <at-keyword-token>, <hash-token>, <string-token>, <url-token>は、0個以上のコードポイントで構成された値を持ちます。 また、hashトークンは"type"フラグが"id"または"unrestricted"のいずれかに設定されます。typeフラグは明示的に設定されない場合"unrestricted"になります。
• <delim-token>は、1つのコードポイントで構成された値を持ちます。
• <number-token>, <percentage-token>, <dimension-token>は数値値を持ちます。<number-token>および<dimension-token>は"type"フラグが"integer"または"number"に設定され、typeフラグは明示的に設定されない場合"integer"になります。<dimension-token>はさらに、1つ以上のコードポイントで構成された単位も持ちます。

注: hashトークンのtypeフラグはSelectors構文[SELECT]で使用されます。 "id"型のhashトークンのみIDセレクターとして有効です。

4.1. トークン レールロード図

この節は規範的ではありません。

この節では、トークナイザーの説明をレールロード図の形で示します。 レールロード図は明示的なパーサよりもコンパクトであり、 正規表現よりも読みやすいことが多いです。

これらの図は参考情報であり、完全ではありません。 「正しい」トークンの文法を説明しますが、エラー処理については全く説明していません。 各トークンの構文を直感的に理解しやすくするためだけに提供しています。

<foo-token>のような名前の図はトークンを表します。 それ以外は他の図から参照される生成規則です。

comment

newline

whitespace

hex digit

escape

<whitespace-token>

ws*

<ident-token>

<function-token>

<at-keyword-token>

<hash-token>

<string-token>

<url-token>

<number-token>

<dimension-token>

<percentage-token>

<CDO-token>

<CDC-token>

4.2. 定義

このセクションでは、トークン化フェーズで使用されるいくつかの用語を定義します。

next input code point

まだ消費されていないコードポイントのうち、入力ストリームの先頭のもの。

current input code point

直前に消費されたコードポイント。

reconsume the current input code point

current input code pointを入力ストリームの先頭に戻す。 次回next input code pointを消費する指示が出た際に、現在のコードポイントを再消費することになる。

EOF code point

入力ストリームの末尾を表す概念上のコードポイント。 入力ストリームが空のときは、next input code pointは常にEOFコードポイントとなる。

digit

U+0030 DIGIT ZERO (0) から U+0039 DIGIT NINE (9) までのコードポイント。

hex digit

digit、またはU+0041 LATIN CAPITAL LETTER A (A) から U+0046 LATIN CAPITAL LETTER F (F) までのコードポイント、またはU+0061 LATIN SMALL LETTER A (a) からU+0066 LATIN SMALL LETTER F (f) までのコードポイント。

uppercase letter

U+0041 LATIN CAPITAL LETTER A (A) から U+005A LATIN CAPITAL LETTER Z (Z) までのコードポイント。

lowercase letter

U+0061 LATIN SMALL LETTER A (a) から U+007A LATIN SMALL LETTER Z (z) までのコードポイント。

letter

uppercase letterまたはlowercase letter。

non-ASCII code point

値がU+0080 <control>以上のコードポイント。

ident-start code point

letter、 non-ASCII code point、 またはU+005F LOW LINE (_)。

ident code point

ident-start code point、 digit、 またはU+002D HYPHEN-MINUS (-)。

non-printable code point

U+0000 NULL から U+0008 BACKSPACE までのコードポイント、 またはU+000B LINE TABULATION、 またはU+000E SHIFT OUT から U+001F INFORMATION SEPARATOR ONE までのコードポイント、 またはU+007F DELETE。

newline

U+000A LINE FEED。 U+000D CARRIAGE RETURNおよびU+000C FORM FEEDはこの定義に含まれません。前処理の際にU+000A LINE FEEDへ変換されるためです。

whitespace

newline、U+0009 CHARACTER TABULATION、またはU+0020 SPACE。

maximum allowed code point

Unicodeで定義されている最大のコードポイント：U+10FFFF。

ident sequence

コードポイントの並びで、<ident-token>と同じ構文を持つもの。

注: <at-keyword-token>の「@」以降の部分、 <hash-token>（typeフラグが"id"の場合）の「#」以降の部分、 <function-token>の「(」より前の部分、 <dimension-token>の単位はすべてident sequenceです。

representation

トークンのrepresentationは、 入力ストリームから consume a tokenアルゴリズムによって消費された部分列。 これは、入力テキストの細かな違いに依存するいくつかのアルゴリズムで保持され、 トークンの単純な「再シリアライズ」では失われる可能性のある情報を守るためのもの。

representationは内部アルゴリズムのみで消費され、直接公開されることはないため、 正確なテキストを保持する必要はなく、 例えばトークンにソーステキストのオフセットを関連付けるなどの方法でも十分です。

注: 特にrepresentationは、 .009が.009として書かれていたか9e-3か、 文字がリテラルで書かれていたかCSSエスケープかなどの違いも保持します。 前者は<urange>生成規則のパースに必要であり、 後者はトークン化抽象化の偶発的なリークですが、実装の定義を容易にするため許容されています。

トークンが本仕様のトークン化アルゴリズム以外から直接生成された場合は、 そのrepresentationは空文字列となります。

4.3. トークナイザー アルゴリズム

このセクションで定義されるアルゴリズムは、コードポイントのストリームをトークンのストリームへ変換します。

4.3.1. トークンの消費

このセクションでは、consume a tokenをコードポイントのストリームから消費する方法を説明します。 任意の型のトークンを1つ返します。

コメントを消費します。

next input code pointを消費します。

whitespace

可能な限り多くのwhitespaceを消費し、 <whitespace-token>を返します。

U+0022 QUOTATION MARK (")

文字列トークンを消費して返します。

U+0023 NUMBER SIGN (#)

next input code pointがident code pointか、次の2コードポイントが有効なエスケープなら:

1. <hash-token>を作成。
2. 次の3コードポイントがident sequenceを開始するなら、 <hash-token>のtypeフラグを"id"に設定。
3. ident sequenceを消費し、 <hash-token>の値に返された文字列を設定。
4. <hash-token>を返す。

それ以外の場合は、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+0027 APOSTROPHE (')

文字列トークンを消費して返します。

U+0028 LEFT PARENTHESIS (()

<(-token>を返します。

U+0029 RIGHT PARENTHESIS ())

<)-token>を返します。

U+002B PLUS SIGN (+)

入力ストリームが数値で始まるなら、current input code pointを再消費し、 数値トークンを消費して返す。

それ以外の場合は、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+002C COMMA (,)

<comma-token>を返します。

U+002D HYPHEN-MINUS (-)

入力ストリームが数値で始まるなら、current input code pointを再消費し、 数値トークンを消費して返す。

それ以外の場合、 次の2コードポイントが U+002D HYPHEN-MINUS U+003E GREATER-THAN SIGN (->)なら、これらを消費し <CDC-token>を返します。

それ以外の場合、 入力ストリームがident sequenceで始まるなら、 current input code pointを再消費し、 ident-likeトークンを消費して返す。

それ以外の場合、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+002E FULL STOP (.)

入力ストリームが数値で始まるなら、current input code pointを再消費し、 数値トークンを消費して返す。

それ以外の場合、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+003A COLON (:)

<colon-token>を返します。

U+003B SEMICOLON (;)

<semicolon-token>を返します。

U+003C LESS-THAN SIGN (<)

次の3コードポイントが U+0021 EXCLAMATION MARK U+002D HYPHEN-MINUS U+002D HYPHEN-MINUS (!--)なら、これらを消費し <CDO-token>を返します。

それ以外の場合、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+0040 COMMERCIAL AT (@)

次の3コードポイントがident sequenceを開始するなら、 ident sequenceを消費し、 <at-keyword-token>を作成し、その値に返された値を設定して返す。

それ以外の場合、 <delim-token>を返し、その値にcurrent input code pointを設定。

U+005B LEFT SQUARE BRACKET ([)

<[-token>を返します。

U+005C REVERSE SOLIDUS (\)

入力ストリームが有効なエスケープで始まるなら、 current input code pointを再消費し、 ident-likeトークンを消費して返す。

それ以外の場合、これはパースエラーです。 <delim-token>を返し、その値にcurrent input code pointを設定。

U+005D RIGHT SQUARE BRACKET (])

<]-token>を返します。

U+007B LEFT CURLY BRACKET ({)

<{-token>を返します。

U+007D RIGHT CURLY BRACKET (})

<}-token>を返します。

digit

current input code pointを再消費し、 数値トークンを消費して返す。

ident-start code point

current input code pointを再消費し、 ident-likeトークンを消費して返す。

EOF

<EOF-token>を返します。

その他

<delim-token>を返し、その値にcurrent input code pointを設定。

4.3.2. コメントの消費

このセクションでは、consume commentsをコードポイントのストリームから消費する方法を説明します。 何も返しません。

次の2コードポイントが U+002F SOLIDUS (/)の後にU+002A ASTERISK (*)の場合、 それらと、最初に出現するU+002A ASTERISK (*)の後にU+002F SOLIDUS (/)が続くまで（またはEOFコードポイントまで）をすべて消費します。 このステップの先頭に戻ります。

前段落がEOFコードポイントの消費で終了した場合、 これはパースエラーです。

何も返しません。

4.3.3. 数値トークンの消費

このセクションでは、consume a numeric tokenをコードポイントのストリームから消費する方法を説明します。 <number-token>、<percentage-token>、または<dimension-token>を返します。

数値を消費し、その結果をnumberとします。

次の3コードポイントがident sequenceを開始する場合：

1. numberと同じ値とtypeフラグで、単位は空文字列の<dimension-token>を作成します。
2. ident sequenceを消費します。 <dimension-token>の単位に返された値を設定します。
3. <dimension-token>を返します。

それ以外の場合、次のコードポイントがU+0025 PERCENTAGE SIGN (%)の場合、 それを消費します。 numberと同じ値で<percentage-token>を作成して返します。

それ以外の場合、 numberと同じ値・typeフラグで<number-token>を作成して返します。

4.3.4. 識別子風トークンの消費

このセクションでは、consume an ident-like tokenをコードポイントのストリームから消費する方法を説明します。 <ident-token>、<function-token>、<url-token>、または<bad-url-token>を返します。

ident sequenceを消費し、その結果をstringとします。

stringの値がASCII大文字小文字無視で"url"と一致し、 次のコードポイントがU+0028 LEFT PARENTHESIS (()の場合、 それを消費します。 次の2コードポイントがwhitespaceである間、 次のコードポイントを消費します。 次の1または2コードポイントがU+0022 QUOTATION MARK (")、 U+0027 APOSTROPHE (')、 またはwhitespace＋U+0022 QUOTATION MARK (")/U+0027 APOSTROPHE (')の場合、 stringを値とする<function-token>を作成して返します。 それ以外の場合、urlトークンを消費して返します。

それ以外の場合、次のコードポイントがU+0028 LEFT PARENTHESIS (()の場合、 それを消費します。 stringを値とする<function-token>を作成して返します。

それ以外の場合、 stringを値とする<ident-token>を作成して返します。

4.3.5. 文字列トークンの消費

このセクションでは、consume a string tokenをコードポイントのストリームから消費する方法を説明します。 <string-token>または<bad-string-token>を返します。

このアルゴリズムはending code pointを引数で受け取る場合があり、 それは文字列を終了するコードポイントです。 ending code pointが指定されない場合は、 current input code pointが使われます。

最初に値を空文字列とした<string-token>を作成します。

ストリームから次のコードポイントを繰り返し消費します：

ending code point

<string-token>を返します。

EOF

これはパースエラーです。 <string-token>を返します。

newline

これはパースエラーです。current input code pointを再消費し、 <bad-string-token>を作成して返します。

U+005C REVERSE SOLIDUS (\)

次のコードポイントがEOFの場合は何もしません。

それ以外の場合、 次のコードポイントが改行の場合はそれを消費します。

それ以外の場合、(ストリームが有効なエスケープで開始) エスケープされたコードポイントを消費し、返されたコードポイントを<string-token>の値に追加します。

その他

current input code pointを<string-token>の値に追加します。

4.3.6. URLトークンの消費

このセクションでは、consume a url tokenをコードポイントのストリームから消費する方法を説明します。 <url-token>または<bad-url-token>を返します。

注: このアルゴリズムは、最初の「url(」がすでに消費されていることを前提としています。 また、url(foo)のような「引用符なし値」を消費する際に呼ばれることも前提です。 url("foo")のような引用符付き値は<function-token>としてパースされます。consume an ident-like tokenがこの区別を自動で行うため、 それ以外の場合にこのアルゴリズムを直接呼び出すべきではありません。

1. 最初に値を空文字列とする<url-token>を作成します。
2. 可能な限り多くのwhitespaceを消費します。
3. ストリームから次のコードポイントを繰り返し消費します：

   U+0029 RIGHT PARENTHESIS ())

   <url-token>を返します。

   EOF

   これはパースエラーです。 <url-token>を返します。

   whitespace

   可能な限り多くのwhitespaceを消費します。 次のコードポイントがU+0029 RIGHT PARENTHESIS ())またはEOFの場合、 それを消費して<url-token>を返します（EOFの場合はパースエラーです）； それ以外の場合、不正なURLの残骸を消費し、 <bad-url-token>を作成して返します。

   U+0022 QUOTATION MARK (")

   U+0027 APOSTROPHE (')

   U+0028 LEFT PARENTHESIS (()

   non-printable code point

   これはパースエラーです。不正なURLの残骸を消費し、 <bad-url-token>を作成して返します。

   U+005C REVERSE SOLIDUS (\)

   ストリームが有効なエスケープで始まるなら、 エスケープされたコードポイントを消費し、返されたコードポイントを<url-token>の値に追加します。

   それ以外の場合、これはパースエラーです。不正なURLの残骸を消費し、 <bad-url-token>を作成して返します。

   その他

   current input code pointを<url-token>の値に追加します。

4.3.7. エスケープされたコードポイントの消費

このセクションでは、consume an escaped code pointの方法を説明します。 U+005C REVERSE SOLIDUS (\)はすでに消費済みであり、 次のコードポイントが有効なエスケープであることも検証済みであることを前提とします。 コードポイントを返します。

次のコードポイントを消費します。

hex digit

可能な限り多くのhex digit（最大5個）を消費する。 合計で1~6桁のhex digitが消費されることになります。 次のコードポイントがwhitespaceなら、それも消費します。 hex digitを16進数として解釈します。 この値が0の場合、surrogateの場合、最大許可コードポイントより大きい場合は、 U+FFFD 置換文字（�）を返します。 それ以外の場合は、その値のコードポイントを返します。

EOF

これはパースエラーです。 U+FFFD 置換文字（�）を返します。

その他

current input code pointを返します。

4.3.8. 2コードポイントが有効なエスケープか判定

このセクションでは、2コードポイントが有効なエスケープか判定の方法を説明します。 このアルゴリズムは、2つのコードポイントを明示的に渡すか、 入力ストリームそのものに対して呼ぶことができます。 後者の場合、対象となる2つのコードポイントは current input code pointと next input code pointの順です。

注: このアルゴリズムは追加のコードポイントは消費しません。

最初のコードポイントがU+005C REVERSE SOLIDUS (\)でない場合はfalseを返します。

それ以外の場合、2つ目のコードポイントがnewlineならfalseを返します。

それ以外の場合はtrueを返します。

4.3.9. 3コードポイントがident sequenceを開始するか判定

このセクションでは、3コードポイントがident sequenceを開始するか判定の方法を説明します。 このアルゴリズムは3つのコードポイントを明示的に渡すか、 入力ストリームそのものに対して呼ぶことができます。 後者の場合、対象となる3つのコードポイントは current input code pointと 次の2コードポイントの順です。

注: このアルゴリズムは追加のコードポイントは消費しません。

最初のコードポイントを見ます：

U+002D HYPHEN-MINUS

2つ目のコードポイントがident-start code pointまたはU+002D HYPHEN-MINUSの場合、 または2つ目と3つ目のコードポイントが有効なエスケープの場合、trueを返します。 それ以外はfalseを返します。

ident-start code point

trueを返します。

U+005C REVERSE SOLIDUS (\)

最初と2つ目のコードポイントが有効なエスケープの場合、trueを返します。 それ以外はfalseを返します。

その他

falseを返します。

4.3.10. 3コードポイントが数値を開始するか判定

このセクションでは、3コードポイントが数値を開始するか判定の方法を説明します。 このアルゴリズムは、3つのコードポイントを明示的に渡すか、 入力ストリームそのものに対して呼ぶことができます。 後者の場合、対象となる3つのコードポイントは current input code pointと 次の2コードポイントの順です。

注: このアルゴリズムは追加のコードポイントは消費しません。

最初のコードポイントを見ます：

U+002B PLUS SIGN (+)

U+002D HYPHEN-MINUS (-)

2つ目のコードポイントがdigitの場合はtrueを返します。

それ以外の場合、 2つ目のコードポイントがU+002E FULL STOP (.)で、 3つ目のコードポイントがdigitの場合はtrueを返します。

それ以外の場合はfalseを返します。

U+002E FULL STOP (.)

2つ目のコードポイントがdigitの場合はtrueを返します。 それ以外はfalseを返します。

digit

trueを返します。

その他

falseを返します。

4.3.11. ident sequenceの消費

このセクションでは、consume an ident sequence をコードポイントのストリームから消費する方法を説明します。 これは、ストリーム内の最初から隣接するコードポイントで形成可能な最大の名前を含む文字列を返します。

注: このアルゴリズムは、返されるコードポイントが<ident-token>となることを保証するために必要な最初の数個のコードポイントの検証は行いません。 その用途であれば、このアルゴリズム呼び出し前にストリームがident sequenceで始まることを確認してください。

resultを最初は空文字列とします。

ストリームからnext input code pointを繰り返し消費します：

ident code point

コードポイントをresultに追加します。

ストリームが有効なエスケープで始まる

エスケープされたコードポイントを消費し、 返されたコードポイントをresultに追加します。

その他

current input code pointを再消費し、 resultを返します。

4.3.12. 数値の消費

このセクションでは、consume a numberをコードポイントのストリームから消費する方法を説明します。 数値valueと、"integer"または"number"のいずれかであるtypeを返します。

注: このアルゴリズムは、ストリームから数値を得られることを保証するために必要な最初の数個のコードポイントの検証は行いません。 呼び出し前にストリームが数値で始まることを確認してください。

以下のステップを順に実行します：

1. 最初にtypeを"integer"とし、 reprを空文字列とします。
2. next input code pointがU+002B PLUS SIGN (+)またはU+002D HYPHEN-MINUS (-)なら、 それを消費してreprに追加します。
3. next input code pointがdigitである間、 それを消費してreprに追加します。
4. 次の2コードポイントが U+002E FULL STOP (.)の後にdigitの場合：
   1. それらを消費します。
   2. reprに追加します。
   3. typeを"number"に設定します。
   4. next input code pointがdigitである間、それを消費してreprに追加します。
5. 次の2〜3コードポイントが U+0045 LATIN CAPITAL LETTER E (E)またはU+0065 LATIN SMALL LETTER E (e)、 （オプションで）U+002D HYPHEN-MINUS (-)またはU+002B PLUS SIGN (+)、 その後digitの場合：
   1. それらを消費します。
   2. reprに追加します。
   3. typeを"number"に設定します。
   4. next input code pointがdigitである間、それを消費してreprに追加します。
6. reprを数値に変換し、 valueに設定します。
7. valueとtypeを返します。

4.3.13. 文字列を数値に変換

このセクションでは、convert a string to a numberの方法を説明します。 数値を返します。

注: このアルゴリズムは、文字列が数値のみを含むことの検証はしません。 呼び出し前に、文字列が有効なCSS数値のみを含むことを確認してください。

文字列を左から順に7つの要素に分割します：

1. 符号： U+002B PLUS SIGN (+)またはU+002D HYPHEN-MINUS (-)のいずれか1文字、または空文字列。 符号がU+002D HYPHEN-MINUS (-)の場合はsを-1、それ以外はsを1とする。
2. 整数部分： 0個以上のdigit。 1つ以上digitがあれば、その数値を10進整数として解釈しiとする。なければiは0。
3. 小数点： U+002E FULL STOP (.)の1文字、または空文字列。
4. 小数部分： 0個以上のdigit。 1つ以上digitがあれば、その数値を10進整数として解釈しfとし、桁数をdとする。なければfとdは0。
5. 指数指示子： U+0045 LATIN CAPITAL LETTER E (E)またはU+0065 LATIN SMALL LETTER E (e)の1文字、または空文字列。
6. 指数符号： U+002B PLUS SIGN (+)またはU+002D HYPHEN-MINUS (-)の1文字、または空文字列。 符号がU+002D HYPHEN-MINUS (-)の場合はtを-1、それ以外はtを1とする。
7. 指数： 0個以上のdigit。 1つ以上digitがあれば、その数値を10進整数として解釈しeとする。なければeは0。

数値 s·(i + f·10-d)·10te を返します。

4.3.14. 不正なURLの残骸を消費

このセクションでは、不正なURLの残骸を消費をコードポイントのストリームから行う方法を説明します。 これは、トークナイザーが<bad-url-token>の途中であることに気づいた場合に「後始末」を行うものです。 何も返しません。 目的は、入力ストリームを十分に消費して回復ポイントに到達し、通常のトークン化を再開できるようにすることです。

ストリームからnext input code pointを繰り返し消費します：

U+0029 RIGHT PARENTHESIS ())

EOF

return。

ストリームが有効なエスケープで始まる

エスケープされたコードポイントを消費。これにより、エスケープされた右括弧（"\)"）が現れても<bad-url-token>が終了しないようになります。 それ以外は「その他」と同じです。

その他

何もしません。

5. パース

パース段階への入力は、トークン化段階からのトークンのストリームまたはリストです。 出力はパーサーの呼び出し方法（このセクション後半の入口点で定義）によって異なります。 パーサーの出力はat-ルール、修飾規則、宣言のいずれかまたは複数となります。

パーサーの出力はCSSの基本的な構文に従って構築され、個別項目の妥当性は考慮しません。 実装は各パーサーアルゴリズムから返された項目の妥当性をチェックし、妥当性がない場合は何も返さないものとして扱ってもよいし、 仕様通りに完全なツリーを構築してから、後処理で妥当性のない項目を除去しても構いません。

ツリーに現れる可能性がある項目は以下です：

at-ルール

at-ルールは名前、 コンポーネント値のリストからなる前置部、 オプションで{}ブロックからなるブロックを持ちます。

注: 本仕様はat-ルールのブロック内容に制限を設けません。 個々のat-ルールが、ブロックを受け入れるかどうか、受け入れる場合のパース方法（できれば本仕様で定義されたパーサーアルゴリズムや入口点を使う）を定義する必要があります。

修飾規則

修飾規則は コンポーネント値のリストからなる前置部と、 {}ブロックからなるブロックを持ちます。

注: ほとんどの修飾規則はスタイル規則となり、 前置部がセレクター[SELECT]、 ブロックが宣言リストとなります。

宣言

概念的には、宣言はプロパティまたは記述子名と値を関連付ける特定のインスタンスです。 構文的には、宣言は名前、コンポーネント値のリストからなる値、最初は未設定のimportantフラグを持ちます。

宣言はさらに、プロパティ宣言または記述子宣言に分類されます。 前者はCSSプロパティを設定し、主に修飾規則内で現れます。 後者はCSS記述子を設定し、at-ルール内にのみ現れます。 （この分類はSyntaxレベルでは行われません。宣言の出現場所によって仕様ごとに定義されます。）

コンポーネント値

コンポーネント値は保存トークン、 関数、 または単純ブロックのいずれかです。

保存トークン

トークナイザーが生成したすべてのトークン（ただし<function-token>、<{-token>、<(-token>、 <[-token>は除く）。

注: 上記の非保存トークンは常により高次のオブジェクト（関数または単純ブロック）に消費されるため、 パーサ出力自体には現れません。

注: <}-token>、<)-token>、<]-token>、<bad-string-token>、<bad-url-token>は常にパースエラーですが、 本仕様ではMedia Queriesなど他の仕様が宣言やブロック全体を破棄せず、より細かなエラー処理を定義できるように、 トークンストリームに保持されます。

関数

関数は名前と、コンポーネント値のリストからなる値を持ちます。

単純ブロック

{}-ブロック

[]-ブロック

()-ブロック

単純ブロックは、関連付けられたトークン（<[-token>、<(-token>、<{-token>のいずれか）と、 コンポーネント値のリストからなる値を持ちます。

{}-ブロック、[]-ブロック、()-ブロックは その該当する関連トークンを持つ単純ブロックを指します。

5.1. パーサ レールロード図

このセクションは規範的ではありません。

このセクションでは、パーサの説明をレールロード図の形で示します。

これらの図は参考情報であり、完全ではありません。 「正しい」スタイルシートの文法を説明しますが、エラー処理については全く説明していません。 構文を直感的に理解しやすくするためだけに提供しています。

Stylesheet

Rule list

At-rule

Qualified rule

Declaration list

Declaration

!important

Component value

{} block

() block

[] block

Function block

5.2. 定義

current input token

トークナイザーによって生成されたトークンリストから、現在操作対象となっているトークンまたはコンポーネント値。

next input token

トークナイザーによって生成されたトークンリストにおいて、current input tokenの次に位置するトークンまたはコンポーネント値。 current input tokenの次にトークンがない場合、next input tokenは<EOF-token>となる。

<EOF-token>

トークンリストの終端を表す概念上のトークン。 トークンリストが空の場合、next input tokenは常に<EOF-token>となる。

consume the next input token

current input tokenを現在のnext input tokenに更新し、next input tokenも適切に調整する。

reconsume the current input token

次回アルゴリズムがconsume the next input tokenを指示した際は、何もしない（current input tokenを変更せず維持する）。

5.3. パーサーの入口点

このセクションで定義されるアルゴリズムは、CSSトークンのリストから高レベルのCSSオブジェクトを生成します。

注: 他の仕様は独自の入口点を目的に合わせて定義可能です。

5.3.1. CSS文法に従って何かをパースする

文字列やトークンリストがCSS文法に一致するか試し、一致した場合はその文法に従って構造化したい、といったケースがしばしばあります。 このセクションはそのような操作のための汎用フックです。 "parse foo as a CSS <color>"のように呼び出します。

このアルゴリズムは、一致しなかった場合はfailureを返し、一致した場合は文法に従ってパースした結果（文法仕様に対応する未定義の構造）を返します。 返り値は仕様の本文からのみ操作する必要があり、表現の曖昧さは問題になりません。 もし仕様外に公開したい場合は、利用側の仕様が明確な表現に変換する必要があります（例えばCSSシリアライズアルゴリズムを呼ぶなど（"serialize as a CSS <string> value"のように）。

注: このアルゴリズムとCSS文法に従ってカンマ区切りリストをパースは、通常他の仕様が呼び出す唯一のパースアルゴリズムです。 他のパースアルゴリズムは主に[CSSOM]や「CSS構造を明示的に構築する」ケース向けです。 他のアルゴリズムを使う必要がある場合は、まずCSSWGに相談してください。

5.3.2. CSS文法に従ってカンマ区切りリストをパース

値をCSS文法に従ってパースする場合、文法中にカンマがあっても値のどこかがパース失敗すると全体がパース失敗となり、failureを返します。

それが望ましい場合もあります（リスト値のCSSプロパティなど）し、逆に、カンマ区切りの各部分ごとに別々にパースでき、成功した部分だけ扱いたい場合（失敗部分は無視するなど、例えば<img sizes>など）もあります。

このアルゴリズムは、まさにそのためのフックです。 「トップレベル」のカンマで分割した値リストを返し、各値はパース失敗ならfailure、成功ならパース結果（parseアルゴリズム同様未定義の構造）となります。

5.3.3. スタイルシートをパースする

5.3.4. 規則リストをパースする

5.3.5. 規則をパースする

5.3.6. 宣言をパースする

注: "宣言リストをパースする"とは異なり、こちらは宣言のみ（at-ルールはパースしない）です。

5.3.7. スタイルブロックの内容をパースする

注: このアルゴリズムはスタイル規則の内容をパースします。 ネストされたスタイル規則やその他のat-ルールを許可する必要があります。 スタイル規則のネストが不要な場合（例：@pageや@keyframesの子規則など）は、 宣言リストをパースするを使ってください。

5.3.8. 宣言リストをパースする

注: 名前とは異なり、このアルゴリズムは宣言とat-ルールが混合したリストをパースします。 CSS 2.1が@pageで行うようにです。 想定外のat-ルール（その文脈では全ての場合もあり得ます）は無効とされ、利用者によって無視されます。

注: このアルゴリズムはネストされたスタイル規則には対応しません。 その必要がある場合はスタイルブロックの内容をパースするを使ってください。

5.3.9. コンポーネント値をパースする

5.3.10. コンポーネント値リストをパースする

5.3.11. コンポーネント値のカンマ区切りリストをパースする

5.4. パーサーアルゴリズム

以下のアルゴリズムがパーサーを構成します。 これらは上記のパーサー入口点から呼び出されます。

これらのアルゴリズムはトークンリストまたはコンポーネント値リストのいずれかで呼び出される場合があります。 （違いは、コンポーネント値リストでは一部トークンが関数や単純ブロックに置き換えられていることです。） トークン化段階で入力ストリームが空の時EOFコードポイントを返したように、 この段階のリストでも次のトークンリクエスト時に空なら<EOF-token>を返さなければなりません。

特定のリストでアルゴリズムを呼び出した場合はそのリストのみ消費し（リストが尽きたら<EOF-token>を返し続けます）、そうでなければ呼び出し元と同じリストで暗黙的に呼び出されます。

5.4.1. 規則リストを消費

規則リストを消費には top-level flagを受け取る：

最初は空の規則リストを作成する。

next input tokenを繰り返し消費する：

<whitespace-token>

何もしない。

<EOF-token>

規則リストを返す。

<CDO-token>

<CDC-token>

top-level flagがセットされていれば何もしない。

そうでなければ、current input tokenを再消費し、修飾規則を消費する。 返り値があれば規則リストに追加。

<at-keyword-token>

current input tokenを再消費し、at-ルールを消費し、返り値を規則リストに追加。

その他

current input tokenを再消費し、修飾規則を消費する。 返り値があれば規則リストに追加。

5.4.2. at-ルールを消費

at-ルールを消費するには：

next input tokenを消費する。 新しいat-ルールを作成し、 名前をcurrent input tokenの値に設定し、 前置部は空のリスト、 値は最初は何も設定しない。

next input tokenを繰り返し消費する：

<semicolon-token>

at-ルールを返す。

<EOF-token>

これはパースエラー。at-ルールを返す。

<{-token>

単純ブロックを消費し、at-ルールのブロックに設定する。 at-ルールを返す。

単純ブロック（関連トークンが<{-token>の場合）

ブロックをat-ルールのブロックに設定し、at-ルールを返す。

その他

current input tokenを再消費し、コンポーネント値を消費する。 返り値をat-ルールの前置部に追加。

5.4.3. 修飾規則を消費

修飾規則を消費するには：

新しい修飾規則を作成し、 前置部は空のリスト、 値は最初は何も設定しない。

next input tokenを繰り返し消費する：

<EOF-token>

これはパースエラー。何も返さない。

<{-token>

単純ブロックを消費し、修飾規則のブロックに設定する。 修飾規則を返す。

単純ブロック（関連トークンが<{-token>の場合）

ブロックを修飾規則のブロックに設定し、修飾規則を返す。

その他

current input tokenを再消費し、コンポーネント値を消費する。 返り値を修飾規則の前置部に追加。

5.4.4. スタイルブロックの内容を消費

スタイルブロックの内容を消費するには：

最初は空の宣言リストdeclsと空の規則リストrulesを作成する。

next input tokenを繰り返し消費する：

<whitespace-token>

<semicolon-token>

何もしない。

<EOF-token>

declsをrulesで拡張し、declsを返す。

<at-keyword-token>

current input tokenを再消費し、at-ルールを消費し、結果をrulesに追加。

<ident-token>

一時リストを作成し、current input tokenで初期化する。 next input tokenが<semicolon-token>または<EOF-token>以外の間、 コンポーネント値を消費し、一時リストに追加する。宣言を消費で一時リストから消費する。 何か返されたらdeclsに追加。

<delim-token>（値が"&" (U+0026 AMPERSAND)の場合）

current input tokenを再消費し、修飾規則を消費する。 何か返されたらrulesに追加。

その他

これはパースエラー。current input tokenを再消費し、 next input tokenが<semicolon-token>または<EOF-token>以外の間、 コンポーネント値を消費して値を破棄。

5.4.5. 宣言リストを消費

宣言リストを消費するには：

最初は空の宣言リストを作成する。

next input tokenを繰り返し消費する：

<whitespace-token>

<semicolon-token>

何もしない。

<EOF-token>

宣言リストを返す。

<at-keyword-token>

current input tokenを再消費し、at-ルールを消費し、結果を宣言リストに追加。

<ident-token>

一時リストを作成し、current input tokenで初期化する。 next input tokenが<semicolon-token>または<EOF-token>以外の間、 コンポーネント値を消費し、一時リストに追加する。宣言を消費で一時リストから消費する。 何か返されたら宣言リストに追加。

その他

これはパースエラー。current input tokenを再消費し、 next input tokenが<semicolon-token>または<EOF-token>以外の間、 コンポーネント値を消費して値を破棄。

5.4.6. 宣言を消費

注: このアルゴリズムはnext input tokenが<ident-token>であることを事前にチェック済みであると仮定します。

宣言を消費するには：

next input tokenを消費する。 新しい宣言を作成し、 名前をcurrent input tokenの値に設定し、 値は最初は空のリストとする。

1. next input tokenが<whitespace-token>の間は、consume the next input tokenで消費する。
2. next input tokenが<colon-token>以外なら、 これはパースエラー。何も返さない。

   それ以外の場合はnext input tokenを消費する。

3. next input tokenが<whitespace-token>の間は、consume the next input tokenで消費する。
4. next input tokenが<EOF-token>以外の間、 コンポーネント値を消費し、宣言の値に追加する。
5. 宣言の値の最後の2つの<whitespace-token>以外のトークンが <delim-token>（値が"!"）と <ident-token>（値がASCII大文字小文字無視で"important"と一致）の場合は、 それらを宣言の値から削除し、宣言のimportantフラグをtrueにする。
6. 宣言の値の最後のトークンが<whitespace-token>の間は、 そのトークンを削除する。
7. 宣言を返す。

5.4.7. コンポーネント値を消費する

コンポーネント値を消費するには:

次の入力トークンを消費する。

現在の入力トークンが <{-token>、<[-token>、または <(-token>の場合、単純ブロックを消費するし、それを返す。

それ以外の場合、現在の入力トークンが <function-token>の場合、関数を消費するし、それを返す。

それ以外の場合、現在の入力トークンを返す。

5.4.8. 単純ブロックを消費する

注: このアルゴリズムは、現在の入力トークンがすでに <{-token>、<[-token>、または <(-token>であることを確認済みと仮定する。

単純ブロックを消費するには:

終了トークンは、現在の入力トークンのミラー変種である。 （例: <[-token>で呼び出された場合、終了トークンは <]-token>となる。）

単純ブロックを生成し、その関連トークンを現在の入力トークンに設定し、値を最初は空のリストに設定する。

次の入力トークンを繰り返し消費し、以下のように処理する:

終了トークン

ブロックを返す。

<EOF-token>

これは構文解析エラーである。ブロックを返す。

その他

現在の入力トークンを再消費する。コンポーネント値を消費するし、その値をブロックの値に追加する。

注: CSSには、宣言を含むことができるブロックと、修飾規則を含むことができるブロックの間で不幸な構文的曖昧さがあるため、ルールを扱う "消費" アルゴリズムは最初により汎用的なこのアルゴリズムを使用し、より具体的な宣言リストを消費するやルールリストを消費するアルゴリズムは、文法が適用されるときに呼び出される。 より具体的なアルゴリズムは、<declaration-list>または<rule-list>/<stylesheet>を含むかどうかによって適用される。

5.4.9. 関数を消費する

注: このアルゴリズムは、現在の入力トークンがすでに <function-token>であることを確認済みと仮定する。

関数を消費するには:

関数を生成し、その名前を現在の入力トークンの値とし、値を最初は空のリストに設定する。

次の入力トークンを繰り返し消費し、以下のように処理する:

<)-token>

関数を返す。

<EOF-token>

これは構文解析エラーである。関数を返す。

その他

現在の入力トークンを再消費する。コンポーネント値を消費するし、返された値を関数の値に追加する。

6. An+Bマイクロ構文

CSSにおいて、 :nth-child()擬似クラスなど、 リスト内のインデックスを示す必要がある場面がいくつかある。 An+Bマイクロ構文はこれに役立ち、 著者がリスト内の単一要素や一定間隔ごとのすべての要素を簡単に指定できる。

An+B記法は整数ステップ(A)とオフセット(B)を定義し、 nが0以上のすべての正の整数値について、 リスト内のAn+B番目の要素を表す。 リストの最初の要素はインデックス1（0ではない）を持つ。

AとBの値が0より大きい場合、 リストをA個ずつのグループに分割し （最後のグループが余りを取る）、 各グループのB番目の要素を選択する。

An+B記法は、evenおよびoddキーワードも受け入れ、 これらはそれぞれ2nと2n+1と同じ意味となる。

2n+0   /* リスト内の偶数要素すべてを表す */

even   /* 同じ */

4n+1   /* リスト内の1番目、5番目、9番目、13番目などを表す */

AとBの値は負も可能だが、 n ≥ 0の場合のAn+Bの正の結果のみが使用される。

-1n+6   /* リストの最初の6要素を表す */

-4n+10  /* リストの2番目、6番目、10番目の要素を表す */

両方のAとBが0の場合、 疑似クラスはリストのいずれの要素も表さない。

6.1. 非公式構文説明

このセクションは規範的ではありません。

Aが0のとき、An部分は省略できる （B部分がすでに省略されていない限り）。 Anが含まれず、Bが非負の場合、 +記号は（許可される場合）Bの前から省略可能。 この場合、構文は単にBのみとなる。

0n+5   /* リストの5番目の要素を表す */

5      /* 同じ */

Aが1または-1のとき、 規則の1は省略できる。

1n+0   /* リスト内のすべての要素を表す */

n+0    /* 同じ */

n      /* 同じ */

Bが0の場合、すべてのA番目の要素が選択される。 この場合、+B（または-B）部分は A部分がすでに省略されていない限り省略可能。

2n+0   /* リスト内のすべての偶数要素を表す */

2n     /* 同じ */

Bが負の場合、そのマイナス記号は+記号を置き換える。

3n-6

3n + -6

両方のAnとBが存在する場合、+または-の両側に空白を入れてもよい。

3n + 1

+3n - 2

-n+ 6

+6

3 n

+ 2n

+ 2

6.2. <an+b>型

An+B記法はもともとCSSとは少し異なるトークナイザーで定義されており、 CSSトークンで表現するとやや奇妙な定義となっていた。 このセクションでは、CSSトークンの観点からAn+B記法を認識する方法 （CSS文法用の<an+b>型の定義）と、 CSSトークンをどのように解釈してAとBの値を取得するかを説明する。

<an+b>型は、 （値定義構文（Values & Units仕様）を使用） 以下のように定義される：

<an+b> =
  odd | even |
  <integer> |

  <n-dimension> |
  '+'?† n |
  -n |

  <ndashdigit-dimension> |
  '+'?† <ndashdigit-ident> |
  <dashndashdigit-ident> |

  <n-dimension> <signed-integer> |
  '+'?† n <signed-integer> |
  -n <signed-integer> |

  <ndash-dimension> <signless-integer> |
  '+'?† n- <signless-integer> |
  -n- <signless-integer> |

  <n-dimension> ['+' | '-'] <signless-integer>
  '+'?† n ['+' | '-'] <signless-integer> |
  -n ['+' | '-'] <signless-integer>

ここで：

• <n-dimension>は<dimension-token>で、typeフラグが "integer" かつ単位がASCII大文字・小文字を区別しない"n"と一致
• <ndash-dimension>は<dimension-token>で、typeフラグが "integer" かつ単位がASCII大文字・小文字を区別しない"n-"と一致
• <ndashdigit-dimension>は<dimension-token>で、typeフラグが "integer" かつ単位がASCII大文字・小文字を区別しない"n-*"と一致し、"*"は1つ以上の数字
• <ndashdigit-ident>は<ident-token>で、値がASCII大文字・小文字を区別しない"n-*"と一致し、"*"は1つ以上の数字
• <dashndashdigit-ident>は<ident-token>で、値がASCII大文字・小文字を区別しない"-n-*"と一致し、"*"は1つ以上の数字
• <integer>は<number-token>で、typeフラグが "integer"
• <signed-integer>は<number-token>で、typeフラグが "integer" かつ表現が"+"または"-"で始まる
• <signless-integer>は<number-token>で、typeフラグが "integer" かつ表現が数字で始まる

^†: 識別子が"n"で始まる場合、前にプラス記号(+)がある場合は、2つのトークンの間に空白があってはならない。 そうでなければ、トークンは上記の文法に一致しない。 他の2つのトークンの間では空白は有効（無視される）。

生成規則の各節は以下のように解釈される：

odd

Aは2、Bは1。

even

Aは2、Bは0。

<integer>

Aは0、Bは整数の値。

<n-dimension>

'+'? n

-n

Aは次元の値、1、または-1。Bは0。

<ndashdigit-dimension>

'+'? <ndashdigit-ident>

Aは次元の値または1。Bは次元の単位または識別子の値（先頭のコードポイントを削除し、残りを10進数として解釈）。Bは負。

<dashndashdigit-ident>

Aは-1。Bは識別子の値（先頭2つのコードポイントを削除し、残りを10進数として解釈）。Bは負。

<n-dimension> <signed-integer>

'+'? n <signed-integer>

-n <signed-integer>

Aは次元の値、1、または-1。Bは整数の値。

<ndash-dimension> <signless-integer>

'+'? n- <signless-integer>

-n- <signless-integer>

Aは次元の値、1、または-1。Bは整数値の負。

<n-dimension> ['+' | '-'] <signless-integer>

'+'? n ['+' | '-'] <signless-integer>

-n ['+' | '-'] <signless-integer>

Aは次元の値、1、または-1。Bは整数の値。 '-'が間にある場合、Bは整数値の負となる。

7. Unicode-Rangeマイクロ構文

いくつかの構造体、例えばunicode-range記述子（@font-face規則用）などは、1つ以上のユニコードコードポイントを記述する方法が必要です。 <urange> 生成規則は1つ以上のユニコードコードポイントの範囲を表します。

非公式には、<urange>生成規則には3つの形式があります：

U+0001

単一のコードポイントからなる範囲を定義します（この場合「1」）。

U+0001-00ff

最初の値から2番目の値まで（両端を含む）のコードポイント範囲を定義します（この場合「1」から「ff」（10進255）まで）。

U+00??

「?」文字がすべての16進数字を表し、範囲を定義します（この場合U+0000-00ffと同じ）。

どの形式でも、各16進数値に最大6桁まで使用できます（「?」を16進数字として扱った場合）。

7.1. <urange>型

<urange>記法は元々CSSのプリミティブトークンとして定義されていましたが、使用頻度は非常に低く、 妥当な<ident-token>（識別子）と紛らわしい衝突を起こすことがあります。 このセクションでは、既存のCSSトークンで<urange>記法を認識する方法と、 それをユニコードコードポイントの範囲として解釈する方法を説明します。

注: ここで記述されている構文は意図的に非常に低レベルで、実装者向けです。 著者は代わりに前セクションの非公式構文説明を読むべきです。そこに<urange>を使うための必要情報がすべてあり、実際に読みやすいです。

<urange>型は （Values & Units仕様の値定義構文を用いて） 以下のように定義されます：

<urange> =
  u '+' <ident-token> '?'* |
  u <dimension-token> '?'* |
  u <number-token> '?'* |
  u <number-token> <dimension-token> |
  u <number-token> <number-token> |
  u '+' '?'+

この生成規則では、いずれのトークンの間にも空白は入れられません。

<urange>生成規則は、連続するユニコードコードポイントの範囲（start valueとend valueの非負整数）を表します。 上記の生成規則を範囲として解釈するには、次の手順を順に実行します：

1. 最初のuトークンを飛ばし、生成規則内のすべてのトークンの表現を連結します。これをtextとします。

2. textの最初の文字がU+002B PLUS SIGNなら消費します。そうでなければ、この<urange>は無効であり、このアルゴリズムは終了します。

3. textからできるだけ多くの16進数字を消費し、その後できるだけ多くのU+003F QUESTION MARK (?)コードポイントを消費します。 0個または6個を超えるコードポイントが消費された場合、この<urange>は無効であり、このアルゴリズムは終了します。

   もしQUESTION MARK (?)コードポイントが消費された場合：

   1. textに未消費のコードポイントが残っていたら、この<urange>は無効であり、アルゴリズムは終了します。

   2. 消費したコードポイントを16進数として解釈し、QUESTION MARK (?)はU+0030 DIGIT ZERO (0)コードポイントに置き換えます。これがstart valueです。

   3. 消費したコードポイントを再び16進数として解釈し、QUESTION MARK (?)はU+0046 LATIN CAPITAL LETTER F (F)コードポイントに置き換えます。これがend valueです。

   4. このアルゴリズムを終了します。

   それ以外の場合、消費したコードポイントを16進数として解釈します。これがstart valueです。

4. textに未消費のコードポイントが残っていなければ、end valueはstart valueと同じでアルゴリズムを終了します。

5. textの次のコードポイントがU+002D HYPHEN-MINUS (-)なら消費します。そうでなければ、この<urange>は無効であり、アルゴリズムは終了します。

6. textからできるだけ多くの16進数字を消費します。

   0個または6個を超える16進数字が消費された場合、 またtextに未消費のコードポイントが残っていた場合、この<urange>は無効であり、アルゴリズムは終了します。

7. 消費したコードポイントを16進数として解釈します。これがend valueです。

<urange>が表すコードポイントを決定するには：

1. end valueが最大許可コードポイントを超えていれば、 <urange>は無効かつ構文エラーです。

2. start valueがend valueより大きければ、 <urange>は無効かつ構文エラーです。

3. それ以外の場合、<urange>はstart valueからend valueまで（両端含む）の連続したコードポイントの範囲を表します。

注: <urange>の構文は意図的にかなり広めに設計されています。 パターンは非公式構文が生成可能なすべてのトークン列を網羅します。 ただし、構成トークン間に空白を許さないため、実際の利用では安全性が高いです。 <urange>の後ろに<number>や<dimension>（著者が<urange>を''u <number>''句で指定する場合など）を続けても、 著者がコメントで区切らない限り曖昧さは生じません。 そのため、著者が紛らわしいものを書くことは可能ですが、実際にそのような書き方をすること自体稀であり、混乱を招くものです。

8. 規則やその他の値の文法定義

Values仕様はプロパティの文法定義方法を規定しています。 このセクションは規則について同様の規定を行います。

プロパティ文法と同様に、 <foo>という記法は「foo」文法項目を指し、他の場所で定義されているものとします。 <foo>をその定義で置き換えても、文法的意味は同じです。

いくつかのトークン種別はリテラルで、クォート無しで記述されます：

• <ident-token>（例：autoやdiscなど）は値そのまま記述します。
• <at-keyword-token>は@記号＋値（例：@media）で記述。
• <function-token>は関数名＋括弧（例：translate(）で記述。
• <colon-token>（:）、<comma-token>（,）、<semicolon-token>（;）、<(-token>、<)-token>、<{-token>、<}-token>。

トークンは、その値が文法で定義された値と一致すればマッチします。 特に指定がない限り、すべての一致はASCII大文字・小文字を区別しない方法です。

注: エスケープを使えば、 <ident-token>の値の末尾を(や先頭を@にすることもできますが、 そのようなトークンは<function-token>や<at-keyword-token>とは見なされず、対応する文法定義にも一致しません。

<delim-token>は値をシングルクォートで囲みます。 例：<delim-token>が「+」コードポイントを含む場合、'+'と記述します。 同様に、<[-token>や<]-token>もシングルクォートで囲む必要があります。なぜなら文法構文自体で句のグループ化に使用されるからです。 <whitespace-token>は文法上は示されません。 <whitespace-token>は、 プローズ定義で明示的に指定しない限り、任意の2つのトークンの前後・間に許可されます。 （例えば、規則の前置部がセレクタの場合、空白は重要です。）

関数やブロックを定義する場合、 終了トークンは文法で指定する必要がありますが、 トークンストリームに存在しなくても一致します。

translateX( <translation-value> )

.foo { transform: translate(50px

8.1. ブロック内容の定義： <declaration-list>, <rule-list>, <stylesheet>生成規則

CSSパーサは、@規則末尾のブロックなど、ブロックの内容には中立的です。 トークンでブロックの汎用文法を定義するのは容易ではありませんが、専用かつ明確な解析アルゴリズムが定義されています。

<style-block>生成規則はスタイル規則のブロック内容を表します。 文法上ブロック内の唯一の値としてのみ使え、 ブロック内容はスタイルブロック内容を消費するアルゴリズムで解析する必要があります。

<declaration-list>生成規則は宣言リストを表します。 文法上ブロック内の唯一の値としてのみ使え、 内容は宣言リストを消費するアルゴリズムで解析します。

同様に、<rule-list>生成規則は規則リストを表し、 文法上ブロック内の唯一の値としてのみ使えます。 内容は規則リストを消費するアルゴリズムで解析します。

最後に、<stylesheet>生成規則は規則リストを表します。 <rule-list>と同じですが、 これを使うブロックはデフォルトで他の文脈に限定されないすべての規則を受け入れます。

@font-face { <declaration-list> }

@keyframes <keyframes-name> { <rule-list> }

<style-block>や<declaration-list>を使う規則については、 規則の仕様で、ブロック内で有効なプロパティ・記述子・@規則を定義する必要があります。 これは「@foo規則は本仕様・本セクションで定義されたプロパティ／記述子を受け入れる」と記述するだけでもよく、 拡張仕様では「@foo規則はさらに以下のプロパティ／記述子を受け入れる」と記述しても良いです。 ブロック内で定義されていない宣言や@規則は規則値から除去されます。

<style-block>や<declaration-list>内では、記述子での!importantは自動的に無効です。 規則がプロパティを受け入れる場合は、仕様でそのプロパティがカスケードに関与するか、どの特異性を持つかを定義する必要があります。 カスケードと関与しない場合、!important付きプロパティは自動的に無効ですが、 そうでなければ!importantは有効で、 important宣言としてカスケードに扱われます。 詳細は[CSS-CASCADE-3]参照。

<rule-list>を使う規則については、 仕様でブロック内で有効な規則種別を定義する必要があり、 <declaration-list>と同様に、未認識規則は値から除去されます。

<keyframe-rule> = <keyframe-selector> { <declaration-list> }

<stylesheet>を使う規則については、 すべての規則がデフォルトで許可されますが、 仕様でそのブロック内で無効な規則種別を定義することもできます。

@media <media-query-list> { <stylesheet> }

8.2. 任意の内容の定義： <declaration-value> および <any-value> 生成規則

一部の文法では、 あらゆる妥当な入力を文法で受け入れて、 内容に対するより具体的なエラー処理を手動で行うことが有用です （文法不一致で単に構造を無効化するのではなく）。

例えば、カスタムプロパティは、任意の妥当な値を許可します。 これは他のCSSプロパティの断片を任意に含めることができるためであり、 既存CSSの一部でないものにも使用できます。 また、Media Queriesの<general-enclosed>生成規則では、 将来の構文でMQが許可する範囲を定義し、 「未知」の値を扱うための特別なロジックを使用しています。

これを補助するため、2つの追加生成規則が定義されています：

<declaration-value>生成規則は、任意の1個以上のトークンの並びにマッチします。 ただし、その並びに<bad-string-token>、<bad-url-token>、 対応しない<)-token>、<]-token>、<}-token>、 またはトップレベルの<semicolon-token>トークンや値が"!"である<delim-token>トークンが含まれていない場合に限ります。 これは有効な宣言が値として持つことができる全てを表します。

<any-value> 生成規則は<declaration-value>と同じですが、 トップレベルの<semicolon-token>トークンおよび値が"!"である<delim-token>トークンも許可されます。 これはあらゆる文脈で有効なCSSが持ち得る全てを表します。

9. CSSスタイルシート

CSSスタイルシートを構文解析するには、 まずスタイルシートを構文解析する。 得られた全てのトップレベル修飾規則を、以下で定義するスタイル規則として解釈する。

いずれかのスタイル規則が無効、 または任意の@規則が認識されない、あるいは文法や文脈に従って無効である場合、 それは構文解析エラーである。 その規則を破棄する。

9.1. スタイル規則

スタイル規則は、 修飾規則であり、 セレクタリストとプロパティ宣言リスト、 そして場合によっては入れ子規則リストを関連付けます。 rule set（[CSS2]）とも呼ばれます。 CSSカスケードと継承は[CSS-CASCADE-3]で、 スタイル規則内の宣言がカスケードにどう関与するかを定義しています。

修飾規則の前置部はCSS文法に従って構文解析され、 <selector-list>となります。 これが失敗した場合、スタイル規則全体が無効となります。

修飾規則のブロック内容はスタイルブロック内容を構文解析する。 他の仕様や将来の仕様で明示的に定義されていない限り、そのリスト内の@規則は無効であり、無視される。

注: [CSS-NESTING-1]では、@nestおよび 条件付きグループ規則がスタイル規則内で許可されることが定義されています。

未知のCSSプロパティの宣言、 または値がそのプロパティで定義された構文と一致しない宣言は無効であり、無視されなければなりません。 スタイル規則内容の妥当性は規則自体の妥当性に影響しません。 特に指定がない限り、プロパティ名はASCII大文字・小文字を区別しないです。

注: カスタムプロパティ名[CSS-VARIABLES]は大文字・小文字を区別します。

修飾規則はCSSスタイルシートのトップレベルではスタイル規則です。 他の文脈の修飾規則は、文脈によってスタイル規則である場合もそうでない場合もあります。

例えば、 @media規則[CSS3-CONDITIONAL]内の修飾規則はスタイル規則ですが、 @keyframes規則[CSS3-ANIMATIONS]内の修飾規則はスタイル規則ではありません。

9.2. @規則

@規則はatキーワードで始まる規則であり、 同じ文脈のスタイル規則と区別できます。

@規則は以下の目的で使われます：

• スタイル規則や他の@規則をグループ化・構造化する （例：条件付きグループ規則）

• 特定の要素と関連付けられていないスタイル情報を宣言する （例：カウンタースタイルを定義する）

• 構文構造を管理する （例：インポートや名前空間キーワードのマッピング）

• そしてスタイル規則では提供できないその他の目的

@規則はその規則や目的によって様々な形を取りますが、 大きく分けて2種類あります：より単純な構造でセミコロンで終わるステートメント@規則と、 {}-ブロックの末尾に終わり、入れ子の修飾規則や@規則、宣言を含められるブロック@規則です。

ブロック@規則は通常、 （汎用または@規則固有の）@規則、修飾規則、および@規則で定義された制限に従う記述子宣言の集合を含みます。 記述子はプロパティと似ています（宣言構文は同じ）が、 ツリー内の要素やボックスではなく、特定の@規則種別に関連付けられます。

9.3. @charset規則

スタイルシートのフォールバックエンコーディングを決定するアルゴリズムは、 ファイルの最初の数バイトとして特定のバイト列を探し、 これは構文的には"@charset"という名前の@規則の形を取ります。

しかし、実際には@charsetという名前の@規則は存在しません。 スタイルシートを解析するとき、@charset規則が出現した場合は認識されない規則として扱われ、 文法チェック時に無効として除去されます。

注: CSS 2.1では@charsetは有効な規則でした。 一部のレガシー仕様では依然として@charset規則に言及しており、 スタイルシート内での存在について明示的に記述しています。

10. シリアライズ

この仕様で説明されているトークナイザーは、コメント用のトークンを生成せず、 コメントを何らかの方法で保存することもありません。 実装はコメント内容とトークンストリーム内の位置を保存しても構いません。 その場合、この保存情報は構文解析ステップには影響を与えてはなりません。

この仕様はCSSの一般的なシリアライズ方法を定義せず、 その作業は[CSSOM]や個別機能仕様に委ねられています。 特に、コメントや空白のシリアライズは定義されていません。

シリアライズの唯一の要件は、構文解析との「ラウンドトリップ」を満たすことです。 つまり、スタイルシートを構文解析した結果と、 構文解析→シリアライズ→再度構文解析した結果が同じデータ構造になることです。 ただし、連続する<whitespace-token>については、 1つのトークンにまとめられる場合があります。

注: この例外が許可されるのは、 CSS文法が任意量の空白を1つのスペースと同じように解釈するためです。

10.1. <an+b>のシリアライズ

11. プライバシーとセキュリティに関する考慮事項

この仕様は新たなプライバシー懸念を導入しません。

この仕様はセキュリティを向上させます。CSSの構文解析がすべての入力に対して明確に定義されたためです。

古いパーサ（ホワイトリストやフィルタ等）がこの仕様と異なる解析を行う場合、 それらはやや安全性に欠けますが、従来の構文解析仕様には多くの曖昧な隅のケースがあり、 ブラウザによって解釈が異なっていたため、 そうしたフィルタはすでに潜在的に安全性に問題があり、 この仕様が状況を悪化させるものではありません。

12. 変更点

このセクションは規範的ではありません。

12.1. 2019年8月16日候補勧告からの変更点

以下の実質的変更を行いました：

• 新しい§ 5.3.2 CSS文法に従ってカンマ区切りリストを構文解析するアルゴリズムを追加。

• 新しい§ 5.3.7 スタイルブロック内容を構文解析するアルゴリズムと 対応する<style-block>生成規則を追加し、 スタイル規則がこれを使うと定義。

• スタイルシートを構文解析するをFetch関連の処理に合わせた。 （コミット参照。）

  inputからスタイルシートを構文解析する （オプションでurllocationを指定可） :

  1. ...
  2. 新しいスタイルシートを生成 。locationを location（未指定ならnull）に設定。
  3. ...

以下の編集上の変更を行いました：

• § 9.2 @規則を追加し、@規則、ステートメント@規則、ブロック@規則、 記述子の定義を追加。 (5633)

• 宣言の定義文を改善し、 プロパティ宣言と記述子宣言の定義を追加。

• 「ident sequence」への参照を一貫して使うよう変更、 時々「name」を使っていた箇所を修正。

• 複数の前トークナイズ処理に明示的な名前を付け、 パースの入口点で明示的に参照するよう変更（アルゴリズム冒頭で「Xを実行」等の包括的記述を避けた）。

• コメント挿入表にエントリ追加、 識別子が--で始まるケースを正しく処理できるよう対応。 (6874)

12.2. 2014年2月20日候補勧告からの変更点

以下の実質的変更を行いました：

• <unicode-range-token>を削除し、 <urange>生成規則を新設。

• 文字列を含むurl()関数は通常の<function-token>として構文解析されるように。 「生」URLを含むurl()関数は依然として<url-token>として特別扱い。

• 「URLトークンを消費する」アルゴリズムのバグ修正。 文字列開始の引用符を消費せずに文字列消費を試みていた。

• いくつかのパーサアルゴリズムのバグ修正。 現在/次の入力トークンの扱いや消費タイミングに関するもの。

• トークナイズ・パースアルゴリズムの細かなバグ修正。

• ident-likeトークン定義を変更し、識別子の先頭に「--」が使えるように。 これに伴い、トークンを消費するの「-」ステップ内の節の順序を変更し、 <CDC-token>が正しく認識されるようにした（「--」<ident-token>にならない）。

• <an+b>のAが1または-1のときは数字をシリアライズしないよう変更。

• すべてのトークンに表現を持たせるよう定義。

• 2つのコードポイントが有効なエスケープか確認するアルゴリズムのバグ修正。 \の直後がEOFの場合は有効なエスケープではないと正しく判定。 スタイルシート末尾の\は単に<delim-token>として出力。

• @charsetはもはや有効なCSS規則ではなく（単なるエンコーディング宣言で、@charsetという名前の規則「のように見える」だけ）

• 構文解析時に宣言値の先頭・末尾の空白をトリムするよう変更。

• WG決議によりSelectors専用トークンを削除。

• WG決議により、入力ストリームからサロゲートを除去。 仕様全体がスカラ値のみを扱うように。

以下の編集上の変更を行いました：

• 「文字列トークンを消費する」アルゴリズムを変更し、明示的な終了トークン指定なしで呼び出せるように。 アルゴリズムの3つの呼び出し箇所もこの形式に変更。

• アルゴリズムの編集上の構造を微調整。

• 構文解析とコンポーネント値のカンマ区切りリストを構文解析するAPI入口点を追加。

• <declaration-value>および<any-value>生成規則を追加。

• 「code point」「surrogate code point」を削除し、Infra Standardの同義定義に置き換え。

• すべての範囲が両端含むことを明確化。

• 数値トークンの隣に「%」区切りトークンが来る場合のコメント挿入表に列を追加。

コメント一覧（Disposition of Comments）が利用可能です。

12.3. 2013年11月5日最終コール作業草案からの変更点

• シリアライズセクションを全面的に書き直し、 「ラウンドトリップ」要件のみを規範的とし、達成方法の詳細は注に移動。 これら詳細の隅のケースを修正。
• [ENCODING]を規範的参照一覧に追加。 既に規範文中で参照していたが、明示されていなかった。
• スタイルシートのフォールバックエンコーディング決定アルゴリズムで、 @charsetバイト列を1024バイトまでに制限。 これはHTMLの<meta charset>と揃え、シーケンスのサイズを制限。 先頭・末尾の空白の扱いに影響が出る：

  @charset "   (空白多数)   utf-8";

12.4. 2013年9月19日作業草案からの変更点

• 環境エンコーディングの概念を追加。 挙動は変わらないが、定義の一部は関連仕様に移すべきもの。

12.5. CSS 2.1およびSelectors Level 3からの変更点

注: 本仕様の目的は現実に合わせることです。 CSS2.1からの変更点はほぼ例外なく、CSS2.1が実ブラウザの動作と合わなかったことや未定義部分があったことに起因します。 もし何か挙動がブラウザと一致しない場合は、ほぼ確実に意図しないものなのでお知らせください。

バイトストリームからのデコード変更点：

• ASCII互換バイトパターンのみで@charset規則を検出。
• ASCII非互換エンコーディングを指定する@charset規則は無視。 そうすると規則自体が正しくデコードできなくなるため。
• 文字エンコーディングにはIANAレジストリではなく[ENCODING]を参照。

トークナイズ変更点：

• CSSソース内のU+0000 NULLコードポイントはU+FFFD置換文字に変換。
• \0のような16進エスケープシーケンスがゼロ値になる場合はU+FFFD置換文字を生成（U+0000 NULLではなく）。
• 非ASCIIコードポイント定義をすべてのASCII定義と一致するよう変更。 これによりU+0080～U+009Fは他の識別子コードポイントと同じく<delim-token>ではなくなる。
• トークナイズはCOMMENT/BAD_COMMENTトークンを出力しなくなった。 BAD_COMMENTは通常トークン（エラーではない）として扱う。シリアライズが トークン間にコメント挿入の責任を持つ（例えば連続する<ident-token>同士など）。
• <unicode-range-token>を削除。 価値が低く、時に有害だったため（例：u+a { font-weight: bold; }は無効なセレクタだった...）。

  代わりにトークンパターンに基づく<urange>生成規則を追加。 技術的には2.1よりも緩い（任意桁の数字や?文字を許可）が、実用上問題はないはず。

• EOFエラー処理規則を トークナイザーに適用し、BAD_STRINGやBAD_URIではなく EOF時には通常の<string-token>や<url-token>を出力。
• BAD_URIトークン（現<bad-url-token>）は「自己完結型」になった。 つまり、トークナイザーが<bad-url-token>だと判断したら、以降は閉じ括弧を探して先送りし、他は無視。 <function-token>としてブロックの開閉等を気にするより簡便。 実装はWebKitのみだが、互換性バグは出ていない。
• <comma-token>を追加。
• <number-token>、<percentage-token>、<dimension-token>は 先頭の+/-記号も値の一部として含むよう変更 （以前は別の<delim-token>として毎回仕様で手動処理が必要だった）。 この結果、記号と数値の間にコメントは挿入できなくなった。
• WG決議により、SVGと合わせて数値/パーセント/次元での科学的記数法をサポート。
• サロゲートの16進エスケープはサロゲートではなく置換文字を出力。 これにより実装が内部的にUTF-16を安全に使えるようになる。

構文解析の変更点：

• 宣言リストは今や@規則も受け入れる（例：@page）。 実際のエラー処理が変わる場合がある。 まだ定義されていない@規則でも、正否に関わらず{}ブロックで終わり、次の宣言開始を可能にする。
• グラム内で様々な「特殊」トークン（未対応の<}-token>等）が 現れる場合の扱いを、少なくとも1つのブラウザが示す合理的挙動で明記。 従来はそうしたトークンがあると文法に一致せず、扱いは完全に未定義だった。 具体的には：
  • []ブロック、()ブロック、関数は{}ブロックや<at-keyword-token>、<semicolon-token>も含め可能
  • 修飾規則の前置部はセミコロンを含め可能
  • 修飾規則・@規則の前置部は<at-keyword-token>も含め可能

An+BのSelectors Level 3 [SELECT]からの変更点：

• An+Bマイクロ構文がCSSトークンに基づく正式定義となり、個別トークナイザーによる定義を廃止。 これにより細かな差異が発生：
  • 一部のケースでマイナス記号や数字がエスケープ可能 （<dimension-token>や<ident-token>の単位の一部として現れる場合）。

謝辞

フィードバック・貢献に感謝： Anne van Kesteren, David Baron, Elika J. Etemad (fantasai), Henri Sivonen, Johannes Koch, 呂康豪 (Kang-Hao Lu), Marc O’Morain, Raffaello Giulietti, Simon Pieter, Tyler Karaszewski, Zack Weinberg.