CSS Syntax Module Level 3 （日本語訳）

~ABSTRACT

この~moduleは、 ~CSS~stylesheetの基本的な構造と構文を一般的な用語により述べるものである。それは、~CSSの構文と構文解析-法 — ~byte~streamを有意義な~stylesheetに転化する方法 — を詳細に定義する。 ◎ This module describes, in general terms, the basic structure and syntax of CSS stylesheets. It defines, in detail, the syntax and parsing of CSS - how to turn a stream of bytes into a meaningful stylesheet.

~CSSisaLANG

1. 序論

~INFORMATIVE

この~moduleは、 ~CSS~stylesheetの［抽象-構文と構文解析-法］を定義し，~CSS構文を利用する他のもの（~HTML `style^a 属性など）を定義する。 ◎ This module defines the abstract syntax and parsing of CSS stylesheets and other things which use CSS syntax (such as the HTML style attribute).

これは、［ ~Unicode `符号位置$の~stream（言い換えれば, ~text）］から，［ ~CSS~tokenの~stream ］へ変換するための一連の~algo，および［その結果の~streamから更に［ ~stylesheet, 規則, 宣言］などからなる，いくつかの~CSS~objへ変換する］ための一連の~algoを定義する。 ◎ It defines algorithms for converting a stream of Unicode code points (in other words, text) into a stream of CSS tokens, and then further into CSS objects such as stylesheets, rules, and declarations.

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.

【この訳に特有な表記規約】

この訳に利用される記号 ε, ~LET, ~IF, ~RET, 等々の意味や定義の詳細は、 ~SYMBOL_DEF_REFを~~参照されたし。

加えて、次の記法も用いる：

.%名前: ドットが接頭された %名前は，その %名前がこの仕様の処理~modelにて生産される~objが持つ［名前が %名前である~~属性~DAGGER ］であることを明示するときに利用される（文脈から明らかな所では，このドット付き表記は利用されない）。例えば “〜の.値” は、実際には，［ "`値^em" という名前の~~属性］の値を意味する。（~DAGGER この訳の中の各種~定義にしばしば現れる，この意味の “~~属性” という語は、訳の都合により導入したものであり，原文には無い非公式な用語である。）

2. ~CSSの構文の記述

~INFORMATIVE

~CSS文書は、一連の`~style規則$からなる — それら各~規則は、次のいずれかを与える ⇒＃ `有修飾~規則$（文書~内の要素に~styleを適用する）／ `~at-規則$（~CSS文書~用に特別な処理~規則や値を定義する） ◎ A CSS document is a series of style rules—which are qualified rules that apply styles to elements in a document—and at-rules—which define special processing rules or values for the CSS document.

`有修飾~規則$は， .`導入部^dfn から開始され，宣言~並びを包含している `波括弧~block$（ `{^c, `}^c で括られた~block）が後続する。 .導入部の意味は、その規則が出現する文脈に基づいて変わり得る — ~style規則に対しては、それは［その宣言が適用されることになる要素たち］を指定する`選択子$である。各~宣言は［名前, ~colon, 宣言~値］並びで与えられる。宣言と宣言は，~semicolonで分離される。 ◎ A qualified rule starts with a prelude then has a {}-wrapped block containing a sequence of declarations. The meaning of the prelude varies based on the context that the rule appears in—for style rules, it’s a selector which specifies what elements the declarations will apply to. Each declaration has a name, followed by a colon and the declaration value. Declarations are separated by semicolons.

典型的な規則は、次に様な見かけになろう： ◎ A typical rule might look something like this:

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

上の規則における "`p > a^css" が選択子である。 ~source文書が~HTMLであるならば、それは `p$e 要素の子であるような，あらゆる `a$e 要素を選択する。 ◎ In the above rule, "p > a" is the selector, which, if the source document is HTML, selects any a elements that are children of a p element.

"`color: blue^css" は、選択子に合致する要素に対し，それらの `color$p ~propが値 `blue^v になるべきであることを指定している宣言である。同様に、それらの `text-decoration$p ~propも，値 `underline$v になるべきであることになる。 ◎ "color: blue" is a declaration specifying that, for the elements that match the selector, their color property should have the value blue. Similarly, their text-decoration property should have the value underline.

~at-規則は、種類ごとに異なるものだが，基本的な構造は共通する： ◎ At-rules are all different, but they have a basic structure in common.＼

それらは、 `符号位置$ "@" で開始され, ~CSS~keywordとして名前が後続する。 ◎ They start with an "@" code point followed by their name as a CSS keyword.＼
一部の`~at-規則$は，単純な`一文$であり、その名前に［その挙動を指定する何個かの~CSS値］が後続し, ~semicolonで終端する。 ◎ Some at-rules are simple statements, with their name followed by more CSS values to specify their behavior, and finally ended by a semicolon.＼
他の`~at-規則$は、 ~blockである：それらにも，その名前に何個かの~CSS値が後続し得るが、 `有修飾~規則$と類似に，`波括弧~block$で終端する。この~blockの内容は，所与の`~at-規則$に特有なものであるが、それは， `有修飾~規則$の様に宣言~並びを包含することも, 追加的に何個かの［ ~block／~at-規則／その他の構造］を一緒に包含することもある。 ◎ Others are blocks; they can have CSS values following their name, but they end with a {}-wrapped block, similar to a qualified rule. Even the contents of these blocks are specific to the given at-rule: sometimes they contain a sequence of declarations, like a qualified rule; other times, they may contain additional blocks, or at-rules, or other structures altogether.

ここに、`~at-規則$が包含し得る種々の構文を解説するいくつかの例を示す： ◎ Here are several examples of at-rules that illustrate the varied syntax they may contain.

@import "my-styles.css";

`import$at `~at-規則$は，単純な`一文$であり、名前の後に［ ~importすべき~stylesheetを指示する 1 個の［文字列, または関数式 `url$f ］］をとる。 ◎ The @import at-rule is a simple statement. After its name, it takes a single string or url() function to indicate the stylesheet that it should import.

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

`page$at `~at-規則$は、［ ~page選択子（省略可能, この例では `:left^css 疑似類）, ［ ~pageの印刷~時に適用される，一連の~propからなる~block ］］並びである。この様に、それは［それらの~propが，どの “要素” にも適用されず, ~pageそれ自身に適用される］ことを除いて，通常の~style規則ととてもよく似る。 ◎ The @page at-rule consists of an optional page selector (the :left pseudoclass), followed by a block of properties that apply to the page when printed. In this way, it’s very similar to a normal style rule, except that its properties don’t apply to any "element", but rather the page itself.

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

`media$at `~at-規則$は、［ `媒体~型$, `媒体~query~list$（省略可能）］並びから始まる。その~blockは，［ `media$at 条件が充足されるときに限り適用される］ような規則~全体を包含する。 ◎ The @media at-rule begins with a media type and a list of optional media queries. Its block contains entire rules, which are only applied when the @medias conditions are fulfilled.

［ `~prop$ ／ `~at-規則$ ］の名前は、常に`~ident$であり： ◎ Property names and at-rule names are always ident sequences,＼

次のいずれかから開始する必要がある ⇒＃ `~identを開始する符号位置$／ 2 個の~hyphen ／［ 1 個の~hyphen, `~identを開始する符号位置$ ］並び ◎ which have to start with an ident-start code point, two hyphens, or a hyphen followed by an ident-start code point,＼
~~後続して 0 個以上の`~ident符号位置$を包含できる ◎ and then can contain zero or more ident code points.＼
上述に加えて，どこにでも、 `~escape法$により，どの`符号位置$も含めれる — それが，~CSSの構文に利用されるものであっても。 ◎ You can include any code point at all, even ones that CSS uses in its syntax, by escaping it.

【言い換えれば、次を満たす必要がある：［ `~identから開始している$ ］~AND［［ `~ident符号位置$／`妥当な~escape$を成す符号位置~並び］のみからなる］】

`選択子$の構文は、 `SELECT$r にて定義される。同様に，多岐に渡る~CSS値の構文は、 `CSS-VALUES-4$r `§ 値~定義の構文$にて定義される。個々の`~at-規則$の特別な構文は、それらを定義する仕様の中に見出せる。 ◎ The syntax of selectors is defined in the Selectors spec. Similarly, the syntax of the wide variety of CSS values is defined in the Values & Units spec. The special syntaxes of individual at-rules can be found in the specs that define them.

2.1. ~escape法

~INFORMATIVE

`~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$ ］, `空白$（省略可能）］並び。この~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の取扱い

~INFORMATIVE

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

各~構成子（宣言, ~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. ~CSSの~token化法と構文解析-法

~UAが，【~MIME型】 `text/css^c の資源から~CSSOM~tree `CSSOM$r を生成するときは、この仕様に述べられる構文解析~規則を利用するモノトスル。同時に，これらの規則は、 ~CSS構文解析器と~~呼ばれるものを定義する。 ◎ User agents must use the parsing rules described in this specification to generate the [CSSOM] trees from text/css resources. Together, these rules define what is referred to as the CSS parser.

この仕様は、［ ~CSS文書が構文上は正しいかどうかを調べるための構文解析~規則］を定義する。構文解析~algoの内側にて、 `構文解析error@ と記される箇所がある。その際の~errorの取扱いは、きちんと定義される — ~UAは，その種の問題に遭遇したときには、以下に述べる規則に従って動作するか, または［それらの規則を適用したいと望まない~errorに最初に遭遇した時点で，処理を中止する］モノトスル。 ◎ This specification defines the parsing rules for CSS documents, whether they are syntactically correct or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below.

適合性~検査器は、文書において 1 個以上の構文解析error【！error conditions】が生じたときには，それら~errorのうち 1 個以上を利用者に報告するモノトスル。また、それら~errorが複数個あるときは，それらのうち複数個を報告してもヨイ。逆に、文書に~errorが存在しない場合は，~errorを報告しないモノトスル。適合性~検査器には，構文解析errorから回復することは要求されないが、それを行う場合は，~UAと同じ仕方で回復するモノトスル。 ◎ Conformance checkers must report at least one parse error condition to the user if one or more parse error conditions exist in the document and must not report parse error conditions if none exist in the document. Conformance checkers may report more than one parse error condition if more than one parse error condition exists in the document. Conformance checkers are not required to recover from parse errors, but if they do, they must recover in the same way as user agents.

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の文字~符号化法に則って，その~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.

`~stylesheetの~byte列を復号する@ ときは、所与の %~stylesheet に対し，その~byte~streamを次に従って`符号位置$~streamの中へ復号する： ◎ To decode a stylesheet’s stream of bytes into a stream of code points:

%~fallback ~LET `~fallback符号化法を決定する$( %~stylesheet ) ◎ Determine the fallback encoding of stylesheet, and let fallback be the result.
~RET `~Unicodeに復号する$( %~stylesheet の~byte~stream, %~fallback ) ◎ Decode stylesheet’s stream of bytes with fallback encoding fallback, and return the result.

注記： `~Unicodeに復号する$ ~algoは、 ~BOM（ `byte order mark^en ／バイト順マーク）を優先する — ~fallbackを利用するのは、 ~BOMが見出されなかったときに限られる。 ◎ Note: The decode algorithm gives precedence to a byte order mark (BOM), and only uses the fallback when none is found.

`~fallback符号化法を決定する@ ときは、所与の %~stylesheet に対し： ◎ To determine the fallback encoding of a stylesheet:

~IF［ ~HTTPまたはそれに等価な~protocol ］は、 %~stylesheet 用の`符号化法~label$として %~label を供している（例： `Content-Type$h ~headerの `charset^c ~parameterを介して）］：
1. %符号化法 ~LET `~labelから符号化法を取得する$( %~label )
2. ~IF［ %符号化法 ~NEQ `失敗^i ］ ⇒ ~RET %符号化法
◎ If HTTP or equivalent protocol provides an encoding label (e.g. via the charset parameter of the Content-Type header) for the stylesheet, get an encoding from encoding label. If that does not return failure, return it.
~IF［ %~stylesheet を成す~byte~stream ］の［先頭から【~stream終端を超えない】 1024 個までの~byteが成す~byte列］の頭部は、次の~hex列に合致する］： ◎ Otherwise, check stylesheet’s 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＼

注記：この~byte列は、~ASCIIとして復号したときには，次の連結になる ⇒＃ `@charset "^l, %~label が表現する文字列, `";^l ◎ ↓
1. %符号化法 ~LET `~labelから符号化法を取得する$( %~label を~ASCIIとして解釈して得られる文字列 ) ◎ get an encoding from a string formed out of the sequence of XX bytes, interpreted as ASCII. ◎ 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.
2. ~IF［ %符号化法 ~NEQ `失敗^i ］：
  1. ~IF［ %符号化法 ~IN { `UTF-16BE$enc, `UTF-16LE$enc } ］ ⇒ ~RET `UTF-8$enc
  2. ~RET %符号化法
  ◎ If the return value was utf-16be or utf-16le, return utf-8; if it was anything else except failure, return it.
  宣言が~UTF-16のときに `UTF-8$enc を利用するのはなぜ？ ◎ Why use utf-8 when the declaration says utf-16?
  
  符号化法~宣言の~byte列は~ASCIIとしては “@charset "…";” になるが、 ~UTF-16は~ASCII互換でない。好ましい行いでないが，文書~内で正しい~byte列になるよう暗号的なもの（例： `䁣桡牳整•utf-16be∻^c ）を与えたとき、あるいは［文書が実際には~ASCII互換の符号化法でありつつ，符号化法~宣言が虚偽である場合］でも、 ~UTF-8を既定にしておくことが，あるべき挙動になる。 ◎ 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-規則$の構文に`似ているように見えるが^em、そのような規則は実際には存在しない — その書き方の規則は、そのような規則を認識する通常のあり方より，ずっと制約的である。 ~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.
~IF［参照元文書にて`環境~符号化法$が供されている］ ⇒ ~RET それ ◎ Otherwise, if an environment encoding is provided by the referring document, return it.
~RET `UTF-8$enc ◎ Otherwise, return utf-8.

注記： ~web用の符号化法は~UTF-8が既定であり，［ ~web用途の新たな~file形式の多くは，~UTF-8符号化法と見做す, あるいは要求している］が、 ~CSSは［どの符号化法が主流になるかはっきりする前の段階］で策定されたので、 ~stylesheetを自動的に~UTF-8と見做すわけにはいかない。 ◎ Though UTF-8 is the default encoding for the web, and many newer web-based file formats assume or require UTF-8 encoding, CSS was created before it was clear which encoding would win, and thus can’t automatically assume the stylesheet is UTF-8.

~stylesheet作者は、［ ~stylesheetを~UTF-8にした上で、 ~HTTP~header（または等価な手法）により， ~stylesheetの符号化法を~UTF-8であるものと宣言する］か［参照元文書の符号化法を~UTF-8として宣言する］`ベキ^emである。（~HTMLにおいてこれを行うには、文書の頭部（ `head^e 内）に `meta charset=utf-8^e 要素を与える。） ◎ Stylesheet authors should author their stylesheets in UTF-8, and ensure that either an HTTP header (or equivalent method) declares the encoding of the stylesheet to be UTF-8, or that the referring document declares its encoding to be UTF-8. (In HTML, this is done by adding a <meta charset=utf-8> element to the head of the document.)

これらのいずれも可用でない場合、作者は，［ ~stylesheetの先頭に~UTF-8~BOMを与える］か，あるいは［正確に次に一致する文字列を与える］べきである： ◎ If neither of these options are available, authors should begin the stylesheet with a UTF-8 BOM or the exact characters

@charset "utf-8";

［ ~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.

注記： ◎ ↓

`HTML$r は、 `link rel=stylesheet^e から参照rされる~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?>.
`CSS-CASCADE-3$r は、 `import$at 用の`環境~符号化法$を定義している。 ◎ Note: [CSS-CASCADE-3] defines the environment encoding for @import.

3.3. 入力~streamの前処理

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

