CSS の構文 — CSS Syntax Module Level 3

1.1. ~module間の相互作用

この~moduleは、~CSS~stylesheetの［ 構文と構文解析-法 ］を定義する。 それは，~CSS 2.1 にて定義される［ 字句走査器と文法 ］に取って代わる。 ◎ This module defines the syntax and parsing of CSS stylesheets. It supersedes the lexical scanner and grammar defined in CSS 2.1.

2.1. ~escaping

`識別子$や, 引用符で括られた文字列には、 `~escaping@ により，任意の~Unicode`符号位置$を含ませられる。 ~CSS~escape-seqは、~backslash（ `\^l ）で開始され, 次のいずれかが後続する： ◎ Any Unicode code point can be included in an identifier or quoted string by escaping it. CSS escape sequences start with a backslash (\), and continue with:

• `~hex$でも`改行$でもない，任意の［ ~Unicode`符号位置$ ］。 この~escape-seqは，その`符号位置$に置換される。 ◎ Any Unicode code point that is not a hex digits or a newline. The escape sequence is replaced by that code point.

• ［［ 1 〜 6 個の`~hex$ ］, `空白$（省略可） ］並び。 この~escape-seqは，［ その~hex並びが表す数を値とする~Unicode`符号位置$ ］に置換される。 省略可の空白は、 16 進~escape-seqの直後に “実の” ~hexを続けられるようにするためにある。 ◎ Or one to six hex digits, followed by an optional whitespace. The escape sequence is replaced by the Unicode code point whose value is given by the hexadecimal digits. This optional whitespace allow hexadecimal escape sequences to be followed by "real" hex digits.

  例えば，.値に `&B^l を伴う`識別子$は、［ `\26 B^css, あるいは `\000026B^css ］のように記すこともできる。 ◎ An identifier with the value "&B" could be written as \26 B or \000026B.

  注記： ~escape-seqの直後に “実の” ~spaceを続ける場合は，二重に記されなければならないことになる。 ◎ A "real" space after the escape sequence must be doubled.

2.2. ~errorの取扱い

~CSSにおいて~errorが生じたときには、構文解析器は，通常通り構文解析に戻る前に［ 最小限の内容のみ~~棄てて， “上品に” 回復しよう ］と試みる。 これは、~errorが必ずしも誤用によるものとは限らないからである — 新たな構文は，古い構文解析器からは~errorに見えるので、［ それを含ませた~stylesheetが，古い~UAにおいて完全に壊れる ］ことを心配せずに［ 言語に新たな構文を追加できる ］ことが有用になる。 ◎ When errors occur in CSS, the parser attempts to recover gracefully, throwing away only the minimum amount of content before returning to parsing as normal. This is because errors aren’t always mistakes—new syntax looks like an error to an old parser, and it’s useful to be able to add new syntax to the language without worrying about stylesheets that include it being completely broken in older UAs.

~error回復の精確な挙動については，構文解析器それ自身の中で 詳細が与えられているが、短い記述でも，それなりに正確aに述べれる： ◎ The precise error-recovery behavior is detailed in the parser itself, but it’s simple enough that a short description is fairly accurate.

• ~stylesheetの “~top-level” においては、 `at-keyword$tok が，`~at-rule$を開始させる。 他のものは どれも，`有修飾~規則$を開始させ、その規則の.導入部の中に含められる。 これは，無効な選択子も生産し得るが、それは ~CSS構文解析器の関知する所ではなく、最悪でも，何にも合致しない選択子になることを意味する。 ◎ At the "top level" of a stylesheet, an <at-keyword-token> starts an at-rule. Anything else starts a qualified rule, and is included in the rule’s prelude. This may produce an invalid selector, but that’s not the concern of the CSS parser—at worst, it means the selector will match nothing.

• `~at-rule$が開始されたなら、構文解析器の視点からは，何が来ようが無効ではなく、次のいずれかに遭遇するまでのすべてが，~at-ruleの.導入部の一部になる： ◎ Once an at-rule starts, nothing is invalid from the parser’s standpoint; it’s all part of the at-rule’s prelude.

  • `semicolon$tok に遭遇したときは，その~at-ruleは即時に終端される。 ◎ Encountering a <semicolon-token> ends the at-rule immediately, while＼
  • 一方で，開き波括弧 `open-curly$Tok に遭遇したときは、その~at-ruleの本体を開始させる — 本体に合致する~block（ `()^c, `{}^c, `[]^c のいずれかに挟まれた内容）が、［［ 他のものや別の~blockの内側 ］には合致されないような閉じ波括弧 `close-curly$Tok ］が見出されるまで，前方検索される。 ◎ encountering an opening curly-brace <{-token> starts the at-rule’s body. The at-rule seeks forward, matching blocks (content surrounded by (), {}, or []) until it finds a closing curly-brace <}-token> that isn’t matched by anything else or inside of another block.

  しかる後、その~at-ruleの内容が，~at-rule~自身の文法に則って解釈される。 ◎ The contents of the at-rule are then interpreted according to the at-rule’s own grammar.

• `有修飾~規則$の場合も，［ ~semicolonが，それを終端させない ］ことを除いて，同様に働く — その~semicolonは，単に規則の.導入部の一部に取り込まれる。 ［ 最初の 波括弧~block ］が見出されたなら、その内容は常に，宣言~listとして解釈される。 ◎ Qualified rules work similarly, except that semicolons don’t end them; instead, they are just taken in as part of the rule’s prelude. When the first {} block is found, the contents are always interpreted as a list of declarations.
• 宣言~listを解釈する際に，未知の構文に出くわしたときは、現在~構築中の宣言は，それが何であれ，構文解析器により~~棄てられ、次の~semicolon（あるいは~blockの終端）が見出されるまで，前方検索される。 しかる後、宣言の構文解析-がまた，新規に試行される。 ◎ When interpreting a list of declarations, unknown syntax at any point causes the parser to throw away whatever declaration it’s currently building, and seek forward until it finds a semicolon (or the end of the block). It then starts fresh, trying to parse a declaration again.
• どの［ 規則, 宣言, 関数式, 文字列, 等々 ］においても，それがまだ閉じられていないにもかかわらず，~stylesheetが終端した場合、あらゆるものが自動的に閉じられる。 これは、それらを無効にはしない。 不完全にもなり得るが、その場合は，それらの文法に照らし合わせて検証される際に~~棄てられる。 ◎ If the stylesheet ends while any rule, declaration, function, string, etc. are still open, everything is automatically closed. This doesn’t make them invalid, though they may be incomplete and thus thrown away when they are verified against their grammar.

各~構成子（宣言, ~style規則, ~at-rule）が構文解析されたなら、~UAは，期待される文法に照らし合わせて検査する。 文法に合致しない場合，それは `無効@ になり、~UAは，元からそれが無かったかのように `無視-@ することになる。 ◎ After each construct (declaration, style rule, at-rule) is parsed, the user agent checks it against its expected grammar. If it does not match the grammar, it’s invalid, and gets ignored by the UA, which treats it as if it wasn’t there at all.

3.1. 構文解析~modelの概観

~CSS構文解析への入力は、［ ~Unicode`符号位置$の~stream ］である。 それは、［ ~tokenization~段階 ］を経て［ 木の構築~段階 ］に渡される。 その出力は［ `CSSStyleSheet$I ~obj ］である。 ◎ The input to the CSS parsing process consists of a stream of Unicode code points, which is passed through a tokenization stage followed by a tree construction stage. The output is a CSSStyleSheet object.

注記： ~scriptingを~supportしない実装は、実際に~CSSOM `CSSStyleSheet^c ~objを作成しなくともよいが、そのような場合でも依然として、~CSSOM木は，この仕様の残りの部分のための~modelとして利用される。 ◎ Note: Implementations that do not support scripting do not have to actually create a CSSOM CSSStyleSheet object, but the CSSOM tree in such cases is still used as the model for the rest of the specification.

3.2. 入力~byte~stream

［ ~stylesheetの構文解析における~tokenization~段階 ］への入力を成す［ ~Unicode`符号位置$の~stream ］は、~UAにとっては，初期~時は（概して，~network越しに, またはローカルファイルシステムからの）~byteの~streamとして見えるであろう。 その場合、 ~UAは，特定0の文字~符号化法に則って，それらの~byteを元の`符号位置$並びに復号しなければならないことになる。 ◎ When parsing a stylesheet, the stream of Unicode code points that comprises the input to the tokenization stage might be initially seen by the user agent as a stream of bytes (typically coming over the network or from the local file system). If so, the user agent must decode these bytes into code points according to a particular character encoding.

~UAが~byte~streamを［ ~Unicode`符号位置$~stream ］に復号するときは、`ENCODING$r にて定義される`~Unicodeに復号する$~algoを利用し~MUST。 その~algoに渡す~fallback符号化法は、下の手続きにより決定されるものとする。 ◎ To decode the stream of bytes into a stream of code points, UAs must use the decode algorithm defined in [ENCODING], with the fallback encoding determined as follows.

