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

1. はじめに

この節は規範的ではない。

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

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

1.1. モジュール間の相互作用

このモジュールは、CSS スタイルシートの構文と構文解析を定義する。 CSS 2.1 で定義された字句スキャナーと文法を置き換える。

2. CSS の構文の説明

この節は規範的ではない。

CSS 文書は、一連のスタイル 規則—​文書内の要素にスタイルを適用する修飾規則—​と、CSS 文書の特別な処理 規則や値を定義するat 規則—​から成る。

修飾規則は 前置部から始まり、 次に、宣言のシーケンスを含む {} で囲まれたブロックを持つ。 前置部の意味は、その規則が現れる文脈によって異なる—​スタイル規則の場合、どの 要素に宣言を適用するかを指定するセレクターである。 各宣言は名前を持ち、 その後にコロンと宣言値が続く。 宣言はセミコロンで区切られる。

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 進数字でも改行でもない任意の Unicode コードポイント。 エスケープシーケンスは、そのコードポイントに置き換えられる。
• または、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 規則自身の文法に従って解釈される。
• 修飾規則も同様に動作するが、 セミコロンでは終了しない。 代わりに、それらは単に規則の前置部の一部として取り込まれる。 最初の {} ブロックが見つかると、 内容は常に宣言のリストとして解釈される。
• 宣言のリストを解釈する際、 任意の時点で未知の構文があると、パーサーは現在 構築中の宣言を破棄し、 セミコロン（またはブロックの終端）が見つかるまで先へ進む。 その後、改めて宣言の構文解析を試みる。
• 規則、宣言、関数、文字列などのいずれかが開いたままスタイルシートが終了した場合、 すべて自動的に閉じられる。 これによってそれらが無効になるわけではないが、 不完全である可能性があり、 そのため文法に照らして検証される際に破棄されることがある。
  例えば、translateX() 関数の構文は次のとおりである:

  translateX( <translation-value> )

  ただし、スタイルシートは、次のように関数を閉じないまま終了する場合がある:

  .foo { transform: translate(50px

  CSS パーサーはこれを、1 つの宣言を含むスタイル規則として構文解析し、 その値は "translate" という名前の関数となる。 これは上記の文法に一致する。 終端トークンがトークンストリームに現れなかったとしても、 パーサーが処理を完了する時点では、 終端トークンが存在したかどうかを判定することはもはや不可能であるためである。 分かるのはブロックと関数が存在するという事実だけである。

各構成要素（宣言、スタイル規則、at 規則）が構文解析された後、 ユーザーエージェントは期待される文法に照らしてそれを確認する。 文法に一致しない場合、 それは無効であり、 UA によって無視され、 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. トークン化

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

注: トークンを消費するアルゴリズムの各呼び出しは 単一のトークンを返すため、 必要であれば、構文解析の最中に コードポイントのストリームを "オンデマンド" でトークン化するためにも使用できる。

トークン化段階の出力は、次のトークンの 0 個以上から成るストリームである: <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>, <unicode-range-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 トークンは "id" または "unrestricted" のいずれかに設定された type フラグを持つ。type フラグは、 他で設定されていない場合、デフォルトで "unrestricted" となる。
• <delim-token> は、単一のコード ポイントから構成される値を持つ。
• <number-token>、<percentage-token>、および <dimension-token> は数値を持ち、 また任意の符号文字 が "+" または "-"（または何もなし）のいずれかに設定される。

  <number-token> と <dimension-token> はさらに、 "integer" または "number" のいずれかに設定された type フラグを持つ。type フラグは、他で設定されていない場合、 デフォルトで "integer" となる。 <dimension-token> はさらに、1 個以上のコードポイントから構成される単位を持つ。

• <unicode-range-token> は開始コード ポイントと終了コードポイントを持つ。 これはコードポイントの包含範囲 （開始と終了の両方を含む）を表す。 終了コードポイントが開始コードポイントより前にある場合、 空の範囲を表す。

注: hash トークンの type フラグは、 Selectors 構文 [SELECT] で使用される。 "id" type の hash トークンのみが有効なID セレクターである。

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

この節は非規範的である。

この節では、トークナイザーを情報提供的な観点から、 レールロード図の形式で示す。 レールロード図は明示的なパーサーより簡潔であり、 多くの場合、正規表現より読みやすい。

これらの図は情報提供的かつ不完全である。 "正しい" トークンの文法を記述するが、 エラー処理についてはまったく記述しない。 各トークンの構文を直感的に把握しやすくすることだけを目的として提供される。

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

コメント

改行

空白

16 進数字

エスケープ

<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>

<unicode-range-token>

4.2. 定義

この節では、トークン化段階で使用されるいくつかの用語を定義する。

次の入力コード ポイント

入力ストリーム内で、まだ消費されていない最初のコードポイント。

現在の入力 コードポイント

最後に消費されたコードポイント。

現在の入力コードポイントを再消費する

現在の入力コードポイントを入力ストリームの先頭に戻し、 次に次の入力コードポイントを消費するよう指示されたとき、 代わりに現在の入力コード ポイントを再消費するようにする。

EOF コードポイント

入力ストリームの終端を表す概念上のコードポイント。 入力ストリームが空である場合は常に、 次の入力 コードポイントは常に EOF コードポイントである。

数字

U+0030 DIGIT ZERO (0) から U+0039 DIGIT NINE (9) まで（両端を含む）のコードポイント。

テスト

• inclusive-ranges.html （ライブ テスト） （ソース）

16 進数字

数字、 または 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) まで（両端を含む）のコードポイント。

大文字

U+0041 LATIN CAPITAL LETTER A (A) から U+005A LATIN CAPITAL LETTER Z (Z) まで（両端を含む）のコードポイント。

小文字

U+0061 LATIN SMALL LETTER A (a) から U+007A LATIN SMALL LETTER Z (z) まで（両端を含む）のコードポイント。

文字

大文字 または小 文字。

非 ASCII ident コードポイント

値が次のいずれかであるコードポイント:

• U+00B7

• U+00C0 から U+00D6 まで

• U+00D8 から U+00F6 まで

• U+00F8 から U+037D まで

• U+037F から U+1FFF まで

• U+200C

• U+200D

• U+203F

• U+2040

• U+2070 から U+218F まで

• U+2C00 から U+2FEF まで

• U+3001 から U+D7FF まで

• U+F900 から U+FDCF まで

• U+FDF0 から U+FFFD まで

• U+10000 以上

これらの範囲はすべて両端を含む。

テスト

• non-ascii-codepoints.html （ライブ テスト） （ソース）

なぜ、具体的にこれらの文字なのか？

これは、HTML の有効なカスタム要素名で使用することが許可されている 非 ASCII コードポイントのリストと一致する。 空白として現れる多数の文字や、 一部のツールでレンダリングまたは構文解析の問題を引き起こす可能性がある文字、 例えば方向上書きコードポイントなどは除外される。

これは、識別子に対して UAX 31 が推奨する制限の集合よりも弱いことに注意すること （JavaScript などの言語では識別子の構文を制限するために使用される）。 例えば、 結合文字で識別子を開始することなども許可される。 HTML カスタム要素名との一貫性 （したがって、エスケープを使用せずにすべてのカスタム要素のセレクターを記述できること） は価値があると考えられ、 HTML によって制限される文字の集合は 「価値の高い」制限を十分に網羅している。

これらの制限によって、混乱を招く可能性のあるすべてのレンダリングが避けられるわけではない。 LTR と RTL のスクリプトの文字を混在させると、 ほとんどのテキストエディターで 予期しない視覚的な転置が依然として発生する可能性がある。 例えばそうである。 ソーステキストには、ident 以外の文脈で制限された文字を含めることもできる: 例えば、そのほとんどは文字列では完全に有効である。 無効な CSS を生成する方法で使用された場合でさえ、 それらが引き起こす構文解析エラーは重要でないものに限定される可能性がある一方、 コードレビューツールでのソーステキストのレンダリングへの影響は 重大および／または悪意のあるものとなる可能性がある。 この種の「ソーステキスト攻撃」の詳細については、 この Rust-lang ブログ 投稿 （アーカイブ）を参照。

ident-start コードポイント

文字、 非 ASCII ident コードポイント、 または U+005F LOW LINE (_)。

ident コード ポイント

ident-start コードポイント、 数字、 または U+002D HYPHEN-MINUS (-)。

印字不能 コードポイント

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

テスト

• inclusive-ranges.html （ライブ テスト） （ソース）

改行

U+000A LINE FEED。 U+000D CARRIAGE RETURN および U+000C FORM FEED はこの定義には含まれないことに注意すること。 これらは前処理中に U+000A LINE FEED に変換されるためである。

空白

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

テスト

• whitespace.html （ライブテスト） （ソース）

許可される最大 コードポイント

Unicode によって定義される最大のコードポイント: U+10FFFF。

ident シーケンス

<ident-token>と同じ構文を持つコードポイントのシーケンス。

注: <at-keyword-token> の "@" より後の部分、 <hash-token>（"id" type フラグを持つ）の "#" より後の部分、 <function-token> の "(" より前の部分、 および <dimension-token> の単位 はすべてident シーケンスである。

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

この節で定義されるアルゴリズムは、コードポイントのストリームを トークンのストリームに変換する。

4.3.1. トークンを消費する

この節では、コード ポイントのストリームからトークンを消費する方法を説明する。 さらに、任意のブール値 unicode ranges allowed を取り、 デフォルトは false である。 任意の type の単一のトークンを返す。

コメントを消費する。

次の 入力コードポイントを消費する。

空白

可能な限り多くの空白を 消費する。 <whitespace-token>を返す。

U+0022 QUOTATION MARK (")

文字列 トークンを消費する そしてそれを返す。

U+0023 NUMBER SIGN (#)

次の 入力コードポイントがident コードポイント であるか、次の 2 つの入力コードポイントが 有効なエスケープである場合、 次を行う:

1. <hash-token>を作成する。
2. 次の 3 つの入力コードポイントが ident シーケンスを開始する場合、 <hash-token>の type フラグを "id" に設定する。
3. ident シーケンスを消費する。 そして<hash-token>の値を返された文字列に設定する。
4. <hash-token>を返す。

それ以外の場合、 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

U+0027 APOSTROPHE (')

文字列 トークンを消費する そしてそれを返す。

U+0028 LEFT PARENTHESIS (()

<(-token>を返す。

U+0029 RIGHT PARENTHESIS ())

<)-token>を返す。

U+002B PLUS SIGN (+)

入力ストリームが数値で開始する場合、 現在の入力コードポイントを再消費する。 数値 トークンを消費する。 そしてそれを返す。

それ以外の場合、 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

U+002C COMMA (,)

<comma-token>を返す。

U+002D HYPHEN-MINUS (-)

入力ストリームが数値で開始する場合、 現在の入力コードポイントを再消費する。 数値 トークンを消費する。 そしてそれを返す。

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

それ以外の場合、 入力ストリームがident シーケンスで開始する場合、 現在の入力コードポイントを再消費する。 ident-like トークンを消費する。 そしてそれを返す。

それ以外の場合、 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

U+002E FULL STOP (.)

入力ストリームが数値で開始する場合、 現在の入力コードポイントを再消費する。 数値 トークンを消費する。 そしてそれを返す。

それ以外の場合、 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

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>を返し、 その値を現在の入力コードポイントに設定する。

U+0040 COMMERCIAL AT (@)

次の 3 つの 入力コードポイントが ident シーケンスを開始する場合、 ident シーケンスを消費する。 その値を返された 値に設定した<at-keyword-token>を作成し、 それを返す。

それ以外の場合、 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

U+005B LEFT SQUARE BRACKET ([)

<[-token>を返す。

U+005C REVERSE SOLIDUS (\)

入力ストリームが有効なエスケープで開始する場合、 現在の入力コードポイントを再消費する。 ident-like トークンを消費する。 そしてそれを返す。

テスト

• url-whitespace-consumption.html （ライブ テスト） （ソース）

それ以外の場合、 これは構文解析エラーである。 <delim-token>を返し、 その値を現在の入力コードポイントに設定する。

U+005D RIGHT SQUARE BRACKET (])

<]-token>を返す。

U+007B LEFT CURLY BRACKET ({)

<{-token>を返す。

U+007D RIGHT CURLY BRACKET (})

<}-token>を返す。

数字

現在の入力コードポイントを再消費する。 数値 トークンを消費する。 そしてそれを返す。

U+0055 LATIN CAPITAL LETTER U (U)

u+0075 LATIN LOWERCASE LETTER U (u)

unicode ranges allowed が true であり、入力ストリームがunicode-range を開始する場合、 現在の入力コードポイントを再消費する。 unicode-range トークンを消費する。 そしてそれを返す。

それ以外の場合、 現在の入力コードポイントを再消費する。 ident-like トークンを消費する。 そしてそれを返す。

ident-start コードポイント

現在の入力コードポイントを再消費する。 ident-like トークンを消費する。 そしてそれを返す。

EOF

<EOF-token>を返す。

その他

<delim-token>を返し、 その値を現在の入力コードポイントに設定する。

4.3.2. コメントを消費する

この節では、コードポイントのストリームからコメントを消費する方法を説明する。 何も返さない。

次の 2 つの 入力コードポイントが U+002F SOLIDUS (/) の後に U+002A ASTERISK (*) が続くものであれば、 それらと、 最初の U+002A ASTERISK (*) の後に U+002F SOLIDUS (/) が続く箇所まで（それを含む）の 後続するすべてのコードポイントを消費するか、 EOF コードポイントまで消費する。 このステップの先頭に戻る。

前の段落が EOF コードポイントを消費して終了した場合、 これは構文解析エラーである。

何も返さない。

4.3.3. 数値トークンを消費する

この節では、コードポイントのストリームから数値トークンを消費する方法を説明する。 <number-token>、<percentage-token>、または <dimension-token>のいずれかを返す。

数値を消費する。その結果を number とする。

次の 3 つの 入力コードポイントが ident シーケンスを開始する場合、 次を行う:

1. number と同じ値、type フラグ、および 符号文字を持ち、単位が最初は空文字列に設定された<dimension-token>を作成する。
2. ident シーケンスを消費する。 <dimension-token>の単位を返された値に設定する。
3. <dimension-token>を返す。

それ以外の場合、 次の入力 コードポイントが U+0025 PERCENTAGE SIGN (%) であれば、 それを消費する。 number と同じ値および符号文字 を持つ<percentage-token>を作成し、 それを返す。

それ以外の場合、 number と同じ値、type フラグ、および符号 文字を持つ<number-token>を作成し、 それを返す。

4.3.4. ident-like トークンを消費する

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

ident シーケンスを消費する。その結果を string とする。

string の値が "url" とASCII 大文字・小文字を区別せず一致し、 次の 入力コードポイントが U+0028 LEFT PARENTHESIS (() であれば、 それを消費する。 次の 2 つの入力コードポイントが 空白である間、 次の入力コードポイントを消費する。 次の 1 つまたは 2 つの入力コードポイントが U+0022 QUOTATION MARK (")、 U+0027 APOSTROPHE (')、 または空白の後に U+0022 QUOTATION MARK (") または U+0027 APOSTROPHE (') が続くものであれば、 <function-token>を作成し、 その値を string に設定して それを返す。 それ以外の場合、 url トークンを消費する。 そしてそれを返す。

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

それ以外の場合、 <ident-token>を作成し、 その値を string に設定して それを返す。

4.3.5. 文字列トークンを消費する

この節では、コードポイントのストリームから文字列トークンを消費する方法を説明する。 <string-token>または <bad-string-token>のいずれかを返す。

このアルゴリズムは ending code point を指定して呼び出してもよく、 これは文字列を終了するコードポイントを示す。 ending code point が指定されていない場合、 現在の 入力コードポイントを使用する。

最初に、値を空文字列に設定した<string-token>を作成する。

ストリームから次の入力コードポイントを繰り返し消費する:

ending code point

<string-token>を返す。

EOF

これは構文解析エラーである。 <string-token>を返す。

改行

これは構文解析エラーである。 現在の入力コードポイントを再消費する。 <bad-string-token>を作成し、それを返す。

U+005C REVERSE SOLIDUS (\)

次の 入力コードポイントが EOF であれば、 何もしない。

それ以外の場合、 次の入力コードポイントが改行であれば、 それを消費する。

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

その他

現在の入力コードポイントを<string-token>の値に追加する。

4.3.6. url トークンを消費する

この節では、コードポイントのストリームからurl トークンを消費する方法を説明する。 <url-token>または <bad-url-token>のいずれかを返す。

注: このアルゴリズムは、最初の "url(" が すでに消費されていることを前提とする。 また、このアルゴリズムは、url(foo) のような 「引用符なし」の値を消費するために呼び出されていることを前提とする。 url("foo") のような引用符付きの値は、 <function-token>として構文解析される。 ident-like トークンを消費するは、この 区別を自動的に処理する。 それ以外の場合、このアルゴリズムを直接呼び出すべきではない。

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

   U+0029 RIGHT PARENTHESIS ())

   <url-token>を返す。

   EOF

   これは構文解析エラーである。 <url-token>を返す。

   空白

   可能な限り多くの空白を消費する。 次の入力コードポイントが U+0029 RIGHT PARENTHESIS ()) または EOF であれば、 それを消費し、<url-token>を返す （EOF に遭遇した場合、これは構文解析エラーである）。 それ以外の場合、 不正な url の残りを消費する。 <bad-url-token>を作成し、 それを返す。

   U+0022 QUOTATION MARK (")

   U+0027 APOSTROPHE (')

   U+0028 LEFT PARENTHESIS (()

   印字不能コードポイント

   これは構文解析エラーである。 不正な url の残りを消費する。 <bad-url-token>を作成し、 それを返す。

   U+005C REVERSE SOLIDUS (\)

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

   それ以外の場合、 これは構文解析 エラーである。 不正な url の残りを消費する。 <bad-url-token>を作成し、 それを返す。

   その他

   現在の入力コードポイント を<url-token>の値に追加する。

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

この節では、エスケープされたコードポイントを消費する方法を説明する。 U+005C REVERSE SOLIDUS (\) がすでに消費されており、 次の入力コードポイントが 有効なエスケープの一部であることがすでに検証されていることを前提とする。 コードポイントを返す。

次の 入力コードポイントを消費する。

16 進数字

可能な限り多くの16 進数字を 消費するが、5 個を超えてはならない。 これは合計で 1-6 個の 16 進数字が消費されたことを意味する点に注意。 次の 入力コードポイントが 空白であれば、 それも消費する。 16 進数字を 16 進数として解釈する。 この数値が 0 である場合、 またはサロゲートに対応する場合、 または許可される最大コードポイントより大きい場合、 U+FFFD REPLACEMENT CHARACTER (�) を返す。 それ以外の場合、その値を持つコードポイントを返す。

EOF

これは構文解析エラーである。 U+FFFD REPLACEMENT CHARACTER (�) を返す。

その他

現在の入力コードポイントを返す。

4.3.8. 2 つのコードポイントが有効なエスケープであるかを確認する

この節では、2 つのコードポイントが有効な エスケープであるかを確認する方法を説明する。 ここで説明するアルゴリズムは、2 つのコードポイントを明示的に指定して呼び出すことも、 入力ストリーム自体を指定して呼び出すこともできる。 後者の場合、対象となる 2 つのコードポイントは、 現在の 入力コードポイント と次の 入力コードポイントであり、 この順序である。

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

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

それ以外の場合、 2 番目のコードポイントが改行であれば、 false を返す。

それ以外の場合、true を返す。

4.3.9. 3 つのコードポイントが ident シーケンスを開始するかを確認する

この節では、 3 つのコードポイントが ident シーケンスを開始するかを確認する方法を説明する。 ここで説明するアルゴリズムは、3 つのコードポイントを明示的に指定して呼び出すことも、 入力ストリーム自体を指定して呼び出すこともできる。 後者の場合、対象となる 3 つのコードポイントは、 現在の 入力コードポイント と次の 2 つの 入力コードポイントであり、 この順序である。

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

最初のコードポイントを見る:

U+002D HYPHEN-MINUS

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

ident-start コードポイント

true を返す。

U+005C REVERSE SOLIDUS (\)

1 番目と 2 番目のコードポイントが有効なエスケープである場合、 true を返す。 それ以外の場合、false を返す。

その他

false を返す。

4.3.10. 3 つのコードポイントが数値を開始するかを確認する

この節では、3 つのコードポイントが 数値を開始するかを確認する方法を説明する。 ここで説明するアルゴリズムは、3 つのコードポイントを明示的に指定して呼び出すことも、 入力ストリーム自体を指定して呼び出すこともできる。 後者の場合、対象となる 3 つのコードポイントは、 現在の 入力コードポイント と次の 2 つの 入力コードポイントであり、 この順序である。

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

最初のコードポイントを見る:

U+002B PLUS SIGN (+)

U+002D HYPHEN-MINUS (-)

2 番目のコードポイント が数字であれば、 true を返す。

それ以外の場合、 2 番目のコードポイント が U+002E FULL STOP (.) であり、 3 番目のコードポイント が数字であれば、 true を返す。

それ以外の場合、false を返す。

U+002E FULL STOP (.)

2 番目のコードポイント が数字であれば、 true を返す。 それ以外の場合、false を返す。

数字

true を返す。

その他

false を返す。

4.3.11. 3 つのコードポイントが unicode-range を開始するかを確認する

この節では、 3 つのコードポイントが unicode-range を開始するかを確認する方法を説明する。 ここで説明するアルゴリズムは、3 つのコードポイントを明示的に指定して呼び出すことも、 入力ストリーム自体を指定して呼び出すこともできる。 後者の場合、対象となる 3 つのコードポイントは、 現在の 入力コードポイント と次の 2 つの 入力コードポイントであり、 この順序である。

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

次のすべてが true である場合:

• 最初のコードポイントが U+0055 LATIN CAPITAL LETTER U (U) または U+0075 LATIN SMALL LETTER U (u) のいずれかである

• 2 番目のコードポイントが U+002B PLUS SIGN (+) である。

• 3 番目のコードポイントが U+003F QUESTION MARK (?) または16 進数字のいずれかである

その場合、true を返す。

それ以外の場合、false を返す。

4.3.12. ident シーケンスを消費する

この節では、ident シーケンスを消費する方法をコードポイントのストリームについて説明する。 最初から始めて、ストリーム内の隣接するコードポイントから 形成できる最大の名前を含む文字列を返す。

注: このアルゴリズムは、返される コードポイントが <ident-token>を構成することを保証するために必要な、 最初のいくつかのコードポイントの検証を行わない。 それが意図した用途である場合、 このアルゴリズムを呼び出す前に、ストリームがident シーケンスで開始する ことを確認する。

最初に result を空文字列とする。

ストリームから次の入力コードポイントを繰り返し消費する:

ident コードポイント

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

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

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

その他

現在の入力コードポイントを再消費する。 result を返す。

4.3.13. 数値を消費する

この節では、コードポイントのストリームから数値を消費する方法を説明する。 数値の value、 "integer" または "number" のいずれかである文字列 type、 および "+"、"-"、または欠落のいずれかである任意の sign character を返す。

注: このアルゴリズムは、 ストリームから数値を取得できることを保証するために必要な 最初のいくつかのコードポイントの検証を行わない。 このアルゴリズムを呼び出す前に、ストリームが数値で開始する ことを確認する。

次のステップを順に実行する:

1. type を文字列 "integer" とする。 number part と exponent part を空文字列とする。
2. 次の 入力コードポイントが U+002B PLUS SIGN (+) または U+002D HYPHEN-MINUS (-) であれば、 それを消費する。 それを number part に追加し、 sign character をそれに設定する。
3. 次の入力コードポイントが数字である間、 それを消費し、number part に追加する。
4. 次の 2 つの 入力コードポイントが、 U+002E FULL STOP (.) の後に数字が続くものであれば、 次を行う:
   1. 次の入力コードポイントを消費し、number part に追加する。
   2. 次の入力コードポイントが数字である間、それを消費して number part に追加する。
   3. type を "number" に設定する。
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 (+) が続き、 その後に数字が続くものであれば、 次を行う:
   1. 次の入力コードポイントを消費する。
   2. 次の入力コードポイントが "+" または "-" であれば、 それを消費し、exponent part に追加する。
   3. 次の入力コードポイントが数字である間、それを消費して exponent part に追加する。
   4. type を "number" に設定する。
6. number part を 10 進数として解釈した結果を value とする。

   exponent part が空でない場合、 それを 10 進整数として解釈し、 10 をその結果の累乗にし、 それに value を乗算し、 value をその結果に設定する。

7. value、type、および sign character を返す。

4.3.14. unicode-range トークンを消費する

この節では、unicode-range トークンを消費する方法を コードポイントのストリームについて説明する。 <unicode-range-token>を返す。

注: このアルゴリズムは、返されるコードポイントが <unicode-range-token>を構成することを保証するために必要な 最初のいくつかのコードポイントの 検証を行わない。 このアルゴリズムを呼び出す前に、ストリームがunicode-range を開始する ことを確認する。

注: このトークンは、通常の状況ではトークナイザーによって 生成されない。 このアルゴリズムが呼び出されるのは、 unicode-range 記述子の値を消費する間のみであり、 それ自体も特殊な場合としてのみ呼び出される。 unicode-range 記述子を構文解析するためである。 言語全体でこの 1 回だけ呼び出されるのは、 初期の CSS における不適切な構文設計によるものである。

1. 次の 2 つの入力コードポイントを消費し、それらを破棄する。

2. 可能な限り多くの16 進数字を 消費するが、 6 個を超えてはならない。 消費された 16 進数字が 6 個未満であれば、 可能な限り多くの U+003F QUESTION MARK (?) コードポイントを消費するが、 16 進数字と U+003F QUESTION MARK (?) コードポイントの 合計が 6 になるために必要な数を 超えてはならない。

   消費されたコードポイントを first segment とする。

3. first segment に疑問符コードポイントが含まれている場合、次を行う:

   1. first segment 内の疑問符を U+0030 DIGIT ZERO (0) コードポイントに置き換え、 その結果を 16 進数として解釈する。 これを start of range とする。

   2. first segment 内の疑問符を U+0046 LATIN CAPITAL LETTER F (F) コードポイントに置き換え、 その結果を 16 進数として解釈する。 これを end of range とする。

   3. start of range で始まり end of range で終わる新しい<unicode-range-token>を返す。

4. それ以外の場合、first segment を 16 進数として解釈し、 その結果を start of range とする。

5. 次の 2 つの入力コードポイントが U+002D HYPHEN-MINUS (-) の後に16 進数字が続くものであれば、 次を行う:

   1. 次の入力コードポイントを消費する。

   2. 可能な限り多くの16 進 数字を消費するが、6 個を超えてはならない。 消費したコードポイントを 16 進数として解釈する。 これを end of range とする。

   3. start of range で始まり end of range で終わる新しい<unicode-range-token>を返す。

6. それ以外の場合、開始と終了の両方が start of range である新しい<unicode-range-token>を返す。

4.3.15. 不正な url の残りを消費する

この節では、コード ポイントのストリームから不正な url の残りを消費する方法を説明し、 トークナイザーが <bad-url-token>ではなく <url-token>の途中にいることを認識した後に「後始末」する。 何も返さない。 唯一の用途は、通常のトークン化を再開できる回復地点に到達するのに十分な 入力ストリームを消費することである。

ストリームから次の入力コードポイントを繰り返し消費する:

U+0029 RIGHT PARENTHESIS ())

EOF

戻る。

入力ストリームが有効なエスケープで開始する

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

その他

何もしない。

5. 構文解析

CSS パーサーはトークンストリーム （この仕様で先に定義された トークン化処理によって生成される）を、 複数ある CSS 構成要素のうち 1 つ以上へ変換する （どの構文解析アルゴリズムが呼び出されるかによる）。

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

この節は非規範的である。

この節では、パーサーを情報提供的な観点から、 レールロード図の形式で示す。

これらの図は情報提供的かつ不完全である。 「正しい」スタイルシートの文法を記述するが、 エラー処理についてはまったく記述しない。 構文を直感的に把握しやすくすることだけを目的として提供される。

スタイルシート

at 規則

修飾規則

{} ブロック

宣言

!important

コンポーネント値

単純ブロック

関数ブロック

5.2. CSS 構文解析結果

構文解析の結果は、次のいずれか （またはそれらのリスト）となり得る:

スタイルシート

スタイルシートは規則のリストを持つ。

規則

規則は、at 規則 または修飾規則のいずれかである。

at 規則

at 規則は、文字列である名前と、 コンポーネント値のリストから成る前置部を持つ。 ブロック at 規則 （{} ブロックで終わる）は、 さらに 宣言のリスト および子規則のリストを持つ。 （文 at 規則は、 セミコロンで終わり、 これらを持たない。）

修飾規則

修飾規則は、 コンポーネント値のリストから成る前置部、 宣言のリスト、 および子規則のリストを持つ。

注: ほとんどの修飾規則はスタイル規則であり、 前置部はセレクター [selectors-4] で、その宣言はプロパティである。

宣言

宣言は、文字列である名前と、 コンポーネント値のリストから成る値と、 初期状態では設定されていない important フラグを持つ。 また、任意の original text も持ち、これは文字列である （ごく一部の宣言についてのみ取得される）。

宣言はさらに、 プロパティ宣言または記述子 宣言に分類され、 前者は CSS プロパティを設定し、 もっとも頻繁に修飾規則に現れ、 後者は CSS 記述子を設定し、 at 規則にのみ現れる。 （この分類は Syntax レベルでは行われず、 代わりに宣言が現れる場所によって決まり、 該当する規則を定義するそれぞれの仕様によって定義される。）

コンポーネント値

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

保持トークン

トークナイザーによって生成される任意のトークンのうち、 <function-token>、 <{-token>、 <(-token>、 および<[-token>を除くもの。

注: 上記の非保持トークンは、 常により高レベルのオブジェクト、 すなわち関数または単純ブロックに取り込まれるため、 それ自体がパーサー出力に現れることはない。

注: トークン <}-token>、<)-token>、<]-token>、<bad-string-token>、および<bad-url-token>は常に構文解析エラーであるが、 Media Queries などの他の仕様が、 宣言またはブロック全体を単に破棄するよりも きめ細かなエラー処理を定義できるようにするため、 この仕様ではトークンストリーム内に保持される。

関数

関数は名前と、 コンポーネント値のリストから成る値を持つ。

単純 ブロック

{} ブロック

[] ブロック

() ブロック

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

{} ブロック、[] ブロック、および() ブロックは、 具体的には、 対応する関連付けられたトークンを持つ単純ブロック を指す。

5.3. トークンストリーム

トークン ストリームは、 トークンおよび／またはコンポーネント値のストリームを表す構造体である。 次の項目を持つ:

トークン

トークン および／またはコンポーネント 値のリスト。

注: この仕様では、簡単のため、 入力ストリームが完全にトークン化された 後に構文解析が開始すると仮定している。 ただし、構文解析アルゴリズムが使用する「先読み」は 1 トークンだけなので、 実際にはトークン化と構文解析を 同期して行うことができる。

インデックス

トークンへのインデックスであり、 構文解析の進行状況を表す。 初期値は 0 である。

注: マークを除き、 インデックスが 後戻りすることはない。 したがって、すでに処理されたトークンの接頭部分は、 処理され次第破棄できる。

マークされたインデックス

インデックス値のスタックであり、 パーサーが戻る可能性のある地点を 表す。 初期状態では空である。

CSS には、 宣言の値として構文解析された 正確なテキストを参照する必要がある箇所が少数存在する （そのテキストから生成されたトークンだけではない）。 これはここでのアルゴリズム構造には明示的に記述されていないが、 そのためトークンストリームは、 必要に応じて宣言の元のテキストを再現する能力を 持たなければならない。 これが必要になる場合の詳細については、宣言を 消費するを参照。

トークンストリームに対して、いくつかの操作を実行できる:

次のトークン

インデックスにあるトークンの項目。

そのインデックスがリスト終端の範囲外となる場合、 代わりに<eof-token>となる。

空

次のトークンが<eof-token>である場合、トークンストリームは空である。

トークンを消費する

token を次のトークンとする。 インデックスを増加させ、 その後 token を返す。

トークンを破棄する

トークン ストリームが空でない場合、 インデックスを増加させる。

マークする

インデックスを マークされたインデックスに追加する。

マークを復元する

マークされたインデックスからポップし、 インデックスをポップされた値に設定する。

マークを破棄する

マークされたインデックスからポップし、 ポップされた値については何もしない。

空白を破棄する

次のトークンが<whitespace-token>である間、 トークンを破棄する。

処理する

後続するトークン型と関連するアクションのリストが与えられたとき、 次のトークンに関連付けられたアクションを実行することによって処理する。 いずれかのアクションが何かを返すまで繰り返し、 その後それを返す。

<eof-token>は概念上のトークンであり、 実際にはトークナイザーによって生成されず、 トークンストリームが使い尽くされたことを示すために使用される。

5.4. パーサーのエントリーポイント

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

注: 他の仕様は、 独自の目的のために追加のエントリーポイントを定義できる。

5.4.1. CSS 文法に従って何かを構文解析する

文字列またはトークンリストを構文解析して、 ある CSS 文法に一致するかどうかを確認し、 一致する場合には、 文法に従ってそれを分解することが望ましい場合がよくある。 この節では、この種の操作のための汎用的なフックを提供する。 次のように呼び出すべきである: 「foo を CSS <color> として構文解析する」、または同様に。

このアルゴリズムは、入力が指定された文法に一致しない場合は 失敗を返し、 それ以外の場合は文法に従って入力を構文解析した結果を返す。 これは指定された文法仕様に対応する未規定の構造である。 戻り値は仕様の文章によってのみ操作されなければならず、 その場合、表現の曖昧さは問題にならない。 仕様言語の外部に公開することを意図する場合、 結果を使用する仕様は、明確に規定された表現へ明示的に変換しなければならない。 例えば、CSS シリアル化アルゴリズムを呼び出すことによって （「CSS <string> 値としてシリアル化する」のように）。

注: このアルゴリズムと、 CSS 文法に従ってカンマ区切りリストを 構文解析するは、 通常、他の仕様が呼び出したい構文解析アルゴリズムのすべてである。 残りの構文解析アルゴリズムは、主として [CSSOM] および関連する「CSS 構造を明示的に構築する」場合を意図している。 他のアルゴリズムのいずれかを使用する必要があると思う場合は、 まず CSSWG に助言を求めること。

5.4.2. CSS 文法に従ってカンマ区切りリストを構文解析する

カンマを含む文法に従って値を構文解析することはもちろん可能だが、 値のいずれかの部分が構文解析に失敗すると、 全体が構文解析されず、 失敗を返す。

それが望ましい場合もある （リスト値の CSS プロパティなど）。 一方で、 値のカンマ区切りの各部分を個別に構文解析し、 正常に構文解析された部分をある方法で処理し、 構文解析に失敗した部分を別の方法で処理する方がよい場合もある （通常はそれらを無視する。 例えば <img sizes>）。

このアルゴリズムは、まさにそれを実現するための簡単なフックを提供する。 「トップレベル」のカンマで分割された値のリストを返し、 各値は失敗 （構文解析に失敗した場合） または構文解析の結果 （構文解析アルゴリズムで説明される 未規定の構造）のいずれかとなる。

5.4.3. スタイルシートを構文解析する

5.4.4. スタイルシートの内容を構文解析する

5.4.5. ブロックの内容を構文解析する

5.4.6. 規則を構文解析する

5.4.7. 宣言を構文解析する

注: 「宣言のリストを構文解析する」とは異なり、 これは宣言のみを構文解析し、at 規則は構文解析しない。

5.4.8. コンポーネント値を構文解析する

5.4.9. コンポーネント値のリストを構文解析する

5.4.10. コンポーネント値のカンマ区切りリストを構文解析する

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

次のアルゴリズムがパーサーを構成する。 これらは上記のパーサーエントリーポイントから呼び出され、 通常、他の仕様から直接呼び出すべきではない。

CSS の構文解析では大文字と小文字が区別され、 特定の文脈における構成要素の有効性の確認は、 少なくとも一部の状況では構文解析中に行わなければならないことに注意すること。 この仕様は意図的に、 有効性の確認を可能にするために十分な文脈を どのように受け渡すべきかを規定しない。

5.5.1. スタイルシートの内容を消費する

トークンストリーム input からスタイルシートの 内容を消費するには:

rules を、初期状態では空の規則のリストとする。

input を処理する:

<whitespace-token>

input からトークンを破棄する。

<EOF-token>

rules を返す。

<CDO-token>

<CDC-token>

input からトークンを破棄する。

これは何のためか？

CSS が初めて導入された当時、 style 要素は古いブラウザーによって 未知の要素として扱われていた。 これらのレガシーブラウザーで その内容がページに表示されることを避けるため、 スタイルシートを HTML コメントで 囲むことが一般的になり、 新しいブラウザーは単に HTML コメント構文を無視していた。 この要件は、 数十年後の現在まで引き継がれている。

同じ慣行は script 要素でも行われ、 HTML コメント構文は同じ理由から JS で 行コメント（// と同様）として扱われる。

<at-keyword-token>

input からat 規則を消費する。 何かが返された場合、 それを rules に追加する。

その他

input から修飾 規則を消費する。 規則が返された場合、 それを rules に追加する。

5.5.2. at 規則を消費する

任意の bool nested（デフォルトは false）が与えられたとき、 トークンストリーム input からat 規則を消費するには:

表明: 次のトークンは<at-keyword-token>である。

input からトークンを消費する。 rule を、名前が返されたトークンの値に設定され、 前置部が初期状態では空のリストに設定され、 宣言も子規則も持たない新しいat 規則とする。

input を処理する:

<semicolon-token>

<EOF-token>

input からトークンを破棄する。 rule が現在の文脈で有効であれば、 それを返す。 それ以外の場合は何も返さない。

<}-token>

nested が true の場合:

• rule が現在の文脈で有効であれば、 それを返す。

• それ以外の場合は何も返さない。

それ以外の場合、トークンを消費し、 その結果を rule の前置部に追加する。

<{-token>

input からブロックを消費し、 その結果を rule の子規則に代入する。

注: 結果に 宣言のリストが含まれる場合、 CSSOM でそれらをどのように具現化するかは 規則によって異なる。 すべてをネストされた宣言規則に変換するものもあれば、 すべてを宣言として扱うものもあり、 最初の項目を残りとは異なる方法で扱うものもある。

rule が現在の文脈で有効であれば、 それを返す。 それ以外の場合は何も返さない。

その他

input からコンポーネント値を消費する。 返された値を rule の前置部に追加する。

5.5.3. 修飾規則を消費する

任意のトークン stop token および任意の bool nested（デフォルトは false）が与えられたとき、 トークンストリーム input から修飾 規則を消費するには:

rule を、新しい修飾規則とし、 その前置部、宣言、および子規則を すべて初期状態では空のリストに設定する。

input を処理する:

<EOF-token>

stop token（渡された場合）

これは構文解析エラーである。 何も返さない。

<}-token>

これは構文解析エラーである。 nested が true の場合、 何も返さない。 それ以外の場合、 トークンを消費し、 その結果を rule の前置部に追加する。

<{-token>

rule の前置部の最初の 2 つの非<whitespace-token>値が、 値が "--" で始まる<ident-token>と、 その後に続く<colon-token>である場合、次を行う:

• nested が true の場合、 input から不正な 宣言の残りを消費し、 nested を true に設定し、 何も返さない。

• nested が false の場合、 input からブロックを 消費し、 何も返さない。

この確認は何のためか？

宣言と修飾規則は、 許可される構文が通常重複しない。 現在定義されている CSS プロパティでは、その値に {} ブロックを使用できないため、 foo:bar {}; は確実に規則であり、 foo: bar; は確実にプロパティである。 将来の CSS プロパティがその値に {} ブロックを許可するとしても、 許可される構文では {} ブロックが値全体となるよう制限され、 例えば foo: {...}; のようになる。 これは有効な規則にはならないことが保証される。 : の後に ident または関数が続かず、 疑似クラスであることを示さないためである。

これにより、宣言と規則を同じ文脈で混在させることができる: まず何かを宣言として構文解析しようとし、 それが有効な宣言にならなければ、 代わりに規則として再構文解析する。 誤って無効になった宣言は、代わりに規則として構文解析されるが、 それで問題ない: パーサーは宣言の終端セミコロンで停止し、 それを無効な規則と見なす。 （または {} ブロックを含むプロパティの場合、 セミコロンの直前で停止し、 それでも無効な規則と見なし、 次に何かを構文解析しようとすると、 単独のセミコロンが無効として破棄される。） したがって、消費されるトークンの総量はいずれの場合も同じである。

ただし、カスタムプロパティの構文は CSSWG によって 慎重に精査されるものではない。 作者は値に {} ブロックを取るカスタムプロパティを 記述でき、 他のものと組み合わせることさえできる。 そのカスタムプロパティが無効になった場合 （例えば、不正に記述された var() 関数による場合）、 規則として再構文解析されると、 {} ブロックのところで早期に停止する。 その後、カスタムプロパティ値の残りのトークンは 新しい構成要素として構文解析され、 予期しない宣言または規則が 作成される可能性がある。

この（確かに非常に特殊な）コーナーケースを避けるため、 カスタムプロパティの構文を 修飾規則の構文から除外する。 プロパティと規則の混在を許可する文脈にいて、 何らかの理由でカスタムプロパティのように見える 規則を構文解析することになった場合、 何かを誤っており、 代わりにカスタムプロパティ全体を （終端セミコロンまで）消費する必要がある。

（プロパティを許可しない文脈にいる場合、 規則がカスタムプロパティのように見えれば 単にそれを破棄する。 これにより、--foo:hover { color: blue; } が どこでも一貫して無効となり、 存在しない終端セミコロンを探して スタイルシートの大量の部分を消費する可能性を回避する。）

それ以外の場合、input からブロックを 消費し、 その結果を child rules とする。 child rules の最初の項目が宣言のリストである場合、 それを child rules から削除し、 rule の宣言に代入する。 child rules に残っている項目のいずれかが宣言のリストである場合、 それらを、そのリストのみを子として含む ネストされた宣言規則に置き換える。 child rules を rule の子規則に代入する。

rule が現在の文脈で有効であれば、 それを返す。 それ以外の場合は無効な規則エラーを返す。

テスト

• invalid-nested-rules.html （ライブ テスト） （ソース）

その他

input からコンポーネント値を消費する。 その結果を rule の前置部に追加する。

5.5.4. ブロックを消費する

トークンストリーム input からブロックを消費するには:

表明: 次のトークン は<{-token>である。

input からトークンを破棄する。 input からブロックの 内容を消費する。 その結果を rules とする。 input からトークンを破棄する。

rules を返す。

5.5.5. ブロックの内容を消費する

トークンストリーム input からブロックの 内容を消費するには:

注: このアルゴリズムは、 規則および宣言のリストから成るリストを返す。 親の文脈に応じて、 宣言のリストは、 CSSOM で、 CSSStyleDeclaration または CSSNestedDeclarations 規則のいずれかとして具現化されることがある。

rules を空のリストとし、 規則 または宣言のリストのいずれかを含むものとする。

decls を宣言の空のリストとする。

input を処理する:

<whitespace-token>

<semicolon-token>

input からトークンを破棄する。

<EOF-token>

<}-token>

rules を返す。

<at-keyword-token>

decls が空でない場合、 それを rules に追加し、 decls を宣言の新しい空のリストに設定する。

input からat 規則を消費し、 nested を true に設定する。 規則が返された場合、 それを rules に追加する。

その他

input をマークする。

input から宣言を 消費し、 nested を true に設定する。 宣言が 返された場合、 それを decls に追加し、 input からマークを破棄する。

それ以外の場合、input からマークを復元し、 次に input から修飾規則を消費し、 nested を true に設定し、 <semicolon-token>を stop token とする。

何も返されなかった場合

何もしない

無効な規則エラーが返された場合

decls が空でない場合、 decls を rules に追加し、 decls を宣言の新しい空のリストに設定する。 （それ以外の場合は何もしない。）

規則が 返された場合

decls が空でない場合、 decls を rules に追加し、 decls を宣言の新しい空のリストに設定する。 規則を rules に追加する。

5.5.6. 宣言を消費する

任意の bool nested（デフォルトは false）が与えられたとき、 トークンストリーム input から宣言を 消費するには:

decl を新しい宣言とし、 名前は初期状態では空で、 値は空のリストに設定する。

1. 次のトークンが<ident-token>である場合、 input からトークンを消費し、 decl の名前を そのトークンの値に設定する。

   それ以外の場合、 input から不正な 宣言の残りを消費し、 nested を使用し、 何も返さない。

2. input から空白を破棄する。
3. 次のトークンが<colon-token>である場合、 input からトークンを破棄する。

   それ以外の場合、 input から不正な 宣言の残りを消費し、 nested を使用し、 何も返さない。

4. input から空白を破棄する。
5. nested を使用し、 <semicolon-token>を停止トークンとして、 input からコンポーネント値のリストを消費し、 その結果を decl の値に設定する。
6. decl の値にある最後の 2 つの非<whitespace-token>が、 値が "!" の<delim-token>と、 その後に続く、値が "important" とASCII 大文字・小文字を区別せず一致する<ident-token>である場合、 それらを decl の値から削除し、 decl の important フラグを設定する。
7. decl の値の最後の項目が<whitespace-token>である間、 そのトークンを削除する。
8. decl の名前がカスタムプロパティ名文字列である場合、 decl の original text を、 decl の値のトークンに 対応する元のソーステキスト文字列の セグメントに設定する。

   それ以外の場合、decl の値に、関連付けられたトークンが <{-token>であるトップレベルの単純ブロック が含まれ、さらにその他の任意の非<whitespace-token>値も含まれる場合、 何も返さない。 （つまり、トップレベルの {} ブロックが許可されるのは、 非カスタムプロパティの値全体である場合だけである。）

   それ以外の場合、decl の名前が "unicode-range" とASCII 大文字・小文字を区別せず一致する場合、 コンポーネント値のリストを消費する呼び出しによって 返されたトークンに 対応する元のソーステキスト文字列のセグメントから unicode-range 記述子の 値を消費し、 decl の値をその結果で置き換える。

   テスト

   • var-with-blocks.html （ライブ テスト） （ソース）
9. decl が現在の文脈で有効であれば、 それを返す。 それ以外の場合は何も返さない。

5.5.7. コンポーネント値のリストを消費する

任意のトークン stop token および任意の boolean nested（デフォルトは false）が与えられたとき、 トークンストリーム input からコンポーネント値の リストを消費するには:

values をコンポーネント値の空のリストとする。

input を処理する:

<eof-token>

stop token（渡された場合）

values を返す。

<}-token>

nested が true の場合、 values を返す。

それ以外の場合、 これは構文解析エラーである。 input からトークンを消費し、 その結果を values に追加する。

その他

input からコンポーネント値を消費し、 その結果を values に追加する。

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

トークンストリーム input からコンポーネント 値を消費するには:

input を処理する:

<{-token>

<[-token>

<(-token>

input から単純 ブロックを消費し、 その結果を返す。

<function-token>

input から関数を 消費し、 その結果を返す。

その他

input からトークンを消費し、 その結果を返す。

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

トークンストリーム input から単純 ブロックを消費するには:

表明: input の次のトークンは、 <{-token>、 <[-token>、 または<(-token>である。

ending token を次のトークンの対になる変種とする。 （例えば、<[-token>を指定して呼び出された場合、 ending token は<]-token>である。）

block を新しい単純 ブロックとし、 関連付けられたトークンを次のトークンに設定し、 値を初期状態では空のリストに設定する。

input からトークンを破棄する。

input を処理する:

<eof-token>

ending token

input からトークンを破棄する。 block を返す。

その他

input からコンポーネント値を消費し、 その結果を block の値に追加する。

5.5.10. 関数を消費する

トークンストリーム input から関数を 消費するには:

表明: 次のトークンは<function-token>である。

input からトークンを消費し、 function を、名前が返されたトークンの値と等しい新しい関数とし、 値を空のリストに設定する。

input を処理する:

<eof-token>

<)-token>

input からトークンを破棄する。 function を返す。

その他

input からコンポーネント値を消費し、 その結果を function の値に追加する。

5.5.11. unicode-range 値を消費する

文字列 input string からunicode-range 記述子の値を消費するには:

1. tokens を、unicode ranges allowed を true に設定して input string をトークン化した結果とする。

2. tokens からコンポーネント値のリストを消費し、 その結果を返す。

注: このアルゴリズムが存在するのは、 初期の CSS における設計上の誤りによるものである。 決して再現すべきではない。

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 番目ごとの要素が選択される。 この場合、 A 部分がすでに省略されていない限り、 +B（または -B）部分を省略できる。

2n+0   /* リスト内の偶数番目の各要素を表す */
2n     /* 同じ */

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

3n-6

3n + -6

An と B の両方が存在する場合、それらを区切る+ または - の いずれの側にも空白が許可される。

3n + 1
+3n - 2
-n+ 6
+6

3 n
+ 2n
+ 2

6.2. <a-n-plus-b> 型

An+B 表記は元々、CSS の他の部分とはわずかに異なるトークナイザーを使用して定義されており、 CSS、 そのため CSS トークンの観点から表現すると、やや奇妙な定義になる。 この節では、CSS トークンの観点から An+B 表記を認識する方法 （したがって、CSS 文法の目的で <a-n-plus-b> 型を定義する）、 および A と B の値を得るために CSS トークンを解釈する方法を説明する。

<a-n-plus-b> 型は、 （Values & Units 仕様の値定義構文を使用して） 次のように定義される:

<a-n-plus-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> は、type フラグが "integer" に設定された<dimension-token>であり、 単位が "n" とASCII 大文字・小文字を区別せず一致する
• <ndash-dimension> は、type フラグが "integer" に設定された<dimension-token>であり、 単位が "n-" とASCII 大文字・小文字を区別せず一致する
• <ndashdigit-dimension> は、type フラグが "integer" に設定された<dimension-token>であり、 単位が "n-*" とASCII 大文字・小文字を区別せず一致し、ここで "*" は 1 個以上の数字の連続である
• <ndashdigit-ident> は、値が "n-*" とASCII 大文字・小文字を区別せず一致する<ident-token>であり、ここで "*" は 1 個以上の数字の連続である
• <dashndashdigit-ident> は、値が "-n-*" とASCII 大文字・小文字を区別せず一致する<ident-token>であり、ここで "*" は 1 個以上の数字の連続である
• <integer> は、type フラグが "integer" に設定された<number-token>である
• <signed-integer> は、type フラグが "integer" に設定され、かつ 符号文字を持つ<number-token>である
• <signless-integer> は、type フラグが "integer" に設定され、かつ 符号文字を持たない<number-token>である

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

生成規則の各節は次のように解釈される:

odd

A は 2、B は 1。

even

A は 2、B は 0。

<integer>

A は 0、B は整数の値。

<n-dimension>

'+'? n

-n

A は、それぞれ dimension の値、1、または -1。 B は 0。

<ndashdigit-dimension>

'+'? <ndashdigit-ident>

A は、それぞれ dimension の値または 1。 B は、それぞれ dimension の単位または ident の値であり、 最初のコードポイントを削除し、残りを 10 進数として解釈する。 B は負である。

<dashndashdigit-ident>

A は -1。 B は ident の値であり、最初の 2 つのコードポイントを削除し、 残りを 10 進数として解釈する。 B は負である。

<n-dimension> <signed-integer>

'+'? n <signed-integer>

-n <signed-integer>

A は、それぞれ dimension の値、1、または -1。 B は整数の値。

<ndash-dimension> <signless-integer>

'+'? n- <signless-integer>

-n- <signless-integer>

A は、それぞれ dimension の値、1、または -1。 B は整数値の符号を反転したもの。

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

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

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

A は、それぞれ dimension の値、1、または -1。 B は整数の値。 2 つの間に '-' が指定された場合、B は代わりに 整数値の符号を反転したものとなる。

7. 規則およびその他の値の文法の定義

CSS Values 4 § 2 値定義 構文は、プロパティおよびその他の CSS 構文構造の文法を指定する方法を定義する。

7.1. ブロック内容の定義: <block-contents>、<declaration-list>、<qualified-rule-list>、<declaration-rule-list>、および <rule-list> 生成規則

CSS パーサーはブロックの内容を区別しない—​すべて同じ アルゴリズムで構文解析され、 どの構成要素が有効かという点だけで区別される。

規則の文法を記述する際、 <block-contents> は、この区別しない構文解析を表す。 ブロック内の唯一の値としてのみ使用しなければならず、 ブロックが含められるものに暗黙の制限が 課されないことを表す。

付随する文章は、この文脈で何が有効で何が無効かを定義しなければならない。 宣言が有効であり、 かつプロパティ宣言である場合、 カスケードと相互作用するかどうかを定義しなければならない。 相互作用する場合、その詳細度と !important の使用方法を定義しなければならない。

ただし、多くの場合、 ブロックは特定の型のいかなる構成要素も有効には含められない。 これらの場合をより明示的に表すため、 次の生成規則を使用できる

• <declaration-list>: 宣言のみが 許可され、 at 規則および修飾規則は 自動的に無効となる。

• <qualified-rule-list>: 修飾 規則のみが許可され、 宣言およびat 規則は自動的に 無効となる。

• <at-rule-list>: at 規則のみが許可され、 宣言および修飾規則 は自動的に無効となる。

• <declaration-rule-list>: 宣言およびat 規則が許可され、 修飾規則は 自動的に無効となる。

• <rule-list>: 修飾規則および at 規則が許可され、 宣言は 自動的に無効となる。

これらはすべて構文解析の点では<block-contents>と完全に同等だが、 付随する文章で有効性を定義する必要があるのは、 自動的に無効とならないカテゴリについてだけである。

<@font-face> = @font-face { <declaration-list> }

<@keyframes> = @keyframes { <qualified-rule-list> }
<keyframe-rule> = <keyframe-selector> { <declaration-list> }

7.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 となり得るものすべてを表す。

8. CSS スタイルシート

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

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

8.1. スタイル規則

スタイル規則は修飾規則であり、 セレクターリストを プロパティ宣言のリスト および場合によってはネストされた規則のリストに関連付ける。 これらは、 規則集合とも[CSS2]では呼ばれる。 CSS Cascading and Inheritance [CSS-CASCADE-3]は、スタイル規則内の宣言が カスケードにどのように参加するかを定義する。

修飾規則の前置部は、 構文解析され、 <selector-list>として扱われる。 これが失敗を返した場合、 スタイル規則全体が無効となる。

修飾規則のブロックの内容は<declaration-list>として構文解析される。 このブロック内の修飾規則もスタイル規則である。 他の仕様またはこの仕様の将来のレベルで別途定義されない限り、 そのリスト内の at 規則は無効 であり、無視しなければならない。

注: [CSS-NESTING-1]は、条件付きグループ規則 およびその他の一部のat 規則が、 スタイル規則内で許可されることを定義する。

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

注: Custom Properties [CSS-VARIABLES]の名前は 大文字と小文字が区別される。

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

例えば、@media 規則 [CSS3-CONDITIONAL]内の修飾規則は スタイル規則だが、 @keyframes 規則 [CSS3-ANIMATIONS]内の修飾規則はそうではない。

8.2. at 規則

at 規則は at-keyword で始まる規則であり、 したがって同じ文脈のスタイル 規則と区別できる。

at 規則は次の目的に使用される:

• 条件付きグループ規則のように、 スタイル規則やその他の at 規則をグループ化し構造化する

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

• インポートや名前空間キーワードマッピングのような 構文構造を管理する

• また、スタイル規則では果たされないその他の雑多な目的に使用される

at 規則は、具体的な規則とその目的に応じて多くの形式を取るが、 大まかには 2 種類ある: セミコロンで終わる、より単純な構造である 文 at 規則と、 ネストされた修飾規則、at 規則、または宣言を含むことのできる{} ブロックで 終わるブロック at 規則。

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

8.3. @charset 規則

スタイルシートのフォールバックエンコーディングを決定するために使用されるアルゴリズムは、 ファイルの最初の数バイトとして特定のバイトシーケンスを探し、 それは "@charset" という名前のat 規則の構文形式を持つ。

ただし、実際には @charset という名前のat 規則は存在しない。 スタイルシートが実際に構文解析される際、 @charset 規則の出現はすべて、認識されない規則として扱わなければならず、 したがってスタイルシートの文法が確認される際に無効として破棄される。

注: CSS 2.1 では、@charset は有効な規則だった。 一部のレガシー仕様では、今でも @charset 規則を参照し、 スタイルシート内に存在することを明示的に述べている場合がある。

9. シリアル化

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

この仕様は、一般に CSS をどのようにシリアル化するかを定義せず、 その作業を[CSSOM]および個々の機能仕様に委ねる。 特に、コメントと空白のシリアル化は定義されない。

シリアル化に対する唯一の要件は、構文解析との「ラウンドトリップ」が可能でなければならないことであり、 すなわち、スタイルシートを構文解析した場合と、 構文解析、シリアル化、再度の構文解析を行った場合とで、同じデータ構造が生成されなければならない。 ただし連続する<whitespace-token>は例外で、 単一のトークンにまとめてもよい。

注: CSS 文法では、任意の量の空白を常に単一の空白と同一に解釈するため、 この例外が存在できる。

9.1. <a-n-plus-b> のシリアル化

10. プライバシーに関する考慮事項

この仕様は、新たなプライバシー上の懸念を導入しない。

11. セキュリティに関する考慮事項

この仕様では CSS の構文解析がすべての入力について曖昧さなく定義されるため、セキュリティが向上する。

ホワイトリスト／フィルターなどの古いパーサーが、この仕様とは異なる方法で構文解析する範囲において、 それらは多少安全でない。 しかし以前の構文解析仕様には、ブラウザーが異なる方法で解釈する 曖昧なコーナーケースが多数残されていたため、 それらのフィルターはすでに潜在的に安全でなく、 この仕様は状況を悪化させない。

12. 変更点

この節は非規範的である。

12.1. 2021 年 12 月 24 日の候補勧告草案からの変更点

次の実質的な変更が行われた:

• <an+b> を <a-n-plus-b> に改名 （9473）

• 重複するトークンストリームの作成を削除 （PR 11129）

• valdef 構文定義を統合

• @nest を廃止し、「ネストされた宣言規則」を導入 （10386）

• ブロック内容の構文解析を変更し、交互に現れる宣言 と規則の相対順序を維持するようにした。これらを表すため Nesting に @nest を追加 （8738）

• ブロックはプロパティの値全体としてのみ許可される （9317）

• そもそもプロパティを許可する文脈でない場合は、 貪欲な custom-prop-lookalike 動作を適用しない （9336）

• サロゲートは、CSS Object Model 操作を介して、 それを含む DOMString を直接代入することによってのみ生成できることを明確化 （PR 7997）

• 非 ASCII コードポイントの定義を、 問題を引き起こす可能性のある一部のコードポイントを除外するよう制限した。 （7129）

• <foo()> および <@foo> 生成規則を定義。 （5728）

• ネストされたスタイル規則を許可。 （7961）。

• Nesting を許可する一環として、 構文解析節全体を大幅に書き直した。 特に、「規則のリストを構文解析する」と「宣言のリストを構文解析する」を削除し、 「スタイルシートの内容を構文解析する」と「ブロックの内容を構文解析する」に置き換えた。 追加の規範的変更は、 一部の文脈でセミコロンがやや異なるエラー回復を 引き起こすようになったことだけであり、 これにより @media ブロックなどの構文解析が、 ネストされているかどうかにかかわらず同一となる。 （8834）。

• 既存のトークンを用いた <urange> 生成規則の試みを削除し、 代わりにソースからの特別な再構文解析に依存するようにした。 これは特にunicode-range 記述子を構文解析するときに行う。 （8835）

• 上記により、トークンの "representation" （構文解析元となった元の文字列）を保持する主な必要性がなくなったため、 An+B 節にある "representation" への残りの参照を削除し、 代わりに必要な少数の情報だけを記録した （数値に明示的な符号があったかどうか）。

• 一部の用途 （カスタムプロパティ、unicode-range 記述子）では、 宣言の値全体の元の文字列にアクセスする必要があることを明示的に記し、 パーサー内でそれが発生する場所を示した。

• ブロックの内容を消費する際、 他の規則に対してどこに現れるかにかかわらず すべての宣言をまとめてグループ化するのではなく、 宣言は周囲の規則に対する相対位置を維持するようになった。 その情報を実際にどう扱うかは個々の規則が決定する。

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

次の実質的な変更が行われた:

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

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

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

  input からスタイルシートを 構文解析するには、 任意のurl location が与えられたとき :

  1. ...
  2. 新しいスタイルシートを作成する 。その場所を location に設定する（location が渡されなかった場合は null）。
  3. ...

次の編集上の変更が行われた:

• § 8.2 at 規則を追加し、 at 規則、文 at 規則、ブロック at 規則、および 記述子の定義を提供した。 （5633）

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

• 場合によって「name」という用語を使用するのではなく、 一貫してident シーケンスを参照するよう変更した。

• トークン化前の複数の処理に明示的な名前を付け、 構文解析エントリーポイントでそれらを明示的に参照するようにした （「これらのアルゴリズムの先頭で X を行う」という包括的な記述に依存する代わりに）。

• 「間にコメントを入れる」表に項目を追加し、 ident が -- で始められるようになったことを正しく処理できるようにした。 （6874）

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

次の実質的な変更が行われた:

• <unicode-range-token>を削除し、代わりに <urange> 生成規則を作成した。

• 文字列を含む url() 関数は、通常の<function-token>として構文解析されるようになった。 "raw" URL を含む url() 関数は、引き続き特別に<url-token>として構文解析される。

• 「URL トークンを消費する」アルゴリズムのバグを修正した。 文字列を消費しようとする前に、文字列を開始する引用符文字を消費していなかった。

• 複数のパーサーアルゴリズムにおける、 現在／次のトークンと、早すぎる／遅すぎる消費に関するバグを修正した。

• トークン化および構文解析アルゴリズムの複数のバグを修正。

• ident-like トークンの定義を変更し、"--" で ident を開始できるようにした。 その一環として、トークンを消費するの "-" ステップにおける節の順序を変更し、 <CDC-token>が -- <ident-token>になるのではなく、そのようなものとして認識されるようにした。

• A が 1 または -1 の場合、<a-n-plus-b>内の数字をシリアル化しない。

• すべてのトークンが表現を持つことを定義。

• 2 つのコードポイントが有効な エスケープであるかを確認するにおける軽微なバグを修正—​EOF が後に続く \ は、正しく有効ではない エスケープとして報告されるようになった。 スタイルシート末尾の \ は、今では単にそれ自体を<delim-token>として出力する。

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

• 構文解析時に宣言の値の先頭／末尾から空白を除去した。

• WG 決議に従い、Selectors 固有のトークンを削除した。

• WG 決議に従い、入力ストリームからサロゲートをフィルターした。 これにより、仕様全体がスカラー値のみを扱うようになった。

次の編集上の変更が行われた:

• 「文字列トークンを消費する」アルゴリズムを、明示的な 終端トークンを指定せずに呼び出せるよう変更し、 その場合は代わりに現在のトークンを使用するようにした。 このアルゴリズムの 3 つの呼び出し箇所を、その形式を使用するよう変更した。

• アルゴリズムを軽微に編集上再構成した。

• 構文解析するおよびコンポーネント値のカンマ区切りリストを 構文解析する API エントリーポイントを追加した。

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

• "code point" および "surrogate code point" を削除し、Infra Standard の同一の定義を使用するようにした。

• すべての範囲について、両端を含むことを明確化した。

• number トークンが "%" delim トークンの隣に現れる場合を処理するため、コメント挿入表に列を追加した。

コメント処理一覧を 利用できる。

12.4. 2013 年 11 月 5 日の最終草案からの変更点

• シリアル化節を書き直し、 「ラウンドトリップ」要件だけを規範的なものとし、 それを実現する方法の詳細を注記へ移した。 これらの詳細にある一部のコーナーケースも修正した。
• [ENCODING]を 規範的参考文献の一覧に追加した。 以前から規範的文章で参照されていたが、 そのようなものとして一覧には記載されていなかっただけである。
• スタイルシートのフォールバックエンコーディングを決定するアルゴリズムで、 @charset バイトシーケンスを 1024 バイトに制限した。 これは HTML が <meta charset> に対して行うことと一致し、 シーケンスのサイズが有限になることを保証する。 これは、エンコーディングラベルに先頭または末尾の空白がある場合にのみ 違いを生じる:

  @charset "   （大量の空白）   utf-8";

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

• 環境エンコーディングの概念を追加した。 動作は変わらないが、 一部の定義は関連する仕様へ移すべきである。

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

注: この仕様の目的は現実に一致させることである。 CSS2.1 からの変更は、ほぼ常に CSS 2.1 が実際のブラウザー の動作と一致しないものを規定していたか、 何かを未規定のまま残していたことによる。 何らかの詳細がブラウザーと一致しない場合、 ほぼ確実に意図したものではないため、 知らせてほしい。

バイトストリームからの復号に関する変更:

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

トークン化の変更:

• CSS ソース内の任意の U+0000 NULL コードポイントは U+FFFD REPLACEMENT CHARACTER に置き換えられる。
• 0 と評価される \0 などの任意の 16 進エスケープシーケンスは、 U+0000 NULL ではなく U+FFFD REPLACEMENT CHARACTER を生成する。
• 非 ASCII ident コードポイントの定義を変更し、 HTML の有効なカスタム要素名と一致するようにした。
• トークン化は COMMENT または BAD_COMMENT トークンを出力しなくなった。 BAD_COMMENT は通常のトークンと同じものと見なされるようになった（エラーではない）。 シリアル化が、 分離する必要があるトークン間に必要に応じてコメントを挿入する責任を負う。 例えば、連続する 2 つの<ident-token>。
• <unicode-range-token>は、 価値が低く、場合によっては積極的に有害だったため削除された。 （例えば u+a { font-weight: bold; } は無効なセレクターだった...）

  代わりに、トークンパターンに基づく<urange> 生成規則を追加した。 技術的には 2.1 が許可していたものより緩い （任意の数の数字と ? 文字）ものだが、 実際の使用に影響するような形ではない。

• EOF エラー処理規則を トークナイザーに適用し、 EOF 時に BAD_STRING または BAD_URI ではなく、 通常の<string-token>および<url-token> を出力する。
• BAD_URI トークン（現在の <bad-url-token>）は「自己完結型」である。 言い換えると、トークナイザーが <bad-url-token> ではなく <url-token> にいることを認識すると、 閉じる ) を探して単に先へ進み、 その他すべてを無視する。 この動作は、それを <function-token> のように扱い、 開いているブロックなどに注意を払うよりも単純である。 この動作を示すのは WebKit だけだが、 これによる互換性バグは発生していないようである。
• <comma-token>が追加された。
• <number-token>、<percentage-token>、および<dimension-token>を変更し、 前置する +/- 符号をその値の一部として含むようにした （他の仕様でトークンが言及されるたびに手動で処理する必要がある別個の<delim-token>としてではなく）。 これによる唯一の結果は、符号と数値の間にコメントを挿入できなくなったことである。
• WG 決議に従い、SVG に合わせて数値／パーセンテージ／dimension で科学表記をサポートする。
• サロゲートの 16 進エスケープは、サロゲートではなく置換文字を出力するようになった。 これにより、実装は内部で UTF-16 を安全に使用できる。

構文解析の変更:

• 宣言の任意のリストが、WG 決議に従い、@pageのような at 規則も受け入れるようになった。 まだそのような at 規則が定義されていない場合でも、 これはエラー処理に違いを生じさせる: at 規則は、有効かどうかにかかわらず、<semicolon-token>なしで {} ブロックで終了し、 次の宣言を開始できるようにする。
• 文法内のさまざまな場所に現れる一部の雑多な「特別な」トークン （対応していない<}-token>など） の処理を、少なくとも 1 つのブラウザーが示す妥当な動作として規定した。 以前は、それらの場所にこうしたトークンを含むスタイルシートはスタイルシート文法に まったく一致しなかったため、 処理は完全に未定義だった。 具体的には:
  • [] ブロック、() ブロック、および関数が {} ブロック、<at-keyword-token>、または<semicolon-token>を含められるようになった
  • 修飾規則の前置部がセミコロンを含められるようになった
  • 修飾規則および at 規則の前置部が<at-keyword-token>を含められるようになった

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

• 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 に感謝する。