`符号位置~列を~filterする@ ときは、所与の（~filter済みでない）`符号位置$列が成す~stream %入力に対し， %入力を成す各`符号位置$に応じて： ◎ To filter code points from a stream of (unfiltered) code points input:

次に該当するものは、除去する ⇒ `0D^U (CR) のうち，直後に `0A^U (LF) があるもの ◎ ↓
次に挙げるものは、 `0A^U (LF) に置換する ⇒＃前項に該当しない `0D^U (CR) ／ `0C^U (FF) ◎ 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) in input by a single U+000A LINE FEED (LF) code point.
次に挙げるものは、 `FFFD^U (LF) に置換する ⇒＃ `00^U／ `~surrogate$ ◎ Replace any U+0000 NULL or surrogate code points in input with U+FFFD REPLACEMENT CHARACTER (�).

4. ~token化

`符号位置$~stream %入力を~CSS~token~stream %出力の中へ `~token化する@ ときは：

~WHILE 無条件
1. %~token ~LET %入力から`~tokenを消費する$()
2. ~IF［ %~token は `EOF$tok である］ ⇒ ~BREAK
3. %出力の中へ %~token を~pushする

◎ To tokenize a stream of code points into a stream of CSS tokens input, repeatedly consume a token from input until an <EOF-token> is reached, pushing each of the returned tokens into a stream.

注記： `~tokenを消費する$~algoは、 `構文解析の間^emに［必要に応じて “その場で”， `符号位置$が成す~streamの~token化に利用できる］ようにするため，各~呼び出しに対し 1 個の~tokenを返す。 ◎ Note: Each call to the consume a token algorithm returns a single token, so it can also be used "on-demand" to tokenize a stream of code points during parsing, if so desired.

~token化の段における出力は、次に挙げる 0 個~以上の~tokenからなる並びが成す~streamである：

【各~tokenには，それが持ち得る~~属性の名前も挙げる。また、その~tokenが表す~CSSの代表的な構成子も併記する（これは、訳者による補足であり，該当する構成子を網羅するものでもない）。】

~token	~~属性	代表的な構成子（括弧内はその例）
`ident@tok	値	~keywordなどの`~CSS識別子$（ `auto^l ）
`function@tok	値	`関数-記法$の名前~部分（ `calc(^l ）
`at-keyword@tok	値	~at-規則（ "`@import`" ）
`hash@tok	値, 型~flag	`~ID選択子$（ `#ID^l ）／ 16 進数による色（ `#ABCDEF^l ）
`string@tok	値	文字列（ `'もじのならび'^l, 引用符~付き）
`bad-string@tok		合法でない文字列
`url@tok	値	~URL（ `url(example.png)^l ）
`bad-url@tok		合法でない~URL
`delim@tok	値	1 個の文字からなる一般的な分離子（`結合子$, `~importantな宣言$の `!^l など）
`number@tok	数値, 型~flag	単位の無い数値（ `123.45^l ）
`percentage@tok	数値,	百分率（ `33.3%^l ）
`dimension@tok	数値, 型~flag, 単位	単位~付きの数値（ `1.5em^l ）
`whitespace@tok		空白
`CDO@tok		`<!--^l — 埋め込み~stylesheetの中の~HTML~commentの~~開始
`CDC@tok		`-->^l — 同上, ~HTML~commentの~~終了
`colon@tok		`:^l — `宣言$の中の~propの名前と値を分離する~colon
`semicolon@tok		`;^l — `宣言$の並びを分離する~semicolon
`comma@tok		`,^l — 成分~値の並びを分離する~comma
`open-square@Tok		`[^l — `属性~選択子$を括る角括弧
`close-square@Tok		`]^l — 同上
`open-paren@Tok		`(^l — `条件付き~group規則$に与える条件を括る丸括弧
`close-paren@Tok		`)^l — 同上
`open-curly@Tok		`{^l — 宣言~listを括る波括弧
`close-curly@Tok		`}^l — 同上

◎ The output of tokenization step is a stream of zero or more of the following tokens: <ident-token>, <function-token>, <at-keyword-token>, <hash-token>, <string-token>, <bad-string-token>, <url-token>, <bad-url-token>, <delim-token>, <number-token>, <percentage-token>, <dimension-token>, <whitespace-token>, <CDO-token>, <CDC-token>, <colon-token>, <semicolon-token>, <comma-token>, <[-token>, <]-token>, <(-token>, <)-token>, <{-token>, and <}-token>.

各種~~属性がとり得る値は： ◎ ↓

［ `ident$tok ／ `function$tok ／ `at-keyword$tok ／ `hash$tok ／ `string$tok ／ `url$tok ］の .`値^dfn は、 0 個以上の`符号位置$からなる。 ◎ <ident-token>, <function-token>, <at-keyword-token>, <hash-token>, <string-token>, and <url-token> have a value composed of zero or more code points.＼
`hash$tok の .`型~flag^dfn は、［ `無制約^i （既定）, `id^i ］のいずれかである。 ◎ Additionally, hash tokens have a type flag set to either "id" or "unrestricted". The type flag defaults to "unrestricted" if not otherwise set.
`delim$tok の .`値^dfn は、 1 個の`符号位置$からなる。 ◎ <delim-token> has a value composed of a single code point.
［ `number$tok ／ `percentage$tok ／ `dimension$tok ］の .`数値^dfn は、実数を与える。 ◎ <number-token>, <percentage-token>, and <dimension-token> have a numeric value.＼
［ `number$tok ／ `dimension$tok ］の .`型~flag^dfn は、［ `整数^i （既定）, `実数^i ］のいずれかである。 ◎ <number-token> and <dimension-token> additionally have a type flag set to either "integer" or "number". The type flag defaults to "integer" if not otherwise set.＼
`dimension$tok の .`単位^dfn は、 1 個以上の`符号位置$からなる。 ◎ <dimension-token> additionally have a unit composed of one or more code points.

注記： `hash$tok の.型~flagは，~Selectors構文 `SELECT$r にて利用される。［型~flag: `id^i ］を伴う `hash$tok のみが，妥当な `~ID選択子$になる。 ◎ Note: The type flag of hash tokens is used in the Selectors syntax [SELECT]. Only hash tokens with the "id" type are valid ID selectors.

4.1. ~tokenの線路図式

~INFORMATIVE

この節では、 ~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（`前処理$前の改行文字）: `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
`CDC$tok: `CDC-token^dgm

4.2. 定義

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

`次入力~符号位置@ ◎ next input code point

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

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

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

すでに消費された`符号位置$のうち，最後のもの。 ◎ 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” と略記する。】 ◎ EOF code point

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

各種符号位置の範囲

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

`数字@ ◎ 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 }
`指数~指示子@ 【これは、この訳による追加的な定義】: { `45^U, `65^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; これらの文字に特定的に限られるのは，なぜか？ ◎ 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 にて識別子~用に推奨される制約の集合（~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 (archived) を見よ。 ◎ 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 } `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.
`空白@ ◎ whitespace: `改行文字$ ∪ { `09^U, `20^U } ◎ A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE.

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

~Unicodeにて定義されている最~大な`符号位置$： `10FFFF^U 。 ◎ 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 （ “~identを成す（ 1 個以上の符号位置からなる）連列” ）と記されており，素直に訳すなら “~ident列” の様になろうが、それだと `sequence of idents^en （ “1 個以上の~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.

`表現@ ◎ representation

~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として］のどちらで記されたか — これは基本的に，~token化法の抽象-化に~~本質的でない漏洩になるが、実装を定義し易くなるので許容される。

◎ 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が，［この仕様における~token化~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.

“〜の符号位置を消費する” 【この項は、この訳による補完】

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

“~streamから`次入力~符号位置を繰返し消費する@：” 【この項は、この訳による補完】

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

`次入力~符号位置$を消費する
`現入力~符号位置$に応じて、［後続の~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.

この節における表記 ⇒ “新たな `foo^tok ( %名前: %値 , … )”

は、新たに作成される~token `foo^tok の~instanceであって，その各種~~属性が括弧内に記された様に初期化されたものを表す（ “値” という名前の~~属性もあることに注意）。定数~token（ ~~属性を持たない~token ）の~instanceは、単に `foo^tok の様に記される。

4.3.1. ~tokenを消費する

この節では、 `符号位置$の~streamから `~tokenを消費する@ 方法を述べる。それは、いずれかの型の 1 個の~tokenを返す： ◎ This section describes how to consume a token from a stream of code points. It will return a single token of any type.

`~comment列を消費する$() ◎ Consume comments.
~streamから`次入力~符号位置を繰返し消費する$： ◎ Consume the next input code point.
`空白$
1. アリな限り多くの`空白$を消費する
2. ~RET `whitespace$tok
◎ Consume as much whitespace as possible. Return a <whitespace-token>.
`22^U
1. ~RET `文字列~tokenを消費する$()
◎ Consume a string token and return it.
`23^U
1. ~IF［ `次入力~符号位置$ ~IN `~ident符号位置$ ］~OR［ `次の 2 個の入力~符号位置$は，`妥当な~escape$を成す］： ◎ If the next input code point is an ident code point or the next two input code points are a valid escape, then:
  1. %型 ~LET ［次が満たされるならば `id^i ／ ~ELSE_ `無制約^i ］ ⇒ `次の 3 個の入力~符号位置$は`~identから開始している$ ◎ Create a <hash-token>. ◎ If the next 3 input code points would start an ident sequence, set the <hash-token>’s type flag to "id".
  2. %値 ~LET `~identを消費する$() ◎ Consume an ident sequence, and set the <hash-token>’s value to the returned string.
  3. ~RET 新たな `hash$tok ( 値: %値 , 型~flag: %型 ) ◎ Return the <hash-token>.
2. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`27^U
1. ~RET `文字列~tokenを消費する$()
◎ Consume a string token and return it.
`28^U
1. ~RET `open-paren$Tok
◎ Return a <(-token>.
`29^U
1. ~RET `close-paren$Tok
◎ Return a <)-token>.
`2B^U
1. ~IF［入力~streamは `実数から開始している$ ］：
  1. `現入力~符号位置を消費し直す$
  2. ~RET `数量-~tokenを消費する$()
  ◎ If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
2. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`2C^U
1. ~RET `comma$tok
◎ Return a <comma-token>.
`2D^U
1. ~IF［入力~streamは `実数から開始している$ ］：
  1. `現入力~符号位置を消費し直す$
  2. ~RET `数量-~tokenを消費する$()
  ◎ If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
2. ~IF［ `次の 2 個の入力~符号位置$は［ `2D^U, `3E^U ］並びである］：
  1. それらを消費する
  2. ~RET `CDC$tok
  ◎ Otherwise, if the next 2 input code points are U+002D HYPHEN-MINUS U+003E GREATER-THAN SIGN (->), consume them and return a <CDC-token>.
3. ~IF［入力~streamは `~identから開始している$ ］：
  1. `現入力~符号位置を消費し直す$
  2. ~RET `~identに類する~tokenを消費する$()
  ◎ Otherwise, if the input stream starts with an ident sequence, reconsume the current input code point, consume an ident-like token, and return it.
4. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`2E^U
1. ~IF［入力~streamは `実数から開始している$ ］：
  1. `現入力~符号位置を消費し直す$
  2. ~RET `数量-~tokenを消費する$()
  ◎ If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
2. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`3A^U
1. ~RET `colon$tok
◎ Return a <colon-token>.
`3B^U
1. ~RET `semicolon$tok
◎ Return a <semicolon-token>.
`3C^U
1. ~IF［ `次の 3 個の入力~符号位置$は［ `21^U, `2D^U, `2D^U ］並びである］：
  1. それらを消費する
  2. ~RET `CDO$tok
  ◎ If the next 3 input code points are U+0021 EXCLAMATION MARK U+002D HYPHEN-MINUS U+002D HYPHEN-MINUS (!--), consume them and return a <CDO-token>.
2. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`40^U
1. ~IF［ `次の 3 個の入力~符号位置$は，`~identから開始している$ ］： ◎ If the next 3 input code points would start an ident sequence,＼
  1. %名前 ~LET `~identを消費する$() ◎ consume an ident sequence,＼
  2. ~RET 新たな `at-keyword$tok ( 値: %名前 ) ◎ create an <at-keyword-token> with its value set to the returned value, and return it.
2. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Otherwise, return a <delim-token> with its value set to the current input code point.
`5B^U
1. ~RET `open-square$Tok
◎ Return a <[-token>.
`5C^U
1. ~IF［入力~streamは `妥当な~escapeから開始している$ ］：
  1. `現入力~符号位置を消費し直す$
  2. ~RET `~identに類する~tokenを消費する$()
  ◎ If the input stream starts with a valid escape, reconsume the current input code point, consume an ident-like token, and return it.
2. `構文解析error$ ◎ Otherwise, this is a parse error.＼
3. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ ) ◎ Return a <delim-token> with its value set to the current input code point.
`5D^U
1. ~RET `close-square$Tok
◎ Return a <]-token>.
`7B^U
1. ~RET `open-curly$Tok
◎ Return a <{-token>.
`7D^U
1. ~RET `close-curly$Tok
◎ Return a <}-token>.
`数字$
1. `現入力~符号位置を消費し直す$
2. ~RET `数量-~tokenを消費する$()
◎ Reconsume the current input code point, consume a numeric token, and return it.
`~identを開始する符号位置$ ◎ ident-start code point
1. `現入力~符号位置を消費し直す$
2. ~RET `~identに類する~tokenを消費する$()
◎ Reconsume the current input code point, consume an ident-like token, and return it.
~EOF
1. ~RET `EOF$tok
◎ Return an <EOF-token>.
他全部
1. ~RET 新たな `delim$tok ( 値: `現入力~符号位置$ )
◎ Return a <delim-token> with its value set to the current input code point.

4.3.2. ~comment列を消費する

この節では、 `符号位置$の~streamから `~comment列を消費する@ 方法を述べる。それは ε を返す： ◎ This section describes how to consume comments from a stream of code points. It returns nothing.

~WHILE［ `次の 2 個の入力~符号位置$は［ `2F^U, `2A^U ］並びである］：
1. その 2 個を消費する
2. 最初の［［ `2A^U, `2F^U ］並び, または~EOF ］までのすべての`符号位置$を消費する
◎ If the next two input code point are U+002F SOLIDUS (/) followed by a U+002A ASTERISK (*), consume them and all following code points up to and including the first U+002A ASTERISK (*) followed by a U+002F SOLIDUS (/), or up to an EOF code point. Return to the start of this step.
~IF［前段の繰返nは~EOFを消費して終えた］ ⇒ `構文解析error$ ◎ If the preceding paragraph ended by consuming an EOF code point, this is a parse error.
~RET ε ◎ Return nothing.

4.3.3. 数量-~tokenを消費する

この節では、 `符号位置$の~streamから `数量-~tokenを消費する@ 方法を述べる。それは［ `number$tok ／ `percentage$tok ／ `dimension$tok ］を返す： ◎ This section describes how to consume a numeric token from a stream of code points. It returns either a <number-token>, <percentage-token>, or <dimension-token>.