注記： `~Unicodeに復号する$~algoは~BOM（ BOM ）を優先させ、見当たらなかったときに限り~fallbackを利用する。 ◎ Note: The decode algorithm gives precedence to a byte order mark (BOM), and only uses the fallback when none is found.

`~fallback符号化法を決定する@ するためには： ◎ To determine the fallback encoding:

1. ~IF［［ ~HTTPまたは それに等価な~protocol ］にて定義される［ `符号化法~label$の指定-法（例えば， Content-Type ~headerの `charset^c ~parameter） ］を通して，~labelが指定されている ］~AND［ `~labelから符号化法を取得する$( その~label ) の結果 ~NEQ `失敗^i ］ ⇒ ~RET その結果 ◎ If HTTP or equivalent protocol defines an encoding (e.g. via the charset parameter of the Content-Type header), get an encoding [ENCODING] for the specified value. If that does not return failure, use the return value as the fallback encoding.

2. ~IF［［ %stream の 【その終端を超えない】 最初の 1024 ~byteまでの部分 ］の頭部は、次の~hex列に合致する ］： ◎ Otherwise, check the byte stream. If the first 1024 bytes of the stream begin with the hex sequence

   40 63 68 61 72 73 65 74 20 22 %~label 22 3B

   ここで %~label は、各~byteが 16 進 範囲 { 0x00 〜 0x21, 0x23 〜 0x7F } に入る任意の~byte列とする。 ◎ where each XX byte is a value between 016 and 2116 inclusive or a value between 2316 and 7F16 inclusive, then get an encoding for the sequence of XX bytes, interpreted as ASCII.

   注記： この~byte列は、~ASCIIとして復号したときには，次の連結になる ⇒＃ `@charset "^l, %~label が表現する文字列, `";^l ◎ What does that byte sequence mean? ◎ The byte sequence above, when decoded as ASCII, is the string "@charset "…";", where the "…" is the sequence of bytes corresponding to the encoding’s label.

   1. %符号化法 ~LET `~labelから符号化法を取得する$( %~label を~ASCIIとして解釈して得られる文字列 ) ◎ ↑

   2. ~IF［ %符号化法 ~IN { `UTF-16BE$enc, `UTF-16LE$enc } ］ ⇒ ~RET `UTF-8$enc

      ~IF［ %符号化法 ~NEQ `失敗^i ］ ⇒ ~RET %符号化法

      ◎ If the return value was utf-16be or utf-16le, use utf-8 as the fallback encoding; if it was anything else except failure, use the return value as the fallback encoding.

      注記： 宣言が~UTF-16のときに `UTF-8$enc を利用する理由は： 符号化法~宣言の~byte列は~ASCIIとしては “@charset "…";” になるが、 ~UTF-16は~ASCII互換でない。 好ましい行いでないが，文書~内で正しい~byte列になるように暗号的なもの（ `䁣桡牳整•utf-16be∻^c など）を与えたとき、あるいは 文書が実際には~ASCII互換の符号化法でありつつ，符号化法~宣言が虚偽である場合でも、~UTF-8を既定にしておくことが，あるべき挙動になる。 ◎ Why use utf-8 when the declaration says utf-16? ◎ The bytes of the encoding declaration spell out “@charset "…";” in ASCII, but UTF-16 is not ASCII-compatible. Either you’ve typed in complete gibberish (like 䁣桡牳整•utf-16be∻) to get the right bytes in the document, which we don’t want to encourage, or your document is actually in an ASCII-compatible encoding and your encoding declaration is lying. ◎ Either way, defaulting to UTF-8 is a decent answer.

      これは、~HTMLの `meta charset^e の挙動を模倣するものでもある。 ◎ As well, this mimics the behavior of HTML’s <meta charset> attribute.

      注記： 符号化法~宣言の構文は、名前 `charset$at の`~at-rule$の構文に似ているように見えるが、そのような規則は実際には存在しない — その書き方の規則は、そのような規則を認識する通常のあり方より，ずっと制約的である。 ~CSS内で［［ ~space並び, ~comment, 一重引用符 ］などを利用して，妥当な `charset$at 規則を生産させつつ、その符号化法~宣言は認識されなくする ］ような、いくつものやり方がある。 この挙動は、符号化法~宣言をできるだけ単純なものにして，正しく実装し易くするためである。 ◎ Note: Note that the syntax of an encoding declaration looks like the syntax of an at-rule named @charset, but no such rule actually exists, and the rules for how you can write it are much more restrictive than they would normally be for recognizing such a rule. A number of things you can do in CSS that would produce a valid @charset rule (if one existed), such as using multiple spaces, comments, or single quotes, will cause the encoding declaration to not be recognized. This behavior keeps the encoding declaration as simple as possible, and thus maximizes the likelihood of it being implemented correctly.

3. ~IF［ 参照元 文書にて`環境~符号化法$が供されている ］ ⇒ ~RET それ ◎ Otherwise, if an environment encoding is provided by the referring document, use that as the fallback encoding.
4. ~RET `UTF-8$enc ◎ Otherwise, use utf-8 as the fallback encoding.

@charset "utf-8";

［ ~byte列から復号される~CSS~stylesheet ］を参照する文書~言語は、それらの各~stylesheetに対し， `環境~符号化法@ を定義しても~MAY。 それは、他の符号化法~hintを入手できない, あるいは可用でないときの，~fallbackとして利用される。 ◎ Document languages that refer to CSS stylesheets that are decoded from bytes may define an environment encoding for each such stylesheet, which is used as a fallback when other encoding hints are not available or can not be used.

`環境~符号化法$の概念は、旧来の内容との互換性のためのみにある。 新たな形式の文書や新たな~link法の仕組みは、~stylesheetの符号化法が明示的に供されない下では，既定で~UTF-8になるように、`環境~符号化法$を供するべきでない。 ◎ The concept of environment encoding only exists for compatibility with legacy content. New formats and new linking mechanisms should not provide an environment encoding, so the stylesheet defaults to UTF-8 instead in the absence of more explicit information.

注記： `HTML$r の `link rel=stylesheet^e から参照される~stylesheetの`環境~符号化法$は、その仕様にて 定義されている。 ◎ Note: [HTML] defines the environment encoding for <link rel=stylesheet>.

注記： `CSSOM$r は `<xml-stylesheet?>^c 用の環境~符号化法 を定義する。 ◎ Note: [CSSOM] defines the environment encoding for <xml-stylesheet?>.

注記： `CSS3CASCADE$r は `import$at 用の環境~符号化法を定義する。 ◎ Note: [CSS3CASCADE] defines the environment encoding for @import.

3.3. 入力~streamの前処理

`入力~stream@ は、入力~byte~streamから復号されて得られる一連の`符号位置$からなる。 ◎ The input stream consists of the code points pushed into it as the input byte stream is decoded.

実装は、入力~streamを~tokenizerに送る前に，次の`符号位置$を置換え~MUST： ◎ Before sending the input stream to the tokenizer, implementations must make the following code point substitutions:

［ `0D^U (CR), `0A^U (LF) ］並び

`0D^U (CR)

`0C^U (FF)

すべて，単独の`符号位置$［ `0A^U (LF) ］に置換する。 ◎ Replace any U+000D CARRIAGE RETURN (CR) code points, U+000C FORM FEED (FF) code points, or pairs of U+000D CARRIAGE RETURN (CR) followed by U+000A LINE FEED (LF), by a single U+000A LINE FEED (LF) code point.

【 当然ながら、［ CR LF ］並びの置換-が，同じ場所での単独の CR より優先される。 】

`00^U

すべて，［ `FFFD^U ］に置換する。 ◎ Replace any U+0000 NULL code point with U+FFFD REPLACEMENT CHARACTER (�).

4.1. ~tokenの線路図式

この節では、~tokenizerの参考~viewを線路図式の形で呈示する。 線路図式は，明示的な構文解析器より簡潔でありつつ, 大抵は正規表現よりも読み取り易い。 ◎ This section presents an informative view of the tokenizer, in the form of railroad diagrams. Railroad diagrams are more compact than an explicit parser, but often easier to read than an regular expression.

これらの図式は、参考 であって, 不完全である。 ~tokenの “正しい” 文法は述べるが、~errorの取扱いについては全く述べない。 それらはもっぱら，各種~tokenの構文を直感的に把握し易くするために供されている。 ◎ These diagrams are informative and incomplete; they describe the grammar of "correct" tokens, but do not describe error-handling at all. They are provided solely to make it easier to get an intuitive grasp of the syntax of each token.

`foo^tok の様な名前が付与されている図式は、~tokenを表現する。 他のものは，他の図式から参照される生成規則である。 ◎ Diagrams with names such as <foo-token> represent tokens. The rest are productions referred to by other diagrams.

`comment^sb（~comment）

`comment^dgm

`newline^sb（`前処理$前の改行）

`newline^dgm

`whitespace^sb（`空白$）

`whitespace^dgm

`hex digit^sb（ `~hex$ ）

`hex-digit^dgm

