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. ~escape法

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

• ［ `~hex$, `改行文字$ ］以外の~Unicode`符号位置$。 この~escape列は、 その`符号位置$に置換される。 ◎ 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$, 省略可能な 1 個の`空白$ ］が成す並び。 この~escape列は、［ その~hex並びが表す数を値とする~Unicode`符号位置$ ］に置換される。 省略可能な空白は、［ 16 進~escape列に “本当の” ~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 を伴う`~ident$は、［ `\26 B^css あるいは `\000026B^css ］として記すこともできる。 ◎ An ident sequence with the value "&B" could be written as \26 B or \000026B.

  注記： ~escape列の直後に “本当の” ~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-規則$を開始させる。 他のものは どれも，`有修飾~規則$を開始させ、 その規則の.導入部の中に含まれる。 これは，`無効な選択子$も生産し得るが、 そのことは，~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-規則$が開始されたなら、 構文解析器の視点からは，何が来ようが無効にならない — 次のいずれかに遭遇するまでを成すすべてが，~at-規則の.導入部の一部になる： ◎ 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-規則は即時に終端される。 ◎ Encountering a <semicolon-token> ends the at-rule immediately, while＼
  • 一方で，開き波括弧 `open-curly$Tok に遭遇したときは、 その~at-規則の本体を開始させる — 本体に合致する~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-規則の内容が，~at-規則の自前の文法に則って解釈される。 ◎ 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が終端した場合、 あらゆるものが自動的に閉じられる。 これは、 それらを無効にはしない。 不完全にもなり得るが、 その場合，各自の文法に照らし合わせて検証yされる際に棄てられる。 ◎ 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.

  例えば，関数 `translateX$f の構文は： ◎ For example, the syntax of the translateX() function is:

  translateX( `length-percentage【！translation-value】^t )
  

  しかしながら，~stylesheetは、 この関数が閉じられないまま終端されてもよい — 次の様に： ◎ However, the stylesheet may end with the function unclosed, like:

  .foo { transform: translateX【！translate】(50px
  

  ~CSS構文解析器は，これを［［［［ `関数$であって，その.名前は `translateX^l であるもの ］のみからなる`成分~値$たちが成す~list ］を.値にとる， 1 個の`宣言$ ］を包含している~style規則 ］として構文解析する。 これは、 終端ng~tokenが~token~streamの中に出現しなくても，上の文法には合致するものとされる。 構文解析器を抜けた時点で，終端ng~tokenの有無は決定し得なくなり、 ~blockと関数が在るという事実のみが残るので。 ◎ The CSS parser parses this as a style rule containing one declaration, whose value is a function named "translate". This matches the above grammar, even though the ending token didn’t appear in the token stream, because by the time the parser is finished, the presence of the ending token is no longer possible to determine; all you have is the fact that there’s a block and a function.

各~構成子（宣言, ~style規則, ~at-規則）が構文解析されたなら、 ~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 ］である。 それは、［ ~token化~段階 ］を経て［ ~treeの構築~段階 ］に渡される。 その出力は［ `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~treeは［ この仕様を成す他の部分 ］用の~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の構文解析における~token化~段階 ］への入力を成す［ ~Unicode`符号位置$たちが成す~stream ］は、 ~UAにとっては，初期~時は （概して，~network越しに, または局所~file~systemからの） ~byte~streamとして見えるであろう。 その場合，~UAは、 特定0の文字~符号化法に則って，当の~streamを成す~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.

［ ~byte列から復号される~CSS~stylesheet ］を参照rする文書~言語は、 それら各~stylesheet用に， `環境~符号化法@ を定義してもヨイ。 それは、 他の符号化法~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.

3.3. 入力~streamの前処理

`入力~stream@ は、 入力~byte~streamを復号するに伴い~pushされた，`一連の~filter済み符号位置＠#css-filter-code-points$からなる。 ◎ The input stream consists of the filtered code points pushed into it as the input byte stream is decoded.

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.

これらの図式は、 `参考であって, 不完全である^em。 ~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を表現する。 他のものは，他の図式から参照rされる生成規則である。 ◎ 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（`前処理＠#input-preprocessing$前の改行文字）

`newline^dgm

`whitespace^sb（`空白$）

`whitespace^dgm

`hex digit^sb（ `~hex$ ）

`hex-digit^dgm

`escape^sb（~escape列）

`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

【 原文の図式は `<!--^l から `<<!---->!--^l へ更新されたが、 何かの間違いに思われる。 】

`CDC$tok

`CDC-token^dgm

`unicode-range$tok

`unicode-range-token^dgm

4.2. 定義

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

`C1^V, `C2^V, `C3^V ◎ next input code point

順に，`入力~stream$内の未だ消費されていない［ 1 個目, 2 個目, 3 個目 ］の`符号位置$を指す — ~streamの末尾を越える所を指す場合、 `~EOF$iと見なされる。 ◎ The first code point in the input stream that has not yet been consumed.

【 これらは、 `入力~符号位置を消費する$に伴い変化することになる。 】【 ~CSSの構文解析において先読みが必要になる符号位置たちは、 これら 3 個までに限られる。 】【 `C1$V は、 原文では `next input code point^en （ “次回の入力~符号位置” ）と称されるが、 2 個目や 3 個目を指す記述も含めて一貫した形で簡明に述べるため，このように改める。 】

`現在の入力~符号位置@ ◎ current input code point

すでに消費された`符号位置$のうち，最後のもの。 【 `~EOF$i もとり得る。】 ◎ The last code point to have been consumed.

`現在の入力~符号位置を消費し直す@ ◎ reconsume the current input code point

`現在の入力~符号位置$を`入力~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符号位置@ 【この訳では、単に `~EOF$i と略記する。】 ◎ EOF code point

`入力~stream$の終端を表現する， 【他のどの符号位置とも異なる】 概念的な符号位置。 `入力~stream$が空になり次第， `C1$V は常に `~EOF$i になる。 ◎ 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.

各種 符号位置の範囲

次に挙げる各種［ `符号位置$の範囲 ］が定義される — 記号 ∪ は、 和集合をとることを意味する： ◎ ↓

`数字@ ◎ digit

{ `30^U 〜 `39^U } ◎ A code point between U+0030 DIGIT ZERO (0) and U+0039 DIGIT NINE (9) inclusive.

`~hex@ ◎ hex digit

`数字$ ∪ { `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) inclusive, or a code point between U+0061 LATIN SMALL LETTER A (a) and U+0066 LATIN SMALL LETTER F (f) inclusive.

`正負符号@ 【これは、この訳による追加的な定義】

{ `2B^U, `2D^U }

`大文字@ ◎ uppercase letter

{ `41^U 〜 `5A^U } ◎ A code point between U+0041 LATIN CAPITAL LETTER A (A) and U+005A LATIN CAPITAL LETTER Z (Z) inclusive.

`小文字@ ◎ lowercase letter

{ `61^U 〜 `7A^U } ◎ A code point between U+0061 LATIN SMALL LETTER A (a) and U+007A LATIN SMALL LETTER Z (z) inclusive.

`英字@ ◎ letter

`大文字$ ∪ `小文字$ ◎ An uppercase letter or a lowercase letter.

`非~ASCII~ident符号位置@ ◎ non-ASCII ident code point

{ `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^U 以上【〜 `10FFFF^U 】 } ◎ A code point whose value is any of: • U+00B7 • between U+00C0 and U+00D6 • between U+00D8 and U+00F6 • between U+00F8 and U+037D • between U+037F and U+1FFF • U+200C • U+200D • U+203F • U+2040 • between U+2070 and U+218F • between U+2C00 and U+2FEF • between U+3001 and U+D7FF • between U+F900 and U+FDCF • between U+FDF0 and U+FFFD • greater than or equal to U+10000 ◎ All of these ranges are inclusive.

これらの文字に特定的に限られるのは，なぜか？ ◎ Why these character, specifically?

これは、 ~HTMLの`妥当な~custom要素~名$に許容される非~ASCII符号位置の~listに合致する。 これは、 いくつかの文字を除外する — ［ 空白として現れるもの／ 何らかの~toolにおいて描画や構文解析の課題の原因になり得るもの／ 方向【書字~方向】上書き符号位置 ］など。 ◎ This matches the list of non-ASCII codepoints allowed to be used in HTML valid custom element names. It excludes a number of characters that appear as whitespace, or that can cause rendering or parsing issues in some tools, such as the direction override codepoints.

これは、 `UAX 31＠https://unicode.org/reports/tr31/#Figure_Code_Point_Categories_for_Identifier_Parsing$ にて識別子~用に推奨される制約の集合 （~JSなどの言語が自身の識別子~構文を制約するために利用される） より弱いことに注意 — これは、 結合~文字から開始する識別子などを許容する。 ~HTML~custom要素~名との整合性 （したがって，~custom要素~用の選択子を~escapeを利用せずに書く能） は，価値があると見なされ、 ~HTMLにより制約される文字の集合は、 この “高価値” な制約をきちんと受持つ。 ◎ Note that this is a weaker set of restrictions than UAX 31 recommends for identifiers (used by languages such as JavaScript to restrict their identifier syntax), allowing things such as starting an identifier with a combining character. Consistency with HTML custom element names (and thus, the ability to write selectors for all custom elements without having to use escapes) was considered valuable, and the set of characters restricted by HTML covers the "high value" restrictions well.

これらの制約は、 混同され得る描画~すべてを避けるものではない — ［ 左横書き, 右横書き ］用字系に属する文字が混在している場合、 結果は，依然として — 例えば、 ほとんどの~text~editorにおいては — 期待されない視覚的な並び替えになる。 ~source~textは、 例えば，非~ident文脈においても制約された【除外された】文字を包含し得る — それらのほとんどは、 文字列~内で完全に妥当である。 それらが妥当でない~CSSを作成する仕方で利用されたときでも、［ それによる構文解析~errorは，何か重要でないものに制限される ］かもしれない一方で，［ ~code考査~toolにおける~source~textの描画 ］に対する それらの効果は［ 有意／悪意的 ］になるかもしれない。 これらの類の “~source~text攻撃” についての詳細は、 `この Rust-lang blog post＠https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html$ `(archived)＠https://web.archive.org/web/20220323175009/https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html$ を見よ。 ◎ These restrictions do not avoid all possible confusing renderings; mixing characters from LTR and RTL scripts can still result in unexpected visual transposition in most text editors, for example. Source text can contain the restricted characters in non-ident contexts, as well: most of them are completely valid in strings, for example. Even when used in a way that creates invalid CSS, the parsing errors they cause might be limited to something unimportant, while their effect on rendering the source text in code review tools might be significant and/or malicious. For more details on these sorts of "source text attacks", see this Rust-lang blog post (archived).

`~identを開始する符号位置@ ◎ ident-start code point

`英字$ ∪ `非~ASCII~ident符号位置$ ∪ { `5F^U } ◎ A letter, a non-ASCII ident code point, or U+005F LOW LINE (_).

`~ident符号位置@ ◎ ident code point

`~identを開始する符号位置$ ∪ `数字$ ∪ { `2D^U } ◎ An ident-start code point, a digit, or U+002D HYPHEN-MINUS (-).

`印字不能~符号位置@ ◎ non-printable code point

{ `00^U 〜 `08^U } ∪ { `0B^U } ∪ { `0E^U 〜 `1F^U } ∪ { `7F^U } ◎ A code point between U+0000 NULL and U+0008 BACKSPACE inclusive, or U+000B LINE TABULATION, or a code point between U+000E SHIFT OUT and U+001F INFORMATION SEPARATOR ONE inclusive, or U+007F DELETE.

`改行文字@ ◎ newline

{ `0A^U } ◎ U+000A LINE FEED.＼

`0D^U, `0C^U は、 この定義には含まれない — それらは、 `前処理＠#input-preprocessing$の段階で `0A^U に変換されるので。 ◎ 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.

`空白@ ◎ whitespace

`改行文字$ ∪ { `09^U, `20^U } ◎ A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE.

`許容される最大な符号位置@ ◎ maximum allowed code point

`10FFFF^U — すなわち、 ~Unicodeにて定義される最~大な`符号位置$。 ◎ The greatest code point defined by Unicode: U+10FFFF.

`~ident@ ◎ ident sequence

`ident$tok と構文が同じな，`符号位置$たちが成す連列。 ◎ A sequence of code points that has the same syntax as an <ident-token>.

【 ~identは、 `identifier^en （識別子）の略語であり， ~CSSにおける識別子（`~CSS識別子$）の構文上の側面を特定的に指す技術-用語。 】【 この~identは、 原文では `ident sequence^en （ “（ 1 個の）~ident（を成す，符号位置たちが成す）連列” ） と記されており，直訳するなら “~ident連列” あるいは “~ident列” の様になろうが、 それだと `sequence of idents^en （ “~identたちが成す連列” ） と紛らわしくなるので，この訳では （ `ident^en, `ident sequence^en どちらも） 単に “~ident” と表記することにする。 】

注記： 次に挙げるものは、 どれも`~ident$になる ⇒＃ `at-keyword$tok の "@" より後の部分, `hash$tok のうち［ .型~flag ~EQ `id^i ］なるものの `#^l より後の部分, `function$tok の `(^l より前の部分, `dimension$tok の.単位 ◎ Note: The part of an <at-keyword-token> after the "@", the part of a <hash-token> (with the "id" type flag) after the "#", the part of a <function-token> before the "(", and the unit of a <dimension-token> are all ident sequences.

【 原文の記述を明確化するため、 この訳では，次に挙げる定義も導入する： 】

%n 個の `入力~符号位置を消費する@

~streamの先頭から %n 個の符号位置を除去した上で、 除去された最後の符号位置を`現在の入力~符号位置$にあてがうことを意味する （言い換えれば、 現在の入力~符号位置を指している~pointerを，最後に消費された符号位置を指すよう移動する）。

最後の 1 個を除去する前に~streamを消費し尽くした場合、 `現在の入力~符号位置$は，`~EOF$iになる。

~streamから`入力~符号位置を繰返し消費する@ ：…

次を繰返し走らすことを意味する：

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

繰返nは、 値を返した時点（ ~RET ）で終了する。

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.

これらの図式は、 `参考であり, 不完全である^em。 ~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

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

`at-rule^dgm

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

`qualified-rule^dgm

`{} block^sb

`declaration-list^dgm

【 `波括弧~block$と同じ名前だが，定義が異なっていて紛らわしい。 】

`Declaration^sb（`宣言$）

`declaration^dgm

`!important^sb

`important^dgm

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

`component-value^dgm

`Simple block^sb（`単純~block$）

`simple-block^dgm

`Function block^sb（`関数$）

`function-block^dgm

5.2. ~CSS構文解析の結果

構文解析の結果は、 次に挙げるいずれか — あるいは、 それらが成す`~list$ — になる： ◎ The result of parsing can be any of the following (or lists of these):

`~stylesheet@ ◎ stylesheet

次に挙げる~fieldを伴う：

• .`規則~群^dfn — `規則$たちが成す`~list$

◎ A stylesheet has a list of rules.

`規則@ ◎ rule

`~at-規則$ ／ `有修飾~規則$ 【／ `入子な宣言~列が成す規則$】 ◎ A rule is either an at-rule or a qualified rule.

`~at-規則$ ◎ at-rule

次に挙げる~fieldを伴う：

• .`名前^dfn — `文字列$
• .`導入部^dfn — `成分~値$たちが成す`~list$
• .`宣言~群^dfn — ε ／ `宣言$たちが成す`~list$
• .`子~規則~群^dfn — ε ／ 子`規則$たちが成す`~list$

これらのうち，［ .宣言~群 ／ .子~規則~群 ］は、 `~block~at-規則$（`波括弧~block$で終端するもの）に限り非 ε になり， ~semicolonで終端する`一文~at-規則$においては ε になる。

◎ An at-rule has a name which is a string, a prelude consisting of a list of component values. Block at-rules (ending in a {}-block) will additionally have a list of declarations and a list of child rules. (Statement at-rules, ending in a semicolon, will not.)

`有修飾~規則@ ◎ qualified rule

次に挙げる~fieldを伴う：

• .`導入部^dfn — `成分~値$たちが成す`~list$
• .`宣言~群^dfn — `宣言$たちが成す`~list$
• .`子~規則~群^dfn — 子`規則$たちが成す`~list$

◎ A qualified rule has a prelude consisting of a list of component values, a list of declarations, and a list of child rules.

注記： ほとんどの有修飾~規則は、 ~style規則になり，その［ .導入部は`選択子$, .宣言~群は`~prop$たち ］を与える。 ◎ Note: Most qualified rules will be style rules, where the prelude is a selector [selectors-4] and its declarations are properties.

`宣言@ ◎ declaration

次に挙げる~fieldを伴う：

• .`名前^dfn — `文字列$
• .`値^dfn — `成分~値$たちが成す`~list$
• .`~importantか^dfn — 真偽値, 初期~時は ~F 【`~importantな宣言$になるかどうかを指示する。】
• .`元の~text^dfn — ε ／ 文字列 （文字列は、少数の宣言に限り捕捉される。）

◎ A declaration has a name which is a string, a value consisting of a list of component values, and an important flag which is initially unset. It also has an optional original text which is a string (captured for only a few declarations).

宣言たちは、 次に挙げるいずれかに分類される： ◎ Declarations are further categorized as property declarations or descriptor declarations, with＼

• `~prop宣言@ ⇒ `有修飾~規則$内で出現することが最も多く，~CSS`~prop$を設定する。 ◎ the former setting CSS properties and appearing most often in qualified rules＼
• `記述子~宣言@ ⇒ `~at-規則$内に限り出現し，~CSS`記述子$を設定する。 ◎ and the latter setting CSS descriptors, which appear only in at-rules.＼

（この分類は、 この仕様の構文~levelにおいては生じない — この分類は、 宣言が出現する所における産物であり， 当の規則を定義する仕様により定義される。） ◎ (This categorization does not occur at the Syntax level; instead, it is a product of where the declaration appears, and is defined by the respective specifications defining the given rule.)

`成分~値@ ◎ component value

`保全d~token$ ／ `関数$ ／ `単純~block$ ◎ A component value is one of the preserved tokens, a function, or a simple block.

`保全d~token@ ◎ preserved tokens

次に挙げるもの以外の，~tokenizerにより生産される任意の~token ⇒＃ `function$tok, `open-curly$Tok, `open-paren$Tok, `open-square$Tok ◎ Any token produced by the tokenizer except for <function-token>s, <{-token>s, <(-token>s, and <[-token>s.

注記： 上に挙げられた非`保全d~token$は、 常に，より高~levelな［ `関数$／`単純~block$ ］~objの中で消費されるので、 構文解析器の出力には，決して出現しない。 ◎ Note: The non-preserved tokens listed above are always consumed into higher-level objects, either functions or simple blocks, and so never appear in any parser output themselves.

注記： 【出力に出現する】 ~tokenのうち［ `close-curly$Tok, `close-paren$Tok, `close-square$Tok, `bad-string$tok, `bad-url$tok ］は，常に`構文解析error$を表すが、 それらは，［ 宣言や~blockを単にまるごと落とすより細やかな、 ~errorの取扱い ］を定義することを他の仕様 — `MEDIAQ$r など — に許容するため、 この仕様により，~token~streamの中に保全される。 ◎ Note: The tokens <}-token>s, <)-token>s, <]-token>, <bad-string-token>, and <bad-url-token> are always parse errors, but they are preserved in the token stream by this specification to allow other specs, such as Media Queries, to define more fine-grained error-handling than just dropping an entire declaration or block.

`関数@ ◎ function

次に挙げる~fieldを伴う：

• .`名前^dfn
• .`値^dfn — `成分~値$たちが成す`~list$

◎ A function has a name and a value consisting of a list of component values.

`単純~block@ ◎ simple block ◎ {}-block ◎ []-block ◎ ()-block

次に挙げる~fieldを伴う：

• .`開き括弧^dfn — 次に挙げるいずれか ⇒＃ `open-square$Tok ／ `open-paren$Tok ／ `open-curly$Tok
• .`値^dfn — `成分~値$たちが成す`~list$

◎ A simple block has an associated token (either a <[-token>, <(-token>, or <{-token>) and a value consisting of a list of component values.

`単純~block$は、 その.開き括弧に応じて：

• `open-square$Tok ならば `角括弧~block@ （ `[]-block^en ）と称される。
• `open-paren$Tok ならば `丸括弧~block@ （ `()-block^en ）と称される。
• `open-curly$Tok ならば `波括弧~block@ （ `{}-block^en ）と称される。

◎ {}-block, []-block, and ()-block refer specifically to a simple block with that corresponding associated token.

5.3. ~token~stream

`~token~stream@ は、［ ~token／`成分~値$ ］たち~DAGGERが成す~streamを表現している`構造体$であり， 次に挙げる`~item$sctからなる： ◎ A token stream is a struct representing a stream of tokens and/or component values. It has the following items:

【 ~DAGGER ~tokenと成分~値が混在し得るかどうかは、 はっきりしない。 】

`~token群@tS ◎ tokens

［ ~token／`成分~値$ ］たちが成す`~list$。 ◎ A list of tokens and/or component values.

注記： 単純にするため、 この仕様は，［ 入力~streamは、 構文解析が始まる前に全部的に~token化済み ］と見做す。 しかしながら、 構文解析~algoは， 1 個の~tokenしか “先読み” に利用しないので、 実施においては，~token化と構文解析は “連動的” に行える。 ◎ Note: This specification assumes, for simplicity, that the input stream has been fully tokenized before parsing begins. However, the parsing algorithms only use one token of "lookahead", so in practice tokenization and parsing can be done in lockstep.

`~index@tS ◎ index

`~token群$tSの中を指す~index — 初期~時は 0 とする。 構文解析の進捗を表現する。 ◎ An index into the tokens, representing the progress of parsing. It starts at 0 initially.

注記： `~markを復旧する$tS【！`~markする$tS】ときは別として、 `~index$tSは決して後戻りしない。 したがって、 `~token群$tSを成す~tokenのうち，すでに処理したものは、 それに伴い，早急に破棄できる。 ◎ Note: Aside from marking, the index never goes backwards. Thus the already-processed prefix of tokens can be eagerly discarded as it’s processed.

`~mark済み~index群@tS ◎ marked indexes

~indexたちが成す`~stack$ — 初期~時は空とする。 これは、 構文解析器が返るかもしれない地点たちを表現する。 ◎ A stack of index values, representing points that the parser might return to. It starts empty initially.

~CSSには、［ 宣言の値~用に構文解析して~tokenを生産する前の精確な~text ］を参照することを要求する箇所が少数ある。 したがって、 `~token~stream$は［ 宣言を成す.元の~textを その場で再生産する能 ］を有していなければナラナイ — それは、 ここでの~algo上の構造には明示的に述べられないが。 これがいつ要求されるかについての詳細は、 `宣言を消費する$を見よ。 ◎ CSS has a small number of places that require referencing the precise text that was parsed for a declaration’s value (not just what tokens were produced from that text). This is not explicitly described in the algorithmic structure here, but the token stream must, thus, have the ability to reproduce the original text of declarations on demand. See consume a declaration for details on when this is required.

`~token~stream$ %入力 に対しては、 次に挙げる演算が遂行され得る： ◎ Several operations can be performed on a token stream:

• %入力 の `次回の~token@tS は、 次の結果を返す：

  1. %~index ~LET %入力 の`~index$tS
  2. %~token群 ~LET %入力 の`~token群$tS
  3. ~IF［ %~index ~GTE %~token群 の`~size$ ］ ⇒ ~RET `EOF$tok
  4. ~RET %~token群[ %~index ]
  ◎ next token • The item of tokens at index. • If that index would be out-of-bounds past the end of the list, it’s instead an <eof-token>.
• %入力 は `空@tS であるとは、 次を満たすことをいう ⇒ %入力 の`次回の~token$tS ~EQ `EOF$tok ◎ empty • A token stream is empty if the next token is an <eof-token>.

• %入力 から `~tokenを消費する@tS ~algoは：

  1. %~token ~LET %入力 の`次回の~token$tS
  2. %入力 の`~index$tS ~INCBY 1
  3. ~RET %~token
  ◎ consume a token • Let token be the next token. Increment index, then return token.
• %入力 から `~tokenを破棄する@tS ~algoは ⇒ ~IF［ %入力 は`空$tSでない ］ ⇒ %入力 の`~index$tS ~INCBY 1 ◎ discard a token • If the token stream is not empty, increment index.
• %入力 を `~markする@tS ~algoは ⇒ %入力 の`~mark済み~index群$tSに %入力 の`~index$tS を`付加する$ ◎ mark • Append index to marked indexes.
• %入力 の `~markを復旧する@tS ~algoは ⇒ %入力 の`~index$tS ~SET %入力 の`~mark済み~index群$tSから`~popする$ ◎ restore a mark • Pop from marked indexes, and set index to the popped value.
• %入力 の `~markを破棄する@tS ~algoは ⇒ %入力 の`~mark済み~index群$tSから`~popする$ （~popされた値は棄てる） ◎ discard a mark • Pop from marked indexes, and do nothing with the popped value.
• %入力 の `空白を破棄する@tS ~algoは ⇒ ~WHILE［ %入力 の`次回の~token$tSは `whitespace$tok である ］ ⇒ %入力 から`~tokenを破棄する$tS ◎ discard whitespace • While the next token is a <whitespace-token>, discard a token.

• %入力 を `処理する@tS 所では、 次を繰返す ⇒ %入力 の`次回の~token$tSに応じて、［ 後続の~block内に記された，当の~tokenの型に対応する動作 ］を遂行する

  繰返nは、 当の動作が値を返した時点（ ~RET ）で終了する。

  ◎ process • To process, given a following list of token types and associated actions, perform the action associated with the next token. Repeat until one of the actions returns something, then return that.

`EOF@tok は、［ 実際に~tokenizerにより生産されることはない，概念的な~token ］であり，［ 当の`~token~stream$が枯渇したことを指示する ］ために利用される。 ◎ An <eof-token> is a conceptual token, not actually produced by the tokenizer, used to indicate that the token stream has been exhausted.

5.4. 構文解析器の入口

この節に定義する各種~algoは、 低~levelな~CSS~tokenから高~levelな~CSS~objを生産する。 ◎ The algorithms defined in this section produce high-level CSS objects from lists of CSS tokens.

これらの~algoは，~token~streamを入力として演算するが、 便利~用に，何種かの他の値~型でも — `~token~streamに正規化する$ことを介して，それが受容する値~型でも — 呼出せる。 ◎ The algorithms here operate on a token stream as input, but for convenience can also be invoked with a number of other value types.

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

5.5. 構文解析器~algo

構文解析器は、 以下に挙げる~algoからなる。 それらは、 上に挙げた構文解析器の入口から~callされる — 他の仕様は、 一般に，それらを直に~callするベキでない。 ◎ The following algorithms comprise the parser. They are called by the parser entry points above, and generally should not be called directly by other specifications.

~CSS構文解析は、 文字大小区別であることに注意。 加えて，所与の文脈における構成子の妥当性は、 少なくとも一部の状況下においては， 構文解析して`いる間に^em検査しなければナラナイことに注意†。 この仕様は、 妥当性の検査-法を可能化するために足る文脈を`どう渡す^emベキかは，意図的に指定しない。 ◎ Note that CSS parsing is case-sensitive, and checking the validity of constructs in a given context must be done during parsing in at least some circumstances. This specification intentionally does not specify how sufficient context should be passed around to enable validity-checking.

【† 以下においては、 “現在の文脈において妥当である” という句で指示される。 】

6.1. 非正式な構文~記述

%A ~EQ 0 の場合、 ~An 部分を省略してもヨイ （ %B 部分がすでに省略されていない限り）。 ~An 部分が無い場合、 負でない %B の前の `+^c 符号も省略してヨイ【！ (when allowed) ？】 — この事例では、 構文は %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 ~IN { 1, −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 ~EQ 0 の場合、 毎 %A 個目の要素が選ばれる。 そのような場合、 正負符号と %B 部分を省略してもヨイ （ ~An 部分がすでに省略されていない限り）。 ◎ 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の用語を通して表出するときには，いくぶん不規則な定義になる。 この節では、［ ~AnB 記法を~CSS~tokenの用語を通して認識する方法 （したがって，~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-4$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

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

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

上で ~DAGGER 印が付与された所のように、 正符号 (`+^c) ~tokenの直後に［ `n^l から開始している `ident^tok ~token ］が来る所では，それらの合間に空白が在ってはナラナイ — さもなければ、 それらの~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. ~block内容の定義-法： `block-contents^t, `declaration-list^t, `qualified-rule-list^t, `declaration-rule-list^t, `rule-list^t 生成規則

~CSS構文解析器は、 ~blockを成す内容を問わない — それらはすべて，同じ`~algo＠#consume-a-blocks-contents$で構文解析され、 もっぱら，構成子として何が妥当になるかにより区別される。 ◎ The CSS parser is agnostic as to the contents of blocks—they’re all parsed with the same algorithm, and differentiate themselves solely by what constructs are valid.

規則の文法を書くときは、 `block-contents@t が，この［ 構成子を問わない構文解析 ］を表現する。 それは、［ ~block全体を占める値 ］としてに限って利用しなければナラナイ。 それは、［ 当の~blockが包含し得るものに対し，暗黙的に設置される制約 ］は無いことを表現する。 ◎ When writing a rule grammar, <block-contents> represents this agnostic parsing. It must only be used as the sole value in a block, and represents that no restrictions are implicitly placed on what the block can contain.

付随している注釈文は、 次を定義しなければナラナイ： ◎ Accompanying prose must＼

• 当の文脈において何が妥当で何が無効になるか。 ◎ define what is valid and invalid in this context.＼
• 妥当な`宣言$が`~prop宣言$である場合、 それは，`~cascade$とヤリトリするか否か — ヤリトリする場合、 その`詳細度＠~CASCADE#cascade-specificity$，それは `!important^css をどう利用するか。 ◎ If any declarations are valid, and are property declarations, it must define whether they interact with the cascade; if they do, it must define their specificity and how they use !important.

しかしながら，多くの事例では、 ~blockは，所与の型を成す どの構成子も妥当に包含できるわけではない。 これらの事例を より明示的に表現するためとして、 次に挙げる生成規則を利用してもヨイ： ◎ In many cases, however, a block can’t validly contain any constructs of a given type. To represent these cases more explicitly, the following productions may be used

• `declaration-list@t ⇒ `宣言$は許容され，［ `~at-規則$, `有修飾~規則$ ］は自動的に無効になる。 ◎ <declaration-list>: only declarations are allowed; at-rules and qualified rules are automatically invalid.
• `qualified-rule-list@t ⇒ `有修飾~規則$は許容され，［ `宣言$, `~at-規則$ ］は自動的に無効になる。 ◎ <qualified-rule-list>: only qualified rules are allowed; declarations and at-rules are automatically invalid.
• `at-rule-list@t ⇒ `~at-規則$は許容され，［ `宣言$, `有修飾~規則$ ］は自動的に無効になる。 ◎ <at-rule-list>: only at-rules are allowed; declarations and qualified rules are automatically invalid.
• `declaration-rule-list@t ⇒ ［ `宣言$, `~at-規則$ ］は許容され， `有修飾~規則$は自動的に無効になる。 ◎ <declaration-rule-list>: declarations and at-rules are allowed; qualified rules are automatically invalid.
• `rule-list@t ⇒ ［ `有修飾~規則$, `~at-規則$ ］は許容され， `宣言$は自動的に無効になる。 ◎ <rule-list>: qualified rules and at-rules are allowed; declarations are automatically invalid.

これらはいずれも、 構文解析の用語においては，正確に `block-contents$t に等価である — 付随している注釈文は、 自動的に無効になるもの以外に限り，妥当性を定義する必要がある。 ◎ All of these are exactly equivalent to <block-contents> in terms of parsing, but the accompanying prose only has to define validity for the categories that aren’t automatically invalid.

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

`keyframes$at
	= @keyframes { `qualified-rule-list$t }
`keyframe-rule^t
	= `keyframe-selector$t { `declaration-list$t }

7.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に まったく含まれないものに利用される ］ような，任意の適理な値を許容する。 他の例として、 `MEDIAQ$r の `general-enclosed$t 生成規則は、 その仕様の将来の構文が許容し得るものを定義して， “未知な” 値を特別な~logicで処する。 ◎ 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.

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

`declaration-value@t

この生成規則は、 `任意の^em［ 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.

8.1. ~style規則

`~style規則@ は、 `有修飾~規則$のうち，`選択子~list$に［ ~prop宣言~群が成す~list, および — 場合によっては — 入子にされた規則~群が成す~list ］を結付けるものである。 `~style規則$は、 `CSS2$r においては`規則~集合$とも呼ばれる。 ~style規則の内側にある宣言が`~cascade$にどう関与するかは、 `CSS-CASCADE-3$r が定義する。 ◎ A style rule is a qualified rule that associates a selector list with a list of property declarations and possibly a list of nested rules. They are also called rule sets in [CSS2]. CSS Cascading and Inheritance [CSS-CASCADE-3] 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の内容は、 `declaration-list$t として構文解析される。 この~block内の有修飾~規則も`~style規則$である。 別の仕様やこの仕様の将来~levelにて定義されない限り、 この~list内の~at-規則は`無効$であり，無視するモノトスル。 ◎ The content of the qualified rule’s block is parsed as a <declaration-list>. Qualified rules in this block are also style rules. Unless defined otherwise by another specification or a future level of this specification, at-rules in that list are invalid and must be ignored.

注記： `CSS-NESTING-1$r は、 `~style規則$の内側では［ `条件付き~group規則$, 他の一部の`~at-規則$たち ］が許容されるものと定義する。 ◎ Note: [CSS-NESTING-1] defines that conditional group rules and some other at-rules are allowed inside of style rules.

~CSS~prop用の宣言のうち，その値が［ 未知なもの／当の~propに定義される構文に合致しないもの ］は、 `無効$であり，無視するモノトスル。 ~style規則の内容の妥当性は、 当の規則~自身の妥当性には~~影響しない。 他から定義されない限り，~prop名は`~ASCII大小無視$である。 ◎ Declarations 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 [CSS3-ANIMATIONS] are not.

8.2. ~at-規則

`~at-規則@ （ `at-rule^en ）は、 `at-keyword$tok 【！at-keyword】から始まる規則であり、 したがって，同じ文脈~内の`~style規則$と判別できる。 ◎ An at-rule is a rule that begins with an at-keyword, and can thus be distinguished from style rules in the same context.

`~at-規則$は、 次のために利用される： ◎ At-rules are used to:

• ~style規則や他の~at-規則 — `条件付き~group規則$内にあるものなど — を~group化したり構造~化する。 ◎ group and structure style rules and other at-rules such as in conditional group rules
• 特定0の要素には結付けられない~style情報を宣言する — `~counter~style$を定義するなど。 ◎ declare style information that is not associated with a particular element, such as defining counter styles
• 構文上の構成子を管理する — `import$at や `namespace$at における対応付けなど ◎ manage syntactic constructs such as imports and namespaces keyword mappings
• `~style規則$が~serveしない，他の諸々の目的を~serveする。 ◎ and serve other miscellaneous purposes not served by a style rule

`~at-規則$は、 自身に特有な規則と目的に依存して多くの形をとり得るが，次の 2 種に大別される： ◎ At-rules take many forms, depending on the specific rule and its purpose, but broadly speaking there are two kinds:＼

• `一文~at-規則@ （ `statement at-rule^en, “~blockを伴わない” ~at-規則） ⇒ これは、 `~block~at-規則$より単純な，~semicolonで終端する構成子である。 ◎ statement at-rules which are simpler constructs that end in a semicolon,＼
• `~block~at-規則@ （ `block at-rule^en, “~blockを伴う” ~at-規則 ） ⇒ これは、 `波括弧~block$で終端する構成子であり，入子な［ `有修飾~規則$／`~at-規則$／`宣言$ ］を包含できる。 ◎ and block at-rules which end in a {}-block that can contain nested qualified rules, at-rules, or declarations.

`~block~at-規則$は、 概して，［ `~at-規則$／`有修飾~規則$／`記述子~宣言$ ］たちが成す~collection【混在し得る】を包含する — それらには、 当の`~at-規則$に特有なものも, そうでない汎用なものもあり， 当の~at-規則により定義される制限の~subjectになる。 ◎ Block at-rules will typically contain a collection of (generic or at-rule–specific) at-rules, qualified rules, and/or descriptor declarations subject to limitations defined by the at-rule.＼

`記述子@ は，`~prop$に類似する（かつ同じ構文で宣言される）が、 ~tree内の［ 要素／~box ］ではなく，特定0の型の`~at-規則$に結付けられる。 ◎ Descriptors are similar to properties (and are declared with the same syntax) but are associated with a particular type of at-rule rather than with elements and boxes in the tree.

8.3. `charset^at 規則

~stylesheet用に`~fallback符号化法を決定する$~algoは、 ~fileの一番先頭から，特定の~byte列 — 構文上は［ 名前 "`charset^at" の`~at-規則$ ］の形をとる，少数の~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-規則$は，実際には無い。 `charset$at 規則のどの出現に対しても、 ~stylesheetを実際に構文解析するときは，認識できない規則として扱った上で、 ~stylesheetの文法を検査するときは，無効なものとして落とすモノトスル。 ◎ 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.

注記： CSS 2.1 においては、 `charset$at は妥当な規則であった。 旧来の仕様には、 依然として，［ `charset$at 規則を参照rして， ~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.

9.1. ~anb の直列化-法

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

~~主要な変更点は： ◎ The following substantive changes were made:

• `非~ASCII符号位置＠~TR/css-syntax-3/#non-ascii-code-point$ 【（旧）今や，`非~ASCII~ident符号位置$】 の定義を一部の面倒事になり得る符号位置を省略するよう制約した。 （ `7129$issue ） ◎ The definition of non-ASCII code point was restricted to omit some potentially troublesome codepoints. (7129)
• ［ 関数, ~at-規則 ］用の生成規則を定義した。 （ `5728$issue ） ◎ Defined the <foo()> and <@foo> productions. (5728)
• 入子な~style規則を許容した。 （ `7961$issue ）。 ◎ Allow nested style rules. (7961).
• 入子ngを許容するための一部として、 `§ 構文解析-法＠#parsing$の全体を有意に書き直した。 特に、［ `~stylesheetの内容を構文解析する$／`~blockの内容を構文解析する$ ］への支持を受けて，［ “規則たちが成す~listを構文解析する” ／ “宣言たちが成す~listを構文解析する” ］を除去した。 追加的な規範的な変更は、 ~semicolonは，一部の文脈では少し異なる~error回復を誘発するようになったことである — `media$at ~blockの様なものを構文解析した結果が， 入子にされていてもいなくても一致するよう。 （ `8834$issue ）。 ◎ As part of allowing Nesting, significantly rewrote the entire parsing section. Notably, removed "parse a list of rules" and "parse a list of declarations" in favor of "parse a stylesheet’s contents" and "parse a block’s contents". Only additional normative change is that semicolons trigger slightly different error-recovery now in some contexts, so that parsing of things like @media blocks is identical whether they’re nested or not. (8834).
• `urange^t 生成規則【 `unicode-range$tok 】を既存の~tokenに基づいて定義する試みを除去した。 代わりに，~sourceから特別に構文解析し直すことに依拠するようにした — 特定的には、 `unicode-range$d 記述子を構文解析する 【`~unicode-range~tokenを消費する$】とき。 （ `8835$issue ） ◎ Removed the attempt at a <urange> production in terms of existing tokens, instead relying on a special re-parse from source specifically when you’re parsing the unicode-range descriptor. (8835)
• 上により，~tokenの “表現” （構文解析する前の，元の文字列）を保全する必要もなくなったので、 `§ ~AnB 小構文＠anb-microsyntax$ にも残っていた “表現” への参照を除去した — 代わりに，それ用に必要yな少しばかりの情報（実数は明示的な符号を伴っていたか否か）を記録するだけにした。 ◎ Since the above removed the main need to preserve a token’s "representation" (the original string it was parsed from), removed the rest of the references to "representation" in the An+B section and instead just recorded the few bits of information necessary for that (whether or not the number had an explicit sign).
• 一部の利用（ `~custom~prop$, `unicode-range^d 記述子）が［ 宣言の値~全体を成す元の文字列への~access ］を要求することを明示的に注記して， それが構文解析器内のどこで生じるかを~markした。 ◎ Explicitly noted that some uses (custom properties, the unicode-range descriptor) require access to the original string of a declaration’s entire value, and marked where that occurs in the parser.
• `~blockの内容を消費する$ときには、 今や，当の内容を成す［ 規則たちに相対的な，宣言たちの順序 ］も保守される — 以前は、 どこに出現するかに関わらず， すべての宣言を一緒に~group化していた。 その情報で実際に何を行うものと決定するかは、 【当の内容を有する】個々の規則に委ねられる。 ◎ When consuming a block’s contents, rather than grouping all declarations together, regardless of where they appear relative to other rules, declarations now maintain their relative position wrt surrounding rules. It’s up to individual rules to determine what they actually do with that information.

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

~~主要な変更点は： ◎ The following substantive changes were made:

• `§ ~commaで分離された~listを ある~CSS文法に則って構文解析する＠#parse-comma-list$ ~algoを新たに追加した。 ◎ Added a new § 5.4.2 Parse a comma-separated list according to a CSS grammar algorithm.

• ［ ~style~blockの内容を構文解析する~algo, それに対応する `style-block^t 生成規則 ］†を新たに追加した。 `~style規則$は、 これらを利用するものと定義した。

  【† これらは、今や［ `~blockの内容を構文解析する$, `block-contents$t ］として定義し直された。 】

  ◎ Added a new "Parse a style block’s content" algorithm and a corresponding <style-block> production, and defined that style rules use it.
• `~stylesheetを構文解析する$ ~algoを Fetch 仕様に関係する `shenanigans^en に揃えた。 （ `commit＠https://github.com/w3c/csswg-drafts/commit/64becb59fe678760608a6f2a8d6bfb3a334500c9#diff-9d409f899ee6e2cc8cd87356d0e2a0ff739c5aa9663d83f49c951c379a38f1f6$ を見よ。） ◎ Aligned parse a stylesheet with the Fetch-related shenanigans. (See commit.) ◎ To parse a stylesheet from an input given an optional url location : • ... • Create a new stylesheet , with its location set to location (or null, if location was not passed). • ...

編集上の変更点は： ◎ The following editorial changes were made:

• ［ `~at-規則$, `一文~at-規則$, `~block~at-規則$, `記述子$ ］用の定義を供するため， `§ ~at-規則＠#at-rules$ を追加した （ `課題 #5633＠~CSSissue/5633$ ）。 ◎ Added § 8.2 At-rules to provide definitions for at-rules, statement at-rules, block at-rules, and descriptors. (5633)
• `宣言$用の定義~textを改善した。 ［ `~prop宣言$, `記述子~宣言$ ］用の定義を追加した。 ◎ Improved the definition text for declaration, and added definitions for property declarations and descriptor declarations.
• 何箇所かで利用していた用語 “名前” に代えて、 一貫して`~ident$を参照rするよう切替えた。 ◎ Switched to consistently refer to ident sequence, rather than sometimes using the term “name”.
• ~token化前の処理nのいくつかを明示的に命名して，それらを構文解析の入口から明示的に参照rするようにした （総括的な言明 “これらの~algoの開始-時には X を行うとする” に依拠するのでなく）。 ◎ Explicitly named several of the pre-tokenizing processes, and explicitly referred to them in the parsing entry points (rather than relying on a blanket "do X at the start of these algorithms" statement).
• “`~tokenの合間に~commentを挟む＠#_put-a-comment-between-tokens$” 表tに~entryを追加して、［ ~identは、 今や `--^c から開始し得る事実 ］を適正に取扱うようにした。 （ `pull #6874＠https://github.com/w3c/csswg-drafts/pull/6874$ ） ◎ Added more entries to the "put a comment between them" table, to properly handle the fact that idents can now start with --. (6874)

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, それが消費される時機 ］に関する，いくつかの構文解析器~algoの~bugを修正した。 ◎ Fixed a bug in several of the parser algorithms related to the current/next token and things getting consumed early/late.
• ~token化と構文解析~algoにおける いくつかの~bugを修正した。 ◎ Fix several bugs in the tokenization and parsing algorithms.
• ~identに類する~tokenの定義を［ `--^c から開始する~ident ］も許容するように変更した 【`参照＠#would-start-an-identifier$】 。 その~~一環として、［ `~tokenを消費する$ときの `2D^U 段を成す段たち ］を配列し直して， `CDC$tok が — `--^c `ident-token$t にはならずに — そう認識されるようにした。 ◎ Change the definition of ident-like tokens to allow "--" to start an ident. As part of this, rearrange the ordering of the clauses in the "-" step of consume a token so that <CDC-token>s are recognized as such instead of becoming a -- <ident-token>.
• `~anb$ の`周期$ ~IN { 1, −1 } のときは、 その数字は直列化しないようにした。 ◎ Don’t serialize the digit in an <an+b> when A is 1 or -1.
• すべての~tokenは `表現^dfn を持つように定義した 【が、廃された（ “.元の~text” に置換された）】 。 ◎ Define all tokens to have a representation.
• 2 個の符号位置が`妥当な~escape$を成すかどうか検査するときの，小さな~bugを修正した — ［ `5C^U, `EOF$tok ］が成す並びは、 今や，妥当な~escapeではないものと正しく報告される。 ~stylesheet内の最後の `\^c は、 今や，自身を `delim$tok として発するだけになる。 ◎ 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. A final \ in a stylesheet now just emits itself as a <delim-token>.
• `charset^at は、 もはや妥当な~CSS規則ではない （単に， `charset^at という名前の規則の`様に見える^em 符号化法~宣言があるに過ぎない）。 ◎ @charset is no longer a valid CSS rule (there’s just an encoding declaration that looks like a rule named @charset)
• 構文解析の間に，宣言の.値の［ 先頭／末尾 ］にある空白~並びは削るようにした。 ◎ Trimmed whitespace from the beginning/ending of a declaration’s value during parsing.
• ~WGによる解決にしたがって、 `Selectors^cite に特有な~tokenは除去した。 ◎ Removed the Selectors-specific tokens, per WG resolution.
• ~WGによる解決にしたがって、 入力~stream内の`~surrogate$は~filterするようにした。 この仕様~全体は、 今や，`~scalar値$のみに演算する。 ◎ Filtered surrogates from the input stream, per WG resolution. Now the entire specification operates only on scalar values.

編集上の変更点は： ◎ The following editorial changes were made:

• “文字列を消費する” ~algoは、 明示的な終端~符号位置を指定せずに~callできるようにされた。 その場合、 現在の~tokenが代わりに利用される。 これにより， 3 箇所の~call元に変更が加えられた。 ◎ The "Consume a string token" algorithm was changed to allow calling it without specifying an explicit ending token, so that it uses the current 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.
• 次に挙げる定義は、 `INFRA$r による定義に一致するので，除去した ⇒＃ “符号位置”, “~surrogate符号位置” ◎ Removed "code point" and "surrogate code point" in favor of the identical definitions in the Infra Standard.
• どの【符号位置】範囲も `inclusive^en であることを明確化した。 ◎ Clarified on every range that they are inclusive.
• `%^l `delim$tok ~tokenの次に出現する `number$tok を取扱うため、 `~comment挿入~表t＠#serialization-tables$に列を追加した。 ◎ Added a column to the comment-insertion table to handle a number token appearing next to a "%" delim token.

`各~commentに対する処置集＠https://github.com/w3c/csswg-drafts/milestone/5?closed=1$ もある。 ◎ A Disposition of Comments is available.

2013年 11月 5日 最終~作業草案からの変更点

• `§ 直列化＠#serialization$は、 “往復-” の要件のみが規範的になるように書き直され、 それを得るための方法の詳細は注記に移動された。 これらの詳細~における，いくつかの際どい事例は解消された。 ◎ 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";
  

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.

`CSS 2.1^cite, `Selectors Level 3^cite からの変更点

注記： この仕様の要点は、 実態に合致させることである — 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 ~registryではなく， `ENCODING$r を参照rするようにされた。 ◎ Refer to [ENCODING] rather than the IANA registry for character encodings.

~token化における変更点： ◎ 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列も， `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~ident符号位置$の定義は、 ~HTMLの`妥当な~custom要素~名$に整合するよう変更された。 ◎ The definition of non-ASCII ident code point was changed to be consistent with HTML’s valid custom element names.
• ~token化は、 もはや［ `COMMENT^c ／ `BAD_COMMENT^c ］~tokenを発することはない。 `BAD_COMMENT^c は今や，（~errorではない）通常の~tokenと同じものと見なされる。 分離される必要がある~token — 例えば 連続する 2 個の `ident$tok など — の合間に，必要yなだけ~commentを挿入することは、 `§ 直列化＠#serialization$が責を負う。 ◎ 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 ）が、 実施におけるその利用には影響iない筈である。 ◎ 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$iに際しては — `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 の中であることが~~判明した時点 ］で， 単に閉じられる箇所を見つけるために，他のすべてを無視して前方検索する。 この挙動は、［ それを `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.
• ~WGによる解決に従って、 ~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:

• ~WGによる解決に従って，今や、 どの`宣言~list$も `page$at のような~at-規則を受容する。 これにより，その種の~at-規則が未だ定義されていなかったとしても，~errorの取扱いには相違が生じる： `~at-規則$は、［ 妥当かどうか, `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 miscellaneous "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-規則の.導入部 ］は、 `at-keyword$tok 包含し得る。 ◎ Qualified rule and at-rule preludes can now contain <at-keyword-token>s

~AnB における， `Selectors Level 3^cite `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>).