( 数値: %num , 型~flag: %型 ) ~LET `実数を消費する$() ◎ Consume a number and let number be the result.
~IF［ `次の 3 個の入力~符号位置$は，`~identから開始している$ ］：
1. %単位 ~LET `~identを消費する$()
2. ~RET 新たな `dimension$tok ( 数値: %num , 型~flag: %型 , 単位: %単位 )
◎ If the next 3 input code points would start an ident sequence, then: • Create a <dimension-token> with the same value and type flag as number, and a unit set initially to the empty string. • Consume an ident sequence. Set the <dimension-token>’s unit to the returned value. • Return the <dimension-token>.
~IF［ `次入力~符号位置$ ~EQ `25^U ］：
1. それを消費する
2. ~RET 新たな `percentage$tok ( 数値: %num )
◎ Otherwise, if the next input code point is U+0025 PERCENTAGE SIGN (%), consume it. Create a <percentage-token> with the same value as number, and return it.
~RET 新たな `number$tok ( 型~flag: %型 , 数値: %num ) ◎ Otherwise, create a <number-token> with the same value and type flag as number, and return it.

4.3.4. ~identに類する~tokenを消費する

この節では、 `符号位置$の~streamから `~identに類する~tokenを消費する@ 方法を述べる。それは［ `ident$tok ／ `function$tok ／ `url$tok ／ `bad-url$tok ］を返す： ◎ This section describes how to consume an ident-like token from a stream of code points. It returns an <ident-token>, <function-token>, <url-token>, or <bad-url-token>.

%文字列 ~LET `~identを消費する$() ◎ Consume an ident sequence, and let string be the result.
~IF［ %文字列 ~EQ`大小無視$sub `url^l ］~AND［ `次入力~符号位置$ ~EQ `28^U ］： ◎ If string’s value is an ASCII case-insensitive match for "url", and the next input code point is U+0028 LEFT PARENTHESIS ((),＼
1. それを消費する ◎ consume it.＼
2. ~WHILE ［ `次の 2 個の入力~符号位置$は，いずれも`空白$である］ ⇒ `次入力~符号位置$を消費する ◎ While the next two input code points are whitespace, consume the next input code point.＼
3. ~IF［ `次の 2 個の入力~符号位置$ %c1, %c2 は、次のいずれかを満たす］…：
  - %c1 ~IN { `22^U, `27^U } （ %c2 は任意）
  - ［ %c1 は`空白$である］~AND［ %c2 ~IN { `22^U, `27^U } ］
  …ならば：
  1. `現入力~符号位置を消費し直す$
  2. ~RET 新たな `function$tok ( 値: %文字列 )
  【引数が引用符で括られた `url("…")^c のような文字列は、 `function$tok と引数の並びと見なされる。】
  ◎ If the next one or two input code points are U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), or whitespace followed by U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE ('), then create a <function-token> with its value set to string and return it.＼
4. ~RET `~url~tokenを消費する$() ◎ Otherwise, consume a url token, and return it.
~IF［ `次入力~符号位置$ ~EQ `28^U ］：
1. それを消費する
2. ~RET 新たな `function$tok ( 値: %文字列 )
◎ Otherwise, if the next input code point is U+0028 LEFT PARENTHESIS ((), consume it. Create a <function-token> with its value set to string and return it.
~RET 新たな `ident$tok ( 値: %文字列 ) ◎ Otherwise, create an <ident-token> with its value set to string and return it.

4.3.5. 文字列~tokenを消費する

この節では、 `符号位置$の~streamから `文字列~tokenを消費する@ 方法を述べる。それは［ `string$tok ／ `bad-string$tok ］を返す： ◎ This section describes how to consume a string token from a stream of code points. It returns either a <string-token> or <bad-string-token>.

この~algoは［文字列を終端させる`符号位置$を表す %終端ng符号位置］も伴って呼ばれることもある。 %終端ng符号位置が指定されずに呼ばれた場合、 `現入力~符号位置$がそれに利用される。【終端ng符号位置までは消費されつつ，結果の文字列には終端ng符号位置は含まれない。】 ◎ This algorithm may be called with an ending code point, which denotes the code point that ends the string. If an ending code point is not specified, the current input code point is used.

%文字列 ~LET 空~文字列 ◎ Initially create a <string-token> with its value set to the empty string.
~streamから`次入力~符号位置を繰返し消費する$： ◎ Repeatedly consume the next input code point from the stream:
%終端ng符号位置
1. ~RET 新たな `string$tok ( 値: %文字列 )
◎ Return the <string-token>.
~EOF
1. `構文解析error$
2. ~RET 新たな `string$tok ( 値: %文字列 )
◎ This is a parse error. Return the <string-token>.
`改行文字$
1. `構文解析error$
2. `現入力~符号位置を消費し直す$
3. ~RET `bad-string$tok
◎ This is a parse error. Reconsume the current input code point, create a <bad-string-token>, and return it.
`5C^U

`次入力~符号位置$に応じて：

~EOF

何もしない

`改行文字$

それを消費する

その他（~streamは `妥当な~escapeから開始している$）

%文字列に次の結果を付加する ⇒ `~escapeされた符号位置を消費する$()

◎ If the next input code point is EOF, do nothing. ◎ Otherwise, if the next input code point is a newline, consume it. ◎ Otherwise, (the stream starts with a valid escape) consume an escaped code point and append the returned code point to the <string-token>’s value.

他全部
1. %文字列に`現入力~符号位置$を付加する
◎ Append the current input code point to the <string-token>’s value.

4.3.6. ~url~tokenを消費する

この節では、 `符号位置$の~streamから `~url~tokenを消費する@ 方法を述べる。それは［ `url$tok ／ `bad-url$tok ］を返す： ◎ This section describes how to consume a url token from a stream of code points. It returns either a <url-token> or a <bad-url-token>.

注記：この~algoは、直前に `url(^l が消費-済みであると見做す。また、 `url(foo)^v の様な “引用符で括られてない” 値を消費するために呼ばれているものと見做す。 `url("foo")^v の様に引用符で括られた値は、 `function-token$t として構文解析される。 `~identに類する~tokenを消費する$~algoは、この~~区別を自動的に取扱う — この~algoは、他からは直に呼ばれるベキでない。 ◎ Note: This algorithm assumes that the initial "url(" has already been consumed. This algorithm also assumes that it’s being called to consume an "unquoted" value, like url(foo). A quoted value, like url("foo"), is parsed as a <function-token>. Consume an ident-like token automatically handles this distinction; this algorithm shouldn’t be called directly otherwise.

%~URL ~LET 空~文字列 ◎ Initially create a <url-token> with its value set to the empty string.
アリな限り多くの`空白$を消費する ◎ Consume as much whitespace as possible.
~streamから`次入力~符号位置を繰返し消費する$： ◎ Repeatedly consume the next input code point from the stream:
`29^U
1. ~RET 新たな `url$tok ( 値: %~URL )
◎ Return the <url-token>.
~EOF
1. `構文解析error$
2. ~RET 新たな `url$tok ( 値: %~URL )
◎ This is a parse error. Return the <url-token>.
`空白$
1. アリな限り多くの`空白$を消費する ◎ Consume as much whitespace as possible.＼
2. `次入力~符号位置$に応じて：
  ~EOF
  
  それを消費する
  
  `構文解析error$
  
  ~RET 新たな `url$tok ( 値: %~URL )
  
  `29^U
  
  それを消費する
  
  ~RET 新たな `url$tok ( 値: %~URL )
  
  その他
  
  `不良~urlの残余を消費する$()
  
  ~RET `bad-url$tok
  ◎ If the next input code point is U+0029 RIGHT PARENTHESIS ()) or EOF, consume it and return the <url-token> (if EOF was encountered, this is a parse error); otherwise, consume the remnants of a bad url, create a <bad-url-token>, and return it.
`22^U

`27^U

`28^U

`印字不能~符号位置$
1. `構文解析error$
2. `不良~urlの残余を消費する$()
3. ~RET `bad-url$tok
◎ This is a parse error. Consume the remnants of a bad url, create a <bad-url-token>, and return it.
`5C^U
1. ~IF［ ~streamは `妥当な~escapeから開始している$ ］： ◎ If the stream starts with a valid escape,＼
  1. %~escape ~LET `~escapeされた符号位置を消費する$() ◎ consume an escaped code point and＼
  2. %~URL に %~escape を付加する ◎ append the returned code point to the <url-token>’s value.
2. ~ELSE：
  1. `構文解析error$
  2. `不良~urlの残余を消費する$()
  3. ~RET `bad-url$tok
  ◎ Otherwise, this is a parse error. Consume the remnants of a bad url, create a <bad-url-token>, and return it.
他全部
1. %~URL に`現入力~符号位置$を付加する
◎ Append the current input code point to the <url-token>’s value.

4.3.7. ~escapeされた符号位置を消費する

この節では、 `~escapeされた符号位置を消費する@ 方法を述べる。これは、［直前に `5C^U が消費-済みである］かつ［次入力~符号位置が`妥当な~escape$の一部を成している］ことが検証y-済みであると見做す。これは、 1 個の`符号位置$を返す： ◎ This section describes how to consume an escaped code point. It assumes that the U+005C REVERSE SOLIDUS (\) has already been consumed and that the next input code point has already been verified to be part of a valid escape. It will return a code point.

`次入力~符号位置$を消費する ◎ Consume the next input code point.
`現入力~符号位置$に応じて： ◎ ↓
`~hex$
1. %~hex列 ~LET `現入力~符号位置$ ◎ ↓
2. %~hex列に［ 5 個までアリな限り多くの`~hex$を消費した結果］を付加する ◎ Consume as many hex digits as possible, but no more than 5. Note that this means 1-6 hex digits have been consumed in total.＼
3. ~IF［ `次入力~符号位置$ ~IN `空白$ ］ ⇒ それも消費する ◎ If the next input code point is whitespace, consume it as well.＼
4. %数値 ~SET %~hex列を16 進数として解釈した結果 ◎ Interpret the hex digits as a hexadecimal number.＼
5. ~IF［ %数値 ~EQ 0 ］~OR［ %数値 ~IN `~surrogate$ ］~OR［ %数値 ~GT `許容される最大な符号位置$ ］ ⇒ ~RET `FFFD^U ◎ If this number is zero, or is for a surrogate, or is greater than the maximum allowed code point, return U+FFFD REPLACEMENT CHARACTER (�).＼
6. ~RET %数値を値とする `符号位置$ ◎ Otherwise, return the code point with that value.
~EOF
1. `構文解析error$
2. ~RET `FFFD^U
◎ This is a parse error. Return U+FFFD REPLACEMENT CHARACTER (�).
他全部

~RET `現入力~符号位置$ ◎ Return the current input code point.

4.3.8. ［ 2 個の符号位置］並びが，妥当な~escapeを成すかどうかの検査

この節では、 2 個の符号位置からなる並び［ %c0, %c1 ］が `妥当な~escape@ を成すかどうか検査する方法を述べる。この~algoの入力には、入力~streamそのものが渡されることもある — その場合、［ %c0 ~SET `現入力~符号位置$, %c1 ~SET `次入力~符号位置$ ］とする。 ◎ This section describes how to check if two code points are a valid escape. The algorithm described here can be called explicitly with two code points, or can be called with the input stream itself. In the latter case, the two code points in question are the current input code point and the next input code point, in that order.

注記：この~algoは`符号位置$を消費しない。 ◎ Note: This algorithm will not consume any additional code point.

~RET［次が満たされるならば ~T ／ ~ELSE_ ~F ］ ⇒ ［ %c0 ~EQ `5C^U ］~AND［ %c1 は`改行文字$でない］ ◎ If the first code point is not U+005C REVERSE SOLIDUS (\), return false. ◎ Otherwise, if the second code point is a newline, return false. ◎ Otherwise, return true.

4.3.9. ［ 3 個の符号位置］並びが，~identを開始しているかどうかの検査

この節では、 3 個の符号位置~並び［ %c0, %c1, %c2 ］が `~identから開始している@ かどうか検査する方法を述べる。この~algoの入力には、入力~streamそのものが渡されることもある — その場合、［ %c0, %c1, %c2 ］ ~SET ［ `現入力~符号位置$, `次の 2 個の入力~符号位置$ ］とする。 ◎ This section describes how to check if three code points would start an ident sequence. The algorithm described here can be called explicitly with three code points, or can be called with the input stream itself. In the latter case, the three code points in question are the current input code point and the next two input code points, in that order.

注記：この~algoは`符号位置$を消費しない。 ◎ Note: This algorithm will not consume any additional code points.

~RET［［ %c0, %c1, %c2 ］が次の表のいずれかの行に示される条件を満たすならば ~T ／ ~ELSE_ ~F ］：

%c0	%c1	%c2
`2D^U	`~identを開始する符号位置$	(任意)
`2D^U	`2D^U	(任意)
`2D^U	`妥当な~escape$を成す
`~identを開始する符号位置$	(任意)	(任意)
`妥当な~escape$を成す		(任意)

Look at the first code point:

U+002D HYPHEN-MINUS: If the second code point is an ident-start code point or a U+002D HYPHEN-MINUS, or the second and third code points are a valid escape, return true. Otherwise, return false.
ident-start code point: Return true.
U+005C REVERSE SOLIDUS (\): If the first and second code points are a valid escape, return true. Otherwise, return false.
anything else: Return false.

4.3.10. ［ 3 個の符号位置］並びが，実数を開始しているかどうかの検査

この節では、 3 個の符号位置~並び［ %c0, %c1, %c2 ］が `実数から開始している@ かどうか検査する方法を述べる。この~algoの入力には、入力~streamそのものが渡されることもある — その場合、［ %c0, %c1, %c2 ］ ~SET ［ `現入力~符号位置$, `次の 2 個の入力~符号位置$ ］とする。 ◎ This section describes how to check if three code points would start a number. The algorithm described here can be called explicitly with three code points, or can be called with the input stream itself. In the latter case, the three code points in question are the current input code point and the next two input code points, in that order.

注記：この~algoは`符号位置$を消費しない。 ◎ Note: This algorithm will not consume any additional code points.

~RET［［ %c0, %c1, %c2 ］が次の表のいずれかの行に示される条件を満たすならば ~T ／ ~ELSE_ ~F ］：

%c0 %c1 %c2

`正負符号$ `数字$ (任意)
`正負符号$ `2E^U `数字$
`2E^U `数字$ (任意)
`数字$ (任意) (任意)

Look at the first code point:

U+002B PLUS SIGN (+)

U+002D HYPHEN-MINUS (-)

If the second code point is a digit, return true.

Otherwise, if the second code point is a U+002E FULL STOP (.) and the third code point is a digit, return true.

Otherwise, return false.

U+002E FULL STOP (.)

If the second code point is a digit, return true. Otherwise, return false.

digit

Return true.

anything else

Return false.

%c0	%c1	%c2
`正負符号$	`数字$	(任意)
`正負符号$	`2E^U	`数字$
`2E^U	`数字$	(任意)
`数字$	(任意)	(任意)

4.3.11. ~identを消費する