`escape^sb（~escape-seq）

`escape^dgm

`whitespace$tok

`whitespace-token^dgm

`ws*^sb

`whitespaces^dgm

`ident$tok

`ident-token^dgm

`function$tok

`function-token^dgm

`at-keyword$tok

`at-keyword-token^dgm

`hash$tok

`hash-token^dgm

`string$tok

`string-token^dgm

`url$tok

`url-token^dgm

`number$tok

`number-token^dgm

`dimension$tok

`dimension-token^dgm

`percentage$tok

`percentage-token^dgm

`CDO$tok

`CDO-token^dgm

`CDC$tok

`CDC-token^dgm

4.2. 定義

この節では、~tokenizationの相にて利用される，いくつかの用語を定義する。 ◎ This section defines several terms used during the tokenization phase.

【 以下の中で， ~DAGGER 印~付きの項目は、この訳による追加の定義／補完である。 】

`次入力~符号位置@

`入力~stream$の中の，未だ消費されていない`符号位置$のうちの，最初のもの。 ◎ The first code point in the input stream that has not yet been consumed.

【 “次の %n 個の入力~符号位置” と記されることもある（ %n ≤ 3 ）。 参照される範囲が~streamの末尾を越えている部分の符号位置は， ~EOF （後述）と見なされる。 】

`現入力~符号位置@

すでに消費された`符号位置$のうちの，最後のもの。 ◎ The last code point to have been consumed.

`現入力~符号位置を再消費する@

`現入力~符号位置$を`入力~stream$の先頭に戻す 【未~消費の状態に戻す】 。 すなわち、次回に`次入力~符号位置$を消費する際には，`現入力~符号位置$を再び消費することになる。 ◎ Push the current input code point back onto the front of the input stream, so that the next time you are instructed to consume the next input code point, it will instead reconsume the current input code point.

`~EOF符号位置@

`入力~stream$の終端を表現する， 【他のいかなる符号位置とも異なる】 概念的な符号位置。 `入力~stream$が空になり次第，`次入力~符号位置$は常に，~EOF 符号位置になる。 【以下、単に ~EOF と記す。】 ◎ A conceptual code point representing the end of the input stream. Whenever the input stream is empty, the next input code point is always an EOF code point.

（各種の，符号位置の範囲）