この節では、 `符号位置$の~streamから `~identを消費する@ 方法を述べる。それは、~stream内の，次の`符号位置$から始まる最長な名前を成す文字列を返す。 ◎ This section describes how to consume an ident sequence from a stream of code points. It returns a string containing the largest name that can be formed from adjacent code points in the stream, starting from the first.

注記：この~algoは、［返される`符号位置$が `ident$tok の一部を成すこと］を確保するために必要な，［最初の少数の`符号位置$の検証y ］は行わない。意図的にそのように利用するときは、［ ~streamは`~identから開始している$こと］を事前に確保すること。 ◎ Note: This algorithm does not do the verification of the first few code points that are necessary to ensure the returned code points would constitute an <ident-token>. If that is the intended use, ensure that the stream starts with an ident sequence before calling this algorithm.

%結果 ~LET 空~文字列 ◎ Let result initially be an empty string.
~streamから`次入力~符号位置を繰返し消費する$： ◎ Repeatedly consume the next input code point from the stream:
`~ident符号位置$ ◎ ident code point
1. %結果にその`符号位置$を付加する
◎ Append the code point to result.
~streamは`妥当な~escapeから開始している$ ◎ the stream starts with a valid escape
1. %結果に次の結果を付加する ⇒ `~escapeされた符号位置を消費する$()
◎ Consume an escaped code point. Append the returned code point to result.
他全部
1. `現入力~符号位置を消費し直す$
2. ~RET %結果
◎ Reconsume the current input code point. Return result.

4.3.12. 実数を消費する

この節では、 `符号位置$の~streamから `実数を消費する@ 方法を述べる。それは、 ( %数値, %型~flag ) が成す組を返す — %型~flag は［ `整数^i, `実数^i ］のいずれかをとり得る。 ◎ This section describes how to consume a number from a stream of code points. It returns a numeric value, and a type which is either "integer" or "number".

注記：この~algoは、［ ~streamから実数が得せること］を確保するために必要な，［最初の少数の`符号位置$の検証y ］を行わない。呼ぶ際には，［ ~streamは`実数から開始している$こと］を事前に確保すること。 ◎ Note: This algorithm does not do the verification of the first few code points that are necessary to ensure a number can be obtained from the stream. Ensure that the stream starts with a number before calling this algorithm.

%型 ~LET `整数^i ◎ Execute the following steps in order:
%表現 ~LET 空~文字列 ◎ Initially set type to "integer". Let repr be the empty string.
~IF［ `次入力~符号位置$ ~IN `正負符号$ ］ ⇒ それを消費して、その結果を %表現に付加する ◎ If the next input code point is U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-), consume it and append it to repr.
~WHILE［ `次入力~符号位置$ ~IN `数字$ ］ ⇒ それを消費して、その結果を %表現に付加する ◎ While the next input code point is a digit, consume it and append it to repr.
~IF［ `次の 2 個の入力~符号位置$は［ `2E^U, `数字$ ］並びである］： ◎ If the next 2 input code points are U+002E FULL STOP (.) followed by a digit, then:
1. それらを消費して、その結果を %表現に付加する ◎ Consume them. ◎ Append them to repr.
2. %型 ~SET `実数^i ◎ Set type to "number".
3. ~WHILE［ `次入力~符号位置$ ~IN `数字$ ］ ⇒ それを消費して、その結果を %表現に付加する ◎ While the next input code point is a digit, consume it and append it to repr.
~IF［［ `次の 3 個の入力~符号位置$は［ `指数~指示子$, `正負符号$, `数字$ ］並びである］~OR［ `次の 2 個の入力~符号位置$は［ `指数~指示子$, `数字$ ］並びである］］： ◎ If the next 2 or 3 input code points are U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), optionally followed by U+002D HYPHEN-MINUS (-) or U+002B PLUS SIGN (+), followed by a digit, then:
1. それらを消費して、その結果を %表現に付加する ◎ Consume them. ◎ Append them to repr.
2. %型 ~SET `実数^i ◎ Set type to "number".
3. ~WHILE［ `次入力~符号位置$ ~IN `数字$ ］ ⇒ それを消費して、その結果を %表現に付加する ◎ While the next input code point is a digit, consume it and append it to repr.
~RET ( 数値: %表現を`実数に変換-$した結果, 型~flag: %型 ) が成す組 ◎ Convert repr to a number, and set the value to the returned value. ◎ Return value and type.

4.3.13. 文字列を実数に変換する

この節では、文字列を `実数に変換-@ する方法を述べる。それは、実数を返す。 ◎ This section describes how to convert a string to a number. It returns a number.

注記：この~algoは、［文字列が実数のみを包含しているかどうか］は検証yしない。 ~algoを呼ぶ際には，［文字列が妥当な~CSS実数のみを包含している］ことを事前に確保すること。 ◎ Note: This algorithm does not do any verification to ensure that the string contains only a number. Ensure that the string contains only a valid CSS number before calling this algorithm.

文字列を先頭から順に 7 個の成分に分割0する： ◎ Divide the string into seven components, in order from left to right:
1. 符号 — 0 〜 1 個の`正負符号$ ⇒ %s ~LET ［符号 ~EQ `2D^U ならば −1 ／ ~ELSE_ 1 ］ ◎ A sign: a single U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-), or the empty string. Let s be the number -1 if the sign is U+002D HYPHEN-MINUS (-); otherwise, let s be the number 1.
2. 整数部 — 0 個以上の`数字$ ⇒ %i ~LET 整数部を 10 進~整数として解釈した結果~DAGGER ◎ An integer part: zero or more digits. If there is at least one digit, let i be the number formed by interpreting the digits as a base-10 integer; otherwise, let i be the number 0.
3. 小数点 — 0 〜 1 個の `2E^U ◎ A decimal point: a single U+002E FULL STOP (.), or the empty string.
4. 小数部 — 0 個以上の`数字$ ⇒＃ %d ~LET 数字の個数, %f ~LET 小数部を 10 進~整数として解釈した結果~DAGGER ◎ A fractional part: zero or more digits. If there is at least one digit, let f be the number formed by interpreting the digits as a base-10 integer and d be the number of digits; otherwise, let f and d be the number 0.
5. 指数~指示子 — 0 〜 1 個の`指数~指示子$ ◎ An exponent indicator: a single U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), or the empty string.
6. 指数~符号 — 0 〜 1 個の`正負符号$ ⇒ %t ~LET ［指数~符号 ~EQ `2D^U ならば −1 ／ ~ELSE_ 1 ］ ◎ An exponent sign: a single U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-), or the empty string. Let t be the number -1 if the sign is U+002D HYPHEN-MINUS (-); otherwise, let t be the number 1.
7. 指数 — 0 個以上の`数字$ ⇒ %e ~LET 指数を 10 進~整数として解釈した結果~DAGGER ◎ An exponent: zero or more digits. If there is at least one digit, let e be the number formed by interpreting the digits as a base-10 integer; otherwise, let e be the number 0.
~DAGGER ［整数部／小数部／指数］を成す文字が 0 個の場合（空~文字列）、 0 に解釈する。
~RET ［ %s ~MUL ( %i ~PLUS %f ~MUL 10^−%d ) ~MUL 10^{%t ~MUL %e} ］ ◎ Return the number s·(i + f·10-d)·10te.

4.3.14. 不良~urlの残余を消費する

この節では、 ~tokenizerが，`符号位置$の~streamにおいて［ `url$tok ではなく，`bad-url$tok の中途にある］ことが~~判明した際の “後始末” のために、 `不良~urlの残余を消費する@ 方法を述べる。それは ε を返し、もっぱら，［通常の~token化処理を再開できるような回復~地点に達するまで，入力~streamを十分に消費する］ために利用される。 ◎ This section describes how to consume the remnants of a bad url from a stream of code points, "cleaning up" after the tokenizer realizes that it’s in the middle of a <bad-url-token> rather than a <url-token>. It returns nothing; its sole use is to consume enough of the input stream to reach a recovery point where normal tokenizing can resume.

~streamから`次入力~符号位置を繰返し消費する$： ◎ Repeatedly consume the next input code point from the stream:
`29^U

~EOF
1. ~RET ε
◎ Return.
入力~streamは `妥当な~escapeから開始している$ ◎ the input stream starts with a valid escape
1. `~escapeされた符号位置を消費する$()
◎ Consume an escaped code point.＼
注記：これは、 `bad-url$tok を終端させずに，［ ~escapeされた閉じ丸括弧（ `\)^l ）］を取り込めるようにする。それ以外については “他全部” の段と一致する。 ◎ This allows an escaped right parenthesis ("\)") to be encountered without ending the <bad-url-token>. This is otherwise identical to the "anything else" clause.

他全部
1. 何もしない
◎ Do nothing.

5. 構文解析-法

構文解析段階への入力は、［ ~stream, または ~token化~段階から得られた~token~list ］である。その出力は、構文解析器が［この節にて後に定義される，一連の入口］のうちどれを介して呼出されたかに依存する。構文解析器の出力は、何個かの［ `~at-規則$, `有修飾~規則$, `宣言$ ］の混成からなる。 ◎ The input to the parsing stage is a stream or list of tokens from the tokenization stage. The output depends on how the parser is invoked, as defined by the entry points listed later in this section. The parser output can consist of at-rules, qualified rules, and/or declarations.

構文解析器の出力は、 ~CSSの基礎的な構文に則って構築される — 特定のどの~itemについても，その妥当性を問うことなく。実装は、種々の構文解析器~algoから~itemが返され次第，それらの~itemの妥当性を検査した上で、 ~itemが実装~自身に備わる文法の知識に則って無効なものであった際には，［その~algoから ε が返されたものと扱う］か, あるいは［指定dどおりに全部的な~treeを構築した上で、無効な~itemは何であれ，除去する］ことにより，それらを “一掃” してもヨイ。 ◎ The parser’s output is constructed according to the fundamental syntax of CSS, without regards for the validity of any specific item. Implementations may check the validity of items as they are returned by the various parser algorithms and treat the algorithm as returning nothing if the item was invalid according to the implementation’s own grammar knowledge, or may construct a full tree as specified and "clean up" afterwards by removing any invalid items.

結果の~treeには、以下に挙げる~itemが出現し得る（一部の~itemには，いくつかの~~属性が伴われる）： ◎ The items that can appear in the tree are:

`~at-規則$ ◎ at-rule

次に挙げる~~属性を持つ：

.`名前^dfn
.`導入部^dfn — `成分~値$~list
.`~block^dfn（省略可能） — `波括弧~block$

◎ An at-rule has a name, a prelude consisting of a list of component values, and an optional block consisting of a simple {} block.

注記：この仕様は、 ~at-規則の.~blockが何を包含し得るかについては，制限sを課さない。個々の`~at-規則$は、それが~blockを受容するかどうか, および受容する場合には［その~blockを構文解析する方法］を定義しなければナラナイ（この仕様が定義する，構文解析器の［ ~algo／入口］のうちいずれかを利用するのが好ましい）。 ◎ Note: This specification places no limits on what an at-rule’s block may contain. Individual at-rules must define whether they accept a block, and if so, how to parse it (preferably using one of the parser algorithms or entry points defined in this specification).

`有修飾~規則@ ◎ qualified rule

次に挙げる~~属性を持つ：

.`導入部^dfn — `成分~値$~list
.`~block^dfn — `波括弧~block$

◎ A qualified rule has a prelude consisting of a list of component values, and a block consisting of a simple {} block.

注記：ほとんどの有修飾~規則は、その［ .導入部は`選択子$, .~blockは`宣言~list$ ］を与えるような，~style規則になる。 ◎ Note: Most qualified rules will be style rules, where the prelude is a selector [SELECT] and the block a list of declarations.

`宣言@ ◎ declaration

宣言は、概念的には，ある［ `~prop$／`記述子$ ］の名前をある値に結付ける，特定0の~instanceである。 ◎ Conceptually, declarations are a particular instance of associating a property or descriptor name with a value.＼

構文上は、次に挙げる~~属性を持つ：

.`名前^dfn
.`値^dfn — `成分~値$~list
.`~importantか^dfn — 真偽値, 初期~時は ~F 【`~importantな宣言$になるかどうかを指示する。】

◎ Syntactically, a declaration has a name, a value consisting of a list of component values, and an important flag which is initially unset.

宣言は更に， `~prop宣言@ と `記述子~宣言@ に分類される。前者は、 `有修飾~規則$内で出現することが最も多く，~CSS`~prop$を設定する。後者は、 `~at-規則$内に限り出現し，~CSS`記述子$を設定する。（この分類は、この仕様の構文~levelにおいては生じない — それは，宣言が出現する所における産物であり、当の規則を定義する仕様により定義される。） ◎ Declarations are further categorized as property declarations or descriptor declarations, with the former setting CSS properties and appearing most often in qualified rules and the latter setting CSS descriptors, which appear only in at-rules. (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

［ `function$tok, `open-curly$Tok, `open-paren$Tok, `open-square$Tok ］以外の，~tokenizerにより生産される任意の~token。 ◎ 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

次に挙げる~~属性を持つ：

.`名前^dfn
.`値^dfn — `成分~値$~list

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

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

次に挙げる~~属性を持つ：

.`開き括弧^dfn ~DAGGER — 次のいずれか ⇒＃ `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.

~DAGGER `単純~block$は、その.開き括弧の値に応じて，順に `角括弧~block@ （`{}-block^en）, `丸括弧~block@ （`()-block^en）, `波括弧~block@ （`{}-block^en）と称される。 ◎ {}-block, []-block, and ()-block refer specifically to a simple block with that corresponding associated token.

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

~INFORMATIVE

この節は、構文解析器の参考~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
`Rule list^sb（`規則~list$）: `rule-list^dgm
`At-rule^sb（`~at-規則$）: `at-rule^dgm
`Qualified rule^sb（`有修飾~規則$）: `qualified-rule^dgm
`Declaration list^sb（`宣言~list$）: `declaration-list^dgm
`Declaration^sb（`宣言$）: `declaration^dgm
`!important^sb: `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@ ◎ current input token

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

`次入力~token@ ◎ next input 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を消費する@ ◎ consume the next input token

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

`現入力~tokenを消費し直す@ ◎ reconsume the current input 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を繰返し消費する@：” 【この項は、この訳による補完】

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

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

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

5.3. 構文解析器の入口

この節に定義する各種~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 are operate on a token stream as input, but for convenience can also be invoked with a number of other value types.

`~token~streamに正規化する@ ときは、所与の %入力に対し，その型に応じて： ◎ To normalize into a token stream a given input:

~CSS~tokenたちが成す~list／ ~CSS成分~値たちが成す~list ⇒ ~RET %入力 ◎ If input is a list of CSS tokens, return input. ◎ If input is a list of CSS component values, return input.

注記：［ ~tokenたちが成す~list, 成分~値たちが成す~list ］の間の唯一の相違は、［関数や~blockの様な，何かを “包含する” 一部の~obj ］は［成分~値~list内では 1 個の実体を成すが，~token~list内では複数個の実体を成す］ことにある。この仕様~内の~algoに対しては、このことにより生じる相違はない。 ◎ Note: The only difference between a list of tokens and a list of component values is that some objects that "contain" things, like functions or blocks, are a single entity in the component-value list, but are multiple entities in a token list. This makes no difference to any of the algorithms in this specification.
`文字列$ ⇒ ~RET `~token化する$( `符号位置~列を~filterする$( %入力 ) ) ◎ If input is a string, then filter code points from input, tokenize the result, and return the final result.
その他 ⇒ ~Assert：この事例は生じ得ない — %入力として渡されるのは、上に挙げた型に限られるベキである。 ◎ Assert: Only the preceding types should be passed as input.

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

以下の注記は、おそらく，関連な仕様の規範的な~textに — この仕様の用語を通して — 翻訳されるべきである： ◎ The following notes should probably be translated into normative text in the relevant specs, hooking this spec’s terms:

“`~stylesheetを構文解析する$” は、 ~stylesheetを構文解析するときの，構文解析器の通常の入口になることが意図されている。 ◎ "Parse a stylesheet" is intended to be the normal parser entry point, for parsing stylesheets.
“`規則~listを構文解析する$” は、 ~at-規則（ `media$at など）の内容~用に意図されている。それは、［ `CDO$tok, `CDC$tok ］の取扱いにおいて， “`~stylesheetを構文解析する$” と異なる。 ◎ "Parse a list of rules" is intended for the content of at-rules such as @media. It differs from "Parse a stylesheet" in the handling of <CDO-token> and <CDC-token>.
“`規則を構文解析する$” は、 ~textを構文解析して 1 個の規則を得る［ `CSSStyleSheet$I の `insertRule()^c ~method ］その他の類似な関数からの利用が意図されている。 ◎ "Parse a rule" is intended for use by the CSSStyleSheet#insertRule method, and similar functions which might exist, which parse text into a single rule.
“`宣言を構文解析する$” は、 `条件付き~group規則$（ `supports$at ）からの利用が意図されている。 `CSS3-CONDITIONAL$r ◎ "Parse a declaration" is used in @supports conditions. [CSS3-CONDITIONAL]
“`宣言~listを構文解析する$” は、 `style^a 属性の内容~用に，~textを 1 個の~style規則の内容として構文解析する。 ◎ "Parse a list of declarations" is for the contents of a style attribute, which parses text into the contents of a single style rule.
“`成分~値を構文解析する$” は、 `attr$f の構文解析~規則の様な， 1 個の値を消費するために必要になる。 ◎ "Parse a component value" is for things that need to consume a single value, like the parsing rules for attr().
“`成分~値~listを構文解析する$” は、呈示~用の属性の内容~text【`非~CSS呈示~用~hint$など】を 1 個の宣言~値として構文解析したり，［【！~Selectors~API】 `querySelector()$c などの選択子~APIに渡す自立的な`選択子$ ／ ~HTMLの `media$a 属性に与える`媒体~query~list$ ］を構文解析するためにある。 ◎ "Parse a list of component values" is for the contents of presentational attributes, which parse text into a single declaration’s value, or for parsing a stand-alone selector [SELECT] or list of Media Queries [MEDIAQ], as in Selectors API or the media HTML attribute.

5.3.1. ある~CSS文法に則って何かを構文解析する

文字列や~token~listを構文解析して，何らかの~CSS文法に合致するかどうか見た上で、合致したならば，その文法に則って各成分に切り分けたい（ `destructure^en ）と欲されることは多い。この節では、この種の演算~用に汎用な~hookを供する。それは、 “ %foo を~CSS `color$t 文法に則って構文解析する” 等々のように呼出されるべきである。 ◎ It is often desirable to parse a string or token list to see if it matches some CSS grammar, and if it does, to destructure it according to the grammar. This section provides a generic hook for this kind of operation. It should be invoked like "parse foo as a CSS <color>", or similar.

この~algoは、所与の［供された文法に対応する構造が指定されていない入力］が，その文法に［合致しないならば `失敗^i ／合致するならばその文法に則って入力を構文解析した結果］を返す。結果とヤリトリできるのは、表現の多義性が問題にならない所, かつ仕様の注釈文に限られなければナラナイ。仕様~言語の外側へ公開することが意味される場合、その仕様は，結果を［きちんと指定された表現］に明示的に翻訳しなければナラナイ — 例えば、（ “~CSS `string$t として直列化する” の様に）何らかの~CSS直列化~algoを呼出して。 ◎ This algorithm returns either failure, if the input does not match the provided grammar, or the result of parsing the input according to the grammar, which is an unspecified structure corresponding to the provided grammar specification. The return value must only be interacted with by specification prose, where the representation ambiguity is not problematic. If it is meant to be exposed outside of spec language, the spec using the result must explicitly translate it into a well-specified representation, such as, for example, by invoking a CSS serialization algorithm (like "serialize as a CSS <string> value").

注記：他の仕様から~callしたいと求まれる構文解析~algoは、 `通例的に^em，［この~algo, および`~commaで分離された~listを~CSS文法に則って構文解析する$ ］に限られる。残りの構文解析~algoは、ほとんど［ `CSSOM$r, それに関係する “明示的に~CSS構造を構築する” 事例］用に意味される — それらの~algoを利用する必要があると~~考えている策定者は、まず~CSS~WGに指導を諮られたし。 ◎ Note: This algorithm, and parse a comma-separated list according to a CSS grammar, are usually the only parsing algorithms other specs will want to call. The remaining parsing algorithms are meant mostly for [CSSOM] and related "explicitly constructing CSS structures" cases. Consult the CSSWG for guidance first if you think you need to use one of the other algorithms.

何かを `~CSS文法に則って構文解析する@ （略して，単に “構文解析する” ）ときは、所与の ( %入力, ~CSS文法 %生成規則 ) に対し： ◎ To parse something according to a CSS grammar (aka simply parse) given an input and a CSS grammar production:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
%結果 ~LET %入力から`成分~値~listを構文解析する$ ◎ Parse a list of component values from input, and let result be the return value.
~RET %結果が %生成規則の文法に［合致するならば，合致した結果／合致しないならば `失敗^i ］ ◎ Attempt to match result against grammar. If this is successful, return the matched result; otherwise, return failure.

5.3.2. ~commaで分離された~listをある~CSS文法に則って構文解析する

~commaを伴う値でも，`~CSS文法に則って構文解析する$ことはもちろんできるが、値を成す`すべての部分^emが成功裡に構文解析されない限り， `失敗^i を返すことになる。 ◎ While one can definitely parse a value according to a grammar with commas in it, if any part of the value fails to parse, the entire thing doesn’t parse, and returns failure.

それが欲されることもあるが（~CSS~propのうち`~list値をとる$ものなど）、値を成す各~commaで分離された下位部分を別々に構文解析して，［各~結果に対し、成功したか失敗したかに応じて，別な仕方で処する］方が良いこともある（失敗した場合、概して，無視されよう — `img$e の `sizes$a 属性を構文解析するときなど）。 ◎ Sometimes that’s what’s desired (such as in list-valued CSS properties); other times, it’s better to let each comma-separated sub-part of the value parse separately, dealing with the parts that parse successfully one way, and the parts that fail to parse another way (typically ignoring them, such as in <img sizes>).

次の~algoは、これを成遂げるための容易な~hookを供する。それは、 “~top-level” の~commaで分割された値たちが成す~listを返す — ~listを成す各~値は、［ `失敗^i （構文解析-に失敗した）／構文解析した結果（`構文解析-$する~algoにて述べたとおり，構造が未指定な）］になる。 ◎ This algorithm provides an easy hook to accomplish exactly that. It returns a list of values split by "top-level" commas, where each values is either failure (if it failed to parse) or the result of parsing (an unspecified structure, as described in the parse algorithm).

`~commaで分離された~listを~CSS文法に則って構文解析する@ （略して，単に “~listを構文解析する” ）ときは、所与の ( %入力, ~CSS文法 %生成規則 ) に対し： ◎ To parse a comma-separated list according to a CSS grammar (aka parse a list) given an input and a CSS grammar production:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~IF［ %入力は `whitespace$tok 以外のものを包含しない］ ⇒ ~RET 空~list ◎ If input contains only <whitespace-token>s, return an empty list.
%~list ~LET %入力から`~commaで分離された成分~値~listを構文解析する$ ◎ Parse a comma-separated list of component values from input, and let list be the return value.
%~list を成す ~EACH( %~item ) に対し ⇒ %~item を次の結果に置換する ⇒ `~CSS文法に則って構文解析する$( %~item, %生成規則 ) ◎ For each item of list, replace item with the result of parsing item with grammar.
~RET %~list ◎ Return list.

5.3.3. ~stylesheetを構文解析する

%入力から `~stylesheetを構文解析する@ ときは、所与の ( `~URL$ %所在（省略時は ~NULL ）) に対し： ◎ To parse a stylesheet from an input given an optional url location:

~IF［ %入力は~stylesheet用の~byte~streamである］ ⇒ %入力 ~SET `~stylesheetの~byte列を復号する$( %入力 ) ◎ If input is a byte stream for stylesheet, decode bytes from input, and set input to the result.
%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
%~stylesheet ~LET 新たな`~CSS~stylesheet$ ◎ Create a new stylesheet,＼
%~stylesheet の`所在$ss ~SET %所在 ◎ with its location set to location (or null, if location was not passed).
%~stylesheet の値 ~SET %入力から`規則~listを消費する$( `~top-level^i ) ◎ Consume a list of rules from input, with the top-level flag set, and set the stylesheet’s value to the result.
~RET %~stylesheet ◎ Return the stylesheet.

5.3.4. 規則~listを構文解析する

%入力から `規則~listを構文解析する@ ときは： ◎ To parse a list of rules from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~RET %入力から`規則~listを消費する$( `~top-level^i ) ◎ Consume a list of rules from the input, with the top-level flag unset. ◎ Return the returned list.

5.3.5. 規則を構文解析する

%入力から `規則を構文解析する@ ときは： ◎ To parse a rule from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~WHILE［ %入力の`次入力~token$は `whitespace$tok である］ ⇒ %入力から`次入力~tokenを消費する$ ◎ While the next input token from input is a <whitespace-token>, consume the next input token from input.
~IF［ %入力の`次入力~token$は `EOF$tok である］ ⇒ ~RET 構文~error ◎ If the next input token from input is an <EOF-token>, return a syntax error.
~IF［ %入力の`次入力~token$は `at-keyword$tok である］ ⇒ %規則 ~LET %入力から`~at-規則を消費する$() ◎ Otherwise, if the next input token from input is an <at-keyword-token>, consume an at-rule from input, and let rule be the return value.
~ELSE：
1. %規則 ~LET %入力から`有修飾~規則を消費する$()
2. ~IF［ %規則 ~EQ ε ］ ⇒ ~RET 構文~error
◎ Otherwise, consume a qualified rule from input and let rule be the return value. If nothing was returned, return a syntax error.
~WHILE［ %入力の`次入力~token$は `whitespace$tok である］ ⇒ %入力から`次入力~tokenを消費する$ ◎ While the next input token from input is a <whitespace-token>, consume the next input token from input.
~IF［ %入力の`次入力~token$は `EOF$tok である］ ⇒ ~RET %規則 ◎ If the next input token from input is an <EOF-token>, return rule.＼
~RET 構文~error ◎ Otherwise, return a syntax error.

5.3.6. 宣言を構文解析する

注記： “`宣言~listを構文解析する$” ときと異なり、これは宣言のみを構文解析し，~at-規則は構文解析しない。 ◎ Note: Unlike "Parse a list of declarations", this parses only a declaration and not an at-rule.

%入力から `宣言を構文解析する@ ときは： ◎ To parse a declaration from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~WHILE［ %入力の`次入力~token$は `whitespace$tok である］ ⇒ %入力から`次入力~tokenを消費する$ ◎ While the next input token from input is a <whitespace-token>, consume the next input token.
~IF［ %入力の`次入力~token$は `ident$tok でない］ ⇒ ~RET 構文~error ◎ If the next input token from input is not an <ident-token>, return a syntax error.
%宣言 ~LET %入力から`宣言を消費する$() ◎ Consume a declaration from input.＼
~IF［ %宣言 ~NEQ ε ］ ⇒ ~RET %宣言 ◎ If anything was returned, return it.＼
~RET 構文~error ◎ Otherwise, return a syntax error.

5.3.7. ~style~blockの内容を構文解析する

注記：この~algoは、 `~style規則$のうち，その~block内に［ `入子に^emされた~style規則, 他の`~at-規則$ ］を許容する必要があるものを構文解析する。入子な`~style規則$は必要ない場合 — ［ `page$at ／ `keyframes$at 【内の】子~規則］内など — `宣言~list$を利用すること。 ◎ Note: This algorithm parses the contents of style rules, which need to allow nested style rules and other at-rules. If you don’t need nested style rules, such as in @page or in @keyframes child rules, use parse a list of declarations.

%入力から `~style~blockの内容を構文解析する@ ときは： ◎ To parse a style block’s contents from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~RET %入力から`~style~blockの内容を消費する$() ◎ Consume a style block’s contents from input, and return the result.

5.3.8. 宣言~listを構文解析する

注記：その名前に反し、これは，実際には［宣言と~at-規則］が混在する~listを構文解析する — CSS 2.1 の `page$at に対し行われるように。期待されない~at-規則（所与の文脈~内の，すべてを占め得る）は、無効であり，消費側からは無視されることになる。 ◎ Note: Despite the name, this actually parses a mixed list of declarations and at-rules, as CSS 2.1 does for @page. Unexpected at-rules (which could be all of them, in a given context) are invalid and will be ignored by the consumer.

注記：この~algoは、入子な`~style規則$を取扱わない。それが要求される場合、 `~style~blockの内容を構文解析する$を利用すること。 ◎ Note: This algorithm does not handle nested style rules. If your use requires that, use parse a style block’s contents.

%入力から `宣言~listを構文解析する@ ときは： ◎ To parse a list of declarations from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~RET %入力から`宣言~listを消費する$() ◎ Consume a list of declarations from input, and return the result.

5.3.9. 成分~値を構文解析する

%入力から `成分~値を構文解析する@ ときは： ◎ To parse a component value from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
~WHILE［ %入力の`次入力~token$は `whitespace$tok である］ ⇒ %入力から`次入力~tokenを消費する$ ◎ While the next input token from input is a <whitespace-token>, consume the next input token from input.
~IF［ %入力の`次入力~token$は `EOF$tok である］ ⇒ ~RET 構文~error ◎ If the next input token from input is an <EOF-token>, return a syntax error.
%成分~値 ~LET %入力から`成分~値を消費する$() ◎ Consume a component value from input and let value be the return value.
~WHILE［ %入力の`次入力~token$は `whitespace$tok である］ ⇒ %入力から`次入力~tokenを消費する$ ◎ While the next input token from input is a <whitespace-token>, consume the next input token.
~IF［ %入力の`次入力~token$は `EOF$tok である］ ⇒ ~RET %成分~値 ◎ If the next input token from input is an <EOF-token>, return value.＼
~RET 構文~error ◎ Otherwise, return a syntax error.

5.3.10. 成分~値~listを構文解析する

%入力から `成分~値~listを構文解析する@ ときは： ◎ To parse a list of component values from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
%~list ~LET 空~list ◎ ↓
~WHILE 無条件：
1. %成分~値 ~LET %入力から`成分~値を消費する$()
2. ~IF［ %成分~値は `EOF$tok である］ ⇒ ~BREAK
3. %~list に %成分~値を付加する
◎ Repeatedly consume a component value from input until an <EOF-token> is returned, appending the returned values (except the final <EOF-token>) into a list.＼
~RET %~list ◎ Return the list.

5.3.11. ~commaで分離された成分~値~listを構文解析する

%入力から `~commaで分離された成分~値~listを構文解析する@ ときは： ◎ To parse a comma-separated list of component values from input:

%入力 ~SET `~token~streamに正規化する$( %入力 ) ◎ Normalize input, and set input to the result.
%成分~値~listの~list ~LET 空~list ◎ Let list of cvls be an initially empty list of component value lists.
~WHILE［ `現入力~token$は `EOF$tok でない］：
1. %~list ~LET 空~list
2. ~WHILE 無条件：
  1. %成分~値 ~LET %入力から`成分~値を消費する$()
  2. ~IF［ %成分~値は［ `EOF$tok ／ `comma$tok ］である ⇒ ~BREAK
  3. %~list に %成分~値を付加する
3. %成分~値~listの~list に %~list を付加する
◎ Repeatedly consume a component value from input until an <EOF-token> or <comma-token> is returned, appending the returned values (except the final <EOF-token> or <comma-token>) into a list. Append the list to list of cvls. ◎ If it was a <comma-token> that was returned, repeat this step.
~RET %成分~値~listの~list ◎ Return list of cvls.

5.4. 構文解析器~algo

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

これらの~algoは、［ ~token~list, 成分~値~list ］のいずれかを伴って呼ばれ得る。【！混成／別種？／一部の~algoが？】（`成分~値$~listにおいては，一部の~tokenが［ `関数式$／`単純~block$ ］に置換される点で異なる）。 ~token化~段階において，入力~streamから［それが空である【消費され尽くした】ことを表現する`~EOF符号位置$が返される］のと同様に、この段階における~listでは、［次の~tokenが要請されたが，それが空であるときは、 `EOF$tok を返す］モノトスル。 ◎ 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.

この節における表記 ⇒ “新たな %~obj ( %名前: %値 , … )”

は、新たに作成される %~obj の~instanceであって，その各種~~属性が括弧内に記されたように初期化されたものを表す。

5.4.1. 規則~listを消費する

`規則~listを消費する@ ときは、所与の ( %~top-levelか ~IN { `~top-level^i , ε } （省略時は ε ） ) に対し： ◎ To consume a list of rules, given a top-level flag:

%規則~list ~LET 新たな`~list$ ◎ Create an initially empty list of rules.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token:
`whitespace$tok
1. 何もしない ◎ Do nothing.
`EOF$tok
1. ~RET %規則~list ◎ Return the list of rules.
`CDO$tok

`CDC$tok
1. ~IF［ %~top-levelか ~EQ `~top-level^i ］ ⇒ 何もしない ◎ If the top-level flag is set, do nothing.
2. ~ELSE： ◎ Otherwise,＼
  1. `現入力~tokenを消費し直す$ ◎ reconsume the current input token.＼
  2. %規則 ~LET `有修飾~規則を消費する$() ◎ Consume a qualified rule.＼
  3. ~IF［ %規則 ~NEQ ε ］ ⇒ %規則~list に %規則を付加する ◎ If anything is returned, append it to the list of rules.
`at-keyword$tok
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %規則~list に次の結果を付加する ⇒ `~at-規則を消費する$() ◎ Consume an at-rule, and append the returned value to the list of rules.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %規則 ~LET `有修飾~規則を消費する$() ◎ Consume a qualified rule.＼
3. ~IF［ %規則 ~NEQ ε ］ ⇒ %規則~list に %規則を付加する ◎ If anything is returned, append it to the list of rules.

5.4.2. ~at-規則を消費する

`~at-規則を消費する@ ときは： ◎ To consume an at-rule:

%~token ~LET `次入力~tokenを消費する$ ◎ Consume the next input token.＼
%~at-規則 ~LET 新たな`~at-規則$( 名前: %~token の.値 , 導入部: 空~list, ~block: ε ) ◎ Create a new at-rule with its name set to the value of the current input token, its prelude initially set to an empty list, and its value initially set to nothing.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token:
`semicolon$tok
1. ~RET %~at-規則 ◎ Return the at-rule.
`EOF$tok
1. `構文解析error$ ◎ This is a parse error.＼
2. ~RET %~at-規則 ◎ Return the at-rule.
`open-curly$Tok
1. %~at-規則の.~block ~SET `単純~blockを消費する$() ◎ Consume a simple block and assign it to the at-rule’s block.＼
2. ~RET %~at-規則 ◎ Return the at-rule.
`波括弧~block$ ◎ simple block with an associated token of <{-token>
1. %~at-規則の.~block ~SET その~block ◎ Assign the block to the at-rule’s block.＼
2. ~RET %~at-規則 ◎ Return the at-rule.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %~at-規則の.導入部に次の結果を付加する ⇒ `成分~値を消費する$() ◎ Consume a component value. Append the returned value to the at-rule’s prelude.

5.4.3. 有修飾~規則を消費する

`有修飾~規則を消費する@ ときは、所与の ( 真偽値 %宣言~群と混合されるか（省略時は ~F ） ) に対し： ◎ To consume a qualified rule, given an optional mixed with declarations boolean (defaulting to false): To consume a qualified rule:

%規則 ~LET 新たな`有修飾~規則$( 導入部: 新たな`~list$, ~block: ε ) ◎ Create a new qualified rule with its prelude initially set to an empty list, and its block initially set to nothing.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token:
`EOF$tok
1. `構文解析error$ ◎ This is a parse error.＼
2. ~RET ε ◎ Return nothing.
`semicolon$tok
1. ~IF［ %宣言~群と混合されるか ~EQ ~T ］：
  1. `構文解析error$
  2. ~RET ε
  ◎ If mixed with declarations is true, this is a parse error; return nothing.