次の表の見出しの各~用語は、同じ行に示される，一定~範囲に属する`符号位置$を表す（記号 ∪ は和集合をとることを意味する）：

用語	符号位置の範囲
`数字@	{ `30^U 〜 `39^U } ◎ A code point between U+0030 DIGIT ZERO (0) and U+0039 DIGIT NINE (9).
`~hex@	`数字$ ∪ { `41^U 〜 `46^U } ∪ { `61^U 〜 `66^U } ◎ A digit, or a code point between U+0041 LATIN CAPITAL LETTER A (A) and U+0046 LATIN CAPITAL LETTER F (F), or a code point between U+0061 LATIN SMALL LETTER A (a) and U+0066 LATIN SMALL LETTER F (f).
`正負符号@ ~DAGGER	{ `2B^U, `2D^U }
`指数~指示子@ ~DAGGER	{ `45^U, `65^U }
`大文字@	{ `41^U 〜 `5A^U } ◎ A code point between U+0041 LATIN CAPITAL LETTER A (A) and U+005A LATIN CAPITAL LETTER Z (Z).
`小文字@	{ `61^U 〜 `7A^U } ◎ A code point between U+0061 LATIN SMALL LETTER A (a) and U+007A LATIN SMALL LETTER Z (z).
`英字@	`大文字$ ∪ `小文字$ ◎ An uppercase letter or a lowercase letter.
`非~ASCII符号位置@	{ `80^U 〜 `10FFFF^U } ◎ A code point with a value equal to or greater than U+0080 <control>.
`名前開始~符号位置@	`英字$ ∪ `非~ASCII符号位置$ ∪ { `5F^U } ◎ A letter, a non-ASCII code point, or U+005F LOW LINE (_).
`名前~符号位置@	`名前開始~符号位置$ ∪ `数字$ ∪ { `2D^U } ◎ A name-start code point, a digit, or U+002D HYPHEN-MINUS (-).
`印字不能~符号位置@	{ `00^U 〜 `08^U } ∪ { `0B^U } ∪ { `0E^U 〜 `1F^U } ∪ { `7F^U } ◎ A code point between U+0000 NULL and U+0008 BACKSPACE, or U+000B LINE TABULATION, or a code point between U+000E SHIFT OUT and U+001F INFORMATION SEPARATOR ONE, or U+007F DELETE.
`改行@	{ `0A^U } `0D^U および `0C^U は，この定義には含められない。 それらは`前処理$の段階で `0A^U に変換されるので。 ◎ U+000A LINE FEED. Note that U+000D CARRIAGE RETURN and U+000C FORM FEED are not included in this definition, as they are converted to U+000A LINE FEED during preprocessing.
`空白@	`改行$ ∪ { `09^U, `20^U } ◎ A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE.

`許容される最大の符号位置@

~Unicodeにて定義されている最大の`符号位置$： `10FFFF^U 。 ◎ The greatest code point defined by Unicode: U+10FFFF.

`識別子@

`ident$tok と同じ構文を持つ，~CSS~sourceの部位。 次に挙げるものの中にも現れる：

• `at-keyword$tok
• `function$tok
• `hash$tok のうち［ .型~flag ~EQ `id^i ］なるもの
• `dimension$tok の.単位

◎ A portion of the CSS source that has the same syntax as an <ident-token>. Also appears in <at-keyword-token>, <function-token>, <hash-token> with the "id" type flag, and the unit of <dimension-token>.

`表現@

~tokenの`表現$は、［ それを生産した，`~tokenを消費$する~algo ］により消費された，`入力~stream$の部分列である。 これは、［ ~tokenの単純な “再~直列化” により妨害され得る ］ような［ 入力~textの微妙な詳細に依拠する，少数の~algo ］用に保全される。 ◎ The representation of a token is the subsequence of the input stream consumed by the invocation of the consume a token algorithm that produced it. This is preserved for a few algorithms that rely on subtle details of the input text, which a simple "re-serialization" of the tokens might disturb.

`表現$は、内部~algoのみに消費され，直に公開されることは決してないので、実際に正確な~textを保全することは要求されない — 各~tokenを~source~textの中の~offsetに結付けるなどの，等価な手法でも足りる。 ◎ The representation is only consumed by internal algorithms, and never directly exposed, so it’s not actually required to preserve the exact text; equivalent methods, such as associating each token with offsets into the source text, also suffice.

注記： 特に，`表現$は、例えば次のような詳細を保全する：

• `.009^v は［ `.009^c ／ `9e-3^c ］のどちらで記されたか — これは， `urange$t 生成規則を適正に構文解析するために必要とされる。
• ある文字は［ ~literalに, あるいは ~CSS~escapeとして ］のどちらで記されたか — これは基本的に，~tokenize法の抽象化に~~本質的でない漏洩になるが、実装を定義し易くなるので許容される。

◎ Note: In particular, the representation preserves details such as whether .009 was written as .009 or 9e-3, and whether a character was written literally or as a CSS escape. The former is necessary to properly parse <urange> productions; the latter is basically an accidental leak of the tokenizing abstraction, but allowed because it makes the impl easier to define.

ある~tokenが，［ この仕様における~tokenization~algoを通さずに，ある~algoにより直に生産されたもの ］である場合、その表現は空~文字列になる。 ◎ If a token is ever produced by an algorithm directly, rather than thru the tokenization algorithm in this specification, its representation is the empty string.

“〜の符号位置を消費” ~DAGGER

~streamの先頭から，“〜” に記された部分の符号位置を取り去った上で、取り去られた最後の符号位置を，現入力~符号位置にアテがうことを意味する（言い換えれば、現入力~符号位置を指している~pointerを， “〜” に記された部分の最後の符号位置を指すように移動させる）。 “消費” が現れる所では、常にそのような副作用が伴われる。 “〜の符号位置を消費した結果” と記されたときは，消費された（取り去られた）符号位置~並びによる文字列を表す。

“~streamから`次入力~符号位置を繰り返し消費する@：” ~DAGGER

次を繰り返し実行することを意味する：

1. `次入力~符号位置$を消費する
2. `現入力~符号位置$に応じて、［ 後続の~blockに記された，対応する段 ］を実行する

繰り返しは，値が返された時点で終了する。

4.3. ~tokenizer~algo

この節にて定義される一連の~algoは、［ `符号位置$の~stream ］を［ ~tokenの~stream ］へ形式変換する。 ◎ The algorithms defined in this section transform a stream of code points into a stream of tokens.

5.1. 構文解析器の線路図式

この節は、構文解析器の参考~viewを，線路図式の形で呈示する。 ◎ This section presents an informative view of the parser, in the form of railroad diagrams.

これらの図式は、参考 であって, 不完全である。 ~stylesheetの “正しい” 文法は述べるが、~errorの取扱いについては全く述べない。 それらはもっぱら，構文を直感的に把握し易くするために供されている。 ◎ These diagrams are informative and incomplete; they describe the grammar of "correct" stylesheets, but do not describe error-handling at all. They are provided solely to make it easier to get an intuitive grasp of the syntax.

`Stylesheet^sb（~stylesheet）

`stylesheet^dgm

`Rule list^sb（`規則~list$）

`rule-list^dgm

`At-rule^sb（`~at-rule$）

`at-rule^dgm

`Qualified rule^sb（`有修飾~規則$）

`qualified-rule^dgm

`Declaration list^sb（`宣言~list$）

`declaration-list^dgm

`Declaration^sb（`宣言$）

`declaration^dgm

~important

`important^dgm

`Component value^sb（`成分値$）

`component-value^dgm

`{} block^sb（`波括弧~block$）

`curly-block^dgm

`() block^sb（`丸括弧~block$）

`paren-block^dgm

`[] block^sb（`角括弧~block$）

`square-block^dgm

`Function block^sb（`関数式$）

`function-block^dgm

5.2. 定義

`現入力~token@

［ ~tokenizerにより生産される~token~list ］からの，現在~操作されている［ ~tokenまたは`成分値$ ］ ◎ The token or component value currently being operated on, from the list of tokens produced by the tokenizer.

`次入力~token@

~tokenizerにより生産される~token~listの中の， `現入力~token$に直後に続く［ ~tokenまたは`成分値$ ］。 そのようなものが無い場合の`次入力~token$は `EOF$tok とする。 ◎ The token or component value following the current input token in the list of tokens produced by the tokenizer. If there isn’t a token following the current input token, the next input token is an <EOF-token>.

`EOF@tok

~token~listの終端を表現する概念的な~token。 ~token~listが空になったときの`次入力~token$は、常に， `EOF$tok である。 ◎ A conceptual token representing the end of the list of tokens. Whenever the list of tokens is empty, the next input token is always an <EOF-token>.

`次入力~tokenを消費@する

［ 現在の`次入力~token$ ］を`現入力~token$にする。 それに伴い，`次入力~token$もその次のものを指すようになる。 ◎ Let the current input token be the current next input token, adjusting the next input token accordingly.

`現入力~tokenを再消費@する

次回の［ `次入力~tokenを消費$する ］の挙動を，何もしない様に変える（`現入力~token$を不変に保たせる）。 ◎ The next time an algorithm instructs you to consume the next input token, instead do nothing (retain the current input token unchanged).

“`次入力~tokenを繰り返し消費する@：” 【この項目はこの訳による補完】

次を繰り返し実行することを意味する：

1. `次入力~tokenを消費$する
2. 消費された~token（すなわち，`現入力~token$）に応じて、［ 後続の~blockに記された，対応する段 ］を実行する

繰り返しは，値が返された時点で終了する。

5.3. 構文解析器の入口

この節にて定義される一連の~algoは、より低次の~objから，より高次の~CSS~objを生産する。 それらは，~token~streamに対し呼出されるものと見做しているが、文字列に対しても呼出され得る — この場合、事前に，`入力の前処理$を遂行して`符号位置$~streamを生産した上で、`~tokenization$を行って~token~streamを生産しておく。 ◎ The algorithms defined in this section produce high-level CSS objects from lower-level objects. They assume that they are invoked on a token stream, but they may also be invoked on a string; if so, first perform input preprocessing to produce a code point stream, then perform tokenization to produce a token stream.

“`~stylesheetを構文解析-$” は、~byte~streamに対しても呼出され得る。 この場合、`入力~byte~stream$が，それを~Unicodeに復号する方法を定義する。 ◎ "Parse a stylesheet" can also be invoked on a byte stream, in which case The input byte stream defines how to decode it into Unicode.

注記： この仕様は、他の入口については，~byte~streamを復号する方法は定義しない。 ◎ Note: This specification does not define how a byte stream is decoded for other entry points.

注記： 他の仕様は、追加の入口を 自身の目的に定義できる。 ◎ Note: Other specs can define additional entry points for their own purposes.

この仕様にて定義される すべての~algoは、［ ~token~list ／`成分値$~list ］の，いずれかを伴って呼ばれ得る。 いずれにせよ，一致する結果を生産する。 ◎ All of the algorithms defined in this spec may be called with either a list of tokens or of component values. Either way produces an identical result.

5.4. 構文解析器~algo

構文解析器は、この節に挙げる一連の~algoからなる。 これらは、上述の各種［ 構文解析器の入口 ］から呼ばれる。 ◎ The following algorithms comprise the parser. They are called by the parser entry points above.

これらの~algoは，［ ~token~list, 成分値~list ］のいずれかを伴って呼ばれ得る。 （`成分値$~listにおいては，一部の~tokenが［ `関数式$や`単純~block$ ］に置換される点で異なる）。 ~tokenization~段階において，入力~streamから［ それが空であることを表現する~EOF符号位置が返される ］のと同様に、この段階における~listでは、次の~tokenが要請されたにもかかわらず，それが空であるときは、 `EOF$tok を返さ~MUST。 ◎ These algorithms may be called with a list of either tokens or of component values. (The difference being that some tokens are replaced by functions and simple blocks in a list of component values.) Similar to how the input stream returned EOF code points to represent when it was empty during the tokenization stage, the lists in this stage must return an <EOF-token> when the next token is requested but they are empty.

~algoは，特定の~listを伴って呼出され得る — この場合、その~listのみを消費する（その~listが枯渇したときは，`EOF$tok を返すようになる）。 他の場合、暗黙的に，呼出している~algoのものと同じ~listを伴って呼出される。 ◎ An algorithm may be invoked with a specific list, in which case it consumes only that list (and when that list is exhausted, it begins returning <EOF-token>s). Otherwise, it is implicitly invoked with the same list as the invoking algorithm.

6.1. 構文（参考）

%A が 0 のときは、 ~An 部分が省略されてもよい（ %B 部分がすでに省略されていない限り）。 ~An が省略されている場合、負でない %B の前の `+^c 符号も省略されてよい — この場合の構文は，単に %B に単純化される。 ◎ When A is 0, the An part may be omitted (unless the B part is already omitted). When An is not included and B is non-negative, the + sign before B (when allowed) may also be omitted. In this case the syntax simplifies to just B.

0n+5   /* ~listの中の 5 個目の要素を表現する
◎
represents the 5th element in the list */
5      /* 同じ
◎
same */

%A が ±1 の場合の `1^c は規則から省略されてよい。 ◎ When A is 1 or -1, the 1 may be omitted from the rule.

1n+0   /* ~listの中のすべての要素を表現する
◎
represents all elements in the list */
n+0    /* 同じ
◎
same */
n      /* 同じ
◎
same */

%B が 0 の場合、毎 %A 個目の要素が選ばれる。 このような場合、（ %A 部分がすでに省略されていない限り，） 正負符号と %B の部分は省略されてよい。 ◎ If B is 0, then every Ath element is picked. In such a case, the +B (or -B) part may be omitted unless the A part is already omitted.

2n+0   /* ~listの中の毎~偶数個目の要素を表現する
◎
represents every even element in the list */
2n     /* 同じ
◎
same */

B が負の場合、正符号は負符号に置換する。 ◎ When B is negative, its minus sign replaces the + sign.

3n-6

3n + -6

~An, %B 両者とも在るときは、それらを区切る正負符号の前後には，空白も許可される。 ◎ Whitespace is permitted on either side of the + or - that separates the An and B parts when both are present.

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

3 n
+ 2n
+ 2

6.2. ~anb 型

~AnB 記法は、元々は，~CSSの他のものと少しばかり異なる~tokenizerを利用して定義されており、その結果，~CSS~tokenの用語で表す際に，いくぶん不規則な定義になる。 この節では、~CSS~tokenの用語を通して ~AnB 記法を認識する方法（従って， ~CSS文法~目的の ~anb 型を定義することになる），および［ %A, %B ］に対する値を得るために，これらの~CSS~tokenを解釈する方法を述べる。 ◎ The An+B notation was originally defined using a slightly different tokenizer than the rest of CSS, resulting in a somewhat odd definition when expressed in terms of CSS tokens. This section describes how to recognize the An+B notation in terms of CSS tokens (thus defining the <an+b> type for CSS grammar purposes), and how to interpret the CSS tokens to obtain values for A and B.

~anb 型は（ `CSS-VALUES$r 仕様の`値定義構文$を利用して）次の様に定義される： ◎ The <an+b> type is defined (using the Value Definition Syntax in the Values & Units spec) as:

`~anb@
  = odd
  | even
  | `integer$t

  | `n-dimension$t
  | '+'?~nB n
  | -n

  | `ndashdigit-dimension$t
  | '+'?~nB `ndashdigit-ident$t
  | `dashndashdigit-ident$t

  | `n-dimension$t `signed-integer$t
  | '+'?~nB n `signed-integer$t
  | -n `signed-integer$t

  | `ndash-dimension$t `signless-integer$t
  | '+'?~nB n- `signless-integer$t
  | -n- `signless-integer$t

  | `n-dimension$t ['+' | '-'] `signless-integer$t
  | '+'?~nB n ['+' | '-'] `signless-integer$t
  | -n ['+' | '-'] `signless-integer$t

上に現れ, 下の表の 1 列目に記される各種~生成規則は、［ 同じ行の 2 列目の~token ］であって, その各種~~属性が［ 同じ行の 3 列目に記された条件 ］を満たすものである： ◎ where:

表の中の `数字~列@ は、`数字$のみからなる，長さ 1 以上の任意の連なりを表す。

上の ~DAGGER 印が付与されている所の様に，［ 正符号 (`+^c) ］が［ `n^l から開始されている `ident^tok ］に先行するときは，その 2 個の~tokenの合間に空白が在っては~MUST_NOT。 さもなければ，それらの~tokenは上の文法に合致しないとする。 他の~tokenの合間の空白は妥当である（無視される）。 ◎ †: When a plus sign (+) precedes an ident starting with "n", as in the cases marked above, there must be no whitespace between the two tokens, or else the tokens do not match the above grammar. Whitespace is valid (and ignored) between any other two tokens.

各~選択肢の~生成規則（~top-levelの "|" で分割された各~項）は、次の様に解釈される： ◎ The clauses of the production are interpreted as follows:

7.1. `urange^t 型

`urange$t 記法は 元々，~CSSでは~primitive~tokenとして定義されていたが、ごく稀にしか利用されず，合法的な `ident$tok と衝突して混同され易い。 この節では、 `urange$t 記法を［ 既存の~CSS~tokenを通して認識する, および ~Unicode符号位置の範囲として解釈する ］ための方法を述べる。 ◎ The <urange> notation was originally defined as a primitive token in CSS, but it is used very rarely, and collides with legitimate <ident-token>s in confusing ways. This section describes how to recognize the <urange> notation in terms of existing CSS tokens, and how to interpret it as a range of unicode codepoints.

注記： ここに述べる構文は、意図的にごく低次であり，実装者~向けである。 作者には、 `urange$t を利用するために必要な情報すべてが含まれた，前節の構文の記述で十分である。 ◎ Note: The syntax described here is intentionally very low-level, and geared toward implementors. Authors should instead read the informal syntax description in the previous section, as it contains all information necessary to use <urange>, and is actually readable.

`urange$t 型は（ `CSS-VALUES$r 仕様の`値定義構文$を利用して），次の様に定義される。 ◎ The <urange> type is defined (using the Value Definition Syntax in the Values & Units spec) as:

`urange@t
  = u '+' `ident$tok '?'*
  | u `dimension$tok '?'*
  | u `number$tok '?'*
  | u `number$tok `dimension$tok
  | u `number$tok `number$tok
  | u '+' '?'+

この生成規則では、どの2つの~tokenの間にも空白は生じ得ない。 ◎ In this production, no whitespace can occur between any of the tokens.

`urange$t 生成規則は、連続的な~Unicode符号位置の範囲 { %始値 〜 %終値 } を表現する。 `urange$t 生成規則を範囲に解釈するときは、まず，次を実行した結果を得る： ◎ The <urange> production represents a range of one or more contiguous unicode code points as a start value and an end value, which are non-negative integers. To interpret the production above into a range, execute the following steps in order:

1. %text ~LET 生成規則~内の［ 最初の `u^c ~tokenを除くすべての~token ］の`表現$を連結した結果 ◎ Skipping the first u token, concatenate the representations of all the tokens in the production together. Let this be text.
2. ~IF［ %text の最初の`符号位置$を消費した結果 ~NEQ `2B^U ］ ⇒ ~RET 無効（すなわち， `urange$t は無効である — 以下~同様） ◎ If the first character of text is U+002B PLUS SIGN, consume it. Otherwise, this is an invalid <urange>, and this algorithm must exit.
3. %N ~LET %text から，できるだけ多くの`~hex$を消費してから，できるだけ多くの`符号位置$ `3F^U を消費した結果 ◎ Consume as many hex digits from text as possible. then consume as many U+003F QUESTION MARK (?) code points as possible.＼
4. ~IF［ %N の長さ ~EQ 0 ］~OR［ %N の長さ ~GT 6 ］ ⇒ ~RET 無効 ◎ If zero code points were consumed, or more than six code points were consumed, this is an invalid <urange>, and this algorithm must exit.

5. ~IF［ %N 内に `3F^U `符号位置$がある ］： ◎ If any U+003F QUESTION MARK (?) code points were consumed, then:

   1. ~IF［ %text は消費され尽くされてない ］ ⇒ ~RET 無効 ◎ If there are any code points left in text, this is an invalid <urange>, and this algorithm must exit.
   2. %始値 ~SET ［ %N 内の各 `3F^U を `30^U に置換した結果 ］を 16 進数として解釈した結果 ◎ Interpret the consumed code points as a hexadecimal number, with the U+003F QUESTION MARK (?) code points replaced by U+0030 DIGIT ZERO (0) code points. This is the start value.
   3. %終値 ~SET ［ %N 内の各 `3F^U を `46^U に置換した結果 ］を 16 進数として解釈した結果 ◎ Interpret the consumed code points as a hexadecimal number again, with the U+003F QUESTION MARK (?) code points replaced by U+0046 LATIN CAPITAL LETTER F (F) code points. This is the end value.
   4. ~RET 範囲 { %始値 〜 %終値 } ◎ Exit this algorithm.
6. %始値 ~SET %N を 16 進数として解釈した結果 ◎ Otherwise, interpret the consumed code points as a hexadecimal number. This is the start value.
7. ~IF［ %text は消費され尽くした ］ ⇒ ~RET 範囲 { %始値 〜 %始値 } ◎ If there are no code points left in text, The end value is the same as the start value. Exit this algorithm.
8. ~IF［ %text の次の`符号位置$を消費した結果 ~NEQ `2D^U ］ ⇒ ~RET 無効 ◎ If the next code point in text is U+002D HYPHEN-MINUS (-), consume it. Otherwise, this is an invalid <urange>, and this algorithm must exit.
9. %N ~LET %text から，できるだけ多くの`~hex$を消費した結果 ◎ Consume as many hex digits as possible from text.
10. ~IF［ %N の長さ ~EQ 0 ］~OR［ %N の長さ ~GT 6 ］~OR［ %text は消費され尽くされてない ］ ⇒ ~RET 無効 ◎ If zero hex digits were consumed, or more than 6 hex digits were consumed, this is an invalid <urange>, and this algorithm must exit. If there are any code points left in text, this is an invalid <urange>, and this algorithm must exit.
11. %終値 ~SET %N を 16 進数として解釈した結果 ◎ Interpret the consumed code points as a hexadecimal number. This is the end value.
12. ~RET 範囲 { %始値 〜 %終値 } ◎ ↑

上の結果の範囲 { %始値 〜 %終値 } において，［ %終値 ~GT `許容される最大の符号位置$ ］~OR［ %始値 ~GT %終値 ］ならば、 `urange$t は無効であり，構文~errorとする。 ◎ To determine what codepoints the <urange> represents: ◎ If end value is greater than the maximum allowed code point, the <urange> is invalid and a syntax error. ◎ If start value is greater than end value, the <urange> is invalid and a syntax error. ◎ Otherwise, the <urange> represents a contiguous range of codepoints from start value to end value, inclusive.

注記： `urange$t の構文は、その~patternが，前節の構文（参考）が生成し得るすべての~token並びを捉える以上に，意図的に幅広くしてある。 ただし，各~tokenの合間には空白を挟めないので、実用上は相応に安全に利用できる： ある構成子の文法が［ `urange$t, ［ `number$t ／ `dimension$t ］］並びを含むとしても（作者が `urange$t を［ `u^c, `number$t ］並びで指定した場合に多義的になり得る）、実際にはごく安全である — 多義的になるためには、作者が `urange$t と［ `number$t ／ `dimension$t ］を，空白ではなく，~commentで意図的に区切る必要があるので。 作者は，構文解析を惑わす仕方でも書けるが、そのためには実際のコード自体も紛らわしく書く必要がある。 ◎ Note: The syntax of <urange> is intentionally fairly wide; its patterns capture every possible token sequence that the informal syntax can generate. However, it requires no whitespace between its constituent tokens, which renders it fairly safe to use in practice. Even grammars which have a <urange> followed by a <number> or <dimension> (which might appear to be ambiguous if an author specifies the <urange> with the ''u <number>'' clause) are actually quite safe, as an author would have to intentionally separate the <urange> and the <number>/<dimension> with a comment rather than whitespace for it to be ambiguous. Thus, while it’s possible for authors to write things that are parsed in confusing ways, the actual code they’d have to write to cause the confusion is, itself, confusing and rare.

8.1. ~block内容を定義する生成規則： `declaration-list^t, `rule-list^t, `stylesheet^t

~CSS構文解析器は、~blockの内容に非依存である — 例えば何らかの~at-ruleの終端に来るものなど。 ~blockの汎用~文法を~tokenの用語を通して定義することは，自明でないが、それを構文解析するために定義される，一義的な専用の~algoが用意されている： ◎ The CSS parser is agnostic as to the contents of blocks, such as those that come at the end of some at-rules. Defining the generic grammar of the blocks in terms of tokens is non-trivial, but there are dedicated and unambiguous algorithms defined for parsing this.

`declaration-list@t 生成規則は、宣言~listを表現する。 文法において それを利用し得るのは、［ ~blockの全体を占める値 ］としてに限られる。 それは、［ ~blockの内容は、`宣言~listを消費$する~algoを利用して構文解析され~MUST ］ことを表現する。 ◎ The <declaration-list> production represents a list of declarations. It may only be used in grammars as the sole value in a block, and represents that the contents of the block must be parsed using the consume a list of declarations algorithm.

同様に， `rule-list@t 生成規則は、規則~listを表現する。 文法において それを利用し得るのは、［ ~blockの全体を占める値 ］としてに限られる。 それは、［ ~blockの内容は、`規則~listを消費$する~algoを利用して構文解析され~MUST ］ことを表現する。 ◎ Similarly, the <rule-list> production represents a list of rules, and may only be used in grammars as the sole value in a block. It represents that the contents of the block must be parsed using the consume a list of rules algorithm.

最後に， `stylesheet@t 生成規則は、規則~listを表現する。 それは、それを利用している~blockが［ 特定0の文脈に制限されるようなものを除く，すべての規則 ］を既定で受容することを除いて、 `rule-list$t と一致する。 ◎ Finally, the <stylesheet> production represents a list of rules. It is identical to <rule-list>, except that blocks using it default to accepting all rules that aren’t otherwise limited to a particular context.

@font-face { `declaration-list$t }

@keyframes `keyframes-name$t { `rule-list$t }

`declaration-list$t を利用する規則に対しては、その規則を定める仕様は，規則の内側において どの［ ~prop ／記述子／~at-rule ］が妥当であるかを定義し~MUST — これは，単純に、 “`foo^at 規則 は，この仕様（または節）にて定義される ~propと記述子 を受容する” といった風に、あるいは，拡張~仕様は， “`foo^at 規則は，追加で以下の~prop／記述子を受容する” といった風に述べ得る。 ~blockの内側にて見出された，妥当なものとして定義されていない，どの宣言／~at-ruleも、その規則の値から除去され~MUST。 ◎ For rules that use <declaration-list>, the spec for the rule must define which properties, descriptors, and/or at-rules are valid inside the rule; this may be as simple as saying "The @foo rule accepts the properties/descriptors defined in this specification/section.", and extension specs may simply say "The @foo rule additionally accepts the following properties/descriptors.". Any declarations or at-rules found inside the block that are not defined as valid must be removed from the rule’s value.

`declaration-list$t 内では、どの記述子であれ，その~importantは自動的に無効になる。 ある規則がある~propを受容する場合、その規則を定める仕様は，［ その~propが~cascadeと相互作用し得るかどうか, および どの`詳細度$で相互作用するか ］を定義し~MUST。 ~cascadeと相互作用しない~propが~importantを包含している場合、自動的に無効になる。 他の~propにおける~importantは，妥当であり、その~propの~cascadeの`出自$に対し，通例の効果を持つ。 ◎ Within a <declaration-list>, !important is automatically invalid on any descriptors. If the rule accepts properties, the spec for the rule must define whether the properties interact with the cascade, and with what specificity. If they don’t interact with the cascade, properties containing !important are automatically invalid; otherwise using !important is valid and has its usual effect on the cascade origin of the property.

例えば，前の例の `font-face$at 用の文法は、そこに記されたものに加えて，［ 許容される宣言は， Fonts 仕様にて定義される記述子である ］ものと定義し~MUST。 ◎ For example, the grammar for @font-face in the previous example must, in addition to what is written there, define that the allowed declarations are the descriptors defined in the Fonts spec.

`rule-list$t を利用する %規則 においても、 `declaration-list$t のときと同様に，その %規則 を定める仕様が，［ どの型の規則が，その %規則 の中で妥当になるか ］を定義し~MUST。 同様に、認識されない規則は，その %規則 の値から除去され~MUST。 ◎ For rules that use <rule-list>, the spec for the rule must define what types of rules are valid inside the rule, same as <declaration-list>, and unrecognized rules must similarly be removed from the rule’s value.

`keyframe-rule^t = `keyframe-selector$t { `declaration-list$t }

`stylesheet$t を利用する %規則 においては，すべての規則が既定で許容されるが、その %規則 を定める仕様は，その %規則 の内側では 無効になる 規則を定義して~MAY。 ◎ For rules that use <stylesheet>, all rules are allowed by default, but the spec for the rule may define what types of rules are invalid inside the rule.

@media `media-query-list$t { `stylesheet$t }

8.2. 任意の内容を定義するもの： `declaration-value^t, `any-value^t 生成規則

文法によっては、ある~~程度までの入力を受容して，その~errorを（単純に，文法への不一致により構成子を即 無効にする方式をとるのでなく，）~~特別に取扱う方が有用になる場合もある。 ◎ In some grammars, it is useful to accept any reasonable input in the grammar, and do more specific error-handling on the contents manually (rather than simply invalidating the construct, as grammar mismatches tend to do).

例えば，`~custom~prop$は、［ 他の~CSS~propがとる値の成分も包含し得る ］ような, あるいは［ 既存の~CSSに全く含まれないものに利用される ］ような，ある~~程度の値を許容する。 他の例として、 Media Queries の `general-enclosed$t 生成規則は、将来の Media Queries 構文が許容し得るものを定義して， “未知の” 値を特別な~~規則で~~扱う。 ◎ For example, custom properties allow any reasonable value, as they can contain arbitrary pieces of other CSS properties, or be used for things that aren’t part of existing CSS at all. For another example, the <general-enclosed> production in Media Queries defines the bounds of what future syntax MQs will allow, and uses special logic to deal with "unknown" values.

これを~~補助するため、二つの生成規則が追加で定義される： ◎ To aid in this, two additional productions are defined:

`declaration-value@t

この生成規則は、どの［ 1 個以上の~tokenからなる並び ］にも，その並びが次のものを包含していない限り，合致する： ◎ The <declaration-value> production matches any sequence of one or more tokens, so long as the sequence does not contain＼

• `bad-string$tok
• `bad-url$tok
• 対になっていない［ `close-paren$Tok ／ `close-square$Tok ／ `close-curly$Tok ］
• ~top-levelの `semicolon$tok
• `!^l を.値にとる `delim$tok

◎ <bad-string-token>, <bad-url-token>, unmatched <)-token>, <]-token>, or <}-token>, or top-level <semicolon-token> tokens or <delim-token> tokens with a value of "!".＼

これは、その並び全体として［ 妥当な宣言がとり得る値 ］を表現する。 ◎ It represents the entirety of what a valid declaration can have as its value.

`any-value@t

この生成規則は、［ ~top-levelの `semicolon$tok ／ `!^l を.値にとる `delim$tok ］も許容されることを除いて， `declaration-value$t と一致する。 ◎ The <any-value> production is identical to <declaration-value>, but also allows top-level <semicolon-token> tokens and <delim-token> tokens with a value of "!".＼

これは、それ全体として［ 何らかの文脈の下で，妥当な~CSSになり得るもの ］を表現する。 ◎ It represents the entirety of what valid CSS can be in any context.

9.1. ~style規則

`~style規則@ は、［ `選択子~list$ `SELECT$r ］と［ ~prop宣言~list ］を結付ける `有修飾~規則$である。 それらは `CSS21$r の中では，`規則集合$とも呼ばれている。 ~style規則の内側の宣言が~cascadeにどの様に関与するかは、 CSS Cascading and Inheritance `CSS3CASCADE$r が定義する。 ◎ A style rule is a qualified rule that associates a selector list [SELECT] with a list of property declarations. They are also called rule sets in [CSS21]. CSS Cascading and Inheritance [CSS3CASCADE] defines how the declarations inside of style rules participate in the cascade.

有修飾~規則の.導入部は， `selector-list$t として`構文解析-$される。 それが `失敗^i を返したならば、その~style規則~全体が`無効$になる。 ◎ The prelude of the qualified rule is parsed as a <selector-list>. If this returns failure, the entire style rule is invalid.

有修飾~規則の~blockの内容は， `宣言~list$として構文解析される。 別の仕様やこの仕様の将来~levelにて定義されない限り、~listの中の~at-ruleは`無効$であり，無視され~MUST。 ［ 未知の, あるいは値が~propに定義される構文に合致しないような ］~CSS~propの宣言は、`無効$であり，無視され~MUST。 ~style規則の内容の妥当性は、~style規則~自身の妥当性には~~影響しない。 他から定義されない限り，~prop名は`~ASCII大小無視$である。 ◎ The content of the qualified rule’s block is parsed as a list of declarations. Unless defined otherwise by another specification or a future level of this specification, at-rules in that list are invalid and must be ignored. Declaration for an unknown CSS property or whose value does not match the syntax defined by the property are invalid and must be ignored. The validity of the style rule’s contents have no effect on the validity of the style rule itself. Unless otherwise specified, property names are ASCII case-insensitive.

注記： `~custom~prop$ `CSS-VARIABLES$r の名前の文字大小は区別される。 ◎ Note: The names of Custom Properties [CSS-VARIABLES] are case-sensitive.

~CSS~stylesheetの~top-levelの`有修飾~規則$は，~style規則である。 他の文脈における有修飾~規則が~style規則になるかどうかは、その文脈の定義に従う。 ◎ Qualified rules at the top-level of a CSS stylesheet are style rules. Qualified rules in other contexts may or may not be style rules, as defined by the context.

例えば， `media$at 規則 `CSS3-CONDITIONAL$r の内側の有修飾~規則は，~style規則であるが、 `keyframes$at 規則 `CSS3-ANIMATIONS$r の内側の有修飾~規則は，そうでない。 ◎ For example, qualified rules inside @media rules [CSS3-CONDITIONAL] are style rules, but qualified rules inside @keyframes rules are not [CSS3-ANIMATIONS].

9.2. `charset^at 規則

~stylesheet用の`~fallback符号化法を決定する$~algoは、特定の~byte並び — 名前 "`charset^at" の`~at-rule$を構文形に持つような, ~file内の先頭に位置する少数の~byte列 — を検索する。 ◎ The algorithm used to determine the fallback encoding for a stylesheet looks for a specific byte sequence as the very first few bytes in the file, which has the syntactic form of an at-rule named "@charset".

しかしがら、名前 `charset@at の`~at-rule$は，実際には無い。 `charset$at 規則のどの出現も、~stylesheetが実際に構文解析されるときは，認識されない規則として扱った上で、~stylesheetの文法が検査されるときは，無効なものとして棄てられ~MUST。 ◎ However, there is no actual at-rule named @charset. When a stylesheet is actually parsed, any occurrences of an @charset rule must be treated as an unrecognized rule, and thus dropped as invalid when the stylesheet is grammar-checked.

注記： `~stylesheetを構文解析-$する~algoは、~stylesheetの文法が検査される前に，文書から最初の `charset$at 規則を明示的に棄てる — したがって，［ `import$at など，~stylesheet内に最初に出現し~MUST規則 ］にも、その規則を無効にすることなく，（無効な） `charset$at 規則を先行させれる。 ◎ Note: The algorithm to parse a stylesheet explicitly drops the first @charset rule from the document, before the stylesheet is grammar-checked, so valid rules that must appear first in the stylesheet, such as @import, can still be preceded by an (invalid) @charset rule without making themselves invalid.

注記： CSS 2.1 においては、 `charset$at は妥当な規則であった。 旧来の仕様には、依然として， `charset$at 規則を参照して, ~stylesheet内における その有無について明示的に~~述べているものもある。 ◎ Note: In CSS 2.1, @charset was a valid rule. Some legacy specs may still refer to a @charset rule, and explicitly talk about its presence in the stylesheet.

10.1. ~anb の直列化-法

`~anb 値を直列化-@ するときは、その ( `周期$ %A, `~offset$ %B ) に対し，次を走らす： ◎ To serialize an <an+b> value, with integer values A and B:

12.1. ［ 2014 年 2 月 20 日付 勧告候補 ］からの変更点

重要な変更点として次のものが加えられた： ◎ The following substantive changes were made:

• `urange$t 生成規則を創出する支持を受けて， `unicode-range$tok は除去した。 ◎ Removed <unicode-range-token>, in favor of creating a <urange> production.
• 文字列を包含する `url^f 関数は、今や，通常通り `function$tok として構文解析される。 “生の” URL を包含する `url^f 関数は、依然として `url$tok として特別に構文解析される。 ◎ url() functions that contain a string are now parsed as normal <function-token>s. url() functions that contain "raw" URLs are still specially parsed as <url-token>s.
• 文字列を消費しようと試みる前に引用符を消費していなかった， “~url~tokenを消費” ~algoの~bugを修正した。 ◎ Fixed a bug in the "Consume a URL token" algorithm, where it didn’t consume the quote character starting a string before attempting to consume the string.
• 現入力~token／次入力~tokenとその消費~時機に関する，いくつかの構文解析器~algoの~bugを修正した。 ◎ Fixed a bug in several of the parser algorithms related to the current/next input token and things getting consumed early/late.
• ~tokenizationと構文解析~algoにおける いくつかの~bugを修正した。 ◎ Fix several bugs in the tokenization and parsing algorithms.
• 識別子に類する~tokenの定義を， `--^c から開始される識別子も許容するように変更した。 【参照】 ◎ Change the definition of ident-like tokens to allow "--" to start an ident.
• `~anb$ の`周期$ ~IN { 1, −1 } のときは、その数字は直列化しないようにした。 ◎ Don’t serialize the digit in an <an+b> when A is 1 or -1.
• すべての~tokenは`表現$を持つように定義した。 ◎ Define all tokens to have a representation.
• 2 個の符号位置が`妥当な~escape$を成すかどうか検査するときの，小さな~bugを修正した — 並び［ `5C^U, `EOF$tok ］は、今や，妥当な~escapeではないものと正しく報告される。 ◎ Fixed minor bug in check if two code points are a valid escape—a \ followed by an EOF is now correctly reported as not a valid escape.
• ~stylesheet内で最初に来る `charset$at 規則は、構文解析-時に落とすようにした。 ◎ If the very first rule in the sheet is a @charset, dropped it during parsing.
• 構文解析の間に，宣言の.値の先頭／末尾にある空白~並びは取り去るようにした。 ◎ Trimmed whitespace from the beginning/ending of a declaration’s value during parsing.

編集上の変更点として次のものが加えられた： ◎ The following editorial changes were made:

• “文字列を消費” する~algoは、明示的な終端~符号位置を指定せずに呼べるようにされた。 その場合は 現入力~符号位置が代わりに利用される。 これにより，３カ所の呼び出しに変更が加えられた。 ◎ The "Consume a string token" algorithm was changed to allow calling it without specifying an explicit ending token, so that it uses the current input token instead. The three call-sites of the algorithm were changed to use that form.
• 編集上の，~algoにおける小さな再構成 ◎ Minor editorial restructuring of algorithms.
• 構文解析-~API用の入口として、［ `何かを~CSS文法に則って構文解析する$, `~comma区切りの成分値~listを構文解析する$ ］を追加した。 ◎ Added the parse and parse a comma-separated list of component values API entry points.
• `declaration-value$t, `any-value$t 生成規則を追加した。 ◎ Added the <declaration-value> and <any-value> productions.
• WG による解決にしたがって、~Selectorsに特有の~tokenは除去した。 ◎ Removed the Selectors-specific tokens, per WG resolution.
• Infra Standard による定義に一致するので、 “符号位置” と “~surrogate符号位置” の定義は除去した。 ◎ Removed "code point" and "surrogate code point" in favor of the identical definitions in the Infra Standard.

12.2. ［ 2013 年 11 月 5 日付 最終~作業草案 ］からの変更点

• `直列化$の節は、“往来” の要件のみが規範的になる様に書き直され、それを得るための方法の詳細は注記に移動された。 これらの詳細~における，いくつかの際どい事例は解消された。 ◎ The Serialization section has been rewritten to make only the "round-trip" requirement normative, and move the details of how to achieve it into a note. Some corner cases in these details have been fixed.
• 参照文献（規範）に `ENCODING$r が追加された。 それは規範的~textからは参照されていたが、単に文献~listから漏れていた。 ◎ [ENCODING] has been added to the list of normative references. It was already referenced in normative text before, just not listed as such.

• ~stylesheetの`~fallback符号化法を決定する$~algoにおける `charset^at ~byte列の上限は、 1024 ~byteにされた。 これは，~HTMLにおける `meta charset^e の取り扱いに倣うものであり、列の長さを常に一定に抑えるようにする。 これは、符号化法~labelの前後の空白についてのみ，以前と相違がある： ◎ In the algorithm to determine the fallback encoding of a stylesheet, limit the @charset byte sequence to 1024 bytes. This aligns with what HTML does for <meta charset> and makes sure the size of the sequence is bounded. This only makes a difference with leading or trailing whitespace in the encoding label:

  @charset "   …多量の空白…   utf-8";
  

12.3. ［ 2013 年 9 月 19 日付 作業草案］からの変更点

• `環境~符号化法$の概念が追加された。 挙動は変更されていないが、定義の一部は，関連する仕様へ移動されるべきである。 ◎ The concept of environment encoding was added. The behavior does not change, but some of the definitions should be moved to the relevant specs.

12.4. ［ CSS 2.1, Selectors Level 3 ］からの変更点

注記： この仕様の要点は、実態に合致させることである — CSS 2.1 からの変更点は、おおよそ常に， CSS 2.1 が［ 実際の~browserの挙動に合致していない何かを指定しているか, または 何かを未指定~のままにしている ］ことに因る。 何らかの詳細が~browserの挙動に合致しない場合、それは，ほぼ意図されていないことなので，編集者まで知らせるよう願う。 ◎ Note: The point of this spec is to match reality; changes from CSS2.1 are nearly always because CSS 2.1 specified something that doesn’t match actual browser behavior, or left something unspecified. If some detail doesn’t match browsers, please let me know as it’s almost certainly unintentional.

~byte~streamからの復号処理における変更点： ◎ Changes in decoding from a byte stream:

• ~ASCII互換~byte~patternの中では、 `charset$at 規則のみが検出される。 ◎ Only detect @charset rules in ASCII-compatible byte patterns.
• ~ASCII非互換の符号化法を指定する `charset$at 規則は、規則それ自身を適正に復号できなくするので，無視される。 ◎ Ignore @charset rules that specify an ASCII-incompatible encoding, as that would cause the rule itself to not decode properly.
• 文字~符号化法は、 IANA 登記簿ではなく， `ENCODING$r を参照するようにされた。 ◎ Refer to [ENCODING] rather than the IANA registery for character encodings.

~tokenizationにおける変更点: ◎ Tokenization changes:

• ~CSS~source内の `00^U `符号位置$はすべて， `FFFD^U に置換される ◎ Any U+0000 NULL code point in the CSS source is replaced with U+FFFD REPLACEMENT CHARACTER.
• `\0^css などの 0 に評価されるどの 16 進~escape-seqも， `00^U でなく `FFFD^U を生産する。 ◎ Any hexadecimal escape sequence such as \0 that evaluates to zero produce U+FFFD REPLACEMENT CHARACTER rather than U+0000 NULL.
• `非~ASCII符号位置$の定義は， ~ASCIIを利用するどの定義にも整合するように変更された。 これは，`符号位置$ { `0080^U 〜 `009F^U } に影響する — それらは今や、他の`非~ASCII符号位置$同様に，`delim$tok ではなく `名前~符号位置$になる。 ◎ The definition of non-ASCII code point was changed to be consistent with every definition of ASCII. This affects code points U+0080 to U+009F, which are now name code points rather than <delim-token>s, like the rest of non-ASCII code points.
• ~tokenizationは、最早［ `COMMENT^c ／ `BAD_COMMENT^c ］~tokenを発することはない。 `BAD_COMMENT^c は今や，（~errorではない）通常の~tokenと同じものと見なされる。 区切られる必要がある~token — 例えば 連続する 2 個の `ident$tok など — の合間に，必要に応じて~commentを挿入することは、`直列化$が責を負う。 ◎ Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore. BAD_COMMENT is now considered the same as a normal token (not an error). Serialization is responsible for inserting comments as necessary between tokens that need to be separated, e.g. two consecutive <ident-token>s.

• `unicode-range$tok は除去された。 価値が低い割に，時折 有害になるので（例えば `u+a { font-weight: bold; }^css は、無効な選択子にされていた…）。 ◎ The <unicode-range-token> was removed, as it was low value and occasionally actively harmful. (u+a { font-weight: bold; } was an invalid selector, for example...)

  代わりに，~token~patternに基づく `urange$t 生成規則が追加された。 それは、 CSS 2.1 で許容されていたものより，形の上では緩い（任意個数の数字や `?^c ）が、実施におけるその利用には~~影響ない筈である。 ◎ Instead, a <urange> production was added, based on token patterns. It is technically looser than what 2.1 allowed (any number of digits and ? characters), but not in any way that should impact its use in practice.

• ~tokenizerにおいては`~EOF~errorの取扱い規則$が適用され、~EOFに際しては、 `BAD_STRING^c や `BAD_URI^c ではなく，通常の `string$tok や `url$tok が発される。 ◎ Apply the EOF error handling rule in the tokenizer and emit normal <string-token> and <url-token> rather than BAD_STRING or BAD_URI on EOF.
• `BAD_URI^c ~token（今や `bad-url$tok ）は “自己完結的” である。 言い換えれば、~tokenizerにおいて，`url$tok ではなく `bad-url$tok の中であることが認識0された時点で、単に，閉じられる箇所を見つけるために 他のすべてを無視して前方検索する。 この挙動は［ それを `function$tok の様に扱って，開いた~blockに類するものに注意を払う ］より単純である。 この挙動は， WebKit のみに見られるが、それによる互換性bugは生じていないように見受けられる。 ◎ The BAD_URI token (now <bad-url-token>) is "self-contained". In other words, once the tokenizer realizes it’s in a <bad-url-token> rather than a <url-token>, it just seeks forward to look for the closing ), ignoring everything else. This behavior is simpler than treating it like a <function-token> and paying attention to opened blocks and such. Only WebKit exhibits this behavior, but it doesn’t appear that we’ve gotten any compat bugs from it.
• `comma$tok が追加された。 ◎ The <comma-token> has been added.
• ［ `number$tok, `percentage$tok, `dimension$tok ］は、前置された`正負符号$を，値の一部に含むように変更された（他の仕様で言及される度に，手動で取扱う必要がある，別個の `delim$tok としてではなく）。 これによる唯一の帰結は、符号とその実数の合間には，最早~commentを挿入し得なくなったことである。 ◎ <number-token>, <percentage-token>, and <dimension-token> have been changed to include the preceding +/- sign as part of their value (rather than as a separate <delim-token> that needs to be manually handled every time the token is mentioned in other specs). The only consequence of this is that comments can no longer be inserted between the sign and the number.
• Working Group による解決に従って、 SVG に合わせるため，［ 実数／百分率／次元 ］における科学的記数法も~supportされる。 ◎ Scientific notation is supported for numbers/percentages/dimensions to match SVG, per WG resolution.
• ［ `~surrogate$用の 16 進~escape ］は今や、その~surrogateではなく，代替文字 【 `FFFD^U 】 を発する。 これにより、実装は，~UTF-16を内部的に安全に利用できるようになる。 ◎ Hexadecimal escape for surrogate now emit a replacement character rather than the surrogate. This allows implementations to safely use UTF-16 internally.

構文解析における変更点: ◎ Parsing changes:

• Working Group による解決に従って，今や、どの`宣言~list$も， `page$at のような~at-ruleを受容する。 これにより，その種の~at-ruleが未だ定義されていなかったとしても，~errorの取扱いには相違が生じる： `~at-rule$は、妥当であろうとなかろうと， `semicolon$tok が伴われなくとも 波括弧~blockで終端し，次の宣言を始めさせる。 ◎ Any list of declarations now also accepts at-rules, like @page, per WG resolution. This makes a difference in error handling even if no such at-rules are defined yet: an at-rule, valid or not, ends at a {} block without a <semicolon-token> and lets the next declaration begin.

• 文法の中の種々の場所に現れる，一部の種々の “特別な” ~token（対になっていない `close-curly$Tok など）の取扱いは、少なくとも 1 つ以上の~browserに見られるような，ある種の理に適った挙動により指定された。 以前までは、その種の~tokenが伴われた~stylesheetは，単に ~stylesheet文法に全く合致しないものとされており、その取扱いは，まったく定義されていなかった。 特定的には： ◎ The handling of some miscellanous "special" tokens (like an unmatched <}-token>) showing up in various places in the grammar has been specified with some reasonable behavior shown by at least one browser. Previously, stylesheets with those tokens in those places just didn’t match the stylesheet grammar at all, so their handling was totally undefined. Specifically:

  • ［ `角括弧~block$, `丸括弧~block$, `関数式$ ］はいずれも，今や［ `波括弧~block$, `at-keyword$tok, `semicolon$tok, ］のいずれをも包含し得る ◎ [] blocks, () blocks and functions can now contain {} blocks, <at-keyword-token>s or <semicolon-token>s
  • 有修飾~規則の.導入部は今や，~semicolonを包含し得る ◎ Qualified rule preludes can now contain semicolons
  • ［ 有修飾~規則, ~at-ruleの.導入部 ］はいずれも，今や `at-keyword$tok 包含し得る。 ◎ Qualified rule and at-rule preludes can now contain <at-keyword-token>s

~AnB における， Selectors Level 3 `SELECT$r からの変更点： ◎ An+B changes from Selectors Level 3 [SELECT]:

• ~AnB 小構文は 今や，別個の~tokenizerではなく，~CSS~tokenの用語を通して，公式的に定義された。 その結果，小さな相違が生じている： ◎ The An+B microsyntax has now been formally defined in terms of CSS tokens, rather than with a separate tokenizer. This has resulted in minor differences:

  • 一部の場合には，負符号や数字を（それらが `dimension$tok の.単位や `ident$tok の一部として現れるときには）~escapeできる。 ◎ In some cases, minus signs or digits can be escaped (when they appear as part of the unit of a <dimension-token> or <ident-token>).