2. %規則の.導入部に `semicolon$tok を付加する ◎ Otherwise, append a <semicolon-token> to the qualified rule’s prelude.
`open-curly$Tok
1. %規則の.~block ~SET `単純~blockを消費する$() ◎ Consume a simple block and assign it to the qualified rule’s block.＼
2. ~RET %規則 ◎ Return the qualified rule.
`波括弧~block$ ◎ simple block with an associated token of <{-token>
1. %規則の.~block ~SET その~block ◎ Assign the block to the qualified rule’s block.＼
2. ~RET %規則 ◎ Return the qualified rule.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %規則の.導入部に次の結果を付加する ⇒ `成分~値を消費する$() ◎ Consume a component value. Append the returned value to the qualified rule’s prelude.

5.4.4. ~style~blockの内容を消費する

`~style~blockの内容を消費する@ ときは： ◎ To consume a style block’s contents:

%宣言~list ~LET 新たな`~list$ ◎ Create an initially empty list of declarations decls,＼
%規則~list ~LET 新たな`~list$ ◎ and an initially empty list of rules rules.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token:
`whitespace$tok

`semicolon$tok

何もしない ◎ Do nothing.

`EOF$tok
1. %宣言~list を %規則~list で`拡張する$
2. ~RET %宣言~list
◎ Extend decls with rules, then return decls.
`at-keyword$tok
1. `現入力~tokenを消費し直す$
2. %規則~list に次の結果を付加する ⇒ `~at-規則を消費する$()
◎ Reconsume the current input token. Consume an at-rule, and append the result to rules.
`ident$tok

`function$tok

`function^t【？】
1. `現入力~tokenを消費し直す$
2. %一時的~list ~LET « »
3. ~WHILE ［ `次入力~token$は［ `semicolon$tok ／ `EOF$tok ］でない］ ⇒ %一時的~list に次の結果を付加する ⇒ `成分~値を消費する$()
4. %宣言 ~LET %一時的~list から`宣言を消費する$()
5. ~IF［ %宣言 ~NEQ ε ］ ⇒ %宣言~list に %宣言を付加する
◎ Reconsume the current input token. Initialize a temporary list, initially empty. As long as the next input token is anything other than a <semicolon-token> or <EOF-token>, consume a component value and append it to the temporary list. Consume a declaration from the temporary list. If anything was returned, append it to decls.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %規則 ~LET `有修飾~規則を消費する$( ~T ) ◎ Consume a qualified rule, with mixed with declarations set to true.＼
3. ~IF［ %規則 ~NEQ ε ］ ⇒ %規則~list に %規則を付加する ◎ If anything was returned, append it to rules.

5.4.5. 宣言~listを消費する

`宣言~listを消費する@ ときは： ◎ To consume a list of declarations:

%宣言~list ~LET 空~list ◎ Create an initially empty list of declarations.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token:
`whitespace$tok

`semicolon$tok
1. 何もしない
◎ Do nothing.
`EOF$tok
1. ~RET %宣言~list ◎ Return the list of declarations.
`at-keyword$tok
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %宣言~list に次の結果を付加する ⇒ `~at-規則を消費する$() ◎ Consume an at-rule. Append the returned rule to the list of declarations.
`ident$tok
1. %一時的~list ~LET « `現入力~token$ » ◎ Initialize a temporary list initially filled with the current input token.＼
2. ~WHILE［ %入力の`次入力~token$は［ `semicolon$tok ／ `EOF$tok ］ではない］ ⇒ %一時的~list に次の結果を付加する ⇒ `成分~値を消費する$() ◎ As long as the next input token is anything other than a <semicolon-token> or <EOF-token>, consume a component value and append it to the temporary list.＼
3. %宣言 ~LET `宣言を消費する$() ◎ Consume a declaration from the temporary list.＼
4. ~IF［ %宣言 ~NEQ ε ］ ⇒ %宣言~list に %宣言を付加する ◎ If anything was returned, append it to the list of declarations.
他全部
1. `構文解析error$ ◎ This is a parse error.＼
2. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
3. ~WHILE［ %入力の`次入力~token$は［ `semicolon$tok ／ `EOF$tok ］ではない］ ⇒ `成分~値を消費する$() （結果は~~棄てる。） ◎ As long as the next input token is anything other than a <semicolon-token> or <EOF-token>, consume a component value and throw away the returned value.

5.4.6. 宣言を消費する

`宣言を消費する@ ときは： ◎ To consume a declaration:

%宣言 ~LET 新たな`宣言$( 名前: 空な名前, 値: 新たな`~list$ ) ◎ Let decl be a new declaration, with an initially empty name and a value set to an empty list.
%名前~token ~LET %入力から`成分~値を消費する$() ◎ Consume a component value.
~IF［ %名前~token は `ident$tok である］ ⇒ %宣言の名前 ~SET %名前~token の .値 ◎ <ident-token>. • Set decl’s name to the value of the <ident-token>.
~ELSE： ◎ anything else
1. `構文解析error$ ◎ This is a parse error.
2. ~WHILE［ `次入力~token$は［ `semicolon$tok ／ `EOF$tok ］でない］ ⇒ %入力から`成分~値を消費する$() （結果は~~棄てる。） ◎ While the next input token is anything but a <semicolon-token> or <eof-token>, consume a component value and throw it away.
3. ~RET ε ◎ Return nothing.
~WHILE［ `次入力~token$は `whitespace$tok である］ ⇒ `次入力~tokenを消費する$ ◎ While the next input token is a <whitespace-token>, consume the next input token.
~IF［ `次入力~token$は `colon$tok でない］：
1. `構文解析error$
2. ~RET ε
◎ If the next input token is anything other than a <colon-token>, this is a parse error. Return nothing.
`次入力~tokenを消費する$ ◎ Otherwise, consume the next input token.
~WHILE［ `次入力~token$は `whitespace$tok である］ ⇒ `次入力~tokenを消費する$ ◎ While the next input token is a <whitespace-token>, consume the next input token.
~WHILE［ `次入力~token$は `EOF$tok でない］ ⇒ %宣言の.値に次の結果を付加する ⇒ `成分~値を消費する$() ◎ As long as the next input token is anything other than an <EOF-token>, consume a component value and append it to decl’s value.
~IF［ %宣言の.値の中に `whitespace$tok でない~tokenが 2 個~以上あって，それらのうち最後の 2 個は順に次を満たす］…： ◎ If the last two non-<whitespace-token>s in the declaration’s value are＼
1. `delim$tok であって，その.値 ~EQ `21^U ◎ a <delim-token> with the value "!" followed by＼
2. `ident$tok であって，その.値 ~EQ`大小無視$sub `important^l ◎ an <ident-token> with a value that is an ASCII case-insensitive match for "important",＼
…ならば： ◎ ＼
1. その 2 個の~tokenを %宣言の.値から除去する ◎ remove them from decl’s value and＼
2. %宣言の.~importantか ~SET ~T ◎ set decl’s important flag to true.
~WHILE［ %宣言の.値の最後の~tokenは `whitespace$tok である］ ⇒ その~tokenを %宣言の.値から除去する ◎ While the last token in decl’s value is a <whitespace-token>, remove that token.
~RET %宣言 ◎ Return decl.

5.4.7. 成分~値を消費する

`成分~値を消費する@ ときは： ◎ To consume a component value:

`次入力~tokenを消費する$ ◎ Consume the next input token.
`現入力~token$に応じて：

`open-curly$Tok

`open-square$Tok

`open-paren$Tok

~RET `単純~blockを消費する$()

`function$tok

~RET `関数式を消費する$()

他全部

~RET `現入力~token$

◎ If the current input token is a <{-token>, <[-token>, or <(-token>, consume a simple block and return it. ◎ Otherwise, if the current input token is a <function-token>, consume a function and return it. ◎ Otherwise, return the current input token.

5.4.8. 単純~blockを消費する

注記：この~algoは、［ `現入力~token$は次のいずれかである］と見做す ⇒ `open-curly$Tok, `open-square$Tok, `open-paren$Tok ◎ Note: This algorithm assumes that the current input token has already been checked to be an <{-token>, <[-token>, or <(-token>.

`単純~blockを消費する@ ときは： ◎ To consume a simple block:

【！ id: 終端 token から移動】 %終端ng~token ~LET `現入力~token$の “鏡像” ~token （例えば `open-square$Tok なら `close-square$Tok ） ◎ The ending token is the mirror variant of the current input token. (E.g. if it was called with <[-token>, the ending token is <]-token>.)
%~block ~LET 新たな`単純~block$( 開き括弧: `現入力~token$ , 値: 新たな`~list$ ) ◎ Create a simple block with its associated token set to the current input token and with its value initially set to an empty list.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token and process it as follows:
%終端ng~token
1. ~RET %~block ◎ Return the block.
`EOF$tok
1. `構文解析error$ ◎ This is a parse error.＼
2. ~RET %~block ◎ Return the block.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %~block の.値に次の結果を付加する ⇒ `成分~値を消費する$() ◎ Consume a component value and append it to the value of the block.

注記：あいにく，~CSSには、［宣言を包含し得る~block, 有修飾~規則を包含し得る~block ］の間で，構文上の多義性がある。そのため、 “消費する” ~algoのうち規則を取扱うものは，どれも、初期~時には，より汎用な［この~algo ］を利用することになる — より特有な［ `宣言~listを消費する$／`規則~listを消費する$ ］~algoではなく。これらのより特有な~algoは、代わりに，文法が適用される時点で呼出される — ~blockが［ `declaration-list$t, ［ `rule-list$t ／ `stylesheet$t ］］のどちらを包含するかに依存して。 ◎ Note: CSS has an unfortunate syntactic ambiguity between blocks that can contain declarations and blocks that can contain qualified rules, so any "consume" algorithms that handle rules will initially use this more generic algorithm rather than the more specific consume a list of declarations or consume a list of rules algorithms. These more specific algorithms are instead invoked when grammars are applied, depending on whether it contains a <declaration-list> or a <rule-list>/<stylesheet>.

5.4.9. 関数式を消費する

注記：この~algoは、［ `現入力~token$は `function$tok である］と見做す。 ◎ Note: This algorithm assumes that the current input token has already been checked to be a <function-token>.

`関数式を消費する@ ときは： ◎ To consume a function:

%関数 ~LET 新たな`関数式$( 名前: `現入力~token$の.値 , 値: 新たな`~list$ ) ◎ Create a function with its name equal to the value of the current input token and with its value initially set to an empty list.
`次入力~tokenを繰返し消費する$： ◎ Repeatedly consume the next input token and process it as follows:
`close-paren$Tok
1. ~RET %関数 ◎ Return the function.
`EOF$tok
1. `構文解析error$ ◎ This is a parse error.＼
2. ~RET %関数 ◎ Return the function.
他全部
1. `現入力~tokenを消費し直す$ ◎ Reconsume the current input token.＼
2. %関数の.値に次の結果を付加する ⇒ `成分~値を消費する$() ◎ Consume a component value and append the returned value to the function’s value.

6. ~AnB 小構文

~CSSにおける一部の~~構成子 — `nth-child()$ps 疑似類など — は、その対象になる~list内の~indexを指示する必要がある。 ~AnB 小構文は、このために有用になる — それは、~list内の［単独の要素／一定周期に~~位置する要素~すべて］を容易に指示することを作者に許容する。 ◎ Several things in CSS, such as the :nth-child() pseudoclass, need to indicate indexes in a list. The An+B microsyntax is useful for this, allowing an author to easily indicate single elements or all elements at regularly-spaced intervals in a list.

`~AnB@ 記法を成す整数 %A は `周期@, を，整数 %B は `~offset@ 定義する。それは、負でないあらゆる整数 %n に対する［ ~list内の ( %A × %n + %B ) 個目の要素］を表現する。ここで，~list内の最初の要素の~indexは 1 とする（ 0 ではなく）。 ◎ The An+B notation defines an integer step (A) and offset (B), and represents the An+Bth elements in a list, for every positive integer or zero value of n, with the first element in the list having index 1 (not 0).

%A, %B どちらも正な場合、これは実質的に，~listを先頭から順に %A 個ずつの要素~groupに分割0した上で（余りの部分は、最後の~groupを成す），各~groupから %B 個目の要素を選択する。 ◎ For values of A and B greater than 0, this effectively divides the list into groups of A elements (the last group taking the remainder), and selecting the Bth element of each group.

~AnB 記法は、 ~keyword［ `even^v ／ `odd^v ］も受容し，［ `2n^v ／ `2n+1^v ］と同じ意味になる。 ◎ The An+B notation also accepts the even and odd keywords, which have the same meaning as 2n and 2n+1, respectively.

◎ Examples:

2n+0   /* 
~list内の偶数個目の要素すべてを表現する
◎
represents all of the even elements in the list
 */
even   /* 
同じ
◎
same
 */
4n+1   /* 
~list内の［ 1, 5, 9, 13, …］個目の要素すべてを表現する
◎
represents the 1st, 5th, 9th, 13th, etc. elements in the list
 */

%A, %B どちらも負になり得るが，いずれにせよ［ %n ~GT 0 に対する正な ( %A × %n + %B ) ］のみが利用される。 ◎ The values of A and B can be negative, but only the positive results of An+B, for n ≥ 0, are used.

◎ Example:

-1n+6   /* 
~list内の最初から 6 個までの要素を表現する
◎
represents the first 6 elements of the list
 */
-4n+10  /* 
~list内の 2, 6, 10 個目の要素を表現する
◎
represents the 2nd, 6th, and 10th elements of the list
 */

%A, %B どちらも 0 の場合、それを用いる疑似類は，~list内のどの要素も表現しない。 ◎ If both A and B are 0, the pseudo-class represents no element in the list.

6.1. 非正式な構文~記述

~INFORMATIVE

%A が 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.

◎ Examples:

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.

◎ Examples:

したがって次の記法は，どれも等価になる： ◎ The following notations are therefore equivalent:

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.

◎ Examples:

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

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

妥当な例： ◎ Valid example:

3n-6

妥当でない例： ◎ Invalid example:

3n + -6

~An, %B どちらも在る場合、それらを分離する正負符号の前後には，空白も許可される。 ◎ Whitespace is permitted on either side of the + or - that separates the An and B parts when both are present.

空白を伴う妥当な例： ◎ Valid Examples with white space:

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

空白を伴う無効な例： ◎ Invalid Examples with white space:

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

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

生成規則	~token	~tokenの~~属性が満たす条件
`n-dimension@t	`dimension$tok	［ .型~flag ~EQ `整数^i ］~AND［ .単位 ~EQ`大小無視$sub `n^l ］
`ndash-dimension@t	`dimension$tok	［ .型~flag ~EQ `整数^i ］~AND［ .単位 ~EQ`大小無視$sub `n-^l ］
`ndashdigit-dimension@t	`dimension$tok	［ .型~flag ~EQ `整数^i ］~AND［ .単位 ~EQ`大小無視$sub "`n-^c`数字~列$" ］
`ndashdigit-ident@t	`ident$tok	.値 ~EQ`大小無視$sub "`n-^c`数字~列$"
`dashndashdigit-ident@t	`ident$tok	.値 ~EQ`大小無視$sub "`-n-^c`数字~列$"
`integer@t	`number$tok	.型~flag ~EQ `整数^i
`signed-integer@t	`number$tok	［ .型~flag ~EQ `整数^i ］~AND［ `表現$の先頭 ~IN `正負符号$ ］
`signless-integer@t	`number$tok	［ .型~flag ~EQ `整数^i ］~AND［ `表現$の先頭 ~IN `数字$ ］

◎ <n-dimension> is a <dimension-token> with its type flag set to "integer", and a unit that is an ASCII case-insensitive match for "n" ◎ <ndash-dimension> is a <dimension-token> with its type flag set to "integer", and a unit that is an ASCII case-insensitive match for "n-" ◎ <ndashdigit-dimension> is a <dimension-token> with its type flag set to "integer", and a unit that is an ASCII case-insensitive match for "n-*", where "*" is a series of one or more digits ◎ <ndashdigit-ident> is an <ident-token> whose value is an ASCII case-insensitive match for "n-*", where "*" is a series of one or more digits ◎ <dashndashdigit-ident> is an <ident-token> whose value is an ASCII case-insensitive match for "-n-*", where "*" is a series of one or more digits ◎ <integer> is a <number-token> with its type flag set to "integer" ◎ <signed-integer> is a <number-token> with its type flag set to "integer", and whose representation starts with "+" or "-" ◎ <signless-integer> is a <number-token> with its type flag set to "integer", and whose representation starts with a digit

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

上の ~DAGGER 印が付与されている所のように，［正符号 (`+^c) ］が［ `n^l から開始している `ident^tok ］に先行するときは，その 2 個の~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:

生成規則	%A の値	%B の値
`odd^v	2	1
`even^v	2	0
`integer$t	0	`integer$t の.数値
`n-dimension$t	`n-dimension$t の.数値	0
'`+^c'? `n^c	1	0
`-n^c	−1	0
`ndashdigit-dimension$t	`ndashdigit-dimension$t の.数値	［ `ndashdigit-dimension$t の.単位から，最初の`符号位置$を除去した残りの部分］を 10 進~数として解釈した結果 — 負になる
'`+^c'? `ndashdigit-ident$t	1	［ `ndashdigit-ident$t の.値から，最初の`符号位置$を除去した残りの部分］を 10 進~数として解釈した結果 — 負になる
`dashndashdigit-ident$t	−1	［ `dashndashdigit-ident$t の.値から最初の 2 個の`符号位置$を除去した残りの部分］を 10 進~数として解釈した結果 — 負になる
`n-dimension$t `signed-integer$t	`n-dimension$t の.数値	`signed-integer$t の.数値
'`+^c'? `n^c `signed-integer$t	1	(同上)
`-n^c `signed-integer$t	−1	(同上)
`ndash-dimension$t `signless-integer$t	`n-dimension$t の.数値	−1 ×［ `signless-integer$t の.数値］
'`+^c'? `n-^c `signless-integer$t	1	(同上)
`-n-^c `signless-integer$t	−1	(同上)
`n-dimension$t ['`+^c' \| '`-^c'] `signless-integer$t	`n-dimension$t の.数値	%sign × ［ `signless-integer$t の.数値］ — ここで %sign は、 ['`+^c' \| '`-^c'] が［ '`+^c' ならば 1 ／ '`-^c' ならば −1 ］
'`+^c'? `n^c ['`+^c' \| '`-^c'] `signless-integer$t	1	(同上)
`-n^c ['`+^c' \| '`-^c'] `signless-integer$t	−1	(同上)

odd: A is 2, B is 1.
even: A is 2, B is 0.
<integer>: A is 0, B is the integer’s value.
<n-dimension>
'+'? n
-n: A is the dimension’s value, 1, or -1, respectively. B is 0.
<ndashdigit-dimension>
'+'? <ndashdigit-ident>: A is the dimension’s value or 1, respectively. B is the dimension’s unit or ident’s value, respectively, with the first code point removed and the remainder interpreted as a base-10 number. B is negative.
<dashndashdigit-ident>: A is -1. B is the ident’s value, with the first two code points removed and the remainder interpreted as a base-10 number. B is negative.
<n-dimension> <signed-integer>
'+'? n <signed-integer>
-n <signed-integer>: A is the dimension’s value, 1, or -1, respectively. B is the integer’s value.
<ndash-dimension> <signless-integer>
'+'? n- <signless-integer>
-n- <signless-integer>: A is the dimension’s value, 1, or -1, respectively. B is the negation of the integer’s value.
<n-dimension> ['+' | '-'] <signless-integer>
'+'? n ['+' | '-'] <signless-integer>
-n ['+' | '-'] <signless-integer>: A is the dimension’s value, 1, or -1, respectively. B is the integer’s value. If a '-' was provided between the two, B is instead the negation of the integer’s value.

7. ~unicode-range小構文

`font-face$at 規則~用の `unicode-range$d 記述子など，一部の構成子は、 ~Unicode符号位置の~~集合を記述する仕方を必要とする。 `urange$t 生成規則が， 1 個以上の~Unicode符号位置からなる範囲を表現する。 ◎ Some constructs, such as the unicode-range descriptor for the @font-face rule, need a way to describe one or more unicode code points. The <urange> production represents a range of one or more unicode code points.

`urange$t 生成規則は、非正式には，次の 3 種の形をとり得る： ◎ Informally, the <urange> production has three forms:

`U+0001^v: 1 個の符号位置からなる範囲を定義する。この事例では、符号位置 0x1 。 ◎ Defines a range consisting of a single code point, in this case the code point "1".
`U+0001-00ff^v: 最初の値から最後の値までの符号位置からなる範囲を定義する。この事例では、 0x1 〜 0xFF の範囲（ 10 進数 1 〜 255 ）になる。 ◎ Defines a range of codepoints between the first and the second value inclusive, in this case the range between "1" and "ff" (255 in decimal) inclusive.
`U+00??^v: 文字 `?^l がすべての`~hex$に渡るような，符号位置の範囲を定義する。この事例では、値 `U+0000-00ff^v のときと同じ範囲を定義する。 ◎ Defines a range of codepoints where the "?" characters range over all hex digits, in this case defining the same as the value U+0000-00ff.

いずれの形でも，（ `?^v も~hexと扱う下で）最大 6 桁までの 16 進数が許容される。 ◎ In each form, a maximum of 6 digits is allowed for each hexadecimal number (if you treat "?" as a hexadecimal digit).

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.

何が衝突して混同され易いのか？ ◎ What are the confusing collisions?

例えば，~CSSにおける規則 `u + a { color: green; }^css に意図される意味は、［ `u^e 要素に後続する `a^e 要素の色は，~greenにされるべきである］になる。通常は，結合子を挟んでいる`選択子$の合間には空白は要求されないので、 `u+a{color:green;}^css のように~minifyしても等価になるべきである： ◎ For example, in the CSS u + a { color: green; } , the intended meaning is that an a element following a u element should be colored green. Whitespace is not normally required between combinators and the surrounding selectors, so it should be equivalent to minify it to • u+a{color:green;}.

この 2 つの~CSS片は，結合子が他のものであれば等価になるが、前述の特化された~unicode-range~tokenの存在に因り，~minifyされた方の`選択子$の部位は、 2 個の `ident$tok と 1 個の結合子ではなく，~unicode-rangeを包含することになり、~Selectors文法に合致しない結果，規則は無効として~~棄てられることになる。 ◎ With any other combinator, the two pieces of CSS would be equivalent, but due to the previous existence of a specialized unicode-range token, the selector portion of the minified code now contains a unicode-range, not two idents and a combinator. It thus fails to match the Selectors grammar, and the rule is thrown out as invalid.

（この例は、 Firefox に報告された~~実在の~bugからとられている。） ◎ (This example is taken from a real-world bug reported to Firefox.)

注記：ここに述べる構文は、意図的にごく低~levelであり，実装者~向けである。作者~向けには、前節に与えた非正式な構文~記述で~~十分になる — `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-4$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符号位置の範囲 { %始値〜 %終値 } を表現する。 ◎ 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.＼

`urange$t 生成規則を範囲に解釈するときは、次を実行する： ◎ To interpret the production above into a range, execute the following steps in order:

%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.
~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.
%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.＼
~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.
~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.
%始値 ~SET %N を 16 進数として解釈した結果 ◎ Otherwise, interpret the consumed code points as a hexadecimal number. This is the start value.
~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.
~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.
%N ~LET %text から，アリな限り多くの`~hex$を消費した結果 ◎ Consume as many hex digits as possible from text.
~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.
%終値 ~SET %N を 16 進数として解釈した結果 ◎ Interpret the consumed code points as a hexadecimal number. This is the end value.
~IF［ %終値 ~GT `許容される最大な符号位置$ ］~OR［ %始値 ~GT %終値］ ⇒ ~RET `失敗^i — `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.
~RET 範囲 { %始値〜 %終値 } ◎ ↑

注記： `urange$t の構文は、その~patternが，前節の非正式な構文が生成し得るすべての~token並びを捉える以上に，意図的に幅広くしてある。ただし，各~tokenの合間には空白を挟めないので、実施においては~~相応に安全に利用できる：ある構成子の文法が［ `urange$t, ［ `number$t ／ `dimension$t ］］並びを含むとしても（作者が `urange$t を［ `u^c, `number$t ］並びで指定した場合に多義的になり得る）、実際にはごく安全である — 多義的になるためには、作者は， `urange$t と［ `number$t ／ `dimension$t ］とを，空白ではなく，意図的に~commentで分離する必要があるので。作者は，構文解析を惑わす仕方でも`書ける^emが、そのためには実際の~code自体も紛らわしく書く必要がある。 ◎ 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. 規則や他の値~用の文法の定義-法

`CSS-VALUES-4$r `§ 値~定義の構文$は、 ~prop用の文法を指定する方法を定義する。この節では、それらの定義を［各種~規則~用の文法を指定することも許容する］よう拡張する。 ◎ defines how to specify a grammar for properties. This section extends those definitions to also allow specifying a grammar for rules.

`~at-規則$の文法~全体を表現している非末端型は、［文字 "@", 当の~at-規則の名前］並びを［ `<^c, `>^c ］で括って記される — 例： <`media^at> は、 `media$at 規則を表現する。 ◎ Non-terminals representing the entire grammar of an at-rule are written as an @ character followed by the at-rule’s name, between < and >, e.g. <@media> to represent the @media rule.

`角括弧付き範囲~記法$は、どの［非末端型な数量-~token ］用にも利用できる。 ◎ The bracketed range notation can be used on any of the numeric token non-terminals.

~tokenの型のうちのいくつかは、引用符で括られずに，~literalとして記される： ◎ Several types of tokens are written literally, without quotes:

`ident$tok （ `auto^v, `disc^v, 等々）は、単純にそれらの.値で記される。 ◎ <ident-token>s (such as auto, disc, etc), which are simply written as their value.
`at-keyword$tok は、［文字 "@", ~tokenの.値］並びとして記される。例えば `media^at 。 ◎ <at-keyword-token>s, which are written as an @ character followed by the token’s value, like @media.
`function$tok は、［関数~名【！？】, 文字 `(^l ］並びとして記される — 例えば `translate(^c ◎ <function-token>s, which are written as the function name followed by a ( character, like translate(.
`colon$tok （ `:^l と記される）, `comma$tok （ `,^l と記される）, `semicolon$tok （ `;^l と記される）, `open-paren$Tok, `close-paren$Tok, `open-curly$Tok, `close-curly$Tok ◎ The <colon-token> (written as :), <comma-token> (written as ,), <semicolon-token> (written as ;), <(-token>, <)-token>, <{-token>, and <}-token>s.

~tokenは、その値~DAGGERが文法に定義される値に — 他が指定されない限り，`~ASCII大小無視$で — 合致するとき，合致するとされる。 ◎ Tokens match if their value is a match for the value defined in the grammar. Unless otherwise specified, all matches are ASCII case-insensitive.

【 ~DAGGER “~tokenの値” — 明文化されていないが、 ~tokenが［（~~属性として）.値を持つ場合はその.値／持たない場合はその~tokenを表現する文字列］を意味するものと思われる。】

注記： `~escape法$により，.値が［ `(^l で終端する／ "@" で開始する］ような `ident$tok を構築することもアリだが、その種の~tokenは，［ `function$tok ／ `at-keyword$tok ］ではなく, 対応する文法~定義には合致しない。 ◎ Note: Although it is possible, with escaping, to construct an <ident-token> whose value ends with ( or starts with @, such a tokens is not a <function-token> or an <at-keyword-token> and does not match corresponding grammar definitions.

`delim$tok は、その.値を一重引用符で括って記される。例えば，［ .値に `符号位置$ "+" を伴う `delim$tok ］は、 `'+'^c のように記される。同様に、［ `open-square$Tok や `close-square$Tok ］も，一重引用符で括って記されなければナラナイ。それらの.値は、項たちを~group化するために，文法それ自身の構文にて利用されるので。 `whitespace$tok は、文法の中では決して指示されず，［ ~tokenの前後, および 2 個の~tokenの合間］に許容される — ただし，定義の注釈文から明示的に指定される場合を除く（例えば，規則の.導入部が`選択子$である場合、空白は有意になる） ◎ <delim-token>s are written with their value enclosed in single quotes. For example, a <delim-token> containing the "+" code point is written as '+'. Similarly, the <[-token> and <]-token>s must be written in single quotes, as they’re used by the syntax of the grammar itself to group clauses. <whitespace-token> is never indicated in the grammar; <whitespace-token>s are allowed before, after, and between any two tokens, unless explicitly specified otherwise in prose definitions. (For example, if the prelude of a rule is a selector, whitespace is significant.)

［関数式／~block ］を定義する際には、その文法において終端ng~tokenが指定されなければナラナイが、最終的に~token~stream内に無い場合でも，依然として合致する。 ◎ When defining a function or a block, the ending token must be specified in the grammar, but if it’s not present in the eventual token stream, it still matches.

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

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

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

.foo { transform: translateX(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.

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

~CSS構文解析器は、 ~blockの内容を問わない — 例えば何らかの~at-規則の終端に来るものなど。 ~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.

`style-block@t 生成規則は、 `~style規則$の~blockの内容を表現する。それは、文法においては［ ~block全体を占める値］としてに限って利用でき，［当の~blockの内容は、 `~style~blockの内容を消費する$~algoを利用して構文解析するモノトスル］ことを表現する。 ◎ The <style-block> production represents the contents of a style rule’s block. 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 style block’s contents algorithm.
`declaration-list@t 生成規則は、宣言~listを表現する。それは、文法においては［ ~block全体を占める値］としてに限って利用でき，［当の~blockの内容は、 `宣言~listを消費する$~algoを利用して構文解析するモノトスル］ことを表現する。 ◎ 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を利用して構文解析するモノトスル］ことを表現する。 ◎ 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.

注記：これら 4 種の生成規則は，かなり類似するので、それぞれが何を受容するかを次の表に要約する。加えて，各~生成規則の例も挙げる： ◎ All four of these productions are pretty similar to each other, so this table summarizes what they accept and lists some example instances of each:

［ “可” は許容される／ “不可” は許容されない］ことを表す。
	`宣言$	`入子な~style規則$	任意な`有修飾~規則$	`~at-規則$	例
`style-block$t	可	可	不可	可	`~style規則$／ `nest^at【廃された】／`入子な条件付き~group規則$
`declaration-list$t	可	不可	不可	可	`font-face$at【！@font】／ `counter-style$at ／ `page$at ／ `keyframes$at 内の子~規則
`rule-list$t	不可	不可	可	可	`keyframes$at ／ `font-feature-values$at
`stylesheet$t	不可	不可	可	可	~stylesheet ／入子にされていない`条件付き~group規則$

◎ Allows declarations｜Allows nested style rules｜Allow arbitrary qualified rules｜Allows at-rules｜Examples <style-block>｜✓｜✓｜✗｜✓｜style rules, @nest, nested conditional group rules <declaration-list>｜✓｜✗｜✗｜✓｜@font, @counter-style, @page, @keyframes child rules <rule-list>｜✗｜✗｜✓｜✓｜@keyframes, @font-feature-values <stylesheet>｜✗｜✗｜✓｜✓｜stylesheets, non-nested conditional group rules

所与の文脈が`~at-規則$`しか受容しない^emものと意図される場合 — `font-feature-values$at【！font-features-values】内など — どの生成規則が利用されても，実際に~~問題になることはないが、より単直な名前 `rule-list$t が選好される。 ◎ If a given context is only intended to accept at-rules, such as in @font-features-values, it doesn’t actually matter which production is used, but <rule-list> is preferred for its more straightforward name.

例えば， `font-face$at 規則は、［その.導入部が空であって, 宣言~listを包含する］ものと定義されている。これは、次の文法で表出される： ◎ For example, the @font-face rule is defined to have an empty prelude, and to contain a list of declarations. This is expressed with the following grammar:

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

これは、規則の文法として，完全かつ十分な定義である。 ◎ This is a complete and sufficient definition of the rule’s grammar.

別の例として、 `keyframes$at 規則は，もっと複階的である — その.導入部は【~animationの】名前として解釈され，その.~blockは一群の~keyframe規則を包含しているものと解釈される。その文法は、次で与えられる： ◎ For another example, @keyframes rules are more complex, interpreting their prelude as a name and containing keyframes rules in their block Their grammar is:

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

［ `style-block$t ／ `declaration-list$t ］を利用する規則に対しては、その規則~用の仕様は，規則の内側においてどの［ ~prop／記述子／~at-規則］が妥当であるかを定義しなければナラナイ — これは，単純に、 “`foo^at 規則は，この仕様（または節）が定義する ~propと記述子を受容する” といった風に、あるいは，拡張~仕様は， “`foo^at 規則は，以下の~prop／記述子を追加的に受容する” といった風に述べ得る。規則の.~blockの内側にて見出された，妥当なものとして定義されていない［宣言／~at-規則］は、その規則の値【当の~blockの.値】から除去するモノトスル。 ◎ For rules that use <style-block> or <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.

［ `style-block$t ／ `declaration-list$t ］の中では、どの記述子においても，その `!important^css は自動的に無効になる。ある規則がある~propを受容する場合、その規則~用の仕様は，［その~propは`~cascade$とヤリトリし得るかどうか, どの`詳細度$でヤリトリするか］を定義しなければナラナイ。 `~cascade$とヤリトリしない~propが `!important^css を包含している場合、自動的に無効になる。他の~propにおける `!important^css は、妥当であり，`~cascade$の目的において当の宣言を`~importantな宣言$にする — `CSS-CASCADE-3$r を見よ。 ◎ Within a <style-block> or <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 causes the declaration to be important for the purposes of the cascade. See [CSS-CASCADE-3].

例えば，前の例の `font-face$at 用の文法は、そこに記されたものに加えて，［許容される宣言は， Fonts 仕様にて定義される記述子である］ものと定義しなければナラナイ。 ◎ 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 のときと同じく，その %規則用の仕様が［どの型の規則が，その %規則の中で妥当になるか］を定義しなければナラナイ。同様に、認識できない規則は，その %規則の値から除去するモノトスル。 ◎ 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.

例えば，先の例の `keyframes$at の文法は、そこに記されたものに加えて，許容される規則は［次で定義される `keyframe-rule^t に限られる］ことを定義しなければナラナイ： ◎ For example, the grammar for @keyframes in the previous example must, in addition to what is written there, define that the only allowed rules are <keyframe-rule>s, which are defined as:

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

更に，~keyframe規則（ `keyframe-rule^t ）の~blockが［ ~animate可能なすべての~CSS~propを宣言として受容する］ことに加え, ［ `animation-timing-function$p ~propを受容する］こと，一方で［それらは`~cascade$とヤリトリしない］ことを定義しなければナラナイ。 ◎ Keyframe rules, then, must further define that they accept as declarations all animatable CSS properties, plus the animation-timing-function property, but that they do not interact with the cascade.

`stylesheet$t を利用する %規則においては，すべての規則が既定で許容されるが、その %規則用の仕様は，その %規則の内側では `無効になる^em 規則を定義してもヨイ。 ◎ 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$at 規則は、 `media^at 規則を除く，~stylesheet内に置き得るものすべてを受容する。なので、その文法は次で与えられる： ◎ For example, the @media rule accepts anything that can be placed in a stylesheet, except more @media rules. As such, its grammar is:

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

加えて，［ `stylesheet$t は `media$at 規則を包含できない］とする制約も定義する。その結果、中に出現する `media^at 規則は，外側の `media^at 規則の値から落とされることになる。 ◎ It additionally defines a restriction that the <stylesheet> can not contain @media rules, which causes them to be dropped from the outer rule’s value if they appear.

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に全く含まれないものに利用される］ような，任意の適理な値を許容する。他の例として、 `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.

9. ~CSS~stylesheet

`~CSS~stylesheetを構文解析する@ ときは、所与の~stylesheet %入力に対し：

%結果 ~LET %入力から`~stylesheetを構文解析する$
%結果を成す ~EACH( ~top-levelの`有修飾~規則$ %規則 ) に対し ⇒ %規則を，以下に定義するように`~style規則$として解釈する

◎ To parse a CSS stylesheet, first parse a stylesheet. Interpret all of the resulting top-level qualified rules as style rules, defined below.

［ `無効$な~style規則／認識できない~at-規則／その文法あるいは文脈に則って無効な~at-規則］は、 `構文解析error$であり，破棄される。 ◎ If any style rule is invalid, or any at-rule is not recognized or is invalid according to its grammar or context, it’s a parse error. Discard that rule.

9.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の内容は、 ~style~blockの内容として構文解析される。別の仕様やこの仕様の将来~levelにて定義されない限り、この~list内の~at-規則は`無効$であり，無視するモノトスル。 ◎ The content of the qualified rule’s block is parsed as a style block’s contents. 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規則$の内側では［ `nest^at 規則【廃された】, `条件付き~group規則$ ］が許容されるものと定義する。 ◎ Note: [CSS-NESTING-1] defines that @nest and conditional group 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.

9.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-規則$／`有修飾~規則$／`記述子~宣言$ ］【混在し得る】を包含する — それらは、当の`~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.

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

10. 直列化

この仕様にて述べられる~tokenizerは、 ~commentに対応する~tokenは，生産しないし，何らかの仕方で保全することもない。実装は、［各~commentの内容，~token~stream内でのその所在］を保全してもヨイ【以下では、 “`保全d~comment^dfn” と称される】。そうする場合、その保全された情報は，構文解析~段に~~影響させないモノトスル。 ◎ The tokenizer described in this specification does not produce tokens for comments, or otherwise preserve them in any way. Implementations may preserve the contents of comments and their location in the token stream. If they do, this preserved information must have no effect on the parsing step.

この仕様は、 ~CSSを直列化する一般的な方法は定義しない。その仕事は、 `CSSOM$r, および個々の特能の仕様に委ねられる。特に，~commentや空白の直列化は定義されない。 ◎ This specification does not define how to serialize CSS in general, leaving that task to the [CSSOM] and individual feature specifications. In particular, the serialization of comments and whitespace is not defined.

直列化に課される唯一の要件は、構文解析と “往来-” できなければナラナイことである。すなわち，~stylesheetの構文解析においては、［連続する `whitespace$tok が 1 個の~tokenに縮約されてもヨイ~DAGGER ］ことを除き，［その結果］と［それを更に直列化して, もう一度~構文解析した結果］は，同じ~data構造を生産しなければナラナイ。 ◎ The only requirement for serialization is that it must "round-trip" with parsing, that is, parsing the stylesheet must produce the same data structures as parsing, serializing, and parsing again, except for consecutive <whitespace-token>s, which may be collapsed into a single token.

注記~DAGGER：上の例外は、 ~CSS文法が，任意の量の空白を常に 1 個の~spaceと同一視することに因る。 ◎ Note: This exception can exist because CSS grammars always interpret any amount of whitespace as identical to a single space.

この要件を満たすためには： ◎ To satisfy this requirement:

［ `5C^U を.値にとる `delim$tok ］は、［ `5C^U, `改行文字$ ］並びとして直列化されなければナラナイ。（~tokenizerがその種の~tokenを発するときは、必ず［改行文字から開始される `whitespace$tok ］を後続させる。） ◎ A <delim-token> containing U+005C REVERSE SOLIDUS (\) must be serialized as U+005C REVERSE SOLIDUS followed by a newline. (The tokenizer only ever emits such a token followed by a <whitespace-token> that starts with a newline.)
`hash$tok であって［ .型~flag ~EQ `無制約^i ］なるものに要する~escapeが，同じ~tokenであって［ .型~flag ~EQ `id^i ］なるものより多くなることはない。 ◎ A <hash-token> with the "unrestricted" type flag may not need as much escaping as the same token with the "id" type flag.
`dimension$tok の.単位は、科学的記数法と区別するために，~escapeを要し得る。 ◎ The unit of a <dimension-token> may need escaping to disambiguate with scientific notation.

下の表の中で，チェック（ ✗ ）が入っている欄と同じ［列, 行］の見出しに示されている 2 個の~tokenを，この順に連続して直列化するときは、それらの合間に~commentを挟むモノトスル。 ◎ For any consecutive pair of tokens, if the first token shows up in the row headings of the following table, and the second token shows up in the column headings, and there’s a ✗ in the cell denoted by the intersection of the chosen row and column, the pair of tokens must be serialized with a comment between them.

~tokenizerが~commentの内容を保全する場合、 2 個の~tokenの合間に在る各~commentに対しては，保全d~commentを利用するベキである。保全しない場合、［空な~comment（ `/**/^c ）］を挿入するモノトスル。（保全d~commentは、 ~tokenの合間に~commentが要求されない所でも，挿入し直してヨイ。） ◎ If the tokenizer preserves comments, and there were comments originally between the token pair, the preserved comment(s) should be used; otherwise, an empty comment (/**/) must be inserted. (Preserved comments may be reinserted even if the following tables don’t require a comment between two tokens.)

見出しに挙げる~tokenのうち， 1 個の文字からなるものは、それを.値に伴う `delim$tok を表現する。 ◎ Single characters in the row and column headings represent a <delim-token> with that value, except for "(", which represents a (-token.
`ident$tok `✗✗✗✗✗✗✗✗✗✗__^cK
	`ident$tok	`function$tok	`url$tok	`bad-url$tok	`-^c	`number$tok	`percentage$tok	`dimension$tok	`CDC$tok	`(^c	`*^c	`%^c
`at-keyword$tok `✗✗✗✗✗✗✗✗✗___^cK
`hash$tok `✗✗✗✗✗✗✗✗✗___^cK
`dimension$tok `✗✗✗✗✗✗✗✗✗___^cK
`#^c `✗✗✗✗✗✗✗✗✗___^cK
`-^c `✗✗✗✗✗✗✗✗✗___^cK
`number$tok `✗✗✗✗_✗✗✗✗__✗^cK
`@^c `✗✗✗✗✗___✗___^cK
`.^c `_____✗✗✗____^cK
`+^c `_____✗✗✗____^cK
`/^c `__________✗_^cK

10.1. ~anb の直列化-法

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

~IF［ %A ~EQ 0 ］ ⇒ ~RET %B を直列化した結果
%結果 ~LET %A に応じて ⇒＃ 1 ならば空~文字列／ −1 ならば `-^l ／ ~ELSE_ %A を直列化した結果
%結果に `n^l を付加する
~IF［ %B ~EQ 0 ］ ⇒ ~RET %結果
~IF［ %B ~GT 0 ］ ⇒ %結果に `+^l を付加する
%結果に %B を直列化した結果を付加する
~RET %結果

◎ • If A is zero, return the serialization of B. • Otherwise, let result initially be an empty string. • A is 1 •• Append "n" to result. • A is -1 •• Append "-n" to result. • A is non-zero •• Serialize A and append it to result, then append "n" to result. • B is greater than zero •• Append "+" to result, then append the serialization of B to result. • B is less than zero •• Append the serialization of B to result. • Return result.

11. ~privacyと~securityの考慮点

この仕様により新たな~privacyの懸念が導入されることはない。 ◎ This specification introduces no new privacy concerns.

この仕様による~CSS構文解析は、今やすべての入力に対し一義的に定義されるので，~securityを改善する。 ◎ This specification improves security, in that CSS parsing is now unambiguously defined for all inputs.

~whitelistや~filterなどの旧い構文解析器には、この仕様と異なるように構文解析する限り~secureでない部分があることになる。以前の構文解析の仕様には，［多義的で, ~browserにより解釈が異なるような多数の際どい事例］が残されているので、それらの~filterは~secureでない可能性がある。この仕様は，その状況を悪化させることはない。 ◎ Insofar as old parsers, such as whitelists/filters, parse differently from this specification, they are somewhat insecure, but the previous parsing specification left a lot of ambiguous corner cases which browsers interpreted differently, so those filters were potentially insecure already, and this specification does not worsen the situation.

12. 変更点

~INFORMATIVE

【変更~箇所の引用は省略する。】

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

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

§ ~commaで分離された~listをある~CSS文法に則って構文解析する ~algoを新たに追加した。 ◎ Added a new § 5.3.2 Parse A Comma-Separated List According To A CSS Grammar algorithm.
新たな`~style~blockの内容を構文解析する$~algo, それに対応する `style-block$t 生成規則を追加して，`~style規則$はそれらを利用するものと定義した。 ◎ Added a new § 5.3.7 Parse a style block’s contents algorithm and a corresponding <style-block> production, and defined that style rules use it.
`~stylesheetを構文解析する$ ~algoを Fetch 仕様に関係する `shenanigans^en に揃えた。（ commit を見よ。） ◎ 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-規則を追加した（課題 #5633 ）。 ◎ Added § 9.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を挟む” 表に~entryを追加して、［ ~identは、今や `--^c から開始し得る事実］を適正に取扱うようにした。（ 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)

12.2. 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.
~token化と構文解析~algoにおけるいくつかの~bugを修正した。 ◎ Fix several bugs in the tokenization and parsing algorithms.
~identに類する~tokenの定義を， `--^c から開始される~identも許容するように変更した【参照】。その~~一環として，`~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は`表現$を持つように定義した。 ◎ 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に特有な~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は、明示的な終端~符号位置を指定せずに呼べるようにされた。その場合は現入力~符号位置が代わりに利用される。これにより，３カ所の呼び出しに変更が加えられた。 ◎ 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.
Infra Standard による定義に一致するので、次の定義は除去した ⇒＃ “符号位置”, “~surrogate符号位置” ◎ Removed "code point" and "surrogate code point" in favor of the identical definitions in the Infra Standard.
どの【符号位置】範囲も， `inclusive^ であることを明確化した。 ◎ Clarified on every range that they are inclusive.
`%^l `delim$tok ~tokenの次に出現する `number$tok を取扱うため、 ~comment挿入~表に列を追加した。 ◎ Added a column to the comment-insertion table to handle a number token appearing next to a "%" delim token.

各~commentに対する処置集もある。 ◎ A Disposition of Comments is available.

12.3. 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.4. 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.5. `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 elements names.
~token化は、最早［ `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 ）が、実施におけるその利用には影響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に際しては — `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>).

謝辞

次の方々からの~feedbackと貢献に： ◎ Thanks for feedback and contributions from＼

Anne van Kesteren, David Baron, Elika J. Etemad (fantasai), Henri Sivonen, Johannes Koch, 呂康豪 (Kang-Hao Lu), Marc O’Morain, Raffaello Giulietti, Simon Pieter, Tyler Karaszewski, and Zack Weinberg.

1. 序論

1.1. ~module間の相互作用

【この訳に特有な表記規約】

2. ~CSSの構文の記述

2.1. ~escape法

2.2. ~errorの取扱い

3. ~CSSの~token化法と構文解析-法

3.1. 構文解析~modelの概観

3.2. 入力~byte~stream

3.3. 入力~streamの前処理

4. ~token化

4.1. ~tokenの線路図式

4.2. 定義

4.3. ~tokenizer~algo

4.3.1. ~tokenを消費する

4.3.2. ~comment列を消費する

4.3.3. 数量-~tokenを消費する

4.3.4. ~identに類する~tokenを消費する

4.3.5. 文字列~tokenを消費する

4.3.6. ~url~tokenを消費する

4.3.7. ~escapeされた符号位置を消費する

4.3.8. ［ 2 個の符号位置 ］並びが，妥当な~escapeを成すかどうかの検査

4.3.9. ［ 3 個の符号位置 ］並びが，~identを開始しているかどうかの検査

4.3.10. ［ 3 個の符号位置 ］並びが，実数を開始しているかどうかの検査

4.3.11. ~identを消費する

4.3.12. 実数を消費する

4.3.13. 文字列を実数に変換する

4.3.14. 不良~urlの残余を消費する

5. 構文解析-法

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

5.2. 定義

5.3. 構文解析器の入口

5.3.1. ある~CSS文法に則って何かを構文解析する

5.3.2. ~commaで分離された~listを ある~CSS文法に則って構文解析する

5.3.3. ~stylesheetを構文解析する

5.3.4. 規則~listを構文解析する

5.3.5. 規則を構文解析する

5.3.6. 宣言を構文解析する

5.3.7. ~style~blockの内容を構文解析する

5.3.8. 宣言~listを構文解析する

5.3.9. 成分~値を構文解析する

5.3.10. 成分~値~listを構文解析する

5.3.11. ~commaで分離された成分~値~listを構文解析する

5.4. 構文解析器~algo

5.4.1. 規則~listを消費する

5.4.2. ~at-規則を消費する

5.4.3. 有修飾~規則を消費する

5.4.4. ~style~blockの内容を消費する

5.4.5. 宣言~listを消費する

5.4.6. 宣言を消費する

5.4.7. 成分~値を消費する

5.4.8. 単純~blockを消費する

5.4.9. 関数式を消費する

6. ~AnB 小構文

6.1. 非正式な構文~記述

6.2. ~anb 型

7. ~unicode-range小構文

7.1. `urange^t 型

8. 規則や他の値~用の文法の定義-法

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

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

9. ~CSS~stylesheet

9.1. ~style規則

9.2. ~at-規則

9.3. `charset^at 規則

10. 直列化

10.1. ~anb の直列化-法

11. ~privacyと~securityの考慮点

12. 変更点

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

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

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

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

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

謝辞

4.3.8. ［ 2 個の符号位置］並びが，妥当な~escapeを成すかどうかの検査

4.3.9. ［ 3 個の符号位置］並びが，~identを開始しているかどうかの検査

4.3.10. ［ 3 個の符号位置］並びが，実数を開始しているかどうかの検査

5.3.2. ~commaで分離された~listをある~CSS文法に則って構文解析する

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

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

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

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