css-syntax-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>CSS Syntax Module Level 3 （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-css.css" type="text/css">

<style>
@namespace svg url(http://www.w3.org/2000/svg);

svg|svg{
	background-color: var(--bg-color-1);
}
svg|path{
	stroke-width: 3;
	stroke: var(--K-color);
	fill: none;
}
svg|text{
	font:bold 14px monospace;
	text-anchor:middle;
	fill: var(--K-color);
}
svg|text.label{
	text-anchor:start;
}
svg|text.comment{
	font:italic 12px monospace;
}
svg|rect{
	stroke-width: 3;
	stroke: var(--K-color);
	fill: var(--G-bg);
}

dd.railroad {
	overflow: auto;
}
</style>
<!-- 
class="railroad-diagram" → 除去（ svg はすべて線路図式）
svg.railroad-diagram tagname → svg|tagname
埋め込み svg に名前空間宣言は不要
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/HTML5_Parser
-->


<style>

.symbol {
	color: var(--K-color);
}

.encoding {
	font-family: sans-serif0, sans-serif;
}


td[colspan] {
	text-align:center;
}

#_ser-table1 {
	> tbody > tr > td {
		min-width: 1em;
		text-align: center;
	}
	> tbody > tr > th {
		white-space: nowrap;
		text-align: right;
	}
	> thead > tr > th > * {
		writing-mode: vertical-rl;
		white-space: nowrap;
	}
}


@supports (grid-template-columns: subgrid) and (display: contents) {

#_token-types {
	grid-template-columns: 4em 12em 1fr;
	min-width: 28em;
	max-width: 52em;

	tr {
		grid-template-areas:
			"token token fields"
			". 例 例"
		;
		> *:nth-child(1) {
			grid-area: token;
			border-left-width: 0;
		}
		> *:nth-child(2) {
			grid-area: fields;
		}
		> *:nth-child(3) {
			grid-area: 例;
		}
	}
}


#_anb-prod {
	grid-template-columns: 4em 12em 1fr;
	min-width: 28em;
	max-width: 52em;
	tr {
		grid-template-areas:
			"prod prod prod"
			". token 条件"
		;
		> *:nth-child(1) {
			grid-area: prod;
			border-left-width: 0;
		}
		> *:nth-child(2) {
			grid-area: token;
		}
		> *:nth-child(3) {
			grid-area: 条件;
		}
	}
}

#_anb-def {
	grid-template-columns: 4em 0.7fr 1fr;
	min-width: 28em;
	max-width: 52em;
	tr {
		grid-template-areas:
			"prod prod prod"
			". A B"
		;
		> *:nth-child(1) {
			grid-area: prod;
			border-left-width: 0;
		}
		> *:nth-child(2) {
			grid-area: A;
		}
		> *:nth-child(3) {
			grid-area: B;
		}
	}
}
}
</style>


<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>

Util.ready = function(){
	const source_data = {
		generate: expand
	};

	const unicode_map = PAGE_DATA.unicode_map
	.replace( /\n(\w+)([:!])(.+)/g, function(t0, t1, t2, t3){
		t0 = (t1.length < 3) ? '00' + t1 : t1;
		t2 = (t2 === '!') ? ` (<code>&#x${t1};</code>)` : '';
		return(
`\n${t1}:<span class="code-point">U+${t0}</span> <span class="cp-name">${t3}</span>${t2}`
		);
	});
	source_data.unicode_map = Util.get_mapping(unicode_map);
	delete PAGE_DATA.unicode_map

	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;
	const unicode_map = this.unicode_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.+?)([$@\^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){
if(!indicator) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'i': // ^i リンク解除（一時的？）
	break;
case 'r': // ref
	text = `[${key}]`;
	href = `#biblio-${key.toLowerCase()}`;
	break;
case 'tok': // token
	href = `#typedef-${key.toLowerCase()}-token`;
	text = `&lt;${key}-token&gt;`;
	break;
case 'Tok': // token
	href = `#tokendef-${key}`;
	text = `&lt;~${key}&gt;`;
	break;
case 't': // typedef
	href = `#typedef-${key}`;
	text = `&lt;${key}&gt;`;
	break;
case 'f':
	text = `${key}()`;
	break;
case 'U': // code point
	text = unicode_map[key] || `<span class="code-point">U+${key}</span>`;
	break;
case 'l': // literal
	text = `"<code>${key}</code>"`;
	break;
case 'at': // at-rule
	text = `@${key}`;
	break;
case 'ps': 
	text = `:${key}`;
	break;
case 'dgm': // place holder for railroad diagram
	return `<a id="_dgm-${key}"></a>`;
	break;
case 'cK':
	text = text.replace(/./g, '<td>$&').replace(/_/g, '-');//✗
	break;
case 'issue':
	text = `課題 #${key}`;
	href = `~CSSissue/${key}`;
	break;
case 'en':
	text = `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}//create_html
}
</script>

<script type="text/plain" id="_source_data">


●●options

spec_title:CSS Syntax Module Level 3
spec_date:2024-10-25
trans_update:2024-10-26
source_checked:230508
page_state_key:CSS
original_url:https://drafts.csswg.org/css-syntax-3/
	abbr_url:CSSSYN
spec_status:ED
ref_id_prefix:biblio-
ref_id_lowercase:true
conformance:css
copyright:2024,permissive
trans_1st_pub:2013-12-14


●●class_map
at:at-rule
p:property
d:descriptor
ps:pseudo
f:func
tok:token
Tok:token
t:type
u:unit
sb:symbol
e:element
a:attr
enc:encoding
css:css
v:value
h:header

●●tag_map
i:i
tok:var
Tok:var
t:var
V:var
at:code
p:code
d:code
ps:code
f:code
sb:code
e:code
a:code
v:code
css:code
I:code
enc:span
c:code
h:code
em:em
sub:sub
dfn:dfn
cite:cite

●●words_table1

nB:<sup><a href="#anb-plus">†</a></sup>
anb:<var>&lt;an+b&gt;</var>
AnB:<span class="css"><var>A</var>n+<var>B</var></span>
An:<span class="css"><var>A</var>n</span>

open-square:[-token
close-square:]-token
open-paren:(-token
close-paren:)-token
open-curly:{-token
close-curly:}-token

DAGGER:<sup>†</sup>

●●words_table

	●処理一般
回復-:recover:~
回復:recovery:~
	-:optionally
	:error handling
入口:entry point::~::エントリポイント
step
無制約:unrestricted:制約なし
	呼ばれ:callされ:~
呼べる:callできる:~
	呼び出し:calling
繰返し:repeatedly:繰り返し
繰返n:repetition:繰り返し
渡す:passする:~
渡され:passされ:~
混合-:mix:~
先読み:lookahead:~
入子か:nestedか::入れ子か
捕捉-:capture:~
EOF:
	後始末:cleaning up
	-:initially
	戻る:returning
	返る:return
	早急に:eagerly
	後戻り:goes backwards
	~call元:call-site
	地点:point
	連動的に:lockstep
	10 の 〜 乗:raise 10 to the power of
	~MUL:multiply
	その場で:on demand
	~tokenを生産する前の:(not just what tokens were produced from that text)
	~~際限なく:potentially 〜 ton of
	探すため:looking
	出くわす:hit
	費やす:spent
	し続ける:keep
	~SET:assign

	%数値:num
	%~URL:url
	%規則~群:rules
	%宣言~群:decls
	%宣言:decl
	%宣言:-
	%規則:-
	%規則:rule
	%値~群:values
	%終端ng~token:ending-token
	%~group群:groups
	%入子か:nested
	%実数~部:number part
	%指数~部:exponent part
	%符号~文字:sign character
	%~unicode-rangeは許容されるか:unicode ranges allowed
	%第一~区分:first-segment
	第二~区分:-
	%範囲~始端:start of range
	%範囲~終端:end of range
	%~token群:tokens
	%~token列

	●構文解析
長さ:
消費側:consumer::~
	消費し直す:reconsume
前方検索-:forward へ seek::~

発する:emitする::~
発され:emitされ::~
次回の:next:~
	2 個目の:next
復旧-:restore:~

小構文:microsyntax::~
形式変換-:transform:~
	引用符で括る:quote
	引用符で括られ:quoted
	引用符で括られてない:unquoted
線路図式:railroad diagram:~
		構文解析図

	~escape列:escape sequence
	~escapeを施す:escaping
	~escape法:escaping
前処理:preprocessing:~
構文解析error:parse error::構文解析エラー::パースエラー

tokenizer:::token 化器:トークン化器:トークナイザ
	~token化:tokenization
	~token化-:tokenize
	~token化法:tokenizing
	~token化処理:tokenizing
	~token化前の:pre-tokenizing

枯渇-:exhaust:~
遭遇-:encounter:~
構築中:build 中:~
		building

分割0:divide:分割
出現する:appearする:現れる
出現し:appearし:現れ
縮約-:collapse:~
削る:trimする:~
連続する:consecutiveな:~
連続的:contiguous:~
代用-:substitute::~
	代用-:substitution
文法記号:grammar term:~
区分:segment:~
退出:exit:~
退出-:exit:~

	棄て:throw away
	棄て:throw out
	棄てる:do nothing with
	一連の:series
	〜並び:, follwed by…
	〜列:sequence
	一部を成す連列:subsequence
	~byte列:sequence of bytes
	挿入し直-:reinsert
	対になっていない:unmatched
	３つ組:3-tuple
	挟まれ:surrounded
	一定周期に~~位置する:regularly-spaced intervals
	先頭に戻す:push〜back onto the front
	始まる:begins with
	始まる:begin
	閉じ:closing
	閉じら:close さ
	closed／unclosed
	開いた:opened
	まだ閉じられていない:still open
	~comment挿入:comment-insertion
	下位部分:sub-part
	成分~値:component-value
	成功した:successfully
	も〜の所で:hit
	早々に:early
	~stylesheet:stylesheet
	`3F^U:question mark

	●符号位置／
BOM:
	BAD_STRING, BAD_URI
UTF-16:
英字:letter::~
hex:hex digit::16 進数字
	10 進数:base-10 number
	16 進数／16 進:hexadecimal number

	基数
	ident
符号:sign:~
負符号:minus sign:~
正符号:plus sign:~
正負符号:plus or minus sign:~

大文字:uppercase letter::~
小文字:lowercase letter::~
	convert 〜 lower-case
代替文字:replacement character:replacement 文字:~
surrogate::::サロゲート
	~surrogate:surrogate code point
backslash::::バックスラッシュ

印字不能:non-printable::~

	●token 他
ident:
	~identを開始する:ident-start
	~identに類する:ident-like
	~ident:ident sequence
	括弧:brace
波括弧:curly:~
丸括弧:paren:~
角括弧:square:~
	閉じ丸括弧:right parenthesis
角括弧付き:bracketed:~
unicode-range:
有修飾:qualified::~
	有資格?
実数:number::~
一文:statement::~
導入部:prelude::~
	〜に応じて:mirror variant
終端ng:ending::終端
	ending token／ending code point
	.終端:ending
	.始端:starting
数値:numeric value:~
数量-:numeric:~
残余:remnants:~
	文字大小は区別:case-sensitive
	-ly
保全d:preserved::保全
一重:single::~

	ε:nothing
	ε:missing

	●An+B
指数:exponent:~
	グループ化
周期:step:~


	●CSS
CSSOM:
keyframe::::キーフレーム
	~animate可能:animatable
	custom property
import:
important:
green:
	疑似類:pseudoclass
字句走査器:lexical scanner::字句 scanner:字句スキャナ
出自:origin::~
詳細度:specificity::~
	~list値をとる:list-valued
	~CSSOM:OM

	●仕様
参考:informative:~
	互換性:compat
上品:graceful:~
事実:fact:~
不規則:odd:~
	問題にならない:not problematic
節:section:~
自己完結的:self-contained:~
相:phase:~
段階:stage:~
自立的:stand-alone:~
視点:standpoint:~
一時的:temporary:~
	temporarily
whitelist::::ホワイトリスト
際どい:corner:きわどい
実態:reality:~
最悪:at worst:~
誤用:mistake:~
総括的:blanket:~
切替えた:switchした:切り替えた
産物:product:~
真似た:mimicした:~
倣う:alignする:~
関知-:concern:~
解消-:fix:~
翻訳-:translate:~
	confusing
参照r:refer:参照
参照元:referring:~
	認識できない:unrecognized
分類-:categorize:~
分類:categorization:~
呈-:exhibit:~
処-:deal:~
細やか:fine-grained:~
把握-:grasp:~
審査-:vet:~
niche::::ニッチ
設置-:place:~
付随-:accompany:~
過ち:mistake:~
偶発的:accidental:~
確定的:definite:~
素朴:naive:~
創出-:create:~

	`MEDIAQ$r:Media Queries
	Fonts
	Syntax
	CSSOM
	SVG
	IANA,
	WebKit,
	`CSS-VALUES-4$r:Values &amp; Units spec

	低~level:low-level
	高~levelな:high-level
	~~主要な:substantive
	^en:destructure
	~~再構成:restructuring
	策定者:you
	~~主流になる:win
	~~考えて:think
	し得る:possible
	それなりに:fairly
	照らし合わせて:against
	最新の:most recent
	必要に応じて:if so desired
	あるべき:decent
	責を負う:responsible
	注意を払う:paying attention
	その場で:on-demand
	易-:easier
	易く:easily
	最小限〜:minimum amount of 〜
	小さな:minor
	優先度:precedence
	優先-:gives precedence
	本当の:real
	満たす:satisfy
	易くなる:easier
	本質的でない漏洩:accidental leak
	単に:just
	simple enough that
	それなり:fairly
	:please let me know
	:question
	多岐に渡る:wide variety of
	:although
	直前に〜済み:initial〜already
	~~区別:distinction
	略して:aka
	もちろん:definitely
	きちんと:well-
	問わない:agnostic
	実装:impl
	~~影響しない:have no effect
	課さない:places no
	きちんと定義され:well-defined
	期待されない:unexpected
	要する:require／need
	~~判明-:realize
	書く:write
	書ける:write
	書き直-:rewrite
	記され:written
	好ましい行い:don’t want to encourage
	見受けられる:we’ve gotten any
	見受けられ:appear
	〜を通して:hooking
	心配せずに:without worrying about
	委ねられる:leaving
	大別され:broadly speaking
	諸々の:miscellaneous
	かなり:pretty
	揃えた:align
	^en:shenanigans
	commit:commit
	価値がある:valuable
	高価値:high-value
	重要でない:unimportant
	類の:sort of
	より弱い:weaker
	原因:cause
	混同され得る〜すべて:all possible confusing
	は別として:aside from
	単純にするため:for simplicity
	された頃:back
	旧来の … それら:older … legacy
	旧い:old
	より旧い:older
	より新たな:newer
	数十年経た今日まで引き継がれた:carries over to today, decades later
	§ ~tokenizer~algo:the tokenization process, defined earlier in this spec
	〜ではあるが:admittedly
	除かれる:subtract
	どういうわけか:somehow
	どこかで間違っている:you’ve messed up
	区別される:differentiate themselves
	なるもの以外:categories
	早期:early
	~algo上の:algorithmic
	に基づいて定義する:in terms of
	必要もなくなった:removed the main need to
	ようになった:now
	少しばかりの:few bits of
	面倒事:troublesome
	特に:notably
	への支持を受けて~favor
	残っていた:rest
	いずれにせよ:regardless
	~~不都合はない:fine
	概ね:roughly
	理解し易さ:understandability
	優先-:prioritize
	だけで済ませられる:still get away with
	効率が悪く:fairly inefficient
	委ねられ:it’s up to
	扱いを違える:treat differently
	~~暗号的な何か:complete gibberish
	~~簡潔:compact

	●未分類
	~filter済みでない:unfiltered
	直後に〜来る:precede
選択-:select:~
正規表現:regular expression:~
	make
印:mark:~
	−1:negation
科学的記数法:scientific notation:~
書字:writing::~
用字系:script::~
左横書き:LTR:~
右横書き:RTL:~
editor::::エディタ
新規:fresh:~
他全部:anything else:その他
部位:portion:~
重合する:overlapする:重なり合う
再生産-:reproduce::~
実体化-:materialize:~

	`選択子$の構文:Selectors syntax
	括られ:enclosed
	取り込む:to be encountered
	選ばれ:chosen
	composed of 〜
	〜からなる:consisting of
	〜からなる:consists
	成す:comprise する
	constitute 〜
	表す／示され:denote
	（互いに）異なる:different
	異なる:differ
	区別する:disambiguate
	抜けた:finish
	よく似る:resemble
	〜:inclusive
	保つ:keep
	見かけ:look
	調べる:looks at
	混在する:mixed
	得る:achieve
	まだ open:still open
	見える:seen
	selecting
	送る:sending
	現れる:showing up
	現れ:show up
	読み綴る:spell
	みなされる:taken
	take
	taking
	後続-:follow
	後続する:continue
	選ばれ:picked
	読み取／読まれる／読む:read
	様々な:varied
	変わり得る:vary
	〜で括られた:wrapped
	値~定義の構文:Value Definition Syntax
	~link法:linking
	側:side
	-:total
	量:amount
	総数:the total amount
	:adjusting
	:afterwards
	場合:case
	欄:cell
	二重に:doubled
	ever
	filled
	最終的に:eventual
	-:final
	-:finally
	見出し:heading
	formed
	hence
		 instruct
	-:intersection
	項目
	より大きい:greater
	高い:high
	より高い:higher
	より長い:longer
	最も長い:longest
	短い:short
	印~付き:marked
	対応する
	同時に，:together
	OFF:unset
	:very
	lower-, higher
	片 pieces
	ident
	一環:part of
	段たちを配列し直し:rearrange the ordering of the clauses
	~group化-:group
	構造~化-:structure
	並び替え:transposition
	混在-:mix:~
	からなる:comprise
	-:bool
	-:prefix of
	頭部:first several
	最~大:greatest
	最長:largest
	もはや:anymore
	のように:similar
	よく似た:very similar
	いくぶん:somewhat
	少し:slightly
	ほぼ:certainly
	中途にある:in the middle of
	再:re
	前述の:previous
	now
	〜まで:until
	一番先頭:very first
	order
	当該の:respective
	respectively
	〜のいずれか:either
	あらゆるもの:everything
	おおよそ:nearly
	まったく:totally
	一緒に:altogether
	一部:part
	他の:rest
	他のもの:anything else
	他のもの:rest
	何らかの／一部の:some
	先頭:front, ...
	全体を占める:the sole
	全然:entirely
	外側の:outer
	次の:adjacent
	次の:next
	残り:remainder
	残りの:remaining
	余った部分:the remainder
	他の部分:rest
	箇所:certain points
	組:pair
	結果:result／resulted／resulting
	自身による:own
	非:non
	ときには:occasionally
	上に挙げた:preceding
	ほとんど:mostly
	何箇所かで:sometimes
	もっぱら:solely
	および:plus
	箇所:place
	少数ある:has a small number of
	符号位置:codepoint
	`直前^em:just *before*
	当の:the lone
	存在しない:non-existent
	全体を成す:being the whole
	上層:top of
	少し:little
	相対的 〜 順序:relative position wrt surrounding
	包装-:turn into
	他の~item:the rest
	新たな:fresh empty
	~group化:grouping

●●original_id_map

	consume-block-contents:consume-list-of-declarations
	consume-block-contents:consume-a-list-of-declarations
	consume-block-contents:parse-a-list-of-declarations
	parse-stylesheet-contents:parse-list-of-rules
	parse-block-contents:parse-list-of-declarations
	consume-stylesheet-contents:consume-list-of-rules

parse-a-list-of-declarations:
repeatedly-consume-next-code-point:
plus-or-minus:
exponent-indicator:

whitespaces-diagram:ws*-diagram
curly-block-diagram:{}-block-diagram
paren-block-diagram:%28%29-block-diagram
square-block-diagram:[]-block-diagram
important-diagram:!important-diagram

●●mdn_urls
at-ruledef-charset:CSS/@charset

●●link_map

I.CSSStyleDeclaration:~CSSOM1#cssstyledeclaration
I.CSSNestedDeclarations:~CSSNESTING#cssnesteddeclarations

	t.any-value:#typedef-any-value
	t.block-contents:#typedef-block-contents
	t.dashndashdigit-ident:#typedef-dashndashdigit-ident
	t.declaration-list:#typedef-declaration-list
	t.declaration-rule-list:#typedef-declaration-rule-list
	t.declaration-value:#typedef-declaration-value
	t.integer:#typedef-integer
	t.n-dimension:#typedef-n-dimension
	t.ndash-dimension:#typedef-ndash-dimension
	t.ndashdigit-dimension:#typedef-ndashdigit-dimension
	t.ndashdigit-ident:#typedef-ndashdigit-ident
	t.qualified-rule-list:#typedef-qualified-rule-list
	t.at-rule-list:#typedef-at-rule-list
	t.rule-list:#typedef-rule-list
	t.signed-integer:#typedef-signed-integer
	t.signless-integer:#typedef-signless-integer

t.string:~CSSVAL#string-value
t.color:~CSSCOLOR#typedef-color
	t.color:~CSSWG/css-color-3/#colorunits
t.keyframe-selector:~CSSANIM#typedef-keyframe-selector
t.selector-list:~SELECTORS4#typedef-selector-list
t.general-enclosed:~MQ5#typedef-general-enclosed
	t.length-percentage
	t.translation-value


	tok.CDC:#typedef-cdc-token
	tok.CDO:#typedef-cdo-token
	tok.EOF:#typedef-eof-token
	tok.at-keyword:#typedef-at-keyword-token
	tok.bad-string:#typedef-bad-string-token
	tok.bad-url:#typedef-bad-url-token
	tok.colon:#typedef-colon-token
	tok.comma:#typedef-comma-token
	tok.delim:#typedef-delim-token
	tok.dimension:#typedef-dimension-token
	tok.function:#typedef-function-token
	tok.hash:#typedef-hash-token
	tok.ident:#typedef-ident-token
	tok.number:#typedef-number-token
	tok.percentage:#typedef-percentage-token
	tok.semicolon:#typedef-semicolon-token
	tok.string:#typedef-string-token
	tok.unicode-range:#typedef-unicode-range-token
	tok.url:#typedef-url-token
	tok.whitespace:#typedef-whitespace-token

	Tok.close-curly:#tokendef-close-curly
	Tok.close-paren:#tokendef-close-paren
	Tok.close-square:#tokendef-close-square
	Tok.open-curly:#tokendef-open-curly
	Tok.open-paren:#tokendef-open-paren
	Tok.open-square:#tokendef-open-square


p.text-decoration:~CSSTEXTDECOR#propdef-text-decoration
p.color:~CSSCOLOR#propdef-color
	~CSSWG/css-color-3/#color0
p.animation-timing-function:~CSSANIM#propdef-animation-timing-function

d.unicode-range:~CSSFONT#descdef-font-face-unicode-range

v.underline:~CSSTEXTDECOR#valdef-text-decoration-line-underline

ps.left:~CSSPAGE#valdef-page-left

f.attr:~CSSVAL5#funcdef-attr
f.translateX:~TRANSFORM#funcdef-transform-translatex
f.url:~CSSVAL#funcdef-url
f.var:~CSSVAR#funcdef-var

at.charset:#at-ruledef-charset
at.keyframes:~CSSANIM#at-ruledef-keyframes
at.import:~CASCADE#at-ruledef-import
at.media:~CSSCOND#at-ruledef-media
at.namespace:~CSSNS#at-ruledef-namespace
at.page:~CSSPAGE#at-ruledef-page
at.supports:~CSSCOND#at-ruledef-supports
at.font-face:~CSSFONT#at-font-face-rule

ps.nth-child():~SELECTORS4#nth-child-pseudo

e.p:~HEgrouping#the-p-element
e.a:~HEtextlevel#the-a-element
e.img:~HEimages#the-img-element

a.sizes:~HEimages#attr-img-sizes
a.media:~HEmetadata#attr-style-media

I.CSSStyleSheet:~CSSOM1#cssstylesheet

h.Content-Type:~HTTPsem#field.content-type
c.querySelector():~DOM4#dom-parentnode-queryselector

e.script:~HEscripting#the-script-element
e.style:~HEmetadata#the-style-element

	●用語
無効:#css-invalid
無視-:#css-ignored
構文解析error:#parse-error

	■stream
~stylesheetの~byte列を復号する:#css-decode-bytes
~fallback符号化法を決定する:#determine-the-fallback-encoding
環境~符号化法:#environment-encoding

入力~stream:#input-stream
符号位置~列を~filterする:#css-filter-code-points
	~filter済み符号位置:#css-filter-code-points

	■ token化
符号位置~streamを~token化する:#css-tokenize
	~token化する:#css-tokenize

V.C1:#next-input-code-point
V.C2:#next-input-code-point
V.C3:#next-input-code-point
	次回の入力~符号位置:#next-input-code-point
入力~符号位置を消費する:#consume-code-points
入力~符号位置を繰返し消費する:#repeatedly-consume-next-code-point
現在の入力~符号位置:#current-input-code-point
現在の入力~符号位置を消費し直す:#reconsume-the-current-input-code-point
~EOF符号位置:#eof-code-point
i.~EOF:#eof-code-point
数字:#digit
~hex:#hex-digit
正負符号:#plus-or-minus
小文字:#lowercase-letter
大文字:#uppercase-letter
英字:#letter
非~ASCII~ident符号位置:#non-ascii-ident-code-point
印字不能~符号位置:#non-printable-code-point
改行文字:#newline
空白:#whitespace
許容される最大な符号位置:#maximum-allowed-code-point
~ident:#ident-sequence
~identを開始する符号位置:#ident-start-code-point
~ident符号位置:#ident-code-point


~tokenを消費する:#tokenizer-consume-a-token
~comment列を消費する:#consume-comments
数量-~tokenを消費する:#consume-a-numeric-token
~identに類する~tokenを消費する:#consume-an-ident-like-token
文字列~tokenを消費する:#consume-a-string-token
~URL~tokenを消費する:#consume-a-url-token
~escapeされた符号位置を消費する:#consume-an-escaped-code-point
妥当な~escape:#check-if-two-code-points-are-a-valid-escape
~identを開始している:#check-if-three-code-points-would-start-an-ident-sequence
実数を開始している:#check-if-three-code-points-would-start-a-number
~unicode-rangeを開始している:#check-if-three-code-points-would-start-a-unicode-range
~identを消費する:#consume-an-ident-sequence
~unicode-range~tokenを消費する:#consume-a-unicode-range-token
~unicode-range記述子の値を消費する:#consume-the-value-of-a-unicode-range-descriptor
実数を消費する:#consume-a-number
実数に変換-:#convert-a-string-to-a-number
不良~URLの残余を消費する:#consume-the-remnants-of-a-bad-url


	■ parse
~stylesheet:#css-stylesheet
規則:#css-rule
~at-規則:#at-rule
一文~at-規則:#statement-at-rule
一文:#statement-at-rule
~block~at-規則:#block-at-rule
有修飾~規則:#qualified-rule
宣言:#declaration
~prop宣言:#css-property-declarations
記述子~宣言:#css-descriptor-declarations
成分~値:#component-value
保全d~token:#preserved-tokens
関数:#function
単純~block:#simple-block
波括弧~block:#curly-block
丸括弧~block:#paren-block
角括弧~block:#square-block

~token~stream:#css-token-stream
tS.~token群:#token-stream-tokens
	tS.~token:#token-stream-tokens
tS.~index:#token-stream-index
tS.~mark済み~index群:#token-stream-marked-indexes
tS.次回の~token:#token-stream-next-token
tS.空:#token-stream-empty
tS.~tokenを消費する:#token-stream-consume-a-token
tS.~tokenを破棄する:#token-stream-discard-a-token
tS.~markする:#token-stream-mark
tS.~markを復旧する:#token-stream-restore-a-mark
tS.~markを破棄する:#token-stream-discard-a-mark
tS.空白を破棄する:#token-stream-discard-whitespace
tS.処理する:#token-stream-process
~token~streamに正規化する:#normalize-into-a-token-stream

~CSS文法に則って構文解析する:#css-parse-something-according-to-a-css-grammar
構文解析-:#css-parse-something-according-to-a-css-grammar
~stylesheetの内容を構文解析する:#parse-a-stylesheets-contents
~blockの内容を構文解析する:#parse-a-blocks-contents
~stylesheetを構文解析する:#parse-a-stylesheet
規則を構文解析する:#parse-a-rule
宣言を構文解析する:#parse-a-declaration
宣言~list:#parse-a-list-of-declarations
成分~値を構文解析する:#parse-a-component-value
成分~値~listを構文解析する:#parse-a-list-of-component-values
~commaで分離された成分~値~listを構文解析する:#parse-a-comma-separated-list-of-component-values

~stylesheetの内容を消費する:#consume-a-stylesheets-contents
~at-規則を消費する:#consume-an-at-rule
有修飾~規則を消費する:#consume-a-qualified-rule
~blockを消費する:#consume-a-block
~blockの内容を消費する:#consume-a-blocks-contents
宣言を消費する:#consume-a-declaration
不良な宣言の残余を消費する:#consume-the-remnants-of-a-bad-declaration
成分~値~listを消費する:#consume-a-list-of-component-values
成分~値を消費する:#consume-a-component-value
単純~blockを消費する:#consume-a-simple-block
関数を消費する:#consume-a-function

~commaで分離された~listを~CSS文法に則って構文解析する:#css-parse-a-comma-separated-list-according-to-a-css-grammar
	~listを構文解析する
~CSS~stylesheetを構文解析する:#parse-a-css-stylesheet

i.妥当な規則でない:#invalid-rule-error

~escape法:#escape-codepoint

~anb 値を直列化する:#serialize-an-anb-value


記述子:#css-descriptor
成分~値~list:#_component-value-list

	復号-:#decode
	終端ng~token:#ending-token
~style規則:#style-rule
	後続の n 番目の符号位置
	後続の符号位置(n)

	符号化法:#at-charset-encoding

~anb:#anb-production
~AnB:#anb
周期:#_anb-step
~offset:#_anb-offset
数字~列:#_series-of-digits


	●外部（CSS
~list値をとる:~CSSTOM1#list-valued-properties

§ 値~定義の構文:~CSSVAL#value-defs
関数-記法:~CSSVAL#functional-notation
~CSS識別子:~CSSVAL#css-css-identifier

選択子:~SELECTORS4#selector
無効な選択子:~SELECTORS4#invalid-selector
選択子~list:~SELECTORS4#selector-list
~ID選択子:~SELECTORS4#id-selectors
属性~選択子:~SELECTORS4#attribute-selectors
結合子:~SELECTORS4#selector-combinator

~prop:~CASCADE#css-property
~cascade:~CASCADE#cascade
~importantな宣言:~CASCADE#important
出自:~CASCADE#origin
非~CSS呈示~用~hint:~CASCADE#preshint

条件付き~group規則:~CSSCOND#conditional-group-rule
媒体~query~list:~MQ5#media-query-list
媒体~型:~MQ5#media-type

~custom~prop:~CSSVAR#custom-property

入子な宣言~列が成す規則:~CSSNESTING#nested-declarations-rule
	#nested-declarations-rule%E2%91%A0

~CSS~stylesheet:~CSSOM1#css-style-sheet
ss.所在:~CSSOM1#concept-css-style-sheet-location

~custom~prop名~文字列:~CSSTOM1#custom-property-name-string

~counter~style:~CSSCOUNTER#counter-style
規則~集合:~CSS22/syndata.html#rule-sets
~EOF~errorの取扱い規則:~CSS22/syndata.html#unexpected-eof

	Selectors API:~TR/selectors-api/
	Selectors仕様:~TR/selectors/

	●外部（他
sub.大小無視:~INFRA#ascii-case-insensitive
~ASCII大小無視:~INFRA#ascii-case-insensitive
符号位置:~INFRA#code-point
~surrogate:~INFRA#surrogate
~scalar値:~INFRA#scalar-value
文字列:~INFRA#string
cp.値:~INFRA#code-point-value

~list:~INFRA#list
~size:~INFRA#list-size
付加する:~INFRA#list-append
除去する:~INFRA#list-remove
構造体:~INFRA#struct
sct.~item:~INFRA#struct-item
~stack:~INFRA#stack
~popする:~INFRA#stack-pop

符号化法~label:~ENCODING#label
~Unicodeに復号する:~ENCODING#decode
	復号-~algo:~ENCODING#decode
~labelから符号化法を取得する:~ENCODING#concept-encoding-get
enc.UTF-16LE:~ENCODING#utf-16le
enc.UTF-16BE:~ENCODING#utf-16be
enc.UTF-8:~ENCODING#utf-8

~URL:~URL1#concept-url

妥当な~custom要素~名:~HEcustom#valid-custom-element-name

●●unicode_map


00:NULL
08:BACKSPACE
09:CHARACTER TABULATION
0A:LINE FEED
0B:LINE TABULATION
0C:FORM FEED
0D:CARRIAGE RETURN
0E:SHIFT OUT
1F:INFORMATION SEPARATOR ONE
20:SPACE
21!EXCLAMATION MARK
22!QUOTATION MARK
23!NUMBER SIGN
24!DOLLAR SIGN
25!PERCENTAGE SIGN
26!AMPERSAND
27!APOSTROPHE
28!LEFT PARENTHESIS
29!RIGHT PARENTHESIS
2A!ASTERISK
2B!PLUS SIGN
2C!COMMA
2D!HYPHEN-MINUS
2E!FULL STOP
2F!SOLIDUS
30!DIGIT ZERO
39!DIGIT NINE
3A!COLON
3B!SEMICOLON
3C!LESS-THAN SIGN
3D!EQUALS SIGN
3E!GREATER-THAN SIGN
3F!QUESTION MARK
40!COMMERCIAL AT
41!LATIN CAPITAL LETTER A
45!LATIN CAPITAL LETTER E
46!LATIN CAPITAL LETTER F
55!LATIN CAPITAL LETTER U
5A!LATIN CAPITAL LETTER Z
5B!LEFT SQUARE BRACKET
5C!REVERSE SOLIDUS
5D!RIGHT SQUARE BRACKET
5E!CIRCUMFLEX ACCENT
5F!LOW LINE
61!LATIN SMALL LETTER A
65!LATIN SMALL LETTER E
66!LATIN SMALL LETTER F
75!LATIN SMALL LETTER U
7A!LATIN SMALL LETTER Z
7B!LEFT CURLY BRACKET
7C!VERTICAL LINE
7D!RIGHT CURLY BRACKET
7E!TILDE
7F:DELETE
80:&lt;control&gt;
FFFD!REPLACEMENT CHARACTER
	0080 〜 009F
	D800 〜 DFFF

●●ref_key_map
CSS3CONDITIONAL:CSSCONDITIONAL3
CSS3ANIMATIONS:CSSANIMATIONS1
MEDIAQ:MEDIAQUERIES4

●●ref_normative

[CSS-CASCADE-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 3＞. URL: https://drafts.csswg.org/css-cascade-3/
[CSS-CASCADE-5]
    Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 5＞. URL: https://drafts.csswg.org/css-cascade-5/
[CSS-COUNTER-STYLES-3]
    Tab Atkins Jr.. ＜CSS Counter Styles Level 3＞. URL: https://drafts.csswg.org/css-counter-styles/
[CSS-FONTS-4]
    Chris Lilley. ＜CSS Fonts Module Level 4＞. URL: https://drafts.csswg.org/css-fonts-4/
[CSS-NESTING-1]
    Tab Atkins Jr.; Adam Argyle. ＜CSS Nesting Module＞. URL: https://drafts.csswg.org/css-nesting/
[CSS-PAGE-3]
    Elika Etemad. ＜CSS Paged Media Module Level 3＞. URL: https://drafts.csswg.org/css-page-3/
[CSS-SYNTAX-3]
    Tab Atkins Jr.; Simon Sapin. ＜CSS Syntax Module Level 3＞. URL: https://drafts.csswg.org/css-syntax/
[CSS-TYPED-OM-1]
    Tab Atkins Jr.; François Remy. ＜CSS Typed OM Level 1＞. URL: https://drafts.css-houdini.org/css-typed-om-1/
[CSS-VALUES-4]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Values and Units Module Level 4＞. URL: https://drafts.csswg.org/css-values-4/
[CSS-VARIABLES-2]
    ＜CSS Custom Properties for Cascading Variables Module Level 2＞. Editor's Draft. URL: https://drafts.csswg.org/css-variables-2/
[CSS3-CONDITIONAL]
    Chris Lilley; David Baron; Elika Etemad. ＜CSS Conditional Rules Module Level 3＞. URL: https://drafts.csswg.org/css-conditional-3/
[CSSOM]
    Daniel Glazman; Emilio Cobos Álvarez. ＜CSS Object Model (CSSOM)＞. URL: https://drafts.csswg.org/cssom/
[ENCODING]
    Anne van Kesteren. ＜Encoding Standard＞. Living Standard. URL: https://encoding.spec.whatwg.org/
[HTML]
    Anne van Kesteren; et al. ＜HTML Standard＞. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
    Anne van Kesteren; Domenic Denicola. ＜Infra Standard＞. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
    S. Bradner. ＜Key words for use in RFCs to Indicate Requirement Levels＞. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-4]
    Elika Etemad; Tab Atkins Jr.. ＜Selectors Level 4＞. URL: https://drafts.csswg.org/selectors/
[URL]
    Anne van Kesteren. ＜URL Standard＞. Living Standard. URL: https://url.spec.whatwg.org/

●●ref_informative

[CSS-COLOR-4]
    Chris Lilley; Tab Atkins Jr.; Lea Verou. ＜CSS Color Module Level 4＞. URL: https://drafts.csswg.org/css-color-4/
[CSS-COLOR-5]
    Chris Lilley; et al. ＜CSS Color Module Level 5＞. URL: https://drafts.csswg.org/css-color-5/
[CSS-FONTS-5]
    Chris Lilley. ＜CSS Fonts Module Level 5＞. URL: https://drafts.csswg.org/css-fonts-5/
[CSS-NAMESPACES-3]
    Elika Etemad. ＜CSS Namespaces Module Level 3＞. URL: https://drafts.csswg.org/css-namespaces/
[CSS-TEXT-DECOR-3]
    Elika Etemad; Koji Ishii. ＜CSS Text Decoration Module Level 3＞. URL: https://drafts.csswg.org/css-text-decor-3/
[CSS-TEXT-DECOR-4]
    Elika Etemad; Koji Ishii. ＜CSS Text Decoration Module Level 4＞. URL: https://drafts.csswg.org/css-text-decor-4/
[CSS-TRANSFORMS-1]
    Simon Fraser; et al. ＜CSS Transforms Module Level 1＞. URL: https://drafts.csswg.org/css-transforms/
[CSS-VALUES-5]
    Tab Atkins Jr.; Elika Etemad; Miriam Suzanne. ＜CSS Values and Units Module Level 5＞. URL: https://drafts.csswg.org/css-values-5/
[CSS-VARIABLES]
    Tab Atkins Jr.. ＜CSS Custom Properties for Cascading Variables Module Level 1＞. URL: https://drafts.csswg.org/css-variables/
[CSS2]
    Bert Bos; et al. ＜Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification＞. URL: https://drafts.csswg.org/css2/
[CSS3-ANIMATIONS]
    David Baron; et al. ＜CSS Animations Level 1＞. URL: https://drafts.csswg.org/css-animations/
[MEDIAQ]
    Florian Rivoal; Tab Atkins Jr.. ＜Media Queries Level 4＞. URL: https://drafts.csswg.org/mediaqueries-4/
[SELECT]
    Tantek Çelik; et al. ＜Selectors Level 3＞. URL: https://drafts.csswg.org/selectors-3/


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより勧告候補として公開された
<a href="~SPEC_URL">CSS Syntax Module Level 3</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/css-syntax-3/
公表履歴
	https://www.w3.org/standards/history/css-syntax-3/
テスト一式
	http://test.csswg.org/suites/css-syntax-3_dev/nightly-unstable/
フィードバック
	<a href="https://github.com/w3c/csswg-drafts/labels/css-syntax-3">CSSWG Issues Repository</a>

編集
	<a href="http://xanthir.com/contact/">Tab Atkins Jr.</a> (Google)
	<a href="http://exyr.org/about/">Simon Sapin</a> (Mozilla)

Suggest an Edit for this Spec
	<a href="https://github.com/w3c/csswg-drafts/blob/main/css-syntax-3/Overview.bs">GitHub Editor</a>
commit 履歴
	https://github.com/w3c/csswg-drafts/commits/main/css-syntax-3

</script>

</head>
<body>

<!--%resource pool -->
<template id="_persisted_parts">

	<!-- tokenizer railroad -->

<svg id="_dgm-comment" class="railroad-diagram" height="80" viewBox="0 0 512.0 80" width="512.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="terminal">
<path d="M50 40h0.0"></path>
<path d="M87.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="37" x="50" y="29"></rect>
<text x="68.5" y="44">/*</text>
</g>
<path d="M87.0 40h10"></path>
<g>
<path d="M97.0 40h0.0"></path>
<path d="M415.0 40h0.0"></path>
<path d="M97.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M117.0 20h278.0"></path>
</g>
<path d="M395.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M97.0 40h20"></path>
<g>
<path d="M117.0 40h0.0"></path>
<path d="M395.0 40h0.0"></path>
<path d="M117.0 40h10"></path>
<g class="non-terminal">
<path d="M127.0 40h0.0"></path>
<path d="M385.0 40h0.0"></path>
<rect height="22" width="258" x="127" y="29"></rect>
<text x="256" y="44">anything but * followed by /</text>
</g>
<path d="M385.0 40h10"></path>
<path d="M127.0 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M127.0 60h258.0"></path>
</g>
<path d="M385.0 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M395.0 40h20"></path>
</g>
<path d="M415.0 40h10"></path>
<g class="terminal">
<path d="M425.0 40h0.0"></path>
<path d="M462.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="37" x="425" y="29"></rect>
<text x="443.5" y="44">*/</text>
</g>
<path d="M462.0 40h10"></path>
<path d="M 472.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-newline" class="railroad-diagram" height="152" viewBox="0 0 174.0 152" width="174.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 31h0.0"></path>
<path d="M134.0 31h0.0"></path>
<path d="M40.0 31h20"></path>
<g class="terminal">
<path d="M60.0 31h8.5"></path>
<path d="M105.5 31h8.5"></path>
<rect height="22" rx="10" ry="10" width="37" x="68.5" y="20"></rect>
<text x="87" y="35">\n</text>
</g>
<path d="M114.0 31h20"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M60.0 61h0.0"></path>
<path d="M114.0 61h0.0"></path>
<rect height="22" rx="10" ry="10" width="54" x="60" y="50"></rect>
<text x="87" y="65">\r\n</text>
</g>
<path d="M114.0 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M60.0 91h8.5"></path>
<path d="M105.5 91h8.5"></path>
<rect height="22" rx="10" ry="10" width="37" x="68.5" y="80"></rect>
<text x="87" y="95">\r</text>
</g>
<path d="M114.0 91a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v70a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M60.0 121h8.5"></path>
<path d="M105.5 121h8.5"></path>
<rect height="22" rx="10" ry="10" width="37" x="68.5" y="110"></rect>
<text x="87" y="125">\f</text>
</g>
<path d="M114.0 121a10 10 0 0 0 10 -10v-70a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 134.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-whitespace" class="railroad-diagram" height="122" viewBox="0 0 199.5 122" width="199.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 31h0.0"></path>
<path d="M159.5 31h0.0"></path>
<path d="M40.0 31h20"></path>
<g class="terminal">
<path d="M60.0 31h8.5"></path>
<path d="M131.0 31h8.5"></path>
<rect height="22" rx="10" ry="10" width="62.5" x="68.5" y="20"></rect>
<text x="99.75" y="35">space</text>
</g>
<path d="M139.5 31h20"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M60.0 61h21.25"></path>
<path d="M118.25 61h21.25"></path>
<rect height="22" rx="10" ry="10" width="37" x="81.25" y="50"></rect>
<text x="99.75" y="65">\t</text>
</g>
<path d="M139.5 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M60.0 91h0.0"></path>
<path d="M139.5 91h0.0"></path>
<rect height="22" width="79.5" x="60" y="80"></rect>
<text x="99.75" y="95">newline</text>
</g>
<path d="M139.5 91a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 159.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-hex-digit" class="railroad-diagram" height="62" viewBox="0 0 239.0 62" width="239.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="non-terminal">
<path d="M50 31h0.0"></path>
<path d="M189.0 31h0.0"></path>
<rect height="22" width="139" x="50" y="20"></rect>
<text x="119.5" y="35">0-9 a-f or A-F</text>
</g>
<path d="M189.0 31h10"></path>
<path d="M 199.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-escape" class="railroad-diagram" height="116" viewBox="0 0 440.0 116" width="440.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M78.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="50" y="20"></rect>
<text x="64.25" y="35">\</text>
</g>
<path d="M78.5 31h10"></path>
<g>
<path d="M88.5 31h0.0"></path>
<path d="M400.0 31h0.0"></path>
<path d="M88.5 31h20"></path>
<g class="non-terminal">
<path d="M108.5 31h23.75"></path>
<path d="M356.25 31h23.75"></path>
<rect height="22" width="224" x="132.25" y="20"></rect>
<text x="244.25" y="35">not newline or hex digit</text>
</g>
<path d="M380.0 31h20"></path>
<path d="M88.5 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g>
<path d="M108.5 61h0.0"></path>
<path d="M380.0 61h0.0"></path>
<g>
<path d="M108.5 61h0.0"></path>
<path d="M225.0 61h0.0"></path>
<path d="M108.5 61h10"></path>
<g class="non-terminal">
<path d="M118.5 61h0.0"></path>
<path d="M215.0 61h0.0"></path>
<rect height="22" width="96.5" x="118.5" y="50"></rect>
<text x="166.75" y="65">hex digit</text>
</g>
<path d="M215.0 61h10"></path>
<path d="M118.5 61a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M118.5 88h11.75"></path>
<path d="M203.25 88h11.75"></path>
<text class="comment" x="166.75" y="93">1-6 times</text>
</g>
<path d="M215.0 88a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M225.0 61h10"></path>
<g>
<path d="M235.0 61h0.0"></path>
<path d="M380.0 61h0.0"></path>
<path d="M235.0 61h20"></path>
<g>
<path d="M255.0 61h105.0"></path>
</g>
<path d="M360.0 61h20"></path>
<path d="M235.0 61a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M255.0 81h0.0"></path>
<path d="M360.0 81h0.0"></path>
<rect height="22" width="105" x="255" y="70"></rect>
<text x="307.5" y="85">whitespace</text>
</g>
<path d="M360.0 81a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
</g>
</g>
<path d="M380.0 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 400.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-whitespace-token" class="railroad-diagram" height="71" viewBox="0 0 225.0 71" width="225.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g>
<path d="M50 31h0.0"></path>
<path d="M175.0 31h0.0"></path>
<path d="M50.0 31h10"></path>
<g class="non-terminal">
<path d="M60.0 31h0.0"></path>
<path d="M165.0 31h0.0"></path>
<rect height="22" width="105" x="60" y="20"></rect>
<text x="112.5" y="35">whitespace</text>
</g>
<path d="M165.0 31h10"></path>
<path d="M60.0 31a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M60.0 51h105.0"></path>
</g>
<path d="M165.0 51a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M175.0 31h10"></path>
<path d="M 185.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-whitespaces" class="railroad-diagram" height="80" viewBox="0 0 313.0 80" width="313.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 40h0.0"></path>
<path d="M273.0 40h0.0"></path>
<path d="M40.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M60.0 20h193.0"></path>
</g>
<path d="M253.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M40.0 40h20"></path>
<g>
<path d="M60.0 40h0.0"></path>
<path d="M253.0 40h0.0"></path>
<path d="M60.0 40h10"></path>
<g class="non-terminal">
<path d="M70.0 40h0.0"></path>
<path d="M243.0 40h0.0"></path>
<rect height="22" width="173" x="70" y="29"></rect>
<text x="156.5" y="44">&lt;whitespace-token&gt;</text>
</g>
<path d="M243.0 40h10"></path>
<path d="M70.0 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M70.0 60h173.0"></path>
</g>
<path d="M243.0 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M253.0 40h20"></path>
</g>
<path d="M 273.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-ident-token" class="railroad-diagram" height="130" viewBox="0 0 793.5 130" width="793.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 51v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 61h0.0"></path>
<path d="M395.5 61h0.0"></path>
<path d="M40.0 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<g class="terminal">
<path d="M60.0 31h139.25"></path>
<path d="M236.25 31h139.25"></path>
<rect height="22" rx="10" ry="10" width="37" x="199.25" y="20"></rect>
<text x="217.75" y="35">--</text>
</g>
<path d="M375.5 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<path d="M40.0 61h20"></path>
<g>
<path d="M60.0 61h0.0"></path>
<path d="M375.5 61h0.0"></path>
<g>
<path d="M60.0 61h0.0"></path>
<path d="M128.5 61h0.0"></path>
<path d="M60.0 61h20"></path>
<g>
<path d="M80.0 61h28.5"></path>
</g>
<path d="M108.5 61h20"></path>
<path d="M60.0 61a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M80.0 81h0.0"></path>
<path d="M108.5 81h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="80" y="70"></rect>
<text x="94.25" y="85">-</text>
</g>
<path d="M108.5 81a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
</g>
<g>
<path d="M128.5 61h0.0"></path>
<path d="M375.5 61h0.0"></path>
<path d="M128.5 61h20"></path>
<g class="non-terminal">
<path d="M148.5 61h0.0"></path>
<path d="M355.5 61h0.0"></path>
<rect height="22" width="207" x="148.5" y="50"></rect>
<text x="252" y="65">a-z A-Z _ or non-ASCII</text>
</g>
<path d="M355.5 61h20"></path>
<path d="M128.5 61a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M148.5 91h68.0"></path>
<path d="M287.5 91h68.0"></path>
<rect height="22" width="71" x="216.5" y="80"></rect>
<text x="252" y="95">escape</text>
</g>
<path d="M355.5 91a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
</g>
<path d="M375.5 61h20"></path>
</g>
<g>
<path d="M395.5 61h0.0"></path>
<path d="M753.5 61h0.0"></path>
<path d="M395.5 61a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M415.5 41h318.0"></path>
</g>
<path d="M733.5 41a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M395.5 61h20"></path>
<g>
<path d="M415.5 61h0.0"></path>
<path d="M733.5 61h0.0"></path>
<path d="M415.5 61h10"></path>
<g>
<path d="M425.5 61h0.0"></path>
<path d="M723.5 61h0.0"></path>
<path d="M425.5 61h20"></path>
<g class="non-terminal">
<path d="M445.5 61h0.0"></path>
<path d="M703.5 61h0.0"></path>
<rect height="22" width="258" x="445.5" y="50"></rect>
<text x="574.5" y="65">a-z A-Z 0-9 _ - or non-ASCII</text>
</g>
<path d="M703.5 61h20"></path>
<path d="M425.5 61a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M445.5 91h93.5"></path>
<path d="M610.0 91h93.5"></path>
<rect height="22" width="71" x="539" y="80"></rect>
<text x="574.5" y="95">escape</text>
</g>
<path d="M703.5 91a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M723.5 61h10"></path>
<path d="M425.5 61a10 10 0 0 0 -10 10v29a10 10 0 0 0 10 10"></path>
<g>
<path d="M425.5 110h298.0"></path>
</g>
<path d="M723.5 110a10 10 0 0 0 10 -10v-29a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M733.5 61h20"></path>
</g>
<path d="M 753.5 61 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-function-token" class="railroad-diagram" height="62" viewBox="0 0 279.0 62" width="279.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="non-terminal">
<path d="M50 31h0.0"></path>
<path d="M180.5 31h0.0"></path>
<rect height="22" width="130.5" x="50" y="20"></rect>
<text x="115.25" y="35">&lt;ident-token&gt;</text>
</g>
<path d="M180.5 31h10"></path>
<path d="M190.5 31h10"></path>
<g class="terminal">
<path d="M200.5 31h0.0"></path>
<path d="M229.0 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="200.5" y="20"></rect>
<text x="214.75" y="35">(</text>
</g>
<path d="M229.0 31h10"></path>
<path d="M 239.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-at-keyword-token" class="railroad-diagram" height="62" viewBox="0 0 279.0 62" width="279.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M78.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="50" y="20"></rect>
<text x="64.25" y="35">@</text>
</g>
<path d="M78.5 31h10"></path>
<path d="M88.5 31h10"></path>
<g class="non-terminal">
<path d="M98.5 31h0.0"></path>
<path d="M229.0 31h0.0"></path>
<rect height="22" width="130.5" x="98.5" y="20"></rect>
<text x="163.75" y="35">&lt;ident-token&gt;</text>
</g>
<path d="M229.0 31h10"></path>
<path d="M 239.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-hash-token" class="railroad-diagram" height="100" viewBox="0 0 466.5 100" width="466.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M78.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="50" y="20"></rect>
<text x="64.25" y="35">#</text>
</g>
<path d="M78.5 31h10"></path>
<path d="M88.5 31h10"></path>
<g>
<path d="M98.5 31h0.0"></path>
<path d="M416.5 31h0.0"></path>
<path d="M98.5 31h10"></path>
<g>
<path d="M108.5 31h0.0"></path>
<path d="M406.5 31h0.0"></path>
<path d="M108.5 31h20"></path>
<g class="non-terminal">
<path d="M128.5 31h0.0"></path>
<path d="M386.5 31h0.0"></path>
<rect height="22" width="258" x="128.5" y="20"></rect>
<text x="257.5" y="35">a-z A-Z 0-9 _ - or non-ASCII</text>
</g>
<path d="M386.5 31h20"></path>
<path d="M108.5 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M128.5 61h93.5"></path>
<path d="M293.0 61h93.5"></path>
<rect height="22" width="71" x="222" y="50"></rect>
<text x="257.5" y="65">escape</text>
</g>
<path d="M386.5 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M406.5 31h10"></path>
<path d="M108.5 31a10 10 0 0 0 -10 10v29a10 10 0 0 0 10 10"></path>
<g>
<path d="M108.5 80h298.0"></path>
</g>
<path d="M406.5 80a10 10 0 0 0 10 -10v-29a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M416.5 31h10"></path>
<path d="M 426.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-string-token" class="railroad-diagram" height="246" viewBox="0 0 470.0 246" width="470.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 40h0.0"></path>
<path d="M430.0 40h0.0"></path>
<path d="M40.0 40h20"></path>
<g>
<path d="M60.0 40h0.0"></path>
<path d="M410.0 40h0.0"></path>
<g class="terminal">
<path d="M60.0 40h0.0"></path>
<path d="M88.5 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="29"></rect>
<text x="74.25" y="44">"</text>
</g>
<path d="M88.5 40h10"></path>
<g>
<path d="M98.5 40h0.0"></path>
<path d="M371.5 40h0.0"></path>
<path d="M98.5 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M118.5 20h233.0"></path>
</g>
<path d="M351.5 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M98.5 40h20"></path>
<g>
<path d="M118.5 40h0.0"></path>
<path d="M351.5 40h0.0"></path>
<path d="M118.5 40h10"></path>
<g>
<path d="M128.5 40h0.0"></path>
<path d="M341.5 40h0.0"></path>
<path d="M128.5 40h20"></path>
<g class="non-terminal">
<path d="M148.5 40h0.0"></path>
<path d="M321.5 40h0.0"></path>
<rect height="22" width="173" x="148.5" y="29"></rect>
<text x="235" y="44">not " \ or newline</text>
</g>
<path d="M321.5 40h20"></path>
<path d="M128.5 40a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M148.5 70h51.0"></path>
<path d="M270.5 70h51.0"></path>
<rect height="22" width="71" x="199.5" y="59"></rect>
<text x="235" y="74">escape</text>
</g>
<path d="M321.5 70a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M128.5 40a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g>
<path d="M148.5 100h22.5"></path>
<path d="M299.0 100h22.5"></path>
<g class="terminal">
<path d="M171.0 100h0.0"></path>
<path d="M199.5 100h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="171" y="89"></rect>
<text x="185.25" y="104">\</text>
</g>
<path d="M199.5 100h10"></path>
<path d="M209.5 100h10"></path>
<g class="non-terminal">
<path d="M219.5 100h0.0"></path>
<path d="M299.0 100h0.0"></path>
<rect height="22" width="79.5" x="219.5" y="89"></rect>
<text x="259.25" y="104">newline</text>
</g>
</g>
<path d="M321.5 100a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
</g>
<path d="M341.5 40h10"></path>
<path d="M128.5 40a10 10 0 0 0 -10 10v59a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 119h213.0"></path>
</g>
<path d="M341.5 119a10 10 0 0 0 10 -10v-59a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M351.5 40h20"></path>
</g>
<path d="M371.5 40h10"></path>
<g class="terminal">
<path d="M381.5 40h0.0"></path>
<path d="M410.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="381.5" y="29"></rect>
<text x="395.75" y="44">"</text>
</g>
</g>
<path d="M410.0 40h20"></path>
<path d="M40.0 40a10 10 0 0 1 10 10v87a10 10 0 0 0 10 10"></path>
<g>
<path d="M60.0 147h0.0"></path>
<path d="M410.0 147h0.0"></path>
<g class="terminal">
<path d="M60.0 147h0.0"></path>
<path d="M88.5 147h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="136"></rect>
<text x="74.25" y="151">'</text>
</g>
<path d="M88.5 147h10"></path>
<g>
<path d="M98.5 147h0.0"></path>
<path d="M371.5 147h0.0"></path>
<path d="M98.5 147a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M118.5 127h233.0"></path>
</g>
<path d="M351.5 127a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M98.5 147h20"></path>
<g>
<path d="M118.5 147h0.0"></path>
<path d="M351.5 147h0.0"></path>
<path d="M118.5 147h10"></path>
<g>
<path d="M128.5 147h0.0"></path>
<path d="M341.5 147h0.0"></path>
<path d="M128.5 147h20"></path>
<g class="non-terminal">
<path d="M148.5 147h0.0"></path>
<path d="M321.5 147h0.0"></path>
<rect height="22" width="173" x="148.5" y="136"></rect>
<text x="235" y="151">not ' \ or newline</text>
</g>
<path d="M321.5 147h20"></path>
<path d="M128.5 147a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M148.5 177h51.0"></path>
<path d="M270.5 177h51.0"></path>
<rect height="22" width="71" x="199.5" y="166"></rect>
<text x="235" y="181">escape</text>
</g>
<path d="M321.5 177a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M128.5 147a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g>
<path d="M148.5 207h22.5"></path>
<path d="M299.0 207h22.5"></path>
<g class="terminal">
<path d="M171.0 207h0.0"></path>
<path d="M199.5 207h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="171" y="196"></rect>
<text x="185.25" y="211">\</text>
</g>
<path d="M199.5 207h10"></path>
<path d="M209.5 207h10"></path>
<g class="non-terminal">
<path d="M219.5 207h0.0"></path>
<path d="M299.0 207h0.0"></path>
<rect height="22" width="79.5" x="219.5" y="196"></rect>
<text x="259.25" y="211">newline</text>
</g>
</g>
<path d="M321.5 207a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
</g>
<path d="M341.5 147h10"></path>
<path d="M128.5 147a10 10 0 0 0 -10 10v59a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 226h213.0"></path>
</g>
<path d="M341.5 226a10 10 0 0 0 10 -10v-59a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M351.5 147h20"></path>
</g>
<path d="M371.5 147h10"></path>
<g class="terminal">
<path d="M381.5 147h0.0"></path>
<path d="M410.0 147h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="381.5" y="136"></rect>
<text x="395.75" y="151">'</text>
</g>
</g>
<path d="M410.0 147a10 10 0 0 0 10 -10v-87a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 430.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-url-token" class="railroad-diagram" height="109" viewBox="0 0 910.0 109" width="910.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="non-terminal">
<path d="M50 40h0.0"></path>
<path d="M231.5 40h0.0"></path>
<rect height="22" width="181.5" x="50" y="29"></rect>
<text x="140.75" y="44">&lt;ident-token "url"&gt;</text>
</g>
<path d="M231.5 40h10"></path>
<path d="M241.5 40h10"></path>
<g class="terminal">
<path d="M251.5 40h0.0"></path>
<path d="M280.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="251.5" y="29"></rect>
<text x="265.75" y="44">(</text>
</g>
<path d="M280.0 40h10"></path>
<path d="M290.0 40h10"></path>
<g class="non-terminal">
<path d="M300.0 40h0.0"></path>
<path d="M345.5 40h0.0"></path>
<rect height="22" width="45.5" x="300" y="29"></rect>
<text x="322.75" y="44">ws*</text>
</g>
<path d="M345.5 40h10"></path>
<g>
<path d="M355.5 40h0.0"></path>
<path d="M756.0 40h0.0"></path>
<path d="M355.5 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M375.5 20h360.5"></path>
</g>
<path d="M736.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M355.5 40h20"></path>
<g>
<path d="M375.5 40h0.0"></path>
<path d="M736.0 40h0.0"></path>
<path d="M375.5 40h10"></path>
<g>
<path d="M385.5 40h0.0"></path>
<path d="M726.0 40h0.0"></path>
<path d="M385.5 40h20"></path>
<g class="non-terminal">
<path d="M405.5 40h0.0"></path>
<path d="M706.0 40h0.0"></path>
<rect height="22" width="300.5" x="405.5" y="29"></rect>
<text x="555.75" y="44">not " ' ( ) \ ws or non-printable</text>
</g>
<path d="M706.0 40h20"></path>
<path d="M385.5 40a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M405.5 70h114.75"></path>
<path d="M591.25 70h114.75"></path>
<rect height="22" width="71" x="520.25" y="59"></rect>
<text x="555.75" y="74">escape</text>
</g>
<path d="M706.0 70a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M726.0 40h10"></path>
<path d="M385.5 40a10 10 0 0 0 -10 10v29a10 10 0 0 0 10 10"></path>
<g>
<path d="M385.5 89h340.5"></path>
</g>
<path d="M726.0 89a10 10 0 0 0 10 -10v-29a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M736.0 40h20"></path>
</g>
<path d="M756.0 40h10"></path>
<g class="non-terminal">
<path d="M766.0 40h0.0"></path>
<path d="M811.5 40h0.0"></path>
<rect height="22" width="45.5" x="766" y="29"></rect>
<text x="788.75" y="44">ws*</text>
</g>
<path d="M811.5 40h10"></path>
<path d="M821.5 40h10"></path>
<g class="terminal">
<path d="M831.5 40h0.0"></path>
<path d="M860.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="831.5" y="29"></rect>
<text x="845.75" y="44">)</text>
</g>
<path d="M860.0 40h10"></path>
<path d="M 870.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-number-token" class="railroad-diagram" height="169" viewBox="0 0 691.5 169" width="691.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 41v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 51h0.0"></path>
<path d="M108.5 51h0.0"></path>
<path d="M40.0 51a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g class="terminal">
<path d="M60.0 31h0.0"></path>
<path d="M88.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="20"></rect>
<text x="74.25" y="35">+</text>
</g>
<path d="M88.5 31a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M40.0 51h20"></path>
<g>
<path d="M60.0 51h28.5"></path>
</g>
<path d="M88.5 51h20"></path>
<path d="M40.0 51a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M60.0 71h0.0"></path>
<path d="M88.5 71h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="60"></rect>
<text x="74.25" y="75">-</text>
</g>
<path d="M88.5 71a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
</g>
<g>
<path d="M108.5 51h0.0"></path>
<path d="M382.0 51h0.0"></path>
<path d="M108.5 51h20"></path>
<g>
<path d="M128.5 51h0.0"></path>
<path d="M362.0 51h0.0"></path>
<g>
<path d="M128.5 51h0.0"></path>
<path d="M211.0 51h0.0"></path>
<path d="M128.5 51h10"></path>
<g class="non-terminal">
<path d="M138.5 51h0.0"></path>
<path d="M201.0 51h0.0"></path>
<rect height="22" width="62.5" x="138.5" y="40"></rect>
<text x="169.75" y="55">digit</text>
</g>
<path d="M201.0 51h10"></path>
<path d="M138.5 51a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M138.5 71h62.5"></path>
</g>
<path d="M201.0 71a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M211.0 51h10"></path>
<path d="M221.0 51h10"></path>
<g class="terminal">
<path d="M231.0 51h0.0"></path>
<path d="M259.5 51h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="231" y="40"></rect>
<text x="245.25" y="55">.</text>
</g>
<path d="M259.5 51h10"></path>
<path d="M269.5 51h10"></path>
<g>
<path d="M279.5 51h0.0"></path>
<path d="M362.0 51h0.0"></path>
<path d="M279.5 51h10"></path>
<g class="non-terminal">
<path d="M289.5 51h0.0"></path>
<path d="M352.0 51h0.0"></path>
<rect height="22" width="62.5" x="289.5" y="40"></rect>
<text x="320.75" y="55">digit</text>
</g>
<path d="M352.0 51h10"></path>
<path d="M289.5 51a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M289.5 71h62.5"></path>
</g>
<path d="M352.0 71a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
</g>
<path d="M362.0 51h20"></path>
<path d="M108.5 51a10 10 0 0 1 10 10v19a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 90h75.5"></path>
<path d="M286.5 90h75.5"></path>
<path d="M204.0 90h10"></path>
<g class="non-terminal">
<path d="M214.0 90h0.0"></path>
<path d="M276.5 90h0.0"></path>
<rect height="22" width="62.5" x="214" y="79"></rect>
<text x="245.25" y="94">digit</text>
</g>
<path d="M276.5 90h10"></path>
<path d="M214.0 90a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M214.0 110h62.5"></path>
</g>
<path d="M276.5 110a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M362.0 90a10 10 0 0 0 10 -10v-19a10 10 0 0 1 10 -10"></path>
<path d="M108.5 51a10 10 0 0 1 10 10v58a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 129h51.25"></path>
<path d="M310.75 129h51.25"></path>
<g class="terminal">
<path d="M179.75 129h0.0"></path>
<path d="M208.25 129h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="179.75" y="118"></rect>
<text x="194" y="133">.</text>
</g>
<path d="M208.25 129h10"></path>
<path d="M218.25 129h10"></path>
<g>
<path d="M228.25 129h0.0"></path>
<path d="M310.75 129h0.0"></path>
<path d="M228.25 129h10"></path>
<g class="non-terminal">
<path d="M238.25 129h0.0"></path>
<path d="M300.75 129h0.0"></path>
<rect height="22" width="62.5" x="238.25" y="118"></rect>
<text x="269.5" y="133">digit</text>
</g>
<path d="M300.75 129h10"></path>
<path d="M238.25 129a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M238.25 149h62.5"></path>
</g>
<path d="M300.75 149a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
</g>
<path d="M362.0 129a10 10 0 0 0 10 -10v-58a10 10 0 0 1 10 -10"></path>
</g>
<g>
<path d="M382.0 51h0.0"></path>
<path d="M651.5 51h0.0"></path>
<path d="M382.0 51h20"></path>
<g>
<path d="M402.0 51h229.5"></path>
</g>
<path d="M631.5 51h20"></path>
<path d="M382.0 51a10 10 0 0 1 10 10v19a10 10 0 0 0 10 10"></path>
<g>
<path d="M402.0 90h0.0"></path>
<path d="M631.5 90h0.0"></path>
<g>
<path d="M402.0 90h0.0"></path>
<path d="M470.5 90h0.0"></path>
<path d="M402.0 90h20"></path>
<g class="terminal">
<path d="M422.0 90h0.0"></path>
<path d="M450.5 90h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="422" y="79"></rect>
<text x="436.25" y="94">e</text>
</g>
<path d="M450.5 90h20"></path>
<path d="M402.0 90a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M422.0 120h0.0"></path>
<path d="M450.5 120h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="422" y="109"></rect>
<text x="436.25" y="124">E</text>
</g>
<path d="M450.5 120a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<g>
<path d="M470.5 90h0.0"></path>
<path d="M539.0 90h0.0"></path>
<path d="M470.5 90a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g class="terminal">
<path d="M490.5 70h0.0"></path>
<path d="M519.0 70h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="490.5" y="59"></rect>
<text x="504.75" y="74">+</text>
</g>
<path d="M519.0 70a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M470.5 90h20"></path>
<g>
<path d="M490.5 90h28.5"></path>
</g>
<path d="M519.0 90h20"></path>
<path d="M470.5 90a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M490.5 110h0.0"></path>
<path d="M519.0 110h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="490.5" y="99"></rect>
<text x="504.75" y="114">-</text>
</g>
<path d="M519.0 110a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
</g>
<path d="M539.0 90h10"></path>
<g>
<path d="M549.0 90h0.0"></path>
<path d="M631.5 90h0.0"></path>
<path d="M549.0 90h10"></path>
<g class="non-terminal">
<path d="M559.0 90h0.0"></path>
<path d="M621.5 90h0.0"></path>
<rect height="22" width="62.5" x="559" y="79"></rect>
<text x="590.25" y="94">digit</text>
</g>
<path d="M621.5 90h10"></path>
<path d="M559.0 90a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M559.0 110h62.5"></path>
</g>
<path d="M621.5 110a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
</g>
<path d="M631.5 90a10 10 0 0 0 10 -10v-19a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 651.5 51 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-dimension-token" class="railroad-diagram" height="62" viewBox="0 0 389.5 62" width="389.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="non-terminal">
<path d="M50 31h0.0"></path>
<path d="M189.0 31h0.0"></path>
<rect height="22" width="139" x="50" y="20"></rect>
<text x="119.5" y="35">&lt;number-token&gt;</text>
</g>
<path d="M189.0 31h10"></path>
<path d="M199.0 31h10"></path>
<g class="non-terminal">
<path d="M209.0 31h0.0"></path>
<path d="M339.5 31h0.0"></path>
<rect height="22" width="130.5" x="209" y="20"></rect>
<text x="274.25" y="35">&lt;ident-token&gt;</text>
</g>
<path d="M339.5 31h10"></path>
<path d="M 349.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-percentage-token" class="railroad-diagram" height="62" viewBox="0 0 287.5 62" width="287.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="non-terminal">
<path d="M50 31h0.0"></path>
<path d="M189.0 31h0.0"></path>
<rect height="22" width="139" x="50" y="20"></rect>
<text x="119.5" y="35">&lt;number-token&gt;</text>
</g>
<path d="M189.0 31h10"></path>
<path d="M199.0 31h10"></path>
<g class="terminal">
<path d="M209.0 31h0.0"></path>
<path d="M237.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="209" y="20"></rect>
<text x="223.25" y="35">%</text>
</g>
<path d="M237.5 31h10"></path>
<path d="M 247.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-CDO-token" class="railroad-diagram" height="62" viewBox="0 0 154.0 62" width="154.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M104.0 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="54" x="50" y="20"></rect>
<text x="77" y="35">&lt;!--</text>
</g>
<path d="M104.0 31h10"></path>
<path d="M 114.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-CDC-token" class="railroad-diagram" height="62" viewBox="0 0 145.5 62" width="145.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M95.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="45.5" x="50" y="20"></rect>
<text x="72.75" y="35">--&gt;</text>
</g>
<path d="M95.5 31h10"></path>
<path d="M 105.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>

<svg id="_dgm-unicode-range-token" class="railroad-diagram" height="203" viewBox="0 0 580.5 203" width="580.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 31h0.0"></path>
<path d="M108.5 31h0.0"></path>
<path d="M40.0 31h20"></path>
<g class="terminal ">
<path d="M60.0 31h0.0"></path>
<path d="M88.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="20"></rect>
<text x="74.25" y="35">U</text>
</g>
<path d="M88.5 31h20"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="terminal ">
<path d="M60.0 61h0.0"></path>
<path d="M88.5 61h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="50"></rect>
<text x="74.25" y="65">u</text>
</g>
<path d="M88.5 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M108.5 31h10"></path>
<g class="terminal ">
<path d="M118.5 31h0.0"></path>
<path d="M147.0 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="118.5" y="20"></rect>
<text x="132.75" y="35">+</text>
</g>
<path d="M147.0 31h10"></path>
<g>
<path d="M157.0 31h0.0"></path>
<path d="M540.5 31h0.0"></path>
<path d="M157.0 31h20"></path>
<g>
<path d="M177.0 31h113.5"></path>
<path d="M407.0 31h113.5"></path>
<path d="M290.5 31h10"></path>
<g class="non-terminal ">
<path d="M300.5 31h0.0"></path>
<path d="M397.0 31h0.0"></path>
<rect height="22" width="96.5" x="300.5" y="20"></rect>
<text x="348.75" y="35">hex digit</text>
</g>
<path d="M397.0 31h10"></path>
<path d="M300.5 31a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M300.5 58h11.75"></path>
<path d="M385.25 58h11.75"></path>
<text class="comment" x="348.75" y="63">1-6 times</text>
</g>
<path d="M397.0 58a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M520.5 31h20"></path>
<path d="M157.0 31a10 10 0 0 1 10 10v43a10 10 0 0 0 10 10"></path>
<g>
<path d="M177.0 94h0.0"></path>
<path d="M520.5 94h0.0"></path>
<g>
<path d="M177.0 94h0.0"></path>
<path d="M333.5 94h0.0"></path>
<path d="M177.0 94a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M197.0 74h116.5"></path>
</g>
<path d="M313.5 74a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M177.0 94h20"></path>
<g>
<path d="M197.0 94h0.0"></path>
<path d="M313.5 94h0.0"></path>
<path d="M197.0 94h10"></path>
<g class="non-terminal ">
<path d="M207.0 94h0.0"></path>
<path d="M303.5 94h0.0"></path>
<rect height="22" width="96.5" x="207" y="83"></rect>
<text x="255.25" y="98">hex digit</text>
</g>
<path d="M303.5 94h10"></path>
<path d="M207.0 94a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M207.0 121h11.75"></path>
<path d="M291.75 121h11.75"></path>
<text class="comment" x="255.25" y="126">1-5 times</text>
</g>
<path d="M303.5 121a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M313.5 94h20"></path>
</g>
<path d="M333.5 94h10"></path>
<g>
<path d="M343.5 94h0.0"></path>
<path d="M520.5 94h0.0"></path>
<path d="M343.5 94h10"></path>
<g class="terminal ">
<path d="M353.5 94h64.25"></path>
<path d="M446.25 94h64.25"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="417.75" y="83"></rect>
<text x="432" y="98">?</text>
</g>
<path d="M510.5 94h10"></path>
<path d="M353.5 94a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M353.5 121h0.0"></path>
<path d="M510.5 121h0.0"></path>
<text class="comment" x="432" y="126">1 to (6-digits) times</text>
</g>
<path d="M510.5 121a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
</g>
<path d="M520.5 94a10 10 0 0 0 10 -10v-43a10 10 0 0 1 10 -10"></path>
<path d="M157.0 31a10 10 0 0 1 10 10v97a10 10 0 0 0 10 10"></path>
<g>
<path d="M177.0 148h21.0"></path>
<path d="M499.5 148h21.0"></path>
<g>
<path d="M198.0 148h0.0"></path>
<path d="M314.5 148h0.0"></path>
<path d="M198.0 148h10"></path>
<g class="non-terminal ">
<path d="M208.0 148h0.0"></path>
<path d="M304.5 148h0.0"></path>
<rect height="22" width="96.5" x="208" y="137"></rect>
<text x="256.25" y="152">hex digit</text>
</g>
<path d="M304.5 148h10"></path>
<path d="M208.0 148a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M208.0 175h11.75"></path>
<path d="M292.75 175h11.75"></path>
<text class="comment" x="256.25" y="180">1-6 times</text>
</g>
<path d="M304.5 175a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M314.5 148h10"></path>
<path d="M324.5 148h10"></path>
<g class="terminal ">
<path d="M334.5 148h0.0"></path>
<path d="M363.0 148h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="334.5" y="137"></rect>
<text x="348.75" y="152">-</text>
</g>
<path d="M363.0 148h10"></path>
<path d="M373.0 148h10"></path>
<g>
<path d="M383.0 148h0.0"></path>
<path d="M499.5 148h0.0"></path>
<path d="M383.0 148h10"></path>
<g class="non-terminal ">
<path d="M393.0 148h0.0"></path>
<path d="M489.5 148h0.0"></path>
<rect height="22" width="96.5" x="393" y="137"></rect>
<text x="441.25" y="152">hex digit</text>
</g>
<path d="M489.5 148h10"></path>
<path d="M393.0 148a10 10 0 0 0 -10 10v7a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M393.0 175h11.75"></path>
<path d="M477.75 175h11.75"></path>
<text class="comment" x="441.25" y="180">1-6 times</text>
</g>
<path d="M489.5 175a10 10 0 0 0 10 -10v-7a10 10 0 0 0 -10 -10"></path>
</g>
</g>
<path d="M520.5 148a10 10 0 0 0 10 -10v-97a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 540.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


	<!-- parser railroad -->


<svg id="_dgm-stylesheet" class="railroad-diagram" height="198" viewBox="0 0 353.0 198" width="353.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 119v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 129h0.0"></path>
<path d="M313.0 129h0.0"></path>
<path d="M40.0 129a10 10 0 0 0 10 -10v-89a10 10 0 0 1 10 -10"></path>
<g>
<path d="M60.0 20h233.0"></path>
</g>
<path d="M293.0 20a10 10 0 0 1 10 10v89a10 10 0 0 0 10 10"></path>
<path d="M40.0 129h20"></path>
<g>
<path d="M60.0 129h0.0"></path>
<path d="M293.0 129h0.0"></path>
<path d="M60.0 129h10"></path>
<g>
<path d="M70.0 129h0.0"></path>
<path d="M283.0 129h0.0"></path>
<path d="M70.0 129a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<g class="non-terminal">
	<path d="M90.0 99h0.0"></path>
	<path d="M263.0 99h0.0"></path>
	<rect height="22" width="173" x="90" y="88"></rect>
	<text x="176.5" y="103">&lt;whitespace-token&gt;</text>
</g>
<path d="M263.0 99a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<path d="M70.0 129a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
<g class="non-terminal">
	<path d="M90.0 69h29.75"></path>
	<path d="M233.25 69h29.75"></path>
	<rect height="22" width="113.5" x="119.75" y="58"></rect>
	<text x="176.5" y="73">&lt;CDC-token&gt;</text>
</g>
<path d="M263.0 69a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<path d="M70.0 129a10 10 0 0 0 10 -10v-70a10 10 0 0 1 10 -10"></path>
<g class="non-terminal">
	<path d="M90.0 39h29.75"></path>
	<path d="M233.25 39h29.75"></path>
	<rect height="22" width="113.5" x="119.75" y="28"></rect>
	<text x="176.5" y="43">&lt;CDO-token&gt;</text>
</g>
<path d="M263.0 39a10 10 0 0 1 10 10v70a10 10 0 0 0 10 10"></path>
<path d="M70.0 129h20"></path>
<g class="non-terminal">
	<path d="M90.0 129h17.0"></path>
	<path d="M246.0 129h17.0"></path>
	<rect height="22" width="139" x="107" y="118"></rect>
	<text x="176.5" y="133">Qualified rule</text>
</g>
<path d="M263.0 129h20"></path>
<path d="M70.0 129a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
	<path d="M90.0 159h46.75"></path>
	<path d="M216.25 159h46.75"></path>
	<rect height="22" width="79.5" x="136.75" y="148"></rect>
	<text x="176.5" y="163">At-rule</text>
</g>
<path d="M263.0 159a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M283.0 129h10"></path>
<path d="M70.0 129a10 10 0 0 0 -10 10v29a10 10 0 0 0 10 10"></path>
<g>
<path d="M70.0 178h213.0"></path>
</g>
<path d="M283.0 178a10 10 0 0 0 10 -10v-29a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M293.0 129h20"></path>
</g>
<path d="M 313.0 129 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-at-rule" class="railroad-diagram" height="101" viewBox="0 0 608.5 101" width="608.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="non-terminal">
<path d="M50 40h0.0"></path>
<path d="M223.0 40h0.0"></path>
<rect height="22" width="173" x="50" y="29"></rect>
<text x="136.5" y="44">&lt;at-keyword-token&gt;</text>
</g>
<path d="M223.0 40h10"></path>
<g>
<path d="M233.0 40h0.0"></path>
<path d="M440.5 40h0.0"></path>
<path d="M233.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M253.0 20h167.5"></path>
</g>
<path d="M420.5 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M233.0 40h20"></path>
<g>
<path d="M253.0 40h0.0"></path>
<path d="M420.5 40h0.0"></path>
<path d="M253.0 40h10"></path>
<g class="non-terminal">
<path d="M263.0 40h0.0"></path>
<path d="M410.5 40h0.0"></path>
<rect height="22" width="147.5" x="263" y="29"></rect>
<text x="336.75" y="44">Component value</text>
</g>
<path d="M410.5 40h10"></path>
<path d="M263.0 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M263.0 60h147.5"></path>
</g>
<path d="M410.5 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M420.5 40h20"></path>
</g>
<g>
<path d="M440.5 40h0.0"></path>
<path d="M568.5 40h0.0"></path>
<path d="M440.5 40h20"></path>
<g class="non-terminal">
<path d="M460.5 40h0.0"></path>
<path d="M548.5 40h0.0"></path>
<rect height="22" width="88" x="460.5" y="29"></rect>
<text x="504.5" y="44">{} block</text>
</g>
<path d="M548.5 40h20"></path>
<path d="M440.5 40a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="terminal">
<path d="M460.5 70h29.75"></path>
<path d="M518.75 70h29.75"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="490.25" y="59"></rect>
<text x="504.5" y="74">;</text>
</g>
<path d="M548.5 70a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 568.5 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-qualified-rule" class="railroad-diagram" height="80" viewBox="0 0 395.5 80" width="395.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 40h0.0"></path>
<path d="M247.5 40h0.0"></path>
<path d="M40.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M60.0 20h167.5"></path>
</g>
<path d="M227.5 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M40.0 40h20"></path>
<g>
<path d="M60.0 40h0.0"></path>
<path d="M227.5 40h0.0"></path>
<path d="M60.0 40h10"></path>
<g class="non-terminal">
<path d="M70.0 40h0.0"></path>
<path d="M217.5 40h0.0"></path>
<rect height="22" width="147.5" x="70" y="29"></rect>
<text x="143.75" y="44">Component value</text>
</g>
<path d="M217.5 40h10"></path>
<path d="M70.0 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M70.0 60h147.5"></path>
</g>
<path d="M217.5 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M227.5 40h20"></path>
</g>
<path d="M247.5 40h10"></path>
<g class="non-terminal">
<path d="M257.5 40h0.0"></path>
<path d="M345.5 40h0.0"></path>
<rect height="22" width="88" x="257.5" y="29"></rect>
<text x="301.5" y="44">{} block</text>
</g>
<path d="M345.5 40h10"></path>
<path d="M 355.5 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-declaration-list" class="railroad-diagram" height="161" viewBox="0 0 570.0 161" width="570.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="terminal ">
<path d="M50 40h0.0"></path>
<path d="M78.5 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="50" y="29"></rect>
<text x="64.25" y="44">{</text>
</g>
<path d="M78.5 40h10"></path>
<path d="M88.5 40h10"></path>
<g class="non-terminal ">
<path d="M98.5 40h0.0"></path>
<path d="M144.0 40h0.0"></path>
<rect height="22" width="45.5" x="98.5" y="29"></rect>
<text x="121.25" y="44">ws*</text>
</g>
<path d="M144.0 40h10"></path>
<g>
<path d="M154.0 40h0.0"></path>
<path d="M416.0 40h0.0"></path>
<path d="M154.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M174.0 20h222.0"></path>
</g>
<path d="M396.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M154.0 40h20"></path>
<g>
<path d="M174.0 40h0.0"></path>
<path d="M396.0 40h0.0"></path>
<path d="M174.0 40h10"></path>
<g>
<path d="M184.0 40h0.0"></path>
<path d="M386.0 40h0.0"></path>
<path d="M184.0 40h20"></path>
<g>
<path d="M204.0 40h0.0"></path>
<path d="M366.0 40h0.0"></path>
<g class="non-terminal ">
<path d="M204.0 40h0.0"></path>
<path d="M317.5 40h0.0"></path>
<rect height="22" width="113.5" x="204" y="29"></rect>
<text x="260.75" y="44">Declaration</text>
</g>
<path d="M317.5 40h10"></path>
<path d="M327.5 40h10"></path>
<g class="terminal ">
<path d="M337.5 40h0.0"></path>
<path d="M366.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="337.5" y="29"></rect>
<text x="351.75" y="44">;</text>
</g>
</g>
<path d="M366.0 40h20"></path>
<path d="M184.0 40a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M204.0 70h41.25"></path>
<path d="M324.75 70h41.25"></path>
<rect height="22" width="79.5" x="245.25" y="59"></rect>
<text x="285" y="74">At-rule</text>
</g>
<path d="M366.0 70a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M184.0 40a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M204.0 100h11.5"></path>
<path d="M354.5 100h11.5"></path>
<rect height="22" width="139" x="215.5" y="89"></rect>
<text x="285" y="104">Qualified rule</text>
</g>
<path d="M366.0 100a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
</g>
<path d="M386.0 40h10"></path>
<path d="M184.0 40a10 10 0 0 0 -10 10v70a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M184.0 130h78.25"></path>
<path d="M307.75 130h78.25"></path>
<rect height="22" width="45.5" x="262.25" y="119"></rect>
<text x="285" y="134">ws*</text>
</g>
<path d="M386.0 130a10 10 0 0 0 10 -10v-70a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M396.0 40h20"></path>
</g>
<path d="M416.0 40h10"></path>
<g class="non-terminal ">
<path d="M426.0 40h0.0"></path>
<path d="M471.5 40h0.0"></path>
<rect height="22" width="45.5" x="426" y="29"></rect>
<text x="448.75" y="44">ws*</text>
</g>
<path d="M471.5 40h10"></path>
<path d="M481.5 40h10"></path>
<g class="terminal ">
<path d="M491.5 40h0.0"></path>
<path d="M520.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="491.5" y="29"></rect>
<text x="505.75" y="44">}</text>
</g>
<path d="M520.0 40h10"></path>
<path d="M 530.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-declaration" class="railroad-diagram" height="91" viewBox="0 0 697.0 91" width="697.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="non-terminal">
<path d="M50 40h0.0"></path>
<path d="M180.5 40h0.0"></path>
<rect height="22" width="130.5" x="50" y="29"></rect>
<text x="115.25" y="44">&lt;ident-token&gt;</text>
</g>
<path d="M180.5 40h10"></path>
<path d="M190.5 40h10"></path>
<g class="non-terminal">
<path d="M200.5 40h0.0"></path>
<path d="M246.0 40h0.0"></path>
<rect height="22" width="45.5" x="200.5" y="29"></rect>
<text x="223.25" y="44">ws*</text>
</g>
<path d="M246.0 40h10"></path>
<path d="M256.0 40h10"></path>
<g class="terminal">
<path d="M266.0 40h0.0"></path>
<path d="M294.5 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="266" y="29"></rect>
<text x="280.25" y="44">:</text>
</g>
<path d="M294.5 40h10"></path>
<g>
<path d="M304.5 40h0.0"></path>
<path d="M512.0 40h0.0"></path>
<path d="M304.5 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M324.5 20h167.5"></path>
</g>
<path d="M492.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M304.5 40h20"></path>
<g>
<path d="M324.5 40h0.0"></path>
<path d="M492.0 40h0.0"></path>
<path d="M324.5 40h10"></path>
<g class="non-terminal">
<path d="M334.5 40h0.0"></path>
<path d="M482.0 40h0.0"></path>
<rect height="22" width="147.5" x="334.5" y="29"></rect>
<text x="408.25" y="44">Component value</text>
</g>
<path d="M482.0 40h10"></path>
<path d="M334.5 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M334.5 60h147.5"></path>
</g>
<path d="M482.0 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M492.0 40h20"></path>
</g>
<g>
<path d="M512.0 40h0.0"></path>
<path d="M657.0 40h0.0"></path>
<path d="M512.0 40h20"></path>
<g>
<path d="M532.0 40h105.0"></path>
</g>
<path d="M637.0 40h20"></path>
<path d="M512.0 40a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<g class="non-terminal">
<path d="M532.0 60h0.0"></path>
<path d="M637.0 60h0.0"></path>
<rect height="22" width="105" x="532" y="49"></rect>
<text x="584.5" y="64">!important</text>
</g>
<path d="M637.0 60a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 657.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-important" class="railroad-diagram" height="62" viewBox="0 0 512.0 62" width="512.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 31h10"></path>
<g class="terminal">
<path d="M50 31h0.0"></path>
<path d="M78.5 31h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="50" y="20"></rect>
<text x="64.25" y="35">!</text>
</g>
<path d="M78.5 31h10"></path>
<path d="M88.5 31h10"></path>
<g class="non-terminal">
<path d="M98.5 31h0.0"></path>
<path d="M144.0 31h0.0"></path>
<rect height="22" width="45.5" x="98.5" y="20"></rect>
<text x="121.25" y="35">ws*</text>
</g>
<path d="M144.0 31h10"></path>
<path d="M154.0 31h10"></path>
<g class="non-terminal">
<path d="M164.0 31h0.0"></path>
<path d="M396.5 31h0.0"></path>
<rect height="22" width="232.5" x="164" y="20"></rect>
<text x="280.25" y="35">&lt;ident-token "important"&gt;</text>
</g>
<path d="M396.5 31h10"></path>
<path d="M406.5 31h10"></path>
<g class="non-terminal">
<path d="M416.5 31h0.0"></path>
<path d="M462.0 31h0.0"></path>
<rect height="22" width="45.5" x="416.5" y="20"></rect>
<text x="439.25" y="35">ws*</text>
</g>
<path d="M462.0 31h10"></path>
<path d="M 472.0 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-component-value" class="railroad-diagram" height="122" viewBox="0 0 267.5 122" width="267.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 21v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 31h0.0"></path>
<path d="M227.5 31h0.0"></path>
<path d="M40.0 31h20"></path>
<g class="non-terminal ">
<path d="M60.0 31h0.0"></path>
<path d="M207.5 31h0.0"></path>
<rect height="22" width="147.5" x="60" y="20"></rect>
<text x="133.75" y="35">Preserved token</text>
</g>
<path d="M207.5 31h20"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v10a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M60.0 61h12.75"></path>
<path d="M194.75 61h12.75"></path>
<rect height="22" width="122" x="72.75" y="50"></rect>
<text x="133.75" y="65">Simple block</text>
</g>
<path d="M207.5 61a10 10 0 0 0 10 -10v-10a10 10 0 0 1 10 -10"></path>
<path d="M40.0 31a10 10 0 0 1 10 10v40a10 10 0 0 0 10 10"></path>
<g class="non-terminal ">
<path d="M60.0 91h4.25"></path>
<path d="M203.25 91h4.25"></path>
<rect height="22" width="139" x="64.25" y="80"></rect>
<text x="133.75" y="95">Function block</text>
</g>
<path d="M207.5 91a10 10 0 0 0 10 -10v-40a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 227.5 31 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-simple-block" class="railroad-diagram" height="176" viewBox="0 0 404.5 176" width="404.5">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<g>
<path d="M40 40h0.0"></path>
<path d="M364.5 40h0.0"></path>
<path d="M40.0 40h20"></path>
<g>
<path d="M60.0 40h0.0"></path>
<path d="M344.5 40h0.0"></path>
<g class="terminal ">
<path d="M60.0 40h0.0"></path>
<path d="M88.5 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="29"></rect>
<text x="74.25" y="44">{</text>
</g>
<path d="M88.5 40h10"></path>
<g>
<path d="M98.5 40h0.0"></path>
<path d="M306.0 40h0.0"></path>
<path d="M98.5 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M118.5 20h167.5"></path>
</g>
<path d="M286.0 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M98.5 40h20"></path>
<g>
<path d="M118.5 40h0.0"></path>
<path d="M286.0 40h0.0"></path>
<path d="M118.5 40h10"></path>
<g class="non-terminal ">
<path d="M128.5 40h0.0"></path>
<path d="M276.0 40h0.0"></path>
<rect height="22" width="147.5" x="128.5" y="29"></rect>
<text x="202.25" y="44">Component value</text>
</g>
<path d="M276.0 40h10"></path>
<path d="M128.5 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 60h147.5"></path>
</g>
<path d="M276.0 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M286.0 40h20"></path>
</g>
<path d="M306.0 40h10"></path>
<g class="terminal ">
<path d="M316.0 40h0.0"></path>
<path d="M344.5 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="316" y="29"></rect>
<text x="330.25" y="44">}</text>
</g>
</g>
<path d="M344.5 40h20"></path>
<path d="M40.0 40a10 10 0 0 1 10 10v28a10 10 0 0 0 10 10"></path>
<g>
<path d="M60.0 88h0.0"></path>
<path d="M344.5 88h0.0"></path>
<g class="terminal ">
<path d="M60.0 88h0.0"></path>
<path d="M88.5 88h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="77"></rect>
<text x="74.25" y="92">(</text>
</g>
<path d="M88.5 88h10"></path>
<g>
<path d="M98.5 88h0.0"></path>
<path d="M306.0 88h0.0"></path>
<path d="M98.5 88a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M118.5 68h167.5"></path>
</g>
<path d="M286.0 68a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M98.5 88h20"></path>
<g>
<path d="M118.5 88h0.0"></path>
<path d="M286.0 88h0.0"></path>
<path d="M118.5 88h10"></path>
<g class="non-terminal ">
<path d="M128.5 88h0.0"></path>
<path d="M276.0 88h0.0"></path>
<rect height="22" width="147.5" x="128.5" y="77"></rect>
<text x="202.25" y="92">Component value</text>
</g>
<path d="M276.0 88h10"></path>
<path d="M128.5 88a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 108h147.5"></path>
</g>
<path d="M276.0 108a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M286.0 88h20"></path>
</g>
<path d="M306.0 88h10"></path>
<g class="terminal ">
<path d="M316.0 88h0.0"></path>
<path d="M344.5 88h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="316" y="77"></rect>
<text x="330.25" y="92">)</text>
</g>
</g>
<path d="M344.5 88a10 10 0 0 0 10 -10v-28a10 10 0 0 1 10 -10"></path>
<path d="M40.0 40a10 10 0 0 1 10 10v76a10 10 0 0 0 10 10"></path>
<g>
<path d="M60.0 136h0.0"></path>
<path d="M344.5 136h0.0"></path>
<g class="terminal ">
<path d="M60.0 136h0.0"></path>
<path d="M88.5 136h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="60" y="125"></rect>
<text x="74.25" y="140">[</text>
</g>
<path d="M88.5 136h10"></path>
<g>
<path d="M98.5 136h0.0"></path>
<path d="M306.0 136h0.0"></path>
<path d="M98.5 136a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M118.5 116h167.5"></path>
</g>
<path d="M286.0 116a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M98.5 136h20"></path>
<g>
<path d="M118.5 136h0.0"></path>
<path d="M286.0 136h0.0"></path>
<path d="M118.5 136h10"></path>
<g class="non-terminal ">
<path d="M128.5 136h0.0"></path>
<path d="M276.0 136h0.0"></path>
<rect height="22" width="147.5" x="128.5" y="125"></rect>
<text x="202.25" y="140">Component value</text>
</g>
<path d="M276.0 136h10"></path>
<path d="M128.5 136a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M128.5 156h147.5"></path>
</g>
<path d="M276.0 156a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M286.0 136h20"></path>
</g>
<path d="M306.0 136h10"></path>
<g class="terminal ">
<path d="M316.0 136h0.0"></path>
<path d="M344.5 136h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="316" y="125"></rect>
<text x="330.25" y="140">]</text>
</g>
</g>
<path d="M344.5 136a10 10 0 0 0 10 -10v-76a10 10 0 0 1 10 -10"></path>
</g>
<path d="M 364.5 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>


<svg id="_dgm-function-block" class="railroad-diagram" height="80" viewBox="0 0 512.0 80" width="512.0">
<g transform="translate(.5 .5)">
<g>
<path d="M20 30v20m10 -20v20m-10 -10h20"></path>
</g>
<path d="M40 40h10"></path>
<g class="non-terminal">
<path d="M50 40h0.0"></path>
<path d="M206.0 40h0.0"></path>
<rect height="22" width="156" x="50" y="29"></rect>
<text x="128" y="44">&lt;function-token&gt;</text>
</g>
<path d="M206.0 40h10"></path>
<g>
<path d="M216.0 40h0.0"></path>
<path d="M423.5 40h0.0"></path>
<path d="M216.0 40a10 10 0 0 0 10 -10v0a10 10 0 0 1 10 -10"></path>
<g>
<path d="M236.0 20h167.5"></path>
</g>
<path d="M403.5 20a10 10 0 0 1 10 10v0a10 10 0 0 0 10 10"></path>
<path d="M216.0 40h20"></path>
<g>
<path d="M236.0 40h0.0"></path>
<path d="M403.5 40h0.0"></path>
<path d="M236.0 40h10"></path>
<g class="non-terminal">
<path d="M246.0 40h0.0"></path>
<path d="M393.5 40h0.0"></path>
<rect height="22" width="147.5" x="246" y="29"></rect>
<text x="319.75" y="44">Component value</text>
</g>
<path d="M393.5 40h10"></path>
<path d="M246.0 40a10 10 0 0 0 -10 10v0a10 10 0 0 0 10 10"></path>
<g>
<path d="M246.0 60h147.5"></path>
</g>
<path d="M393.5 60a10 10 0 0 0 10 -10v0a10 10 0 0 0 -10 -10"></path>
</g>
<path d="M403.5 40h20"></path>
</g>
<path d="M423.5 40h10"></path>
<g class="terminal">
<path d="M433.5 40h0.0"></path>
<path d="M462.0 40h0.0"></path>
<rect height="22" rx="10" ry="10" width="28.5" x="433.5" y="29"></rect>
<text x="447.75" y="44">)</text>
</g>
<path d="M462.0 40h10"></path>
<path d="M 472.0 40 h 20 m -10 -10 v 20 m 10 -20 v 20"></path>
</g>
</svg>

</template>

<header>
	<hgroup>
<h1>CSS の構文 — CSS Syntax Module Level 3</h1>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p class="p-summary">
この~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.
</p>

~CSSisaLANG

	</section>
	<section id="sotd">
◎位置付け

<p>
これは、
編集者草案の公な複製です…
【以下、この節の内容は，~SOTD-CSSに移譲。】
</p>

	</section>

<main id="MAIN0">
	<section id="intro">
<h2 title="Introduction">1. 序論</h2>

◎非規範的

<p>
この~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).
</p>

<p>
これは、［
~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.
</p>

		<section id="placement">
<h3 title="Module interactions">1.1. ~module間の相互作用</h3>

<p>
この~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.
</p>
		</section>
	</section>
	<section id="_conventions">
<h3>【この訳に特有な表記規約】</h3>

◎表記記号

<p>
加えて、
所与の %名前 に対し，ドットが接頭された記法 .%名前 も用いる。
それは、
この仕様の処理~modelにて生産される各［
~token／~CSS構成子
］に伴われる［
%名前 と命名された~field~DAGGER
］であることを指示する
（文脈から明らかな所では、
このドットは省略され得る）。
例えば， “〜の.値” は、［
"`値^em" と命名された~field
］の値を意味する。
（~DAGGER
この訳に現れる，この意味の “~field” という語は、
訳の都合により導入したものであり，原文には無い非公式な用語である。）
</p>

	</section>
	<section id="syntax-description">
<h2 title="Description of CSS’s Syntax">2. ~CSSの構文の記述</h2>

◎非規範的

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

<p>
`有修飾~規則$は，
.`導入部^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.
</p>

<div class="example">
<p>
典型的な規則は、
次に様な見かけになろう：
◎
A typical rule might look something like this:
</p>

<pre class="lang-css">
p &gt; a {
  color: blue;
  text-decoration: underline;
}
</pre>

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

<p>
"`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.
</p>
</div>

<p>
~at-規則は、
種類ごとに異なるものだが，基本的な構造は共通する：
◎
At-rules are all different, but they have a basic structure in common.＼
</p>
<ul>
	<li>
それらは、
`符号位置$ "<code>@</code>" から開始して，
~CSS~keywordとして名前が後続する。
◎
They start with an "@" code point followed by their name as a CSS keyword.＼
</li>
	<li>
一部の`~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.＼
</li>
	<li>
他の`~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.
</li>
</ul>

<div class="example">
<p>
ここに、
`~at-規則$が包含し得る様々な構文を解説する いくつかの例を示す：
◎
Here are several examples of at-rules that illustrate the varied syntax they may contain.
</p>

<pre class="lang-css">
@import "my-styles.css";
</pre>

<p>
`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.
</p>

<pre class="lang-css">
@page :left {
  margin-left: 4cm;
  margin-right: 3cm;
}
</pre>

<p>
`page$at `~at-規則$は、［
省略可能な~page選択子（この例では `left$ps 疑似類）,
~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.
</p>

<pre class="lang-css">
@media print {
  body { font-size: 10pt }
}
</pre>

<p>
`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.
</p>
</div>

<p>
［
`~prop$ ／ `~at-規則$
］の名前は、
常に`~ident$であり：
◎
Property names and at-rule names are always ident sequences,＼
</p>
<ul>
	<li>
次のいずれかから開始する必要がある
⇒＃
`~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,＼
</li>
	<li>
~~後続して 0 個以上の`~ident符号位置$を包含できる
◎
and then can contain zero or more ident code points.＼
</li>
	<li>
上述に加えて，どこにでも、
`~escape法$により，どの`符号位置$も含めれる
— それが，~CSSの構文に利用されるものであっても。
◎
You can include any code point at all, even ones that CSS uses in its syntax, by escaping it.
</li>
</ul>

<p class="trans-note">【
もっと簡潔に言い換えるなら、
次を満たす必要がある：
［
`~identを開始している$
］~AND［［
`~ident符号位置$／
`妥当な~escape$を成す符号位置~並び
］のみからなる
］
】</p>

<p>
`選択子$の構文は、
`SELECTORS-4$r【！`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 &amp; Units spec. The special syntaxes of individual at-rules can be found in the specs that define them.
</p>

		<section id="escaping">
<h3 title="Escaping">2.1. ~escape法</h3>

◎非規範的

<p>
`~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:
</p>
<ul>
	<li>
［
`~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.
</li>
	<li>
<p>
［
1 〜 6 個の`~hex$,
省略可能な 1 個の`空白$
］が成す並び。
この~escape列は、［
その~hex並びが表す数を値とする~Unicode`符号位置$
］に置換される。
省略可能な空白は、［
16 進~escape列に “本当の” ~hex列が後続する
］ことを許容するためにある。
◎
Or one to six hex digits, followed by an optional whitespace. The escape sequence is replaced by the Unicode code point whose value is given by the hexadecimal digits. This optional whitespace allow hexadecimal escape sequences to be followed by "real" hex digits.
</p>

<p class="example">
例えば，.値に `&amp;B^l を伴う`~ident$は、［
`\26 B^css あるいは `\000026B^css
］として記すこともできる。
◎
An ident sequence with the value "&amp;B" could be written as \26 B or \000026B.
</p>

<p class="note">注記：
~escape列の直後に “本当の” ~spaceを続ける場合、
二重に記さなければならないことになる。
◎
A "real" space after the escape sequence must be doubled.
</p>
	</li>
</ul>

		</section>
		<section id="error-handling">
<h3 title="Error Handling">2.2. ~errorの取扱い</h3>

◎非規範的

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

<p>
~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.
</p>
<ul>
	<li>
~stylesheetの “~top-level” においては、
`at-keyword$tok が，`~at-規則$を開始させる。
他のものは どれも，`有修飾~規則$を開始させ、
その規則の.導入部の中に含まれる。
これは，`無効な選択子$も生産し得るが、
そのことは，~CSS構文解析器が関知する所ではなく［
最悪でも，何にも合致しない`選択子$になる
］ことを意味する。
◎
At the "top level" of a stylesheet, an &lt;at-keyword-token&gt; 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.
</li>
	<li>
<p>
`~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.＼
</p>
		<ul>
			<li>
`semicolon$tok に遭遇したときは、
当の~at-規則は即時に終端される。
◎
Encountering a &lt;semicolon-token&gt; ends the at-rule immediately, while＼
</li>
			<li>
一方で，開き波括弧 `open-curly$Tok に遭遇したときは、
その~at-規則の本体を開始させる
— 本体に合致する~block（ `()^c, `{}^c, `[]^c のいずれかに挟まれた内容）が、［［
他のもの／別の~blockの内側
］には合致しない閉じ波括弧 `close-curly$Tok
］が見出されるまで，前方検索される。
◎
encountering an opening curly-brace &lt;{-token&gt; starts the at-rule’s body. The at-rule seeks forward, matching blocks (content surrounded by (), {}, or []) until it finds a closing curly-brace &lt;}-token&gt; that isn’t matched by anything else or inside of another block.＼
</li>
		</ul>
<p>
次に、
当の~at-規則の内容が，~at-規則の自前の文法に則って解釈される。
◎
The contents of the at-rule are then interpreted according to the at-rule’s own grammar.
</p>
	</li>
	<li>
`有修飾~規則$の場合も，［
~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.
</li>
	<li>
宣言~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.
</li>
	<li>
<p id="autoclosing">
どの［
規則, 宣言, 関数, 文字列, 等々
］においても，
それが閉じられる前に~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.
</p>

<div class="example">
<p>
例えば，関数 `translateX$f の構文は：
◎
For example, the syntax of the translateX() function is:
</p>

<pre class="prod">
translateX( `length-percentage【！translation-value】^t )
</pre>

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

<pre class="lang-css">
.foo { transform: translateX【！translate】(50px
</pre>

<p>
~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.
</p>
</div>
	</li>
</ul>

<p>
各~構成子（宣言, ~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.
</p>

		</section>
	</section>
	<section id="tokenizing-and-parsing">
<h2 title="Tokenizing and Parsing CSS">3. ~CSSの~token化法と構文解析-法</h2>

<p>
~UAは、
【~MIME型】 `text/css^c の資源から~CSSOM~tree `CSSOM$r を生成するときは，
この仕様に述べられる構文解析~規則を利用するモノトスル。
同時に，これらの規則は、
~CSS構文解析器として参照rされるものを定義する。
◎
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.
</p>

<p>
この仕様は、
~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.
</p>

<p>
適合性~検査器は、
文書において 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.
</p>

		<section id="parsing-overview">
<h3 title="Overview of the Parsing Model">3.1. 構文解析~modelの概観</h3>

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

<p class="note">注記：
~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.
</p>

		</section>
		<section id="input-byte-stream">
<h3 title="The input byte stream">3.2. 入力~byte~stream</h3>

<p>
［
~stylesheetの構文解析における~token化~段階
］への入力を成す［
~Unicode`符号位置$たちが成す~stream
］は、
~UAにとっては，初期~時は
（概して，~network越しに, または局所~file~systemからの）
~byte~streamとして見えるであろう。
その場合，~UAは、
特定0の文字~符号化法に則って，当の~streamを成す~byte列を`符号位置$列に復号するモノトスル。
◎
When parsing a stylesheet, the stream of Unicode code points that comprises the input to the tokenization stage might be initially seen by the user agent as a stream of bytes (typically coming over the network or from the local file system). If so, the user agent must decode these bytes into code points according to a particular character encoding.
</p>

<div class="algo">
<p>
`~stylesheetの~byte列を復号する@
~algoは、
所与の
( %~stylesheet )
に対し，その~byte~streamを次に従って`符号位置$~streamの中へ復号する：
◎
To decode a stylesheet’s stream of bytes into a stream of code points:
</p>

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

<p class="note">注記：
`~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.
</p>
</div>

<div class="algo">
<p>
`~fallback符号化法を決定する@
~algoは、
所与の
( %~stylesheet )
に対し：
◎
To determine the fallback encoding of a stylesheet:
</p>

<ol>
	<li>
<p>
~IF［
~HTTPまたは それに等価な~protocol
］は、
%~stylesheet 用の`符号化法~label$として %~label を供している
（例： `Content-Type$h ~headerの `charset^c ~parameterを介して）
］：
</p>
		<ol>
			<li>
%符号化法 ~LET `~labelから符号化法を取得する$( %~label )
</li>
			<li>
~IF［
%符号化法 ~NEQ `失敗^i
］
⇒
~RET %符号化法
</li>
		</ol>
◎
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.
</li>
	<li>
<p>
~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
</p>

<pre>40 63 68 61 72 73 65 74 20 22 %~label 22 3B</pre>

<p>
ここで %~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＼
</p>

<p class="note">注記：
この~byte列は、
~ASCIIとして復号したときには，次の連結になる
⇒＃
`@charset "^l,
%~label が表現する文字列,
`";^l
◎
↓</p>
		<ol>
			<li>
<p>
%符号化法 ~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.
</p>
			</li>
			<li>
<div class="p">
<p>
~IF［
%符号化法 ~NEQ `失敗^i
］：
</p>
				<ol>
					<li>
~IF［
%符号化法 ~IN { `UTF-16BE$enc, `UTF-16LE$enc }
］
⇒
~RET `UTF-8$enc
</li>
					<li>
~RET %符号化法
</li>
				</ol>
◎
If the return value was utf-16be or utf-16le, return utf-8; if it was anything else except failure, return it.
</div>

<details class="note">
<summary>
宣言が~UTF-16のときに `UTF-8$enc を利用するのはなぜ？
◎
Why use utf-8 when the declaration says utf-16?
</summary>
<p>
符号化法~宣言の~byte列は~ASCIIとしては
“<code>@charset "…";</code>”
になるが、
~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.
</p>

<p>
これは、
~HTMLの `meta charset^e の挙動を真似たものでもある。
◎
As well, this mimics the behavior of HTML’s &lt;meta charset&gt; attribute.
</p>
</details>

<p class="note">注記：
符号化法~宣言の構文は、
名前 `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.
</p>
			</li>
		</ol>
	</li>
	<li>
~IF［
参照元 文書にて`環境~符号化法$が供されている
］
⇒
~RET それ
◎
Otherwise, if an environment encoding is provided by the referring document, return it.
</li>
	<li>
~RET `UTF-8$enc
◎
Otherwise, return utf-8.
</li>
</ol>

<div class="note">

<p>注記：
~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.
</p>

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

<p>
これらいずれも可用でない場合、
作者は，~stylesheetが次のいずれかで始まるようにするべきである
⇒＃
~UTF-8~BOM ／
正確に `@charset "utf-8";^c に一致する文字列
◎
If neither of these options are available, authors should begin the stylesheet with a UTF-8 BOM or the exact characters
• @charset "utf-8";
</p>
</div>
</div>

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

<p>
`環境~符号化法$の概念は、
旧来の内容との互換性を得るために限り，存在する。
［
新たな形式の文書／新たな~link法の仕組み
］は、［
~stylesheetの符号化法が明示的に供されない下では、
~UTF-8が既定になる
］よう，`環境~符号化法$を供する<strong>べきでない</strong>。
◎
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.
</p>

<div class="note">
<p>
注記：
◎
↓</p>
<ul>
	<li>
`HTML$r は、
`link rel=stylesheet^e から参照rされる~stylesheet用の`環境~符号化法$を`定義する＠~HTMLlinks#link-type-stylesheet$。
◎
Note: [HTML] defines the environment encoding for &lt;link rel=stylesheet&gt;.
</li>
	<li>
`CSSOM$r は、
`&lt;xml-stylesheet?&gt;^c 用の`環境~符号化法$を`定義する＠~CSSOM1#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction$。
◎
Note: [CSSOM] defines the environment encoding for &lt;xml-stylesheet?&gt;.
</li>
	<li>
`CSS-CASCADE-3$r は、
`import$at 用の`環境~符号化法$を`定義する＠~CASCADE#import-processing$。
◎
Note: [CSS-CASCADE-3] defines the environment encoding for @import.
</li>
</ul>
</div>

		</section>
		<section id="input-preprocessing">
<h3 title="Preprocessing the input stream">3.3. 入力~streamの前処理</h3>

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

<div class="algo">
<p>
`符号位置~列を~filterする@
~algoは、
所与の
( （~filter済みでない）`符号位置$列が成す~stream %入力 )
に対し，
%入力 を成す各`符号位置$に応じて：
◎
To filter code points from a stream of (unfiltered) code points input:
</p>
<ul class="switch">
	<li>
次に該当するものは、
除去する
⇒
`0D^U (CR) のうち，直後に `0A^U (LF) が在るもの
◎
↓</li>
	<li>
次に挙げるものは、
`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.
</li>
	<li>
<p>
次に挙げるものは、
`FFFD^U に置換する
⇒＃
`00^U／
`~surrogate$
◎
Replace any U+0000 NULL or surrogate code points in input with U+FFFD REPLACEMENT CHARACTER (�).
</p>

<p class="note">注記：
~CSS内容~内に`~surrogate$を生産する仕方は、
~CSSOM演算を介して，それを含んだ `DOMString^c を直にアテガう他にない。
◎
Note: The only way to produce a surrogate code point in CSS content is by directly assigning a DOMString with one in it via an OM operation.
</p>
	</li>
</ul>
</div>

		</section>
	</section>
	<section id="tokenization">
<h2 title="Tokenization">4. ~token化</h2>

<div class="algo">
<p>
`符号位置~streamを~token化する@
~algoは、
所与の
( `符号位置$たちが成す~stream %入力, ~tokenたちが成す~stream %出力【, 真偽値 %~unicode-rangeは許容されるか （省略時は ~F ）】 )
に対し：
</p>
<ol>
	<li>
~WHILE 無条件
		<ol>
			<li>
%~token ~LET `~tokenを消費する$( %入力【, %~unicode-rangeは許容されるか 】 )
</li>
			<li>
~IF［
%~token は `EOF$tok である
］
⇒
~BREAK
</li>
			<li>
%出力 の中へ %~token を~pushする
</li>
		</ol>
	</li>
</ol>

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

<p class="note">注記：
`~tokenを消費する$~algoは、
構文解析して`いる間に^em［
必要に応じて “その場で”，
`符号位置$たちが成す~streamを~token化する
］ためにも利用できるよう，
各~callに対し 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.
</p>

<div class="p">
<p>
~token化の段における出力は、
次に挙げる 0 個~以上の~tokenたちが成す~streamである：
</p>

<table id="_token-types" class="grid-table"><thead>
<tr><th>~token
<th>~tokenが有する~field
<th>代表的な~CSS構成子（括弧内はその例）
【この列は、訳者による補足であり，該当する構成子を網羅するものでもない。】
<tbody>

<tr><td>`ident@tok
<td>値
<td>~keywordなどの`~CSS識別子$（ `auto^l ）

<tr><td>`function@tok
<td>値
<td>`関数-記法$の名前（および直後にある丸括弧）を成す部分（ `calc(^l ）

<tr><td>`at-keyword@tok
<td>値
<td>~at-規則（ "<code>@import</code>" ）

<tr><td>`hash@tok
<td>値, 型~flag
<td>`~ID選択子$（ `#ID^l ）／ 16 進数による色（ `#ABCDEF^l ）

<tr><td>`string@tok
<td>値
<td>文字列（ `'もじのならび'^l, 引用符も含む）

<tr><td>`bad-string@tok
<td>
<td>合法でない文字列

<tr><td>`url@tok
<td>値
<td>~URL（ `url(example.png)^l ）

<tr><td>`bad-url@tok
<td>
<td>合法でない~URL

<tr><td>`delim@tok
<td>値
<td>1 個の文字からなる一般的な分離子（`結合子$, `~importantな宣言$の `!^l など）

<tr><td>`number@tok
<td>数値, 型~flag, 符号~文字
<td>単位を伴わない数値（ `123.45^l ）

<tr><td>`percentage@tok
<td>数値, 符号~文字
<td>百分率（ `33.3%^l ）

<tr><td>`dimension@tok
<td>数値, 型~flag, 符号~文字, 単位
<td>単位を伴う数値（ `1.5em^l ）

<tr><td>`unicode-range@tok
<td>始端, 終端
<td>`U+20-7E^l

<tr><td>`whitespace@tok
<td>
<td>空白

<tr><td>`CDO@tok
<td>
<td>`&lt;!--^l — ~HTML~comment開始~構文（互換性のためにあり，単純に無視される）

<tr><td>`CDC@tok
<td>
<td>`--&gt;^l — ~HTML~comment終了~構文（同上）

<tr><td>`colon@tok
<td>
<td>`:^l — `宣言$の中の~propの名前と値を分離する~colon

<tr><td>`semicolon@tok
<td>
<td>`;^l — `宣言$どうしを分離する~semicolon

<tr><td>`comma@tok
<td>
<td>`,^l — 成分~値どうしを分離する~comma

<tr><td>`open-square@Tok
<td>
<td>`[^l — `属性~選択子$を括る角括弧

<tr><td>`close-square@Tok
<td>
<td>`]^l — 同上

<tr><td>`open-paren@Tok
<td>
<td>`(^l — `条件付き~group規則$に与える条件を括る丸括弧

<tr><td>`close-paren@Tok
<td>
<td>`)^l — 同上

<tr><td>`open-curly@Tok
<td>
<td>`{^l — 宣言~listを括る波括弧

<tr><td>`close-curly@Tok
<td>
<td>`}^l — 同上
</table>

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

<p>
各種~fieldがとり得る値は：
◎
↓</p>
<ul>
	<li>
［
`ident$tok ／
`function$tok ／
`at-keyword$tok ／
`hash$tok ／
`string$tok ／
`url$tok
］の
.`値^dfn
は、
0 個以上の`符号位置$からなる。
◎
&lt;ident-token&gt;, &lt;function-token&gt;, &lt;at-keyword-token&gt;, &lt;hash-token&gt;, &lt;string-token&gt;, and &lt;url-token&gt; have a value composed of zero or more code points.＼
</li>
	<li>
`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.
</li>
	<li>
`delim$tok の
.`値^dfn
は、
1 個の`符号位置$をとる。
◎
&lt;delim-token&gt; has a value composed of a single code point.
</li>
	<li>
<p>［
`number$tok ／
`percentage$tok ／
`dimension$tok
］の：
</p>
		<ul>
			<li>
.`数値^dfn
は、
実数をとる。
</li>
			<li>
`.符号~文字^dfn
は、
次のいずれかをとる
⇒＃
ε（既定）,
`正負符号$
</li>
		</ul>
◎
&lt;number-token&gt;, &lt;percentage-token&gt;, and &lt;dimension-token&gt; have a numeric value, and an optional sign character set to either "+" or "-" (or nothing).
</li>
	<li>
［
`number$tok ／
`dimension$tok
］の
.`型~flag^dfn
は、
次のいずれかをとる
⇒＃
`整数^i（既定）,
`実数^i
◎
&lt;number-token&gt; and &lt;dimension-token&gt; additionally have a type flag set to either "integer" or "number". The type flag defaults to "integer" if not otherwise set.＼
</li>
	<li>
`dimension$tok の
.`単位^dfn
は、
1 個以上の`符号位置$からなる。
◎
&lt;dimension-token&gt; additionally have a unit composed of one or more code points.
</li>
	<li>
<p>
`unicode-range$tok の［
.`始端^dfn,
.`終端^dfn
］は、
いずれも`符号位置$の`値$cpをとる。
◎
&lt;unicode-range-token&gt; has a starting and ending code point.＼
</p>

<p>
この~tokenは、
次を満たす`符号位置$たちが成す範囲を表現する
⇒
.始端 ~LTE その`値$cp ~LTE .終端
◎
It represents an inclusive range of codepoints (including both the start and end).＼
</p>

<p>
（ .始端 ~GT .終端 の場合、
空な範囲を表現する。）
◎
If the ending code point is before the starting code point, it represents an empty range.
</p>
	</li>
</ul>

<p class="note">注記：
`hash$tok の.型~flagは、
`選択子$の構文 `SELECTORS-4$r【！`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.
</p>

		<section id="token-diagrams">
<h3 title="Token Railroad Diagrams">4.1. ~tokenの線路図式</h3>

◎非規範的

<p>
この節では、
~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.
</p>

<p>
これらの図式は、
`参考であって, 不完全である^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.
</p>

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

<dl>
	<dt id="comment-diagram">`comment^sb（~comment）</dt>
	<dd class="railroad">`comment^dgm</dd>

	<dt id="newline-diagram">`newline^sb（`前処理＠#input-preprocessing$前の改行文字）</dt>
	<dd class="railroad">`newline^dgm</dd>

	<dt id="whitespace-diagram">`whitespace^sb（`空白$）</dt>
	<dd class="railroad">`whitespace^dgm</dd>

	<dt id="hex-digit-diagram">`hex digit^sb（ `~hex$ ）</dt>
	<dd class="railroad">`hex-digit^dgm</dd>

	<dt id="escape-diagram">`escape^sb（~escape列）</dt>
	<dd class="railroad">`escape^dgm</dd>

	<dt id="whitespace-token-diagram">`whitespace$tok</dt>
	<dd class="railroad">`whitespace-token^dgm</dd>

	<dt id="whitespaces-diagram">`ws*^sb</dt>
	<dd class="railroad">`whitespaces^dgm</dd>

	<dt id="ident-token-diagram">`ident$tok</dt>
	<dd class="railroad">`ident-token^dgm</dd>

	<dt id="function-token-diagram">`function$tok</dt>
	<dd class="railroad">`function-token^dgm</dd>

	<dt id="at-keyword-token-diagram">`at-keyword$tok</dt>
	<dd class="railroad">`at-keyword-token^dgm</dd>

	<dt id="hash-token-diagram">`hash$tok</dt>
	<dd class="railroad">`hash-token^dgm</dd>

	<dt id="string-token-diagram">`string$tok</dt>
	<dd class="railroad">`string-token^dgm</dd>

	<dt id="url-token-diagram">`url$tok</dt>
	<dd class="railroad">`url-token^dgm</dd>

	<dt id="number-token-diagram">`number$tok</dt>
	<dd class="railroad">`number-token^dgm</dd>

	<dt id="dimension-token-diagram">`dimension$tok</dt>
	<dd class="railroad">`dimension-token^dgm</dd>

	<dt id="percentage-token-diagram">`percentage$tok</dt>
	<dd class="railroad">`percentage-token^dgm</dd>

	<dt id="CDO-token-diagram">`CDO$tok</dt>
	<dd class="railroad">`CDO-token^dgm</dd>
	<dd class="trans-note">【
原文の図式は `&lt;!--^l から `&lt;&lt;!----&gt;!--^l へ更新されたが、
何かの間違いに思われる。
】</dd>

	<dt id="CDC-token-diagram">`CDC$tok</dt>
	<dd class="railroad">`CDC-token^dgm</dd>

	<dt id="unicode-range-token-diagram">`unicode-range$tok</dt>
	<dd class="railroad">`unicode-range-token^dgm</dd>
</dl>

		</section>
		<section id="tokenizer-definitions">
<h3 title="Definitions">4.2. 定義</h3>

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

<dl>
	<dt id="next-input-code-point">
`C1^V, `C2^V, `C3^V
◎
next input code point
</dt>
	<dd>
順に，`入力~stream$内の未だ消費されていない［
1 個目, 2 個目, 3 個目
］の`符号位置$を指す
— ~streamの末尾を越える所を指す場合、
`~EOF$iと見なされる。
◎
The first code point in the input stream that has not yet been consumed.
</dd>
	<dd class="trans-note">【
これらは、
`入力~符号位置を消費する$に伴い変化することになる。
】【
~CSSの構文解析において先読みが必要になる符号位置たちは、
これら 3 個までに限られる。
】【
`C1$V は、
原文では `next input code point^en （ “次回の入力~符号位置” ）と称されるが、
2 個目や 3 個目を指す記述も含めて一貫した形で簡明に述べるため，このように改める。
】</dd>

	<dt>
`現在の入力~符号位置@
◎
current input code point
</dt>
	<dd>
すでに消費された`符号位置$のうち，最後のもの。
【 `~EOF$i もとり得る。】
◎
The last code point to have been consumed.
</dd>

	<dt>
`現在の入力~符号位置を消費し直す@
◎
reconsume the current input code point
</dt>
	<dd>
`現在の入力~符号位置$を`入力~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.
</dd>

	<dt>
`~EOF符号位置@
【この訳では、単に `~EOF$i と略記する。】
◎
EOF code point
</dt>
	<dd>
`入力~stream$の終端を表現する，
【他のどの符号位置とも異なる】
概念的な符号位置。
`入力~stream$が空になり次第， `C1$V は常に `~EOF$i になる。
◎
A conceptual code point representing the end of the input stream. Whenever the input stream is empty, the next input code point is always an EOF code point.
</dd>

	<dt>各種 符号位置の範囲</dt>
	<dd>
<p>
次に挙げる各種［
`符号位置$の範囲
］が定義される
— 記号 ∪ は、
和集合をとることを意味する：
◎
↓</p>
		<dl>
			<dt>
`数字@
◎
digit
</dt>
			<dd>
{ `30^U 〜 `39^U }
◎
A code point between U+0030 DIGIT ZERO (0) and U+0039 DIGIT NINE (9) inclusive.
</dd>

			<dt>
`~hex@
◎
hex digit
</dt>
			<dd>
`数字$ ∪ { `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.
</dd>

			<dt>
`正負符号@
【これは、この訳による追加的な定義】
</dt>
			<dd>
{ `2B^U, `2D^U }
</dd>

			<dt>
`大文字@
◎
uppercase letter
</dt>
			<dd>
{ `41^U 〜 `5A^U }
◎
A code point between U+0041 LATIN CAPITAL LETTER A (A) and U+005A LATIN CAPITAL LETTER Z (Z) inclusive.
</dd>

			<dt>
`小文字@
◎
lowercase letter
</dt>
			<dd>
{ `61^U 〜 `7A^U }
◎
A code point between U+0061 LATIN SMALL LETTER A (a) and U+007A LATIN SMALL LETTER Z (z) inclusive.
</dd>

			<dt>
`英字@
◎
letter
</dt>
			<dd>
`大文字$ ∪ `小文字$
◎
An uppercase letter or a lowercase letter.
</dd>

			<dt>
`非~ASCII~ident符号位置@
◎
non-ASCII ident code point
</dt>
			<dd>
<p>
{ `00B7^U }
∪ { `00C0^U 〜 `00D6^U }
∪ { `00D8^U 〜 `00F6^U }
∪ { `00F8^U 〜 `037D^U }
∪ { `037F^U 〜 `1FFF^U }
∪ { `200C^U, `200D^U, `203F^U, `2040^U }
∪ { `2070^U 〜 `218F^U }
∪ { `2C00^U 〜 `2FEF^U }
∪ { `3001^U 〜 `D7FF^U }
∪ { `F900^U 〜 `FDCF^U }
∪ { `FDF0^U 〜 `FFFD^U }
∪ { `10000^U 以上【〜 `10FFFF^U 】 }
◎
A code point whose value is any of:
• U+00B7
• between U+00C0 and U+00D6
• between U+00D8 and U+00F6
• between U+00F8 and U+037D
• between U+037F and U+1FFF
• U+200C
• U+200D
• U+203F
• U+2040
• between U+2070 and U+218F
• between U+2C00 and U+2FEF
• between U+3001 and U+D7FF
• between U+F900 and U+FDCF
• between U+FDF0 and U+FFFD
• greater than or equal to U+10000
◎
All of these ranges are inclusive.
</dd>
			<dd>
<details class="note">
<summary>
これらの文字に特定的に限られるのは，なぜか？
◎
Why these character, specifically?
</summary>

<p>
これは、
~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.
</p>

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

<p>
これらの制約は、
混同され得る描画~すべてを避けるものではない
— ［
左横書き, 右横書き
］用字系に属する文字が混在している場合、
結果は，依然として
— 例えば、
ほとんどの~text~editorにおいては —
期待されない視覚的な並び替えになる。
~source~textは、
例えば，非~ident文脈においても制約された【除外された】文字を包含し得る
— それらのほとんどは、
文字列~内で完全に妥当である。
それらが妥当でない~CSSを作成する仕方で利用されたときでも、［
それによる構文解析~errorは，何か重要でないものに制限される
］かもしれない一方で，［
~code考査~toolにおける~source~textの描画
］に対する それらの効果は［
有意／悪意的
］になるかもしれない。
これらの類の “~source~text攻撃” についての詳細は、
`この Rust-lang blog post＠https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html$
<small>`(archived)＠https://web.archive.org/web/20220323175009/https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html$</small>
を見よ。
◎
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).
</p>
</details>
			</dd>

			<dt>
`~identを開始する符号位置@
◎
ident-start code point
</dt>
			<dd>
`英字$ ∪ `非~ASCII~ident符号位置$ ∪ { `5F^U }
◎
A letter, a non-ASCII ident code point, or U+005F LOW LINE (_).
</dd>

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

			<dt>
`印字不能~符号位置@
◎
non-printable code point
</dt>
			<dd>
{ `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.
</dd>

			<dt>
`改行文字@
◎
newline
</dt>
			<dd>
{ `0A^U }
◎
U+000A LINE FEED.＼
</dd>
			<dd class="note">
`0D^U, `0C^U は、
この定義には含まれない
— それらは、
`前処理＠#input-preprocessing$の段階で `0A^U に変換されるので。
◎
Note that U+000D CARRIAGE RETURN and U+000C FORM FEED are not included in this definition, as they are converted to U+000A LINE FEED during preprocessing.
</dd>

			<dt>
`空白@
◎
whitespace
</dt>
			<dd>
`改行文字$ ∪ { `09^U, `20^U }
◎
A newline, U+0009 CHARACTER TABULATION, or U+0020 SPACE.
</dd>
		</dl>
	</dd>

	<dt>
`許容される最大な符号位置@
◎
maximum allowed code point
</dt>
	<dd>
`10FFFF^U
— すなわち、
~Unicodeにて定義される最~大な`符号位置$。
◎
The greatest code point defined by Unicode: U+10FFFF.
</dd>

	<dt>
`~ident@
◎
ident sequence
</dt>
	<dd>
`ident$tok と構文が同じな，`符号位置$たちが成す連列。
◎
A sequence of code points that has the same syntax as an &lt;ident-token&gt;.
</dd>
	<dd class="trans-note">【
~identは、
`identifier^en （識別子）の略語であり，
~CSSにおける識別子（`~CSS識別子$）の構文上の側面を特定的に指す技術-用語。
】【
この~identは、
原文では
`ident sequence^en
（ “（ 1 個の）~ident（を成す，符号位置たちが成す）連列” ）
と記されており，直訳するなら “~ident連列” あるいは “~ident列” の様になろうが、
それだと
`sequence of idents^en
（ “~identたちが成す連列” ）
と紛らわしくなるので，この訳では
（ `ident^en, `ident sequence^en どちらも）
単に “~ident” と表記することにする。
】</dd>
	<dd class="note">注記：
次に挙げるものは、
どれも`~ident$になる
⇒＃
`at-keyword$tok の "<code>@</code>" より後の部分,
`hash$tok のうち［ .型~flag ~EQ `id^i ］なるものの `#^l より後の部分,
`function$tok の `(^l より前の部分,
`dimension$tok の.単位
◎
Note: The part of an &lt;at-keyword-token&gt; after the "@", the part of a &lt;hash-token&gt; (with the "id" type flag) after the "#", the part of a &lt;function-token&gt; before the "(", and the unit of a &lt;dimension-token&gt; are all ident sequences.
</dd>
</dl>

<p class="trans-note">【
原文の記述を明確化するため、
この訳では，次に挙げる定義も導入する：
】</p>

<dl>
	<dt>
%n 個の
`入力~符号位置を消費する@
</dt>
	<dd>
~streamの先頭から %n 個の符号位置を除去した上で、
除去された最後の符号位置を`現在の入力~符号位置$にあてがうことを意味する
（言い換えれば、
現在の入力~符号位置を指している~pointerを，最後に消費された符号位置を指すよう移動する）。
</dd>
	<dd>
最後の 1 個を除去する前に~streamを消費し尽くした場合、
`現在の入力~符号位置$は，`~EOF$iになる。
</dd>

	<dt>
~streamから`入力~符号位置を繰返し消費する@
：…
</dt>
	<dd>
<p>
次を繰返し走らすことを意味する：
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
</li>
			<li>
`現在の入力~符号位置$に応じて、［
後続の~blockに記された，対応する段
］を走らす
</li>
		</ol>
<p>
繰返nは、
値を返した時点（ ~RET ）で終了する。
</p>
	</dd>
</dl>

		</section>
		<section id="tokenizer-algorithms">
<h3 title="Tokenizer Algorithms">4.3. ~tokenizer~algo</h3>

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

			<section id="consume-token">
<h4 title="Consume a token">4.3.1. ~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~streamから
`~tokenを消費する@
方法を述べる。
それは、
所与の
( %入力, 真偽値 %~unicode-rangeは許容されるか（ 省略時は ~F ） )
に対し，
1 個の~tokenを返す：
◎
This section describes how to consume a token from a stream of code points. It additionally takes an optional boolean unicode ranges allowed, defaulting to false. It will return a single token of any type.
</p>
<ol>
	<li>
`~comment列を消費する$()
◎
Consume comments.
</li>
	<li>
<p>
~streamから`入力~符号位置を繰返し消費する$：
◎
Consume the next input code point.
</p>

<dl class="switch">
	<dt>`空白$</dt>
	<dd>
		<ol>
			<li>
~WHILE［
`C1$V ~IN `空白$
］
⇒
1 個の`入力~符号位置を消費する$
</li>
			<li>
~RET 新たな `whitespace$tok
</li>
		</ol>
◎
Consume as much whitespace as possible. Return a &lt;whitespace-token&gt;.
</dd>

	<dt>`22^U</dt>
	<dd>
		<ol>
			<li>
~RET `文字列~tokenを消費する$()
</li>
		</ol>
◎
Consume a string token and return it.
</dd>

	<dt>`23^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
`C1$V ~IN `~ident符号位置$
］~OR［
( `C1$V, `C2$V ) は`妥当な~escape$を成す
］：
◎
If the next input code point is an ident code point or the next two input code points are a valid escape, then:
</p>

				<ol>
					<li>
%型 ~LET ［
次が満たされるならば `id^i ／
~ELSE_ `無制約^i
］
⇒
( `C1$V, `C2$V, `C3$V ) は`~identを開始している$
◎
Create a &lt;hash-token&gt;.
◎
If the next 3 input code points would start an ident sequence, set the &lt;hash-token&gt;’s type flag to "id".
</li>
					<li>
%値 ~LET `~identを消費する$()
◎
Consume an ident sequence, and set the &lt;hash-token&gt;’s value to the returned string.
</li>
					<li>
~RET 新たな `hash$tok
— その
⇒＃
.値 ~SET %値,
.型~flag ~SET %型
◎
Return the &lt;hash-token&gt;.
</li>
				</ol>
			</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`27^U</dt>
	<dd>
		<ol>
			<li>
~RET `文字列~tokenを消費する$()
</li>
		</ol>
◎
Consume a string token and return it.
</dd>

	<dt>`28^U</dt>
	<dd>
		<ol>
			<li>
~RET `open-paren$Tok
</li>
		</ol>
◎
Return a &lt;(-token&gt;.
</dd>

	<dt>`29^U</dt>
	<dd>
		<ol>
			<li>
~RET `close-paren$Tok
</li>
		</ol>
◎
Return a &lt;)-token&gt;.
</dd>

	<dt>`2B^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
入力~streamは`実数を開始している$
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET `数量-~tokenを消費する$()
</li>
				</ol>
◎
If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`2C^U</dt>
	<dd>
		<ol>
			<li>
~RET 新たな `comma$tok
</li>
		</ol>
◎
Return a &lt;comma-token&gt;.
</dd>

	<dt>`2D^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
入力~streamは`実数を開始している$
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET `数量-~tokenを消費する$()
</li>
				</ol>
◎
If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
</li>
			<li>
<p>
~IF［
`C1$V ~EQ `2D^U
］~AND［
`C2$V ~EQ `3E^U
］：
</p>
				<ol>
					<li>
2 個の`入力~符号位置を消費する$
</li>
					<li>
~RET 新たな `CDC$tok
</li>
				</ol>
◎
Otherwise, if the next 2 input code points are U+002D HYPHEN-MINUS U+003E GREATER-THAN SIGN (-&gt;), consume them and return a &lt;CDC-token&gt;.
</li>
			<li>
<p>
~IF［
入力~streamは`~identを開始している$
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET `~identに類する~tokenを消費する$()
</li>
				</ol>
◎
Otherwise, if the input stream starts with an ident sequence, reconsume the current input code point, consume an ident-like token, and return it.
</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`2E^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
入力~streamは`実数を開始している$
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET `数量-~tokenを消費する$()
</li>
				</ol>
◎
If the input stream starts with a number, reconsume the current input code point, consume a numeric token, and return it.
</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`3A^U</dt>
	<dd>
		<ol>
			<li>
~RET 新たな `colon$tok
</li>
		</ol>
◎
Return a &lt;colon-token&gt;.
</dd>

	<dt>`3B^U</dt>
	<dd>
		<ol>
			<li>
~RET 新たな `semicolon$tok
</li>
		</ol>
◎
Return a &lt;semicolon-token&gt;.
</dd>

	<dt>`3C^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
`C1$V ~EQ `21^U
］~AND［
`C2$V ~EQ `2D^U
］~AND［
`C3$V ~EQ `2D^U
］：
</p>
				<ol>
					<li>
3 個の`入力~符号位置を消費する$
</li>
					<li>
~RET 新たな `CDO$tok
</li>
				</ol>
◎
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 &lt;CDO-token&gt;.
</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`40^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
( `C1$V, `C2$V, `C3$V ) は`~identを開始している$
］：
◎
If the next 3 input code points would start an ident sequence,＼
</p>
				<ol>
					<li>
%名前 ~LET `~identを消費する$()
◎
consume an ident sequence,＼
</li>
					<li>
~RET 新たな `at-keyword$tok
— その
⇒＃
.値 ~SET %名前
◎
create an &lt;at-keyword-token&gt; with its value set to the returned value, and return it.
</li>
				</ol>
			</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Otherwise, return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`5B^U</dt>
	<dd>
		<ol>
			<li>
~RET `open-square$Tok
</li>
		</ol>
◎
Return a &lt;[-token&gt;.
</dd>

	<dt>`5C^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
( `現在の入力~符号位置$, `C1$V ) は`妥当な~escape$を成す
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET `~identに類する~tokenを消費する$()
</li>
				</ol>
◎
If the input stream starts with a valid escape, reconsume the current input code point, consume an ident-like token, and return it.
</li>
			<li>
`構文解析error$
◎
Otherwise, this is a parse error.＼
</li>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
◎
Return a &lt;delim-token&gt; with its value set to the current input code point.
</li>
		</ol>
	</dd>

	<dt>`5D^U</dt>
	<dd>
		<ol>
			<li>
~RET `close-square$Tok
</li>
		</ol>
◎
Return a &lt;]-token&gt;.
</dd>

	<dt>`7B^U</dt>
	<dd>
		<ol>
			<li>
~RET `open-curly$Tok
</li>
		</ol>
◎
Return a &lt;{-token&gt;.
</dd>

	<dt>`7D^U</dt>
	<dd>
		<ol>
			<li>
~RET `close-curly$Tok
</li>
		</ol>
◎
Return a &lt;}-token&gt;.
</dd>

	<dt>`数字$</dt>
	<dd>
		<ol>
			<li>
`現在の入力~符号位置を消費し直す$
</li>
			<li>
~RET `数量-~tokenを消費する$()
</li>
		</ol>
◎
Reconsume the current input code point, consume a numeric token, and return it.
</dd>

	<dt>`55^U</dt>
	<dt>`75^U</dt>
	<dd>
		<ol>
			<li>
<p>
~IF［
%~unicode-rangeは許容されるか ~EQ ~T
］~AND［
入力~streamは`~unicode-rangeを開始している$
］：
◎
If unicode ranges allowed is true and the input stream would start a unicode-range,＼
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
◎
reconsume the current input code point,＼
</li>
					<li>
~RET `~unicode-range~tokenを消費する$()
◎
consume a unicode-range token, and return it.
</li>
				</ol>
			</li>
			<li>
`現在の入力~符号位置を消費し直す$
◎
Otherwise, reconsume the current input code point,＼
</li>
			<li>
~RET `~identに類する~tokenを消費する$()
◎
consume an ident-like token, and return it.
</li>
		</ol>
	</dd>
	<dt>
`~identを開始する符号位置$
◎
ident-start code point
</dt>
	<dd>
		<ol>
			<li>
`現在の入力~符号位置を消費し直す$
</li>
			<li>
~RET `~identに類する~tokenを消費する$()
</li>
		</ol>
◎
Reconsume the current input code point, consume an ident-like token, and return it.
</dd>

	<dt>`~EOF$i</dt>
	<dd>
		<ol>
			<li>
~RET `EOF$tok
</li>
		</ol>
◎
Return an &lt;EOF-token&gt;.
</dd>

	<dt>他全部</dt>
	<dd>
		<ol>
			<li>
~RET 新たな `delim$tok
— その
⇒＃
.値 ~SET `現在の入力~符号位置$
</li>
		</ol>
◎
Return a &lt;delim-token&gt; with its value set to the current input code point.
</dd>
</dl>

	</li>
</ol>

			</section>
			<section id="consume-comments">
<h4 title="Consume comments">4.3.2. ~comment列を消費する</h4>

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

<ol>
	<li>
<p>
~WHILE［
`C1$V ~EQ `2F^U
］~AND［
`C2$V ~EQ `2A^U
］：
</p>
		<ol>
			<li>
2 個の`入力~符号位置を消費する$
</li>
			<li>
<p>
~WHILE［
`現在の入力~符号位置$ ~NEQ `~EOF$i
］：
</p>
				<ol>
					<li>
1 個の`入力~符号位置を消費する$
</li>
					<li>
~IF［
`現在の入力~符号位置$ ~EQ `2A^U
］~AND［
`C1$V ~EQ `2F^U
］
⇒＃
1 個の`入力~符号位置を消費する$；
~BREAK
</li>
				</ol>
			</li>
		</ol>
◎
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.
</li>
	<li>
~IF［
`現在の入力~符号位置$ ~EQ `~EOF$i
］
⇒
`構文解析error$
◎
If the preceding paragraph ended by consuming an EOF code point, this is a parse error.
</li>
	<li>
~RET ε
◎
Return nothing.
</li>
</ol>

			</section>
			<section id="consume-numeric-token">
<h4 title="Consume a numeric token">4.3.3. 数量-~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~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 &lt;number-token&gt;, &lt;percentage-token&gt;, or &lt;dimension-token&gt;.
</p>

<ol >
	<li>
( %数値 , %型, %符号~文字 ) ~LET `実数を消費する$()
◎
Consume a number and let number be the result.
</li>
	<li>
<p>
~IF［
( `C1$V, `C2$V, `C3$V ) は`~identを開始している$
］：
</p>
		<ol>
			<li>
%単位 ~LET `~identを消費する$()
</li>
			<li>
~RET 新たな `dimension$tok
— その
⇒＃
.数値 ~SET %数値,
.型~flag ~SET %型,
.符号~文字 ~SET %符号~文字,
.単位 ~SET %単位
</li>
		</ol>
◎
If the next 3 input code points would start an ident sequence, then:
• Create a &lt;dimension-token&gt; with the same value, type flag, and sign character as number, and a unit set initially to the empty string.
• Consume an ident sequence. Set the &lt;dimension-token&gt;’s unit to the returned value.
• Return the &lt;dimension-token&gt;.
</li>
	<li>
<p>
~IF［
`C1$V ~EQ `25^U
］：
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
</li>
			<li>
~RET 新たな `percentage$tok
— その
⇒＃
.数値 ~SET %数値,
.符号~文字 ~SET %符号~文字
</li>
		</ol>
◎
Otherwise, if the next input code point is U+0025 PERCENTAGE SIGN (%), consume it. Create a &lt;percentage-token&gt; with the same value and sign character as number, and return it.
</li>
	<li>
~RET 新たな `number$tok
— その
⇒＃
.数値 ~SET %数値,
.型~flag ~SET %型,
.符号~文字 ~SET %符号~文字
◎
Otherwise, create a &lt;number-token&gt; with the same value, type flag, and sign character as number, and return it.
</li>
</ol>

			</section>
			<section id="consume-ident-like-token">
<h4 title="Consume an ident-like token">4.3.4. ~identに類する~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~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 &lt;ident-token&gt;, &lt;function-token&gt;, &lt;url-token&gt;, or &lt;bad-url-token&gt;.
</p>

<ol >
	<li>
%文字列 ~LET `~identを消費する$()
◎
Consume an ident sequence, and let string be the result.
</li>
	<li>
<p>
~IF［
%文字列 ~EQ`大小無視$sub `url^l
］~AND［
`C1$V ~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 ((),＼
</p>
		<ol >
			<li>
1 個の`入力~符号位置を消費する$
◎
consume it.＼
</li>
			<li>
~WHILE ［
`C1$V ~IN `空白$
］~AND［
`C2$V ~IN `空白$
］
⇒
1 個の`入力~符号位置を消費する$
◎
While the next two input code points are whitespace, consume the next input code point.＼
</li>
			<li>
%c ~LET ［
`C1$V ~IN `空白$ならば `C2$V／
~ELSE_ `C1$V
］
◎
↓</li>
			<li>
<p>
~IF［
%c ~IN { `22^U, `27^U }
］：
</p>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET 新たな `function$tok
— その
⇒＃
.値 ~SET %文字列
</li>
				</ol>

<p class="trans-note">【
引数が引用符で括られた `url("…")^c のような文字列は、
`function$tok と引数たちが成す並びと見なされる。
】</p>

◎
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 &lt;function-token&gt; with its value set to string and return it.＼
</li>
			<li>
~RET `~URL~tokenを消費する$()
◎
Otherwise, consume a url token, and return it.
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
`C1$V ~EQ `28^U
］：
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
</li>
			<li>
~RET 新たな `function$tok
— その
⇒＃
.値 ~SET %文字列
</li>
		</ol>
◎
Otherwise, if the next input code point is U+0028 LEFT PARENTHESIS ((), consume it. Create a &lt;function-token&gt; with its value set to string and return it.
</li>
	<li>
~RET 新たな `ident$tok
— その
⇒＃
.値 ~SET %文字列
◎
Otherwise, create an &lt;ident-token&gt; with its value set to string and return it.
</li>
</ol>

			</section>
			<section id="consume-string-token">
<h4 title="Consume a string token">4.3.5. 文字列~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~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 &lt;string-token&gt; or &lt;bad-string-token&gt;.
</p>

<p>
この~algoは［
文字列を終端させる`符号位置$を表す %終端ng符号位置
］も伴って~callされることもある。
%終端ng符号位置 が指定されずに~callされた場合、
`現在の入力~符号位置$がそれに利用される。
【終端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.
</p>

<ol >
	<li>
%文字列 ~LET 空~文字列
◎
Initially create a &lt;string-token&gt; with its value set to the empty string.
</li>
	<li>
<p>
~streamから`入力~符号位置を繰返し消費する$：
◎
Repeatedly consume the next input code point from the stream:
</p>
		<dl class="switch">
			<dt>%終端ng符号位置</dt>
			<dd>
				<ol>
					<li>
~RET 新たな `string$tok
— その
⇒＃
.値 ~SET %文字列
</li>
				</ol>
◎
Return the &lt;string-token&gt;.
</dd>

			<dt>`~EOF$i</dt>
			<dd>
				<ol>
					<li>
`構文解析error$
</li>
					<li>
~RET 新たな `string$tok
— その
⇒＃
.値 ~SET %文字列
</li>
				</ol>
◎
This is a parse error. Return the &lt;string-token&gt;.
</dd>

			<dt>`改行文字$</dt>
			<dd>
				<ol>
					<li>
`構文解析error$
</li>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET 新たな `bad-string$tok
</li>
				</ol>
◎
This is a parse error. Reconsume the current input code point, create a &lt;bad-string-token&gt;, and return it.
</dd>

			<dt>`5C^U</dt>
			<dd>
<p>
`C1$V に応じて：
</p>
				<dl class="switch">
					<dt>`~EOF$i</dt>
					<dd>
何もしない
</dd>

					<dt>`改行文字$</dt>
					<dd>
1 個の`入力~符号位置を消費する$
</dd>

					<dt>その他</dt>
					<dd>
						<ol>
							<li>
~Assert：
( `現在の入力~符号位置$, `C1$V ) は`妥当な~escape$を成す
</li>
							<li>

%文字列 に次の結果を付加する
⇒
`~escapeされた符号位置を消費する$()
</li>
						</ol>
					</dd>
				</dl>
◎
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 &lt;string-token&gt;’s value.
</dd>

			<dt>他全部</dt>
			<dd>
				<ol>
					<li>
%文字列 に`現在の入力~符号位置$を付加する
</li>
				</ol>
◎
Append the current input code point to the &lt;string-token&gt;’s value.
</dd>
		</dl>
	</li>
</ol>

			</section>
			<section id="consume-url-token">
<h4 title="Consume a url token">4.3.6. ~URL~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~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 &lt;url-token&gt; or a &lt;bad-url-token&gt;.
</p>

<p class="note">注記：
この~algoは、
直前に `url(^l が消費-済みであると見做す。
また、
`url(foo)^v の様な “引用符で括られてない” 値を消費するために~callされているものと見做す。
`url("foo")^v の様に引用符で括られた値は、
 `function-token$t として構文解析される。
`~identに類する~tokenを消費する$~algoは、
この~~区別を自動的に取扱う
— この~algoは、
他からは直に~callされるベキでない。
◎
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 &lt;function-token&gt;. Consume an ident-like token automatically handles this distinction; this algorithm shouldn’t be called directly otherwise.
</p>

<ol>
	<li>
%~URL ~LET 空~文字列
◎
Initially create a &lt;url-token&gt; with its value set to the empty string.
</li>
	<li>
~WHILE［
`C1$V ~IN `空白$
］
⇒
1 個の`入力~符号位置を消費する$
◎
Consume as much whitespace as possible.
</li>
	<li>
<p>
~streamから`入力~符号位置を繰返し消費する$：
◎
Repeatedly consume the next input code point from the stream:
</p>
		<dl class="switch">
			<dt>`29^U</dt>
			<dd>
				<ol>
					<li>
~RET 新たな `url$tok
— その
⇒＃
.値 ~SET %~URL
</li>
				</ol>
◎
Return the &lt;url-token&gt;.
</dd>
			<dt>`~EOF$i</dt>
			<dd>
				<ol>
					<li>
`構文解析error$
</li>
					<li>
~RET 新たな `url$tok
— その
⇒＃
.値 ~SET %~URL
</li>
				</ol>
◎
This is a parse error. Return the &lt;url-token&gt;.
</dd>

			<dt>`空白$</dt>
			<dd>
				<ol>
					<li>
~WHILE［
`C1$V ~IN `空白$
］
⇒
1 個の`入力~符号位置を消費する$
◎
Consume as much whitespace as possible.＼
</li>
					<li>
<p>
`C1$V に応じて：
</p>

						<dl class="switch">
							<dt>`~EOF$i</dt>
							<dd>
								<ol>
									<li>
1 個の`入力~符号位置を消費する$
</li>
									<li>
`構文解析error$
</li>
									<li>
~RET 新たな `url$tok
— その
⇒＃
.値 ~SET %~URL
</li>
							</ol>
							</dd>

							<dt>`29^U</dt>
							<dd>
								<ol>
									<li>
1 個の`入力~符号位置を消費する$
</li>
									<li>
~RET 新たな `url$tok
— その
⇒＃
.値 ~SET %~URL
</li>
								</ol>
							</dd>

							<dt>その他</dt>
							<dd>
								<ol>
									<li>
`不良~URLの残余を消費する$()
</li>
									<li>
~RET 新たな `bad-url$tok
</li>
								</ol>
							</dd>
						</dl>
◎
If the next input code point is U+0029 RIGHT PARENTHESIS ()) or EOF, consume it and return the &lt;url-token&gt; (if EOF was encountered, this is a parse error); otherwise, consume the remnants of a bad url, create a &lt;bad-url-token&gt;, and return it.
</li>
				</ol>
			</dd>

			<dt>`22^U</dt>
			<dt>`27^U</dt>
			<dt>`28^U</dt>
			<dt>`印字不能~符号位置$</dt>
			<dd>
				<ol>
					<li>
`構文解析error$
</li>
					<li>
`不良~URLの残余を消費する$()
</li>
					<li>
~RET 新たな `bad-url$tok
</li>
				</ol>
◎
This is a parse error. Consume the remnants of a bad url, create a &lt;bad-url-token&gt;, and return it.
</dd>

			<dt>`5C^U</dt>
			<dd>
				<ol>
					<li>
<p>
~IF［
( `現在の入力~符号位置$, `C1$V ) は`妥当な~escape$を成す
］：
◎
If the stream starts with a valid escape,＼
</p>
						<ol>
							<li>
%~escape ~LET `~escapeされた符号位置を消費する$()
◎
consume an escaped code point and＼
</li>
							<li>
%~URL に %~escape を付加する
◎
append the returned code point to the &lt;url-token&gt;’s value.
</li>
						</ol>
					</li>
					<li>
<p>
~ELSE：
</p>
						<ol>
							<li>
`構文解析error$
</li>
							<li>
`不良~URLの残余を消費する$()
</li>
							<li>
~RET 新たな `bad-url$tok
</li>
						</ol>
◎
Otherwise, this is a parse error. Consume the remnants of a bad url, create a &lt;bad-url-token&gt;, and return it.
</li>
				</ol>
			</dd>
			<dt>他全部</dt>
			<dd>
				<ol>
					<li>
%~URL に`現在の入力~符号位置$を付加する
</li>
				</ol>
◎
Append the current input code point to the &lt;url-token&gt;’s value.
</dd>
		</dl>
	</li>
</ol>

			</section>
			<section id="consume-escaped-code-point">
<h4 title="Consume an escaped code point">4.3.7. ~escapeされた符号位置を消費する</h4>

<p>
この節では、
`~escapeされた符号位置を消費する@
方法を述べる。
これは、［
直前に `5C^U が消費-済みである
］かつ［
`C1$V は`妥当な~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.
</p>

<ol>
	<li>
1 個の`入力~符号位置を消費する$
◎
Consume the next input code point.
</li>
	<li>
<p>
`現在の入力~符号位置$に応じて：
◎
↓</p>
		<dl class="switch">
			<dt>`~hex$</dt>
			<dd>
				<ol>
					<li>
%~hex列 ~LET 空~文字列
◎
↓</li>
					<li>
<p>
~WHILE［
%~hex列 の長さ ~LT 6
］：
</p>
						<ol>
							<li>
%~hex列 に`現在の入力~符号位置$を付加する
</li>
							<li>
~IF［
`C1$V ~IN `~hex$
］
⇒
1 個の`入力~符号位置を消費する$
</li>
							<li>
~ELSE
⇒
~BREAK
</li>
						</ol>
◎
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.＼
</li>
					<li>
~IF［
`C1$V ~IN `空白$
］
⇒
1 個の`入力~符号位置を消費する$
◎
If the next input code point is whitespace, consume it as well.＼
</li>
					<li>
%数値 ~SET %~hex列 を16 進数として解釈した結果
◎
Interpret the hex digits as a hexadecimal number.＼
</li>
					<li>
~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 (&#xFFFD;).＼
</li>
					<li>
~RET %数値 を値とする `符号位置$
◎
Otherwise, return the code point with that value.
</li>
				</ol>
			</dd>

			<dt>`~EOF$i</dt>
			<dd>
				<ol>
					<li>
`構文解析error$
</li>
					<li>
~RET `FFFD^U
</li>
				</ol>
◎
This is a parse error. Return U+FFFD REPLACEMENT CHARACTER (�).
</dd>

			<dt>他全部</dt>
			<dd>
~RET `現在の入力~符号位置$
◎
Return the current input code point.
</dd>
		</dl>
	</li>
</ol>

			</section>
			<section id="starts-with-a-valid-escape">
<h4 title="Check if two code points are a valid escape">4.3.8. 2 個の符号位置が成す並びが妥当な~escapeを成すかどうか検査する</h4>

<p>
この節では、
2 個の`符号位置$
( %c0, %c1 )
が成す並びが
`妥当な~escape@
を成すかどうか検査する方法を述べる。
【！or can be called with the input stream itself…】
◎
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.
</p>

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

<ol>
	<li>
~RET ~IS［
%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.
</li>
</ol>

			</section>
			<section id="would-start-an-identifier">
<h4 title="Check if three code points would start an ident sequence">4.3.9. 3 個の符号位置が成す並びが~identを開始しているかどうか検査する</h4>

<p>
この節では、
3 個の`符号位置$
( %c0, %c1, %c2 )
が成す並びが
`~identを開始している@
かどうか検査する方法を述べる。
この~algoの入力には、
入力~streamそのものが渡されることもある
— その場合、
( `現在の入力~符号位置$, `C1$V, `C2$V )
に対し適用するとする。
◎
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.
</p>

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

<ol>
	<li>
<p>
~RET ~IS［
( %c0, %c1, %c2 ) は次の表tを成す いずれかの行に示される条件を満たす
］：
</p>

<table><thead>
<tr><th>%c0
<th>%c1
<th>%c2
<tbody>

<tr><td>`2D^U
<td>`~identを開始する符号位置$
<td>(任意)

<tr><td>`2D^U
<td>`2D^U
<td>(任意)

<tr><td>`2D^U
<td colspan="2">`妥当な~escape$を成す

<tr><td>`~identを開始する符号位置$
<td>(任意)
<td>(任意)

<tr><td colspan="2">`妥当な~escape$を成す
<td>(任意)
</table>

<div lang="en" class="_en">
<p>
Look at the first code point:
</p>

<dl>
	<dt>U+002D HYPHEN-MINUS</dt>
	<dd>
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.
</dd>
	<dt>ident-start code point</dt>
	<dd>Return true.</dd>

	<dt>U+005C REVERSE SOLIDUS (\)</dt>
	<dd>If the first and second code points are a valid escape, return true. Otherwise, return false.</dd>

	<dt>anything else</dt>
	<dd>Return false.</dd>
</dl>
</div>

	</li>
</ol>

			</section>
			<section id="starts-with-a-number">
<h4 title="Check if three code points would start a number">4.3.10. 3 個の符号位置が成す並びが実数を開始しているかどうか検査する</h4>

<p>
この節では、
3 個の`符号位置$
( %c0, %c1, %c2 )
が成す並びが
`実数を開始している@
かどうか検査する方法を述べる。
この~algoの入力には、
入力~streamそのものが渡されることもある
— その場合、
( `現在の入力~符号位置$, `C1$V, `C2$V )
に対し適用するとする。
◎
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.
</p>

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

<ol>
	<li>
<p>
~RET ~IS［
( %c0, %c1, %c2 ) は次の表tを成す いずれかの行に示される条件を満たす
］：
</p>

<table><thead>
<tr><th>%c0
<th>%c1
<th>%c2
<tbody>

<tr><td>`正負符号$
<td>`数字$
<td>(任意)

<tr><td>`正負符号$
<td>`2E^U
<td>`数字$

<tr><td>`2E^U
<td>`数字$
<td>(任意)

<tr><td>`数字$
<td>(任意)
<td>(任意)
</table>

<div lang="en" class="_en">
<p>
Look at the first code point:
</p>
<dl>
	<dt>U+002B PLUS SIGN (+)</dt>
	<dt>U+002D HYPHEN-MINUS (-)</dt>
	<dd>
<p>
If the second code point is a digit, return true.
</p>
<p>
Otherwise, if the second code point is a U+002E FULL STOP (.) and the third code point is a digit, return true.
</p>
<p>
Otherwise, return false.
</p>
	</dd>

	<dt>U+002E FULL STOP (.)</dt>
	<dd>If the second code point is a digit, return true. Otherwise, return false.</dd>

	<dt>digit</dt>
	<dd>Return true.</dd>

	<dt>anything else</dt>
	<dd>Return false.</dd>
</dl>

		</div>

	</li>
</ol>

			</section>
			<section id="starts-a-unicode-range">
<h4 title="Check if three code points would start a unicode-range">4.3.11. 3 個の符号位置が成す並びが~unicode-rangeを開始しているかどうか検査する</h4>

<p>
この節では、
3 個の`符号位置$が成す並び
( %c0, %c1, %c2 )
が
`~unicode-rangeを開始している@
かどうか検査する方法を述べる。
この~algoの入力には、
入力~streamそのものが渡されることもある
— その場合、
( `現在の入力~符号位置$, `C1$V, `C2$V )
に対し適用するとする。
◎
This section describes how to check if three code points would start a unicode-range. 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.
</p>

<p class="note">注記：
この~algoは`符号位置$を消費しない。
◎
Note: This algorithm will not consume any additional code points.
</p>
<ol>
	<li>
<p>
~RET ~IS ~AND↓：
</p>
		<ul>
			<li>
%c0 ~IN { `55^U, `75^U }
</li>
			<li>
%c1 ~EQ `2B^U
</li>
			<li>
%c2 ~IN { `3F^U, `~hex$ }
</li>
		</ul>
◎
If all of the following are true:
• The first code point is either U+0055 LATIN CAPITAL LETTER U (U) or U+0075 LATIN SMALL LETTER U (u)
• The second code point is U+002B PLUS SIGN (+).
• The third code point is either U+003F QUESTION MARK (?) or a hex digit
◎
then return true.
◎
Otherwise return false.
</li>
</ol>

			</section>
			<section id="consume-name">
<h4 title="Consume an ident sequence">4.3.12. ~identを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~streamから
`~identを消費する@
方法を述べる。
それは、
~stream内の `C1$V から始まる最長な名前を成す文字列を返す。
◎
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.
</p>

<p class="note">注記：
この~algoは、
最初の少数の`符号位置$の検証y
— それは、
返される`符号位置$が `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 &lt;ident-token&gt;. If that is the intended use, ensure that the stream starts with an ident sequence before calling this algorithm.
</p>

<ol>
	<li>
%結果 ~LET 空~文字列
◎
Let result initially be an empty string.
</li>
	<li>
<p>
~streamから`入力~符号位置を繰返し消費する$：
◎
Repeatedly consume the next input code point from the stream:
</p>
		<dl class="switch">
			<dt>
`~ident符号位置$
◎
ident code point
</dt>
			<dd>
				<ol>
					<li>
%結果 に`現在の入力~符号位置$を付加する
</li>
				</ol>
◎
Append the code point to result.
</dd>

			<dt>
( `現在の入力~符号位置$, `C1$V ) は`妥当な~escape$を成す
◎
the stream starts with a valid escape
</dt>
			<dd>
				<ol>
					<li>
%結果 に次の結果を付加する
⇒
`~escapeされた符号位置を消費する$()
</li>
				</ol>
◎
Consume an escaped code point. Append the returned code point to result.
</dd>

			<dt>他全部</dt>
			<dd>
				<ol>
					<li>
`現在の入力~符号位置を消費し直す$
</li>
					<li>
~RET %結果
</li>
				</ol>
◎
Reconsume the current input code point. Return result.
</dd>
		</dl>
	</li>
</ol>

			</section>
			<section id="consume-number">
<h4 title="Consume a number">4.3.13. 実数を消費する</h4>

<p>
この節では、
`符号位置$たちが成す~streamから
`実数を消費する@
方法を述べる。
それは、
( 数値, %型~flag ~IN { `整数^i, `実数^i }, %符号~文字 ~IN { `正負符号$, ε} )
が成す組を返す。
◎
This section describes how to consume a number from a stream of code points. It returns a numeric value, a string type which is either "integer" or "number", and an optional sign character which is either "+", "-", or missing.
</p>

<p class="note">注記：
この~algoは、［
~streamから実数が得せること
］を確保するために必要yな［
最初の少数の`符号位置$の検証y
］を行わない。
~callする際には，［
~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.
</p>

<ol>
	<li>
%型 ~LET `整数^i
◎
Let type be the string "integer".＼
</li>
	<li>
%実数~部 ~LET 空~文字列
◎
Let number part and exponent part be the empty string.
</li>
	<li>
%指数~部 ~LET 空~文字列
◎
↑</li>
	<li>
%符号~文字 ~LET `C1$V
◎
↓</li>
	<li>
~IF［
%符号~文字 ~NIN `正負符号$
］
⇒
%符号~文字 ~SET ε
◎
↓</li>
	<li>
~ELSE
⇒＃
1 個の`入力~符号位置を消費する$；
%符号~文字 を %実数~部 に付加する
◎
If the next input code point is U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-), consume it. Append it to number part and set sign character to it.
</li>
	<li>
~WHILE［
`C1$V ~IN `数字$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%実数~部 に`現在の入力~符号位置$を付加する
◎
While the next input code point is a digit, consume it and append it to number part.
</li>
	<li>
<p>
~IF［
`C1$V ~EQ `2E^U
］~AND［
`C2$V ~IN `数字$
］：
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
</li>
			<li>
%実数~部 に`現在の入力~符号位置$を付加する
</li>
			<li>
~WHILE［
`C1$V ~IN `数字$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%実数~部 に`現在の入力~符号位置$を付加する
</li>
			<li>
%型 ~SET `実数^i
</li>
		</ol>
◎
If the next 2 input code points are U+002E FULL STOP (.) followed by a digit, then:
• Consume the next input code point and append it to number part.
• While the next input code point is a digit, consume it and append it to number part.
• Set type to "number".
</li>
	<li>
%c ~LET ［
`C2$V ~IN `正負符号$ならば `C3$V ／
~ELSE_ `C2$V
］
◎
↓</li>
	<li>
<p>
~IF［
`C1$V ~IN { `45^U, `65^U }
］~AND［
%c ~IN `数字$
］：
◎
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:
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
◎
Consume the next input code point.
</li>
			<li>
~IF［
`C1$V ~IN `正負符号$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%指数~部 に`現在の入力~符号位置$を付加する
◎
If the next input code point is "+" or "-", consume it and append it to exponent part.
</li>
			<li>
~WHILE［
`C1$V ~IN `数字$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%指数~部 に`現在の入力~符号位置$を付加する
◎
While the next input code point is a digit, consume it and append it to exponent part.
</li>
			<li>
%型 ~SET `実数^i
◎
Set type to "number".
</li>
		</ol>
	</li>
	<li>
%値 ~LET %実数~部 を 10 進数として解釈した結果
◎
Let value be the result of interpreting number part as a base-10 number.
</li>
	<li>
~IF［
%指数~部 ~NEQ 空~文字列
］
⇒
%値 ~SET %値 ~MUL ( 10 の ( %指数~部 を 10 進数として解釈した結果 ) 乗 )
◎
If exponent part is non-empty, interpret it as a base-10 integer, then raise 10 to the power of the result, multiply it by value, and set value to that result.
</li>
	<li>
~RET ( %値, %型, %符号~文字 )
◎
Return value, type, and sign character.
</li>
</ol>

			</section>
			<section id="consume-unicode-range-token">
<h4 title="Consume a unicode-range token">4.3.14. ~unicode-range~tokenを消費する</h4>

<p>
この節では、
`符号位置$たちが成す~streamから
`~unicode-range~tokenを消費する@
方法を述べる。
それは `unicode-range$tok を返す：
◎
This section describes how to consume a unicode-range token from a stream of code points. It returns a &lt;unicode-range-token&gt;.
</p>

<p class="note">注記：
この~algoは、［
返される`符号位置$が `unicode-range$tok の一部を成すこと
］を確保するために必要yな［
最初の少数の`符号位置$の検証y
］を行わない。
［
~streamは`~unicode-rangeを開始している$こと
］を事前に確保すること。
◎
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 &lt;unicode-range-token&gt;. Ensure that the stream would start a unicode-range before calling this algorithm.
</p>

<p class="note">注記：
~tokenizerは、
通常の状況下では，
この~tokenを生産しない。
この~algoは、
`~unicode-range記述子の値を消費する$間に限り，~callされる
— それ自体も `unicode-range$d 記述子を構文解析するための特別な事例に限り，~callされる。
~CSS言語~全体における この単独の呼出nは，
早期~CSSにおける構文の不良な設計に因る。
◎
Note: This token is not produced by the tokenizer under normal circumstances. This algorithm is only called during consume the value of a unicode-range descriptor, which itself is only called as a special case for parsing the unicode-range descriptor; this single invocation in the entire language is due to a bad syntax design in early CSS.
</p>
<ol>
	<li>
1 個の`入力~符号位置を消費する$
◎
Consume the next two input code points and discard them.
</li>
	<li>
%第一~区分 ~LET 空~文字列
◎
↓</li>
	<li>
~WHILE［
%第一~区分 の長さ ~LT 6
］~AND［
`C1$V ~IN `~hex$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%第一~区分 に`現在の入力~符号位置$を付加する
◎
Consume as many hex digits as possible, but no more than 6.＼
</li>
	<li>
~WHILE［
%第一~区分 の長さ ~LT 6
］~AND［
`C1$V ~EQ `3F^U
］
⇒＃
1 個の`入力~符号位置を消費する$；
%第一~区分 に`現在の入力~符号位置$を付加する
◎
If less than 6 hex digits were consumed, consume as many U+003F QUESTION MARK (?) code points as possible, but no more than enough to make the total of hex digits and U+003F QUESTION MARK (?) code points equal to 6.
◎
Let first segment be the consumed code points.
</li>
	<li>
%範囲~始端 ~LET ［
%第一~区分 を成す各 `3F^U を `30^U に置換した結果
］を 16 進数として解釈した結果
◎
↓</li>
	<li>
%範囲~終端 ~LET ［
%第一~区分 を成す各 `3F^U を `46^U に置換した結果
］を 16 進数として解釈した結果
◎
If first segment contains any question mark code points, then:
• Replace the question marks in first segment with U+0030 DIGIT ZERO (0) code points, and interpret the result as a hexadecimal number. Let this be start of range.
• Replace the question marks in first segment with U+0046 LATIN CAPITAL LETTER F (F) code points, and interpret the result as a hexadecimal number. Let this be end of range.
• ↓ Return a new &lt;unicode-range-token&gt; starting at start of range and ending at end of range.
◎
↓</li>
	<li>
<p>
~IF［
%範囲~始端 ~EQ %範囲~終端
（すなわち， %第一~区分 は `3F^U を包含しない）
］~AND［
`C1$V ~EQ `2D^U
］~AND［
`C2$V ~IN `~hex$
］：
◎
Otherwise, interpret first segment as a hexadecimal number, and let the result be start of range.
◎
If the next 2 input code points are U+002D HYPHEN-MINUS (-) followed by a hex digit, then:
</p>
		<ol>
			<li>
1 個の`入力~符号位置を消費する$
◎
Consume the next input code point.
</li>
			<li>
%第二~区分 ~LET 空~文字列
◎
↓</li>
	<li>
~WHILE［
%第二~区分 の長さ ~LT 6
］~AND［
`C1$V ~IN `~hex$
］
⇒＃
1 個の`入力~符号位置を消費する$；
%第二~区分 に`現在の入力~符号位置$を付加する
◎
Consume as many hex digits as possible, but no more than 6.＼
</li>
			<li>
%範囲~終端 ~SET %第二~区分 を 16 進数として解釈した結果
◎
Interpret the consumed code points as a hexadecimal number. Let this be end of range.
◎
↓ Return a new &lt;unicode-range-token&gt; starting at start of range and ending at end of range.
</li>
		</ol>
	</li>
	<li>
~RET 新たな `unicode-range$tok
— その
⇒＃
.始端 ~SET %範囲~始端,
.終端 ~SET %範囲~始端
◎
Otherwise, return a new &lt;unicode-range-token&gt; both starting and ending at start of range.
</li>
</ol>

			</section>
			<section id="consume-remnants-of-bad-url">
<h4 title="Consume the remnants of a bad url">4.3.15. 不良~URLの残余を消費する</h4>

<p>
この節では、
`不良~URLの残余を消費する@
方法を述べる。
それは、
~tokenizerが，`符号位置$たちが成す~streamにおいて［
`url$tok ではなく，`bad-url$tok の中途にある
］ことが~~判明した際の “後始末” を行う。
それは ε を返し、
もっぱら，［
通常の~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 &lt;bad-url-token&gt; rather than a &lt;url-token&gt;. It returns nothing; its sole use is to consume enough of the input stream to reach a recovery point where normal tokenizing can resume.
</p>

<ol >
	<li>
<p>
~streamから`入力~符号位置を繰返し消費する$：
◎
Repeatedly consume the next input code point from the stream:
</p>
		<dl class="switch">
			<dt>`29^U</dt>
			<dt>`~EOF$i</dt>
			<dd>
				<ol>
					<li>
~RET ε
</li>
				</ol>
◎
Return.
</dd>

			<dt>
( `現在の入力~符号位置$, `C1$V ) は`妥当な~escape$を成す
◎
the input stream starts with a valid escape
</dt>
			<dd>
				<ol>
					<li>
`~escapeされた符号位置を消費する$()
</li>
				</ol>
◎
Consume an escaped code point.＼
</dd>
			<dd class="note">注記：
これは、
`bad-url$tok を終端させずに，［
~escapeされた閉じ丸括弧（ `\)^l ）
］を取り込めるようにする。
それ以外については “他全部” の段と一致する。
◎
This allows an escaped right parenthesis ("\)") to be encountered without ending the &lt;bad-url-token&gt;. This is otherwise identical to the "anything else" clause.
</dd>

			<dt>他全部</dt>
			<dd>
				<ol>
					<li>
何もしない
</li>
				</ol>
◎
Do nothing.
</dd>
		</dl>
	</li>
</ol>

			</section>
		</section>
	</section>
	<section id="parsing">
<h2 title="Parsing">5. 構文解析-法</h2>

<p>
~CSS構文解析器は、
`~token~stream$
（`§ ~tokenizer~algo＠#tokenizer-algorithms$により生産された結果）
を 1 個以上の~CSS構成子たち
（どの構文解析~algoが呼出されたかに依存する）
へ変換する。
◎
The CSS parser converts a token stream (produced by the tokenization process, defined earlier in this spec) into one or more of several CSS constructs (depending on which parsing algorithm is invoked).
</p>

		<section id="parser-diagrams">
<h3 title="Parser Railroad Diagrams">5.1. 構文解析器の線路図式</h3>

◎非規範的

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

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

<dl>
	<dt id="stylesheet-diagram">`Stylesheet^sb（~stylesheet）</dt>
	<dd class="railroad">`stylesheet^dgm</dd>

	<dt id="at-rule-diagram">`At-rule^sb（`~at-規則$）</dt>
	<dd class="railroad">`at-rule^dgm</dd>

	<dt id="qualified-rule-diagram">`Qualified rule^sb（`有修飾~規則$）</dt>
	<dd class="railroad">`qualified-rule^dgm</dd>

	<dt id="curly-block-diagram">`{} block^sb</dt>
	<dd class="railroad">`declaration-list^dgm</dd>
	<dd class="trans-note">【
`波括弧~block$と同じ名前だが，定義が異なっていて紛らわしい。
】</dd>

	<dt id="declaration-diagram">`Declaration^sb（`宣言$）</dt>
	<dd class="railroad">`declaration^dgm</dd>

	<dt id="important-diagram">`!important^sb</dt>
	<dd class="railroad">`important^dgm</dd>

	<dt id="component-value-diagram">`Component value^sb（`成分~値$）</dt>
	<dd class="railroad">`component-value^dgm</dd>

	<dt id="simple-block-diagram">`Simple block^sb（`単純~block$）</dt>
	<dd class="railroad">`simple-block^dgm</dd>

	<dt id="function-block-diagram">`Function block^sb（`関数$）</dt>
	<dd class="railroad">`function-block^dgm</dd>

</dl>

		</section>
		<section id="css-tree">
<h3 title="CSS Parsing Results">5.2. ~CSS構文解析の結果</h3>

<p>
構文解析の結果は、
次に挙げるいずれか
— あるいは、
それらが成す`~list$ —
になる：
◎
The result of parsing can be any of the following (or lists of these):
</p>
<dl>
	<dt>
`~stylesheet@
◎
stylesheet
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`規則~群^dfn
— `規則$たちが成す`~list$
</li>
		</ul>
◎
A stylesheet has a list of rules.
</dd>
	<dt>
`規則@
◎
rule
</dt>
	<dd>
`~at-規則$ ／ `有修飾~規則$ 【／ `入子な宣言~列が成す規則$】
◎
A rule is either an at-rule or a qualified rule.
</dd>

	<dt>
`~at-規則$
◎
at-rule
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`名前^dfn
— `文字列$
</li>
			<li>
.`導入部^dfn
— `成分~値$たちが成す`~list$
</li>
			<li>
.`宣言~群^dfn
— ε ／ `宣言$たちが成す`~list$
</li>
			<li>
.`子~規則~群^dfn
— ε ／ 子`規則$たちが成す`~list$
</li>
		</ul>
<p>
これらのうち，［
.宣言~群 ／ .子~規則~群
］は、
`~block~at-規則$（`波括弧~block$で終端するもの）に限り非 ε になり，
~semicolonで終端する`一文~at-規則$においては ε になる。
</p>
◎
An at-rule has a name which is a string, a prelude consisting of a list of component values. Block at-rules (ending in a {}-block) will additionally have a list of declarations and a list of child rules. (Statement at-rules, ending in a semicolon, will not.)
</dd>

	<dt>
`有修飾~規則@
◎
qualified rule
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`導入部^dfn
— `成分~値$たちが成す`~list$
</li>
			<li>
.`宣言~群^dfn
— `宣言$たちが成す`~list$
</li>
			<li>
.`子~規則~群^dfn
— 子`規則$たちが成す`~list$
</li>
		</ul>
◎
A qualified rule has a prelude consisting of a list of component values, a list of declarations, and a list of child rules.
</dd>

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

	<dt>
`宣言@
◎
declaration
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`名前^dfn
— `文字列$
</li>
			<li>
.`値^dfn
— `成分~値$たちが成す`~list$
</li>
			<li>
.`~importantか^dfn
— 真偽値, 初期~時は ~F
【`~importantな宣言$になるかどうかを指示する。】
</li>
			<li>
.`元の~text^dfn
— ε ／ 文字列
（文字列は、少数の宣言に限り捕捉される。）
</li>
		</ul>
◎
A declaration has a name which is a string, a value consisting of a list of component values, and an important flag which is initially unset. It also has an optional original text which is a string (captured for only a few declarations).
</dd>
	<dd>
<p>
宣言たちは、
次に挙げるいずれかに分類される：
◎
Declarations are further categorized as property declarations or descriptor declarations, with＼
</p>
		<ul>
			<li>
`~prop宣言@
⇒
`有修飾~規則$内で出現することが最も多く，~CSS`~prop$を設定する。
◎
the former setting CSS properties and appearing most often in qualified rules＼
</li>
			<li>
`記述子~宣言@
⇒
`~at-規則$内に限り出現し，~CSS`記述子$を設定する。
◎
and the latter setting CSS descriptors, which appear only in at-rules.＼
</li>
		</ul>
<p>
（この分類は、
この仕様の構文~levelにおいては生じない
— この分類は、
宣言が出現する所における産物であり，
当の規則を定義する仕様により定義される。）
◎
(This categorization does not occur at the Syntax level; instead, it is a product of where the declaration appears, and is defined by the respective specifications defining the given rule.)
</p>
	</dd>

	<dt>
`成分~値@
◎
component value
</dt>
	<dd>
`保全d~token$ ／
`関数$ ／
`単純~block$
◎
A component value is one of the preserved tokens, a function, or a simple block.
</dd>

	<dt>
`保全d~token@
◎
preserved tokens
</dt>
	<dd>
次に挙げるもの以外の，~tokenizerにより生産される任意の~token
⇒＃
`function$tok,
`open-curly$Tok,
`open-paren$Tok,
`open-square$Tok
◎
Any token produced by the tokenizer except for &lt;function-token&gt;s, &lt;{-token&gt;s, &lt;(-token&gt;s, and &lt;[-token&gt;s.
</dd>
	<dd class="note">注記：
上に挙げられた非`保全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.
</dd>
	<dd class="note">注記：
【出力に出現する】
~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 &lt;}-token&gt;s, &lt;)-token&gt;s, &lt;]-token&gt;, &lt;bad-string-token&gt;, and &lt;bad-url-token&gt; 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.
</dd>

	<dt>
`関数@
◎
function
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`名前^dfn
</li>
			<li>
.`値^dfn
— `成分~値$たちが成す`~list$
</li>
		</ul>
◎
A function has a name and a value consisting of a list of component values.
</dd>

	<dt>
`単純~block@
◎
simple block
◎
{}-block
◎
[]-block
◎
()-block
</dt>
	<dd>
<p>
次に挙げる~fieldを伴う：
</p>
		<ul>
			<li>
.`開き括弧^dfn
— 次に挙げるいずれか
⇒＃
`open-square$Tok ／
`open-paren$Tok ／
`open-curly$Tok
</li>
			<li>
.`値^dfn
— `成分~値$たちが成す`~list$
</li>
		</ul>
◎
A simple block has an associated token (either a &lt;[-token&gt;, &lt;(-token&gt;, or &lt;{-token&gt;) and a value consisting of a list of component values.
</dd>
	<dd>
<p>
`単純~block$は、
その.開き括弧に応じて：
</p>
		<ul>
			<li>
`open-square$Tok ならば
`角括弧~block@
（ `[]-block^en ）と称される。
</li>
			<li>
`open-paren$Tok ならば
`丸括弧~block@
（ `()-block^en ）と称される。
</li>
			<li>
`open-curly$Tok ならば
`波括弧~block@
（ `{}-block^en ）と称される。
</li>
		</ul>
◎
{}-block, []-block, and ()-block refer specifically to a simple block with that corresponding associated token.
</dd>
</dl>

		</section>
		<section id="parser-definitions">
<h3 title="Token Streams">5.3. ~token~stream</h3>

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

<p class="trans-note">【
~DAGGER
~tokenと成分~値が混在し得るかどうかは、
はっきりしない。
】</p>

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

	<dt>
`~index@tS
◎
index
</dt>
	<dd>
`~token群$tSの中を指す~index
— 初期~時は 0 とする。
構文解析の進捗を表現する。
◎
An index into the tokens, representing the progress of parsing. It starts at 0 initially.
</dd>
	<dd class="note">注記：
`~markを復旧する$tS【！`~markする$tS】ときは別として、
`~index$tSは決して後戻りしない。
したがって、
`~token群$tSを成す~tokenのうち，すでに処理したものは、
それに伴い，早急に破棄できる。
◎
Note: Aside from marking, the index never goes backwards. Thus the already-processed prefix of tokens can be eagerly discarded as it’s processed.
</dd>

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

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

<p>
`~token~stream$ %入力 に対しては、
次に挙げる演算が遂行され得る：
◎
Several operations can be performed on a token stream:
</p>
<ul>
	<li class="algo">
<p>
%入力 の
`次回の~token@tS
は、
次の結果を返す：
</p>
		<ol>
			<li>
%~index ~LET %入力 の`~index$tS
</li>
			<li>
%~token群 ~LET %入力 の`~token群$tS
</li>
			<li>
~IF［
%~index ~GTE %~token群 の`~size$
］
⇒
~RET `EOF$tok
</li>
			<li>
~RET %~token群[ %~index ]
</li>
		</ol>
◎
next token
• The item of tokens at index.
• If that index would be out-of-bounds past the end of the list, it’s instead an &lt;eof-token&gt;.
</li>
	<li>
%入力 は
`空@tS
であるとは、
次を満たすことをいう
⇒
%入力 の`次回の~token$tS ~EQ `EOF$tok
◎
empty
• A token stream is empty if the next token is an &lt;eof-token&gt;.
</li>
	<li class="algo">
<p>
%入力 から
`~tokenを消費する@tS
~algoは：
</p>
		<ol>
			<li>
%~token ~LET %入力 の`次回の~token$tS
</li>
			<li>
%入力 の`~index$tS ~INCBY 1
</li>
			<li>
~RET %~token
</li>
		</ol>
◎
consume a token
• Let token be the next token. Increment index, then return token.
</li>
	<li class="algo">
%入力 から
`~tokenを破棄する@tS
~algoは
⇒
~IF［
%入力 は`空$tSでない
］
⇒
%入力 の`~index$tS ~INCBY 1
◎
discard a token
• If the token stream is not empty, increment index.
</li>

	<li class="algo">
%入力 を
`~markする@tS
~algoは
⇒
%入力 の`~mark済み~index群$tSに %入力 の`~index$tS を`付加する$
◎
mark
• Append index to marked indexes.
</li>
	<li class="algo">
%入力 の
`~markを復旧する@tS
~algoは
⇒
%入力 の`~index$tS ~SET %入力 の`~mark済み~index群$tSから`~popする$
◎
restore a mark
• Pop from marked indexes, and set index to the popped value.
</li>
	<li class="algo">
%入力 の
`~markを破棄する@tS
~algoは
⇒
%入力 の`~mark済み~index群$tSから`~popする$
（~popされた値は棄てる）
◎
discard a mark
• Pop from marked indexes, and do nothing with the popped value.
</li>
	<li class="algo">
%入力 の
`空白を破棄する@tS
~algoは
⇒
~WHILE［
%入力 の`次回の~token$tSは `whitespace$tok である
］
⇒
%入力 から`~tokenを破棄する$tS
◎
discard whitespace
• While the next token is a &lt;whitespace-token&gt;, discard a token.
</li>
	<li>
<p>
%入力 を
`処理する@tS
所では、
次を繰返す
⇒
%入力 の`次回の~token$tSに応じて、［
後続の~block内に記された，当の~tokenの型に対応する動作
］を遂行する
</p>

<p>
繰返nは、
当の動作が値を返した時点（ ~RET ）で終了する。
</p>
◎
process
• To process, given a following list of token types and associated actions, perform the action associated with the next token. Repeat until one of the actions returns something, then return that.
</li>
</ul>

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

		</section>
		<section id="parser-entry-points">
<h3 title="Parser Entry Points">5.4. 構文解析器の入口</h3>

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

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

<div class="algo">
<p>
`~token~streamに正規化する@
~algoは、
所与の
( %入力 )
に対し，
%入力 の型に応じて：
◎
To normalize into a token stream a given input:
</p>
<ul class="switch">
	<li>
`~token~stream$
⇒
~RET %入力
◎
If input is already a token stream, return it.
</li>
	<li>
［
~token／`成分~値$
］たちが成す~list
⇒
~RET 新たな`~token~stream$
— その
⇒
`~token群$tS ~SET %入力
◎
If input is a list of CSS tokens and/or component values, create a new token stream with input as its tokens, and return it.
</li>
	<li>
<p>
`文字列$：
</p>
		<ol>
			<li>
%入力 ~SET `符号位置~列を~filterする$( %入力 )
</li>
			<li>
%~token群 ~LET 新たな`~list$
</li>
			<li>
`符号位置~streamを~token化する$( %入力, %~token群 )
</li>
			<li>
~RET 新たな`~token~stream$
— その
⇒
`~token群$tS ~SET %~token群
</li>
		</ol>
◎
If input is a string, then filter code points from input, tokenize the result, then create a new token stream with those tokens as its tokens, and return it.
</li>
	<li>
その他
⇒
~Assert：
この事例は生じ得ない
— %入力 として渡されるのは、
上に挙げた型に限られるベキである。
◎
Assert: Only the preceding types should be passed as input.
</li>
</ul>
</div>

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

<div class="note">
<p>
以下の注記は、
おそらく，関連な仕様の規範的な~textに
— この仕様の用語を通して —
翻訳されるべきである：
◎
The following notes should probably be translated into normative text in the relevant specs, hooking this spec’s terms:
</p>
<ul>
	<li>
`~stylesheetを構文解析する$
⇒
~stylesheetを構文解析するための，
構文解析器の通常の入口になることが意図される。
◎
"Parse a stylesheet" is intended to be the normal parser entry point, for parsing stylesheets.
</li>
	<li>
`~stylesheetの内容を構文解析する$
⇒
`CSSStyleSheet^I の `replace()＠~CSSOM1#dom-cssstylesheet-replace$c ~methodやそれに類似なものによる利用-用に意図され、
~textを既存の~stylesheetを成す内容へ構文解析する。
◎
"Parse a stylesheet’s contents" is intended for use by the CSSStyleSheet replace() method, and similar, which parse text into the contents of an existing stylesheet.
</li>
	<li>
`規則を構文解析する$
⇒
`CSSStyleSheet^I の
`insertRule()＠~CSSOM1#dom-cssstylesheet-insertrule$c ~methodやそれに類似なもの
による利用-用に意図され、
~textを単独の規則に構文解析する。
◎
"Parse a rule" is intended for use by the CSSStyleSheet insertRule() method, and similar, which parse text into a single rule. CSSStyleSheet#insertRule method, and similar functions which might exist, which parse text into a single rule.
</li>
	<li>
`宣言を構文解析する$
⇒
`条件付き~group規則$（ `supports$at ）における利用が意図される。
`CSS3-CONDITIONAL$r
◎
"Parse a declaration" is used in @supports conditions. [CSS3-CONDITIONAL]
</li>
	<li>
`~blockの内容を構文解析する$
⇒
次に意図される
⇒
~CSSにおける任意の~block
（`~style属性＠~CSSSTYLEATTR#style-attribute$の様なものも含む）
を成す内容を構文解析するため／
`CSSStyleDeclaration^I の `cssText＠~CSSOM1#dom-cssstyledeclaration-csstext$c 属性などの~API用
◎
"Parse a block’s contents" is intended for parsing the contents of any block in CSS (including things like the style attribute), and APIs such as the CSSStyleDeclaration cssText attribute.
</li>
	<li>
`成分~値を構文解析する$
⇒
1 個の値を消費するために必要になる
— `attr$f 用の構文解析~規則の様な。
◎
"Parse a component value" is for things that need to consume a single value, like the parsing rules for attr().
</li>
	<li>
`成分~値~listを構文解析する$
⇒
呈示~用の属性の内容~text【例：`非~CSS呈示~用~hint$】を 1 個の宣言~値として構文解析したり，［
【！＊`~Selectors~API＠~TR/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.
</li>
</ul>
</div>

			<section id="parse-grammar">
<h4 title="Parse something according to a CSS grammar">5.4.1. ある~CSS文法に則って何かを構文解析する</h4>

<p>
文字列や~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 &lt;color&gt;", or similar.
</p>

<p>
この~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 &lt;string&gt; value").
</p>

<p class="note">注記：
他の仕様から~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.
</p>

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

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

			</section>
			<section id="parse-comma-list">
<h4 title="Parse a comma-separated list according to a CSS grammar">5.4.2. ~commaで分離された~listを ある~CSS文法に則って構文解析する</h4>

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

<p>
それが欲されることもあるが
（~CSS~propのうち`~list値をとる$ものなど）、
値を成す各~commaで分離された下位部分を別々に構文解析して，［
各~結果に対し、
成功したか失敗したかに応じて，別な仕方で処する
］方が良いこともある
（失敗した場合、
概して，無視されよう
— `img$e の `sizes$a 属性を`構文解析する＠~HEimages#parse-a-sizes-attribute$ときなど）。
◎
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 &lt;img sizes&gt;).
</p>

<p>
次の~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).
</p>

<div class="algo">
<p>
`~commaで分離された~listを~CSS文法に則って構文解析する@
（略して，単に “~listを構文解析する” ）
~algoは、
所与の
( %入力, ~CSS文法 %生成規則 )
に対し：
◎
To parse a comma-separated list according to a CSS grammar (aka parse a list) given an input and a CSS grammar production:
</p>
<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
~IF［
%入力 の`~token群$tSを成す どの~itemも `whitespace$tok である
］
⇒
~RET 新たな`~list$
◎
If input contains only &lt;whitespace-token&gt;s, return an empty list.
</li>
	<li>
%~list ~LET `~commaで分離された成分~値~listを構文解析する$( %入力 )
◎
Parse a comma-separated list of component values from input, and let list be the return value.
</li>
	<li>
%~list を成す
~EACH( %~item )
に対し
⇒
%~item を次の結果に置換する
⇒
`~CSS文法に則って構文解析する$( %~item, %生成規則 )
◎
For each item of list, replace item with the result of parsing item with grammar.
</li>
	<li>
~RET %~list
◎
Return list.
</li>
</ol>
</div>

			</section>
			<section id="parse-stylesheet">
<h4 title="Parse a stylesheet">5.4.3. ~stylesheetを構文解析する</h4>

<div class="algo">
<p>
`~stylesheetを構文解析する@
~algoは、
所与の
( %入力, `~URL$ %所在 （省略時は ~NULL ）)
に対し：
◎
To parse a stylesheet from an input given an optional url location:
</p>
<ol>
	<li>
~IF［
%入力 は ある~stylesheet用の~byte~streamである
］
⇒
%入力 ~SET `~stylesheetの~byte列を復号する$( %入力 )
◎
If input is a byte stream for a stylesheet, decode bytes from input, and set input to the result.
</li>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
%~stylesheet ~LET 新たな`~CSS~stylesheet$
— その
⇒＃
`所在$ss ~SET %所在
◎
Create a new stylesheet, with its location set to location (or null, if location was not passed).
</li>
	<li>
%~stylesheet の.規則~群 ~SET `~stylesheetの内容を消費する$( %入力 )
◎
Consume a stylesheet’s contents from input, and set the stylesheet’s rules to the result.
</li>
	<li>
~RET %~stylesheet
◎
Return the stylesheet.
</li>
</ol>
</div>

			</section>
			<section id="parse-stylesheet-contents">
<h4 title="Parse a stylesheet’s contents">5.4.4. ~stylesheetの内容を構文解析する</h4>

<div class="algo">
<p>
`~stylesheetの内容を構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a stylesheet’s contents from input:
</p>
<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
~RET `~stylesheetの内容を消費する$( %入力 )
◎
Consume a stylesheet’s contents from input, and return the result.
</li>
</ol>
</div>

			</section>
			<section id="parse-block-contents">
<h4 title="Parse a block’s contents">5.4.5. ~blockの内容を構文解析する</h4>

<div class="algo">
<p>
`~blockの内容を構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a block’s contents from input:
</p>
<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
~RET `~blockの内容を消費する$( %入力 )
◎
Consume a block’s contents from input, and return the result.
</li>
</ol>
</div>

			</section>
			<section id="parse-rule">
<h4 title="Parse a rule">5.4.6. 規則を構文解析する</h4>

<div class="algo">
<p>
`規則を構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a rule from input:
</p>

<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
~IF［
%入力 は`空$tSである【！`次回の~token$tS は `EOF$tok 】
］
⇒
~RET `構文~error^i
◎
If the next token from input is an &lt;EOF-token&gt;, return a syntax error.
</li>
	<li>
%規則 ~LET %入力 の`次回の~token$tS に応じて
⇒＃
`at-keyword$tok であるならば `~at-規則を消費する$( %入力 ) ／
~ELSE_ `有修飾~規則を消費する$( %入力 )
◎
Otherwise, if the next token from input is an &lt;at-keyword-token&gt;, consume an at-rule from input, and let rule be the return value.
◎
Otherwise, consume a qualified rule from input and let rule be the return value.＼
</li>
	<li>
~IF［
%規則 ~IN { ε, `妥当な規則でない$i }
］
⇒
~RET `構文~error^i
◎
If nothing or an invalid rule error was returned, return a syntax error.
</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
~IF［
%入力 は`空$tSである【！`次回の~token$tS は `EOF$tok 】
］
⇒
~RET %規則
◎
If the next token from input is an &lt;EOF-token&gt;, return rule.＼
</li>
	<li>
~RET `構文~error^i
◎
Otherwise, return a syntax error.
</li>
</ol>
</div>

			</section>
			<section id="parse-declaration">
<h4 title="Parse a declaration">5.4.7. 宣言を構文解析する</h4>

<p class="note">注記：
`~blockの内容を消費する$【！宣言~listを構文解析する$】ときと違って、
これは，宣言のみを構文解析する
— ~at-規則は構文解析しない。
◎
Note: Unlike "Parse a list of declarations", this parses only a declaration and not an at-rule.
</p>

<div class="algo">
<p>
`宣言を構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a declaration from input:
</p>

<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
%宣言 ~LET `宣言を消費する$( %入力 )
◎
Consume a declaration from input.＼
</li>
	<li>
~IF［
%宣言 ~NEQ ε
］
⇒
~RET %宣言
◎
If anything was returned, return it.＼
</li>
	<li>
~RET `構文~error^i
◎
Otherwise, return a syntax error.
</li>
</ol>
</div>

			</section>
			<section id="parse-component-value">
<h4 title="Parse a component value">5.4.8. 成分~値を構文解析する</h4>

<div class="algo">
<p>
`成分~値を構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a component value from input:
</p>

<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
~IF［
%入力 は`空$tSである
］
⇒
~RET `構文~error^i
◎
If input is empty, return a syntax error.
</li>
	<li>
%値 ~LET `成分~値を消費する$( %入力 )
◎
Consume a component value from input and let value be the return value.
</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
~IF［
%入力 は`空$tSである
］
⇒
~RET %値
◎
If input is empty, return value.＼
</li>
	<li>
~RET `構文~error^i
◎
Otherwise, return a syntax error.
</li>
</ol>
</div>

			</section>
			<section id="parse-list-of-component-values">
<h4 title="Parse a list of component values">5.4.9. 成分~値~listを構文解析する</h4>

<div class="algo">
<p>
`成分~値~listを構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a list of component values from input:
</p>

<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
~RET `成分~値~listを消費する$( %入力 )
◎
Consume a list of component values from input, and return the result.
</li>
</ol>
</div>

			</section>
			<section id="parse-comma-separated-list-of-component-values">
<h4 title="Parse a comma-separated list of component values">5.4.10. ~commaで分離された成分~値~listを構文解析する</h4>

<div class="algo">
<p>
`~commaで分離された成分~値~listを構文解析する@
~algoは、
所与の
( %入力 )
に対し：
◎
To parse a comma-separated list of component values from input:
</p>

<ol>
	<li>
%入力 ~SET `~token~streamに正規化する$( %入力 )
◎
Normalize input, and set input to the result.
</li>
	<li>
%~group群 ~LET 新たな`~list$
◎
Let groups be an empty list.
</li>
	<li>
<p>
~WHILE［
%入力 は`空$tSでない
］：
◎
While input is not empty:
</p>
		<ol>
			<li>
%~group群 に次の結果を`付加する$
⇒
`成分~値~listを消費する$( %入力, `comma$tok )
◎
Consume a list of component values from input, with &lt;comma-token&gt; as the stop token, and append the result to groups.
</li>
			<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.
</li>
		</ol>
	</li>
	<li>
~RET %~group群
◎
Return groups.
</li>
</ol>
</div>

			</section>
		</section>
		<section id="parser-algorithms">
<h3 title="Parser Algorithms">5.5. 構文解析器~algo</h3>

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

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

<p class="trans-note">【†
以下においては、
“現在の文脈において妥当である”
という句で指示される。
】</p>

			<section id="consume-stylesheet-contents">
<h4 title="Consume a stylesheet’s contents">5.5.1. ~stylesheetの内容を消費する</h4>

<div class="algo">
<p>
`~stylesheetの内容を消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a stylesheet’s contents from a token stream input:
</p>
<ol>
	<li>
%規則~群 ~LET 新たな`~list$
◎
Let rules be an initially empty list of rules.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
`whitespace$tok
⇒
%入力 から`~tokenを破棄する$tS
◎
&lt;whitespace-token&gt;
• Discard a token from input.
</li>
			<li>
`EOF$tok
⇒
~RET %規則~群
◎
&lt;EOF-token&gt;
• Return rules.
</li>
			<li>
<p>
`CDO$tok ／ `CDC$tok
⇒
%入力 から`~tokenを破棄する$tS
◎
&lt;CDO-token&gt;
&lt;CDC-token&gt;
• Discard a token from input.
</p>

<details class="note">
<summary>
これは何のためにある？
◎
What’s this for?
</summary>

<p>
~CSSが最初に導入された頃、
`style$e 要素は，
旧来の~browserにおいては未知な要素として扱われた。
それらの~browserにおいて，要素の内容が~page内に表示されるのを避けるため、
~stylesheetを~HTML~comment内に包装することが共通な実施になり、
より新たな~browserは，単純に~HTML~comment構文を無視するようになった。
この要件は、
数十年経た今日まで引き継がれている。
◎
Back when CSS was first being introduced, the style element was treated as an unknown element by older browsers. To avoid having its contents displayed in the page for these legacy browsers, it became common practice to wrap the stylesheet in an HTML comment, and newer browsers would simply ignore the HTML comment syntax. This requirement carries over to today, decades later.
</p>

<p>
同じ実施は、
`script$e 要素に対しても行われた
— 同じ理由から、
~JS内における~HTML~comment構文は，
（ `//^c に類似な）行l~commentとして扱われるようになった。
◎
The same practice was done for script elements, where HTML comment syntax is treated as a line comment in JS (similar to //) for the same reason.
</p>
</details>
			</li>
			<li>
<p>
`at-keyword$tok：
◎
&lt;at-keyword-token&gt;
</p>
				<ol>
					<li>
`~at-規則を消費する$( %入力 )
◎
Consume an at-rule from input.
</li>
					<li>
~IF［
%規則 ~NEQ ε
］
⇒
%規則~群 に %規則 を`付加する$
◎
If anything is returned, append it to rules. 
</li>
				</ol>
			</li>
			<li>
<p>
その他：
◎
anything else
</p>
				<ol>
					<li>
%規則 ~LET `有修飾~規則を消費する$( %入力 )
◎
Consume a qualified rule from input.＼
</li>
					<li>
~IF［
%規則 は`規則$である
］
⇒
%規則~群 に %規則 を`付加する$
◎
If a rule is returned, append it to rules.
</li>
				</ol>
			</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-at-rule">
<h4 title="Consume an at-rule">5.5.2. ~at-規則を消費する</h4>

<div class="algo">
<p>
`~at-規則を消費する@
~algoは、
所与の
( `~token~stream$ %入力, 真偽値 %入子か （省略時は ~F ） )
に対し：
◎
To consume an at-rule from a token stream input, given an optional bool nested (default false):
</p>
<ol>
	<li>
~Assert：
`次回の~token$tSは `at-keyword$tok である。
◎
Assert: The next token is an &lt;at-keyword-token&gt;.
</li>
	<li>
%~token ~LET %入力 から`~tokenを消費する$tS
◎
Consume a token from input,＼
</li>
	<li>
%規則 ~LET 新たな`~at-規則$
— その
⇒＃
.名前 ~SET %~token の.値,
.導入部 ~SET 新たな`~list$,
.宣言~群 ~SET ε,
.子~規則~群 ~SET ε
◎
and let rule be a new at-rule with its name set to the returned token’s value, its prelude initially set to an empty list, and no declarations or child rules.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
<p>
`semicolon$tok ／ `EOF$tok：
◎
&lt;semicolon-token&gt;
◎
&lt;EOF-token&gt;
</p>
				<ol>
					<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.＼
</li>
					<li>
~IF［
%規則 は現在の文脈において妥当である
］
⇒
~RET %規則
◎
If rule is valid in the current context, return it;＼
</li>
					<li>
~RET ε
◎
otherwise return nothing.
</li>
				</ol>
			</li>
			<li>
<p>
`close-curly$Tok：
◎
&lt;}-token&gt;
</p>
				<ol>
					<li>
<p>
~IF［
%入子か ~EQ ~T
］：
◎
If nested is true:
</p>
						<ol>
							<li>
~IF［
%規則 は現在の文脈において妥当である
］
⇒
~RET %規則
◎
If rule is valid in the current context, return it.
</li>
							<li>
~RET ε
◎
Otherwise, return nothing.
</li>
						</ol>
					</li>
					<li>
%規則 の.導入部に次の結果を`付加する$
⇒
%入力 から`~tokenを消費する$tS
◎
Otherwise, consume a token and append the result to rule’s prelude.
</li>
				</ol>
			</li>
			<li>
<p>
`open-curly$Tok：
◎
&lt;{-token&gt;
</p>
				<ol>
					<li>
<p>
%規則 の.子~規則~群 ~SET `~blockを消費する$( %入力 )
◎
Consume a block from input, and assign the result to rule’s child rules.
</p>

<p class="note">注記：
結果が`宣言$たちが成す`~list$を包含する場合、
それらが~CSSOMにおいて どう実体化されるかは，当の規則に依存する。
すべてを`入子な宣言~列が成す規則$の中へ包装する場合も，
すべてを宣言として扱う場合も，
最初の~itemと他の~itemの扱いを違える場合もある。
◎
Note: If the result contains lists of declarations, how they’re materialized in the CSSOM depends on the rule. Some turn them all into nested declarations rules, others will treat them all as declarations, and others will treat the first item differently from the rest.
</p>

<p class="trans-note">【
%規則 の.宣言~群 をどう初期化するか，~algoの中では明示的に指定されていない
— この注記に従って，適切に初期化することが意図される？
】</p>
					</li>
					<li>
~IF［
%規則 は現在の文脈において妥当である
］
⇒
~RET %規則
◎
If rule is valid in the current context, return it.＼
</li>
					<li>
~RET ε
◎
Otherwise, return nothing.
</li>
				</ol>
			</li>
			<li>
その他
⇒
%規則 の.導入部に次の結果を`付加する$
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input and append the returned value to rule’s prelude.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-qualified-rule">
<h4 title="Consume a qualified rule">5.5.3. 有修飾~規則を消費する</h4>

<div class="algo">
<p>
`有修飾~規則を消費する@
~algoは、
所与の
( `~token~stream$ %入力, ~token %停止-~token （省略時は ε ）, 真偽値 %入子か （省略時は ~F ） )
に対し：
◎
To consume a qualified rule, from a token stream input, given an optional token stop token and an optional bool nested (default false):
</p>
<ol>
	<li>
%導入部 ~LET 新たな`~list$
◎
↓↓ Let rule be a new qualified rule with its prelude, declarations, and child rules all initially set to empty lists.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
<p>
`EOF$tok ／
%停止-~token（ ~NEQ ε )
◎
&lt;EOF-token&gt;
stop token (if passed)
</p>
				<ol>
					<li>
`構文解析error$
◎
This is a parse error.＼
</li>
					<li>
~RET ε
◎
Return nothing.＼
</li>
				</ol>
			</li>
			<li>
<p>
`close-curly$Tok：
◎
&lt;}-token&gt;
</p>
				<ol>
					<li>
`構文解析error$
◎
This is a parse error.＼
</li>
					<li>
~IF［
%入子か ~EQ ~T
］
⇒
~RET ε
◎
If nested is true, return nothing.＼
</li>
					<li>
%導入部 に次の結果を`付加する$
⇒
%入力 から`~tokenを消費する$tS
◎
Otherwise, consume a token and append the result to rule’s prelude. 
</li>
				</ol>
			</li>
			<li>
<p>
`open-curly$Tok：
◎
&lt;{-token&gt;
</p>
				<ol>
					<li>
<p>
~IF［
%導入部 の中に
`whitespace$tok でないものが 2 個~以上あって，それらのうち最初の 2 個は順に次を満たす
］…
◎
If the first two non-&lt;whitespace-token&gt; values of rule’s prelude are＼
</p>
				<ol>
					<li>
`ident$tok であって，その.値は `--^l から開始している
◎
an &lt;ident-token&gt; whose value starts with "--"＼
</li>
					<li>
`colon$tok である
◎
followed by a &lt;colon-token&gt;,＼
</li>
				</ol>
<p>
…ならば：
◎
then:＼
</p>
				<ol>
					<li>
~IF［
%入子か ~EQ ~T
］
⇒
`不良な宣言の残余を消費する$( %入力, ~T )
◎
If nested is true, consume the remnants of a bad declaration from input, with nested set to true, and return nothing.
</li>
					<li>
~ELSE
⇒
`~blockを消費する$( %入力 )
◎
If nested is false, consume a block from input, and return nothing.
</li>
					<li>
~RET ε
◎
↑</li>
				</ol>

<details class="note">
<summary>
この検査は何のためにある？
◎
What’s this check for?
</summary>

<p>
`一般に^em、［
`宣言$に許容される構文,
`有修飾~規則$に許容される構文
］が重合することはない。
現時点で定義-済みな~CSS~propには，その値~内に`波括弧~block$を許容するものは無いので、
`foo:bar {};^css は確定的に規則であり，
`foo: bar;^css は確定的に~propである。
将来の~CSS~propが その値~内に`波括弧~block$を許容する場合でも、
それに許容される構文は
— `foo: {...};^css のように —
`波括弧~block$が値~全体を成すよう制約される。
それは、
妥当な規則にならないことが保証される
— `:^css に~identや関数が後続して，それを疑似類として~markすることは、
ないので。
◎
Declarations and qualified rules don’t generally overlap in their allowed syntax. No currently-defined CSS property allows {}-blocks in its value, so foo:bar {}; is definitely a rule, and foo: bar; is definitely a property. Even if a future CSS property allows {}-blocks in its value, the allowed syntax is restricted to the {}-block being the whole value, such as foo: {...};, which is guaranteed to not be a valid rule, since the : doesn’t have an ident or function following it to mark it as a pseudo-class.
</p>

<p>
このことは、
同じ文脈~内に宣言と規則を混合することを許容する。
まずは、
何かを宣言として構文解析するよう試行してから、
その結果が妥当な宣言でない場合には，代わりに規則として構文解析し直す。
偶発的に無効になる宣言は，
代わりに規則として構文解析されることになるが、
~~不都合はない。
構文解析器は、
宣言を終端している~semicolonの所で停止して，
それを無効な規則と見なすことになる
（あるいは，~propが`波括弧~block$を包含している事例でも、
当の~semicolonの`直前^emで停止して，
それを無効な規則と見なしてから、
何かを構文解析する次回の試みにおいて，
当の~semicolonを無効なものとして棄てることになる）。
なので、
消費される~tokenの総数は，いずれにせよ同じになる。
◎
This allows us to mix declarations and rules in the same context: we first try to parse something as a declaration, and if that doesn’t result in a valid declaration, we reparse it as a rule instead. An accidentally-invalid declaration will parse as a rule instead, but that’s fine: the parser will stop at the declaration’s ending semicolon and consider it an invalid rule. (Or in the case of a property containing a {}-block, will stop just *before* the semicolon, still considering it an invalid rule, and then the next attempt to parse something will throw out the lone semicolon as invalid.) So the total amount of tokens consumed is the same regardless.
</p>

<p>
しかしながら，`~custom~prop$の構文に対しては、
~CSS~WGは，注意深く審査しない。
作者は、
値に`波括弧~block$を含んでいる~custom~propを`書ける^em
— ~blockを他と組合せて書くことも。
そのような~custom~propが妥当でない場合
（例えば， `var$f 関数が妥当に記されなかったことに因り）、
それが規則として構文解析し直されるとき，
`波括弧~block$の所で早々に停止することになる。
~custom~propの値を成す残りの~tokenたちは、
新規な構成子として構文解析され，期待されない［
宣言／規則
］を作成させることにもなり得る。
◎
Custom properties, however, don’t have the CSSWG carefully vetting their syntax. Authors can write a custom property that takes a {}-block in its value, even combined with other things; if that custom property is then invalid (due to an invalidly-written var() function, for example), when it’s reparsed as a rule it will stop early, at the {}-block. The remaining tokens of the custom property’s value will then get parsed as a fresh construct, potentially causing unexpected declarations or rules to be created.
</p>

<p>
この（ごく~nicheではあるが）際どい事例を避けるため、
`~custom~prop$の構文は，`有修飾~規則$の構文から除かれる。
~propと規則を混合することを許容する文脈において，
`~custom~prop$の様な見かけの規則が どういうわけか構文解析された場合、
どこかで間違っている
— 代わりに、
~custom~prop全体（それを終端している~semicolonまでを成すすべて）を消費する必要がある。
◎
To avoid this (admittedly very niche) corner-case, we subtract the syntax of a custom property from that of a qualified rule; if you’re in a context that allows properties and rules to be mixed, and you somehow end up parsing a rule that looks like a custom property, you’ve messed up, and need to instead consume an entire custom property (all the way to the ending semicolon).
</p>

<p>
（~propを許容しない文脈においては、
~custom~propの様な見かけになる規則は，ただ棄てられるだけである。
これは、
`--foo:hover { color: blue; }^css が，
どこでも一貫して無効になることを確保する
— それを終端させる存在しない~semicolonを探すために，~stylesheetを~~際限なく消費することはない。）
◎
(If we’re in a context that doesn’t allow properties, we just throw away the rule if it looks like a custom property. This ensures that --foo:hover { color: blue; } is consistently invalid everywhere, without potentially consuming a ton of a stylesheet looking for the non-existent ending semicolon.)
</p>
</details>
					</li>
					<li>
%規則 ~LET 新たな`有修飾~規則$
— その
⇒＃
.導入部 ~SET %導入部,
.宣言~群 ~SET 新たな`~list$,
.子~規則~群 ~SET 新たな`~list$
◎
↑↑</li>
					<li>
%子~規則~群 ~LET `~blockを消費する$( %入力 )
◎
Otherwise, consume a block from input, and let child rules be the result.＼
</li>
					<li>
<p>
~IF［
%子~規則~群 は空でない
【この条件は，この訳による補完】
］：
</p>
						<ol>
							<li>
<p>
~IF［
%子~規則~群[ 0 ] は`宣言$たちが成す`~list$である
］：
</p>
								<ol>
									<li>
%規則 の.宣言~群 ~SET %子~規則~群[ 0 ]
</li>
									<li>
%子~規則~群 から %子~規則~群[ 0 ] を`除去する$
</li>
								</ol>
◎
If the first item of child rules is a list of declarations, remove it from child rules and assign it to rule’s declarations.＼
</li>
							<li>
<p>
%子~規則~群 を成す
~EACH( %子~規則 )
に対し：
</p>
								<ol>
									<li>
~IF［
%子~規則 は`宣言$たちが成す`~list$である
］
⇒
%子~規則 ~SET %子~規則 を包装する新たな`入子な宣言~列が成す規則$
</li>
									<li>
%規則 の.子~規則~群 に %子~規則 を`付加する$
</li>
								</ol>
◎
If any remaining items of child rules are lists of declarations, replace them with nested declarations rules containing the list as its sole child. Assign child rules to rule’s child rules.
</li>
						</ol>
					</li>
					<li>
~IF［
%規則 は現在の文脈において妥当である
］
⇒
~RET %規則
◎
If rule is valid in the current context, return it;＼
</li>
					<li>
~RET `妥当な規則でない@i
◎
otherwise return an invalid rule error.
</li>
				</ol>
			</li>
			<li>
その他
⇒
%導入部 に次の結果を`付加する$
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input and append the result to rule’s prelude.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-block">
<h4 title="Consume a block">5.5.4. ~blockを消費する</h4>

<div class="algo">
<p>
`~blockを消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a block, from a token stream input:
</p>
<ol>
	<li>
~Assert：
`次回の~token$tSは `open-curly$Tok である
◎
Assert: The next token is a &lt;{-token&gt;.
</li>
	<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.＼
</li>
	<li>
%規則~群 ~LET `~blockの内容を消費する$( %入力 )
◎
Consume a block’s contents from input and let rules be the result.＼
</li>
	<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.
</li>
	<li>
~RET %規則~群
◎
Return rules.
</li>
</ol>
</div>

			</section>
			<section id="consume-block-contents">
<h4 title="Consume a block’s contents">5.5.5. ~blockの内容を消費する</h4>

<div class="algo">
<p>
`~blockの内容を消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a block’s contents from a token stream input:
</p>

<p class="note">注記：
この~algoは、［
`宣言$たちが成す~list／`規則$
］たちが成す新たな`~list$（ %規則~群 ）を返す。
各［
`宣言$たちが成す`~list$
］は、
~CSSOMにおいては，親の文脈に依存して
`CSSStyleDeclaration$I として実体化されることも,
`CSSNestedDeclarations$I として実体化されることもある。
◎
Note: This algorithm returns a list, consisting of rules and lists of declarations. Depending on the parent context, a list of declarations might be materialized in the CSSOM as either a CSSStyleDeclaration, or as a CSSNestedDeclarations rule.
</p>

<ol>
	<li>
%規則~群 ~LET 新たな`~list$
◎
Let rules be an empty list, containing either rules or lists of declarations.
</li>
	<li>
%宣言~群 ~LET 新たな`~list$
（`宣言$たち）
◎
Let decls be an empty list of declarations.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
`whitespace$tok ／ `semicolon$tok
⇒
%入力 から`~tokenを破棄する$tS
◎
&lt;whitespace-token&gt;
&lt;semicolon-token&gt;
• Discard a token from input.
</li>
			<li>
`EOF$tok ／ `close-curly$Tok
⇒
~RET %規則~群
◎
&lt;EOF-token&gt;
&lt;}-token&gt;
• Return rules.
</li>
			<li>
<p>
`at-keyword$tok：
◎
&lt;at-keyword-token&gt;
</p>
				<ol>
					<li>
<p>
~IF［
%宣言~群 は空でない
］：
</p>
						<ol>
							<li>
%規則~群 に %宣言~群 を`付加する$
</li>
							<li>
%宣言~群 ~SET 新たな`~list$
</li>
						</ol>
◎
If decls is not empty, append it to rules, and set decls to a fresh empty list of declarations.
</li>
					<li>
%規則 ~LET `~at-規則を消費する$( %入力, ~T )
◎
Consume an at-rule from input, with nested set to true.＼
</li>
					<li>
~IF［
%規則 は`規則$である
］
⇒
%規則~群 に %規則 を`付加する$
◎
If a rule was returned, append it to rules.
</li>
				</ol>
			</li>
			<li>
<p>
その他：
◎
anything else
</p>
				<ol>
					<li>
%入力 を`~markする$tS
◎
Mark input.
</li>
					<li>
%宣言 ~LET `宣言を消費する$( %入力, ~T )
◎
Consume a declaration from input, with nested set to true.＼
</li>
					<li>
<p>
~IF［
%宣言 ~NEQ ε【！`宣言$である】
］
◎
If a declaration was returned,＼
</p>
						<ol>
							<li>
%宣言~群 に %宣言 を`付加する$
◎
append it to decls,＼
</li>
							<li>
%入力 から`~markを破棄する$tS
◎
and discard a mark from input.
</li>
						</ol>
					</li>
					<li>
<p>
~ELSE：
◎
Otherwise,＼
</p>
						<ol>
							<li>
%入力 から`~markを復旧する$tS
◎
restore a mark from input,＼
</li>
							<li>
%規則 ~LET `有修飾~規則を消費する$( %入力, `semicolon$tok, ~T )
◎
then consume a qualified rule from input, with nested set to true, and &lt;semicolon-token&gt; as the stop token.
</li>
							<li>
<p>
~IF［
%規則 ~NEQ ε
］：
</p>
								<ol>
									<li>
~Assert：
%規則 は`規則$であるか `妥当な規則でない$i
</li>
									<li>
<p>
~IF［
%宣言~群 は空でない
］：
</p>
										<ol>
											<li>
%規則~群 に %宣言~群 を`付加する$
</li>
											<li>
%宣言~群 ~SET 新たな`~list$
</li>
										</ol>
									</li>
									<li>
~IF［
%規則 は`規則$である
］
⇒
%規則~群 に`規則$を`付加する$
</li>
								</ol>
◎
If nothing was returned
• Do nothing
◎
If an invalid rule error was returned
• If decls is not empty, append decls to rules, and set decls to a fresh empty list of declarations. (Otherwise, do nothing.)
◎
If a rule was returned
• If decls is not empty, append decls to rules, and set decls to a fresh empty list of declarations. Append the rule to rules.
</li>
						</ol>
					</li>
				</ol>
			</li>
		</ul>
	</li>
</ol>
</div>

<details class="note">
<summary>
実装~向けの注記
◎
Implementation note
</summary>

<p>
この仕様は、
他の多くの~CSS仕様と同じく，
効率より理解し易さを優先するよう書かれた。
いくつかの~algo
— 特に，上述した
“宣言として構文解析してから，規則 として構文解析する”
挙動 —
は、
述べられたとおり，素朴に実装された場合に効率が悪くなり得る。
◎
This spec, as with many CSS specs, has been written to prioritize understandability over efficiency. A number of algorithms, notably the above "parse as a declaration, then parse as a rule" behavior can be fairly inefficient if implemented naively as described.
</p>

<p>
しかしながら，この挙動は、
アリな限り “早々な退出” を許容するよう，注意深く書かれた。
特に，これらの退出は、
概ね次に挙げる順序で生じ得る：
◎
However, the behavior has been carefully written to allow "early exits" as much as possible. In particular, and roughly in order of when the exit can occur:
</p>
<ul>
	<li>
<p>
1 個目の非~空白~token【非 `whitespace$tok 】が［
認識される~prop名（または~custom~prop名）用の `ident$tok
］ではない場合、
宣言として構文解析することを即時に停止して，
代わりに規則として構文解析し直せる。
類似に，
`2 個目の^em 非~空白~tokenは `colon$tok でない場合、
宣言として構文解析することを即時に停止できる。
◎
If the first non-whitespace token isn’t an &lt;ident-token&gt; for a recognized property name (or a custom property name), you can immediately stop parsing as a declaration and reparse as a rule instead. If the next non-whitespace token isn’t a &lt;colon-token&gt;, you can similarly immediately stop parsing as a declaration.
</p>

<p>
（すなわち，
`font+ ...^css は、
~propでも `not-a-prop-name: ...^css
でもないことが保証される。）
◎
(That is, font+ ... is guaranteed to not be a property, nor is not-a-prop-name: ....)
</p>
	</li>
	<li>
<p>
1 個目, 2 個目の非~空白~tokenが，順に［
~custom~prop名, ~colon
］である場合、
それは，確定的に~custom~propである
— それは，妥当な規則を生産し得ないので、
当の~custom~propとして妥当でない場合でも，
規則として構文解析し直すよう試行する必要は無い。
◎
If the first two non-whitespace tokens are a custom property name and a colon, it’s definitely a custom property and won’t ever produce a valid rule, so even if the custom property ends up invalid there’s no need to try and reparse as a rule.
</p>

<p>
（すなわち，
`--foo:hover {...}^css は、
規則ではなく~custom~propであることが保証される。）
◎
(That is, --foo:hover {...} is guaranteed to be a custom property, not a rule.)
</p>
	</li>
	<li>
<p>
1 個目, 2 個目, 3 個目の非~空白~tokenが，順に［
妥当な~prop名,
~colon,
`open-curly$Tok 以外
］であり，当の宣言の値を構文解析している間に
`open-curly$Tok に遭遇した場合、
宣言として構文解析することを即時に停止して，
代わりに規則として構文解析し直せる。
◎
If the first three non-whitespace tokens are a valid property name, a colon, and anything other than a &lt;{-token&gt;, and then while parsing the declaration’s value you encounter a &lt;{-token&gt;, you can immediately stop parsing as a declaration and reparse as a rule instead.
</p>

<p>
（すなわち，
`font:bar {...^css は、
無効な~propになることが保証される。）
◎
(That is, font:bar {... is guaranteed to be an invalid property.)
</p>
	</li>
	<li>
<p>
［
認識される~prop名,
~colon,
`波括弧~block$
］が成す並びに出くわしたが，
その~blockに後続している非~空白~tokenのうち［
1 個目は~semicolonでない
］かつ［
1 個目, 2 個目は順に［
`!important^css, ~semicolon
］ではない
］場合、
宣言として構文解析することを即時に停止して，
代わりに規則として構文解析し直せる。
◎
If you see a recognized property name, a colon, and a {}-block, but the first non-whitespace tokens following that block isn’t either immediately the final semicolon, or the !important followed by the semicolon, you can immediately stop parsing as a declaration and reparse as a rule instead.
</p>

<p>
（すなわち，
`font: {} bar ...^css は、
無効な~propになることが保証され，
~semicolonに出くわすまで構文解析し続ける必要は無い。）
◎
(That is, font: {} bar ... is guaranteed to be an invalid property; you don’t need to keep parsing until you hit a semicolon.)
</p>
	</li>
</ul>

<p>
類似に，構文解析~要件が［
構文解析する際に，当の宣言の文法を検査することに依拠する
］よう指定されたとしても、
汎用な~CSS`構文^emの上層に非~CSS言語を実装するよう試行している`汎用^emな処理器は，当の宣言が［
~ident, ~colon
］から開始していて，［
`波括弧~block$と他の何かを同時に包含しない
］ことを検証yするだけで済ませられる。
それらは，
`foo:hover ... {}^css の様な事例においては、
1 個目の~tokenで早々に退出し得ないので，
文法~知識を有する実装よりも少しだけ構文解析に時間を費やすことになるが。
◎
Similarly, even tho the parsing requirements are specified to rely on checking the grammar of the declarations as you parse, a generic processor trying to implement a non-CSS language on top of the generic CSS syntax can still get away with just verifying that declarations start with an ident, a colon, and then either contain solely a {}-block or no {}-block at all. They’ll just spent a little more time on parsing than an implementation with grammar knowledge in cases like foo:hover ... {}, since they can’t early-exit on the first token.
</p>
</details>

			</section>
			<section id="consume-declaration">
<h4 title="Consume a declaration">5.5.6. 宣言を消費する</h4>

<div class="algo">
<p>
`宣言を消費する@
~algoは、
所与の
( `~token~stream$ %入力, 真偽値 %入子か （省略時は ~F ） )
に対し：
◎
To consume a declaration from a token stream input, given an optional bool nested (default false):
</p>
<ol>
	<li>
%宣言 ~LET 新たな`宣言$
— その
⇒＃
.名前 ~SET 空~文字列,
.値 ~SET 新たな`~list$
.元の~text ~SET ε
.~importantか ~SET ~F
◎
Let decl be a new declaration, with an initially empty name and a value set to an empty list.
</li>
	<li>
<p>
~IF［
`次回の~token$tSは `ident$tok である
］：
◎
If the next token is an &lt;ident-token&gt;,＼
</p>
		<ol>
			<li>
%~token ~LET %入力 から`~tokenを消費する$tS
◎
consume a token from input and＼
</li>
			<li>
%宣言 の.名前 ~SET %~token の.値
◎
set decl’s name to the token’s value.
</li>
		</ol>
	</li>
	<li>
<p>
~ELSE：
◎
Otherwise,＼
</p>
		<ol>
			<li>
`不良な宣言の残余を消費する$( %入力, %入子か )
◎
consume the remnants of a bad declaration from input, with nested,＼
</li>
			<li>
~RET ε
◎
and return nothing.
</li>
		</ol>
	</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
~IF［
`次回の~token$tSは `colon$tok である
］
⇒
%入力 から`~tokenを破棄する$tS
◎
If the next token is a &lt;colon-token&gt;, discard a token from input.
</li>
	<li>
<p>
~ELSE：
◎
Otherwise,＼
</p>
		<ol>
			<li>
`不良な宣言の残余を消費する$( %入力, %入子か )
◎
consume the remnants of a bad declaration from input, with nested,＼
</li>
			<li>
~RET ε
◎
and return nothing.
</li>
		</ol>
	</li>
	<li>
%入力 から`空白を破棄する$tS
◎
Discard whitespace from input.
</li>
	<li>
%宣言 の.値 ~SET `成分~値~listを消費する$( %入力, `semicolon$tok, %入子か )
◎
Consume a list of component values from input, with nested, and with &lt;semicolon-token&gt; as the stop token, and set decl’s value to the result.
</li>
	<li>
%元の~text ~LET 前~段にて消費された， %入力 を成す文字列
◎
↓</li>
	<li>
<p>
~IF［
%宣言 の.値の中に `whitespace$tok でないものが 2 個~以上あって，それらのうち最後の 2 個は順に次を満たす
］…
◎
If the last two non-&lt;whitespace-token&gt;s in decl’s value are＼
</p>
		<ol>
			<li>
［
`delim$tok である
］~AND［
その.値 ~EQ `21^U
］
◎
a &lt;delim-token&gt; with the value "!"＼
</li>
			<li>
［
`ident$tok である
］~AND［
その.値 ~EQ`大小無視$sub `important^l
］
◎
followed by an &lt;ident-token&gt; with a value that is an ASCII case-insensitive match for "important",＼
</li>
		</ol>
<p>
…ならば：
◎
＼
</p>
		<ol>
			<li>
その 2 個の~tokenを %宣言 の.値から`除去する$
◎
remove them from decl’s value＼
</li>
			<li>
%宣言 の.~importantか ~SET ~T
◎
and set decl’s important flag.
</li>
		</ol>
	</li>
	<li>
~WHILE［
%宣言 の.値を成す最後の~itemは `whitespace$tok である
］
⇒
%宣言 の.値から最後の~itemを`除去する$
◎
While the last item in decl’s value is a &lt;whitespace-token&gt;, remove that token.
</li>
	<li>
~IF［
%宣言 の.名前は`~custom~prop名~文字列$である
］
⇒
%宣言 の.元の~text ~SET %元の~text
【！corresponding to the tokens of decl’s value】
◎
If decl’s name is a custom property name string, then set decl’s original text to the segment of the original source text string corresponding to the tokens of decl’s value.
</li>
	<li>
<p>
~ELIF［
%宣言 の.値は、
~top-levelの`波括弧~block$に`加えて^em 非 `whitespace$tok を包含する
］
⇒
~RET ε
◎
Otherwise, if decl’s value contains a top-level simple block with an associated token of &lt;{-token&gt;, and also contains any other non-&lt;whitespace-token&gt; value, return nothing.＼
</p>

<p>
（すなわち、
~top-levelの`波括弧~block$は，非~custom~propの値~全体を成す場合に限り許容される。）
◎
(That is, a top-level {}-block is only allowed as the entire value of a non-custom property.)
</p>
	</li>
	<li>
~ELIF［
%宣言 の.名前は `~ASCII大小無視$で `unicode-range^l に合致する
］
⇒
%宣言 の.値 ~SET `~unicode-range記述子の値を消費する$( %元の~text )
◎
Otherwise, if decl’s name is an ASCII case-insensitive match for "unicode-range", consume the value of a unicode-range descriptor from the segment of the original source text string corresponding to the tokens returned by the consume a list of component values call, and replace decl’s value with the result.
</li>
	<li>
~IF［
%宣言 は現在の文脈において妥当である
］
⇒
~RET %宣言
◎
If decl is valid in the current context, return it;＼
</li>
	<li>
~RET ε
◎
otherwise return nothing.
</li>
</ol>
</div>

<div class="algo">
<p>
`不良な宣言の残余を消費する@
~algoは、
所与の
( `~token~stream$ %入力, 真偽値 %入子か )
に対し：
◎
To consume the remnants of a bad declaration from a token stream input, given a bool nested:
</p>
<ol>
	<li>
<p>
%入力 を`処理する$tS：
◎
process input:
</p>
		<ul class="switch">
			<li>
<p>
`EOF$tok ／ `semicolon$tok：
◎
&lt;eof-token&gt;
&lt;semicolon-token&gt;
</p>
				<ol>
					<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input,＼
</li>
					<li>
~RET ε
◎
and return nothing.
</li>
				</ol>
			</li>
			<li>
<p>
`close-curly$Tok：
◎
&lt;}-token&gt;
</p>
				<ol>
					<li>
~IF［
%入子か ~EQ ~T
］
⇒
~RET ε
◎
If nested is true, return nothing.＼
</li>
					<li>
%入力 から`~tokenを破棄する$tS
◎
Otherwise, discard a token.
</li>
				</ol>
			</li>
			<li>
その他
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input, and do nothing.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-list-of-components">
<h4 title="Consume a list of component values">5.5.7. 成分~値~listを消費する</h4>

<div class="algo">
<p>
`成分~値~listを消費する@
~algoは、
所与の
( `~token~stream$ %入力, ~token %停止-~token （省略時は ε ）, 真偽値 %入子か （省略時は ~F ） )
に対し：
◎
To consume a list of component values from a token stream input, given an optional token stop token and an optional boolean nested (default false):
</p>
<ol>
	<li>
%値~群 ~LET 新たな`~list$
（`成分~値$たち）
◎
Let values be an empty list of component values.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
`EOF$tok ／
%停止-~token（ ~NEQ ε )
⇒
~RET %値~群
◎
&lt;eof-token&gt;
stop token (if passed)
• Return values.
</li>
			<li>
<p>
`close-curly$Tok：
◎
&lt;}-token&gt;
</p>
				<ol>
					<li>
<p>
~IF［
%入子か ~EQ ~T
］
⇒
~RET %値~群
◎
If nested is true, return values.
</li>
					<li>
`構文解析error$
◎
Otherwise, this is a parse error.＼
</li>

					<li>
%値~群 に次の結果を`付加する$
⇒
%入力 から`~tokenを消費する$tS
◎
Consume a token from input and append the result to values.
</li>
				</ol>
			</li>
			<li>
その他
⇒
%値~群 に次の結果を`付加する$
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input, and append the result to values.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-component-value">
<h4 title="Consume a component value">5.5.8. 成分~値を消費する</h4>

<div class="algo">
<p>
`成分~値を消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a component value from a token stream input:
</p>
<ol>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
`open-curly$Tok ／ `open-square$Tok ／ `open-paren$Tok
⇒
~RET `単純~blockを消費する$( %入力 )
◎
&lt;{-token&gt;
&lt;[-token&gt;
&lt;(-token&gt;
• Consume a simple block from input and return the result.
</li>
			<li>
`function$tok
⇒
~RET `関数を消費する$( %入力 )
◎
&lt;function-token&gt;
• Consume a function from input and return the result.
</li>
			<li>
その他
⇒
~RET %入力 から`~tokenを消費する$tS
◎
anything else
• Consume a token from input and return the result.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-simple-block">
<h4 title="Consume a simple block">5.5.9. 単純~blockを消費する</h4>

<div class="algo">
<p>
`単純~blockを消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a simple block from a token stream input:
</p>
<ol>
	<li>
%始端~token ~LET %入力 の`次回の~token$tS
◎
↓</li>
	<li>
~Assert：
%始端~token は次に挙げるいずれかである
⇒＃
`open-curly$Tok,
`open-square$Tok,
`open-paren$Tok
◎
Assert: the next token of input is &lt;{-token&gt;, &lt;[-token&gt;, or &lt;(-token&gt;.
</li>
	<li>
%終端ng~token ~LET %始端~token に応じて
⇒＃
`open-curly$Tok ならば `close-curly$Tok ／
`open-square$Tok ならば `close-square$Tok ／
`open-paren$Tok ならば `close-paren$Tok
◎
Let ending token be the mirror variant of the next token. (E.g. if it was called with &lt;[-token&gt;, the ending token is &lt;]-token&gt;.)
</li>
	<li>
%~block ~LET 新たな`単純~block$
— その
⇒＃
.開き括弧 ~SET %始端~token,
.値 ~SET 新たな`~list$
◎
Let block be a new simple block with its associated token set to the next token and with its value initially set to an empty list.
</li>
	<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
<p>
`EOF$tok ／ %終端ng~token：
◎
&lt;eof-token&gt;
ending token
</p>
				<ol>
					<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.＼
</li>
					<li>
~RET %~block
◎
Return block.
</li>
				</ol>
			</li>
			<li>
その他
⇒
%~block の.値に次の結果を`付加する$
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input and append the result to block’s value.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>
			<section id="consume-function">
<h4 title="Consume a function">5.5.10. 関数を消費する</h4>

<div class="algo">
<p>
`関数を消費する@
~algoは、
所与の
( `~token~stream$ %入力 )
に対し：
◎
To consume a function from a token stream input:
</p>
<ol>
	<li>
~Assert：
`次回の~token$tS は `function$tok である
◎
Assert: The next token is a &lt;function-token&gt;.
</li>
	<li>
%~token ~LET %入力 から`~tokenを消費する$tS
◎
Consume a token from input,＼
</li>
	<li>
%関数 ~LET 新たな`関数$
— その
⇒＃
.名前 ~SET %~token の.値,
.値 ~SET 新たな`~list$
◎
and let function be a new function with its name equal the returned token’s value, and a value set to an empty list.
</li>
	<li>
<p>
%入力 を`処理する$tS：
◎
Process input:
</p>
		<ul class="switch">
			<li>
<p>
`EOF$tok ／ `close-paren$Tok：
◎
&lt;eof-token&gt;
&lt;)-token&gt;
</p>
				<ol>
					<li>
%入力 から`~tokenを破棄する$tS
◎
Discard a token from input.＼
</li>
					<li>
~RET %関数
◎
Return function.
</li>
				</ol>
			</li>
			<li>
その他
⇒
%関数 の.値に次の結果を`付加する$
⇒
`成分~値を消費する$( %入力 )
◎
anything else
• Consume a component value from input and append the result to function’s value.
</li>
		</ul>
	</li>
</ol>
</div>

			</section>

			<section id="consume-unicode-range-value">
<h4 title="Consume a unicode-range value">5.5.11. `unicode-range$d 値を消費する</h4>


<div class="algo">
<p>
`~unicode-range記述子の値を消費する@
~algoは、
所与の
( 文字列 %入力~文字列 )
に対し：
◎
To consume the value of a unicode-range descriptor from a string input string:
</p>
<ol>
	<li>
%~token群 ~LET 新たな`~token~stream$
◎
↓</li>
	<li>
`符号位置~streamを~token化する$( %入力~文字列, %~token群, ~T )
◎
Let tokens be the result of tokenizing input string with unicode ranges allowed set to true. Let input be a new token stream from tokens.
</li>
	<li>
~RET `成分~値~listを消費する$( %~token群 )
◎
Consume a list of component values from input, and return the result.
</li>
</ol>
</div>

<p class="note">注記：
この~algoは、
早期~CSSにおける［
決して再生産されるべきでない設計の過ち
］に因り存在する。
◎
Note: The existence of this algorithm is due to a design mistake in early CSS. It should never be reproduced.
</p>

			</section>
		</section>
	</section>
	<section id="anb-microsyntax">
<h2 title="The An+B microsyntax">6. ~AnB 小構文</h2>

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

<p>
`~AnB@
記法を成す整数［
%A は
`周期@
／
%B は
`~offset@
］を定義する。
それは、
負でない あらゆる整数 %n に対する［
~list内の ( %A × %n + %B ) 個目の要素
］を表現する
（ 0 ではなく 1 から数える）。
◎
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).
</p>

<p>
%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.
</p>

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

<div class="example">
<p>
◎
Examples:
</p>

<pre class="lang-css">
2n+0   /* <span class="comment">
~list内の偶数個目の要素すべてを表現する
◎
represents all of the even elements in the list
</span> */
even   /* <span class="comment">
同じ
◎
same
</span> */
4n+1   /* <span class="comment">
~list内の［ 1, 5, 9, 13, …］個目の要素すべてを表現する
◎
represents the 1st, 5th, 9th, 13th, etc. elements in the list
</span> */
</pre>
</div>

<p>
%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.
</p>

<div class="example">
<p>
◎
Example:
</p>

<pre class="lang-css">
-1n+6   /* <span class="comment">
~list内の最初から 6 個までの要素を表現する
◎
represents the first 6 elements of the list
</span> */
-4n+10  /* <span class="comment">
~list内の［ 2, 6, 10 ］個目の要素を表現する
◎
represents the 2nd, 6th, and 10th elements of the list
</span> */
</pre>
</div>

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

		<section id="anb-syntax">
<h3 title="Informal Syntax Description">6.1. 非正式な構文~記述</h3>

◎非規範的

<p>
%A ~EQ 0 の場合、
~An 部分を省略してもヨイ
（ %B 部分がすでに省略されていない限り）。
~An 部分が無い場合、
負でない %B の前の `+^c 符号も省略してヨイ【！ (when allowed) ？】
— この事例では、
構文は %B だけに単純~化される。
◎
When A is 0, the An part may be omitted (unless the B part is already omitted). When An is not included and B is non-negative, the + sign before B (when allowed) may also be omitted. In this case the syntax simplifies to just B.
</p>

<div class="example">
<p>
◎
Examples:
</p>

<pre class="lang-css">
0n+5   /* <span class="comment">
~list内の 5 個目の要素を表現する
◎
represents the 5th element in the list
</span> */
5      /* <span class="comment">
同じ
◎
same
</span> */
</pre>
</div>

<p>
%A ~IN { 1, −1 } の場合、
当の規則から `1^c を省略してもヨイ。
◎
When A is 1 or -1, the 1 may be omitted from the rule.
</p>

<div class="example">
<p>
◎
Examples:
</p>

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

<pre class="lang-css">
1n+0   /* <span class="comment">
~list内のすべての要素を表現する
◎
represents all elements in the list
</span> */
n+0    /* <span class="comment">
同じ
◎
same
</span> */
n      /* <span class="comment">
同じ
◎
same
</span> */
</pre>
</div>

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

<div class="example">
<p>
◎
Examples:
</p>

<pre class="lang-css">
2n+0   /* <span class="comment">
~list内の毎~偶数個目の要素を表現する
◎
represents every even element in the list
</span> */
2n     /* <span class="comment">
同じ
◎
same
</span> */
</pre>
</div>

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

<div class="example">
<p>
妥当な例：
◎
Valid example:
</p>

<pre class="lang-css">3n-6</pre>

<p>
妥当でない例：
◎
Invalid example:
</p>

<p>
<pre class="lang-css">3n + -6</pre>
</div>

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

<div class="example">
<p>
空白を伴う妥当な例：
◎
Valid Examples with white space:
</p>

<pre class="lang-css">
3n + 1
+3n - 2
-n+ 6
+6
</pre>

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

<pre class="lang-css">
3 n
+ 2n
+ 2
</pre>
</div>

		</section>
		<section id="the-anb-type">
<h3 title="The &lt;an+b&gt; type">6.2. ~anb 型</h3>

<p>
~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 &lt;an+b&gt; type for CSS grammar purposes), and how to interpret the CSS tokens to obtain values for A and B.
</p>

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

<pre class="prod">
`~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
</pre>

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

<div>
<table id="_anb-prod" class="grid-table"><thead>
<tr><th>生成規則
<th>~token
<th>~fieldが満たす条件
<tbody>

<tr><td>`n-dimension@t
<td>`dimension$tok
<td>
［
.型~flag ~EQ `整数^i
］~AND［
.単位 ~EQ`大小無視$sub `n^l
］

<tr><td>`ndash-dimension@t
<td>`dimension$tok
<td>
［
.型~flag ~EQ `整数^i
］~AND［
.単位 ~EQ`大小無視$sub `n-^l
］

<tr><td>`ndashdigit-dimension@t
<td>`dimension$tok
<td>
［
.型~flag ~EQ `整数^i
］~AND［
.単位 ~EQ`大小無視$sub "`n-^c`数字~列$"
］

<tr><td>`ndashdigit-ident@t
<td>`ident$tok
<td>
.値 ~EQ`大小無視$sub "`n-^c`数字~列$"

<tr><td>`dashndashdigit-ident@t
<td>`ident$tok
<td>
.値 ~EQ`大小無視$sub "`-n-^c`数字~列$"

<tr><td>`integer@t
<td>`number$tok
<td>
.型~flag ~EQ `整数^i

<tr><td>`signed-integer@t
<td>`number$tok
<td>
［
.型~flag ~EQ `整数^i
］~AND［
.符号~文字 ~NEQ ε
］

<tr><td>`signless-integer@t
<td>`number$tok
<td>
［
.型~flag ~EQ `整数^i
］~AND［
.符号~文字 ~EQ ε
］
</table>

◎
&lt;n-dimension&gt; is a &lt;dimension-token&gt; with its type flag set to "integer", and a unit that is an ASCII case-insensitive match for "n"
◎
&lt;ndash-dimension&gt; is a &lt;dimension-token&gt; with its type flag set to "integer", and a unit that is an ASCII case-insensitive match for "n-"
◎
&lt;ndashdigit-dimension&gt; is a &lt;dimension-token&gt; 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
◎
&lt;ndashdigit-ident&gt; is an &lt;ident-token&gt; whose value is an ASCII case-insensitive match for "n-*", where "*" is a series of one or more digits
◎
&lt;dashndashdigit-ident&gt; is an &lt;ident-token&gt; whose value is an ASCII case-insensitive match for "-n-*", where "*" is a series of one or more digits
◎
&lt;integer&gt; is a &lt;number-token&gt; with its type flag set to "integer"
◎
&lt;signed-integer&gt; is a &lt;number-token&gt; with its type flag set to "integer", and a sign character
◎
&lt;signless-integer&gt; is a &lt;number-token&gt; with its type flag set to "integer", and no sign character
</div>

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

<p id="anb-plus">
上で ~DAGGER 印が付与された所のように、
正符号 (`+^c) ~tokenの直後に［
`n^l から開始している `ident^tok ~token
］が来る所では，それらの合間に空白が在ってはナラナイ
— さもなければ、
それらの~tokenは上の文法に合致しないとする。
他の［
~tokenたちの合間に在る空白
］は妥当である（無視される）。
◎
†: When a plus sign (+) precedes an ident starting with "n", as in the cases marked above, there must be no whitespace between the two tokens, or else the tokens do not match the above grammar. Whitespace is valid (and ignored) between any other two tokens.
</p>

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

<div>
<table id="_anb-def" class="grid-table"><thead>
<tr><th>生成規則
<th>%A の値
<th>%B の値
<tbody>

<tr><td><span class="prod">`odd^v</span>
<td>2
<td>1

<tr><td><span class="prod">`even^v</span>
<td>2
<td>0

<tr><td><span class="prod">`integer$t</span>
<td>0
<td>`integer$t の.数値

<tr><td><span class="prod">`n-dimension$t</span>
<td>`n-dimension$t の.数値
<td>0

<tr><td><span class="prod">'`+^c'? `n^c</span>
<td>1
<td>0

<tr><td><span class="prod">`-n^c</span>
<td>−1
<td>0

<tr><td><span class="prod">`ndashdigit-dimension$t</span>
<td>`ndashdigit-dimension$t の.数値
<td>［
`ndashdigit-dimension$t の.単位から，最初の`符号位置$を除去した残りの部分
］を 10 進数として解釈した結果
<span class="note">— 負になる</span>

<tr><td><span class="prod">'`+^c'? `ndashdigit-ident$t</span>
<td>1
<td>［
`ndashdigit-ident$t の.値から，最初の`符号位置$を除去した残りの部分
］を 10 進数として解釈した結果
<span class="note">— 負になる</span>

<tr><td><span class="prod">`dashndashdigit-ident$t</span>
<td>−1
<td>［
`dashndashdigit-ident$t の.値から最初の 2 個の`符号位置$を除去した残りの部分
］を 10 進数として解釈した結果
<span class="note">— 負になる</span>

<tr><td><span class="prod">`n-dimension$t `signed-integer$t</span>
<td>`n-dimension$t の.数値
<td>`signed-integer$t の.数値

<tr><td><span class="prod">'`+^c'? `n^c `signed-integer$t</span>
<td>1
<td>(同上)

<tr><td><span class="prod">`-n^c `signed-integer$t</span>
<td>−1
<td>(同上)

<tr><td><span class="prod">`ndash-dimension$t `signless-integer$t</span>
<td>`n-dimension$t の.数値
<td>−1 ×［ `signless-integer$t の.数値 ］

<tr><td><span class="prod">'`+^c'? `n-^c `signless-integer$t</span>
<td>1
<td>(同上)

<tr><td><span class="prod">`-n-^c `signless-integer$t</span>
<td>−1
<td>(同上)

<tr><td><span class="prod">`n-dimension$t ['`+^c' | '`-^c'] `signless-integer$t</span>
<td>`n-dimension$t の.数値
<td>%sign × ［
`signless-integer$t の.数値
］
— ここで %sign は、
['`+^c' | '`-^c'] が［
'`+^c' ならば 1 ／ '`-^c' ならば −1
］

<tr><td><span class="prod">'`+^c'? `n^c ['`+^c' | '`-^c'] `signless-integer$t</span>
<td>1
<td>(同上)

<tr><td><span class="prod">`-n^c ['`+^c' | '`-^c'] `signless-integer$t</span>
<td>−1
<td>(同上)
</table>

<dl lang="en" class="_en">
	<dt>odd</dt>
	<dd>A is 2, B is 1.</dd>

	<dt>even</dt>
	<dd>A is 2, B is 0.</dd>

	<dt>&lt;integer&gt;</dt>
	<dd>A is 0, B is the integer’s value.</dd>

	<dt>&lt;n-dimension&gt;</dt>
	<dt>'+'? n</dt>
	<dt>-n</dt>
	<dd>A is the dimension’s value, 1, or -1, respectively. B is 0.</dd>

	<dt>&lt;ndashdigit-dimension&gt;</dt>
	<dt>'+'? &lt;ndashdigit-ident&gt;</dt>
	<dd>
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.
</dd>

	<dt>&lt;dashndashdigit-ident&gt;</dt>
	<dd>
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.
</dd>

	<dt>&lt;n-dimension&gt; &lt;signed-integer&gt;</dt>
	<dt>'+'? n &lt;signed-integer&gt;</dt>
	<dt>-n &lt;signed-integer&gt;</dt>
	<dd>
A is the dimension’s value, 1, or -1, respectively. B is the integer’s value.
</dd>

	<dt>&lt;ndash-dimension&gt; &lt;signless-integer&gt;</dt>
	<dt>'+'? n- &lt;signless-integer&gt;</dt>
	<dt>-n- &lt;signless-integer&gt;</dt>
	<dd>
A is the dimension’s value, 1, or -1, respectively. B is the negation of the integer’s value.
</dd>

	<dt>&lt;n-dimension&gt; ['+' | '-'] &lt;signless-integer&gt;</dt>
	<dt>'+'? n ['+' | '-'] &lt;signless-integer&gt;</dt>
	<dt>-n ['+' | '-'] &lt;signless-integer&gt;</dt>
	<dd>
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.
</dd>
</dl>
</div>

		</section>
	</section>
	<section id="rule-defs">
<h2 title="Defining Grammars for Rules and Other Values">7. 規則や他の値~用の文法の定義-法</h2>

<p>
~propその他の~CSS構文-構成子~用の文法を指定する方法は、
`CSS-VALUES-4$r `§ 値~定義の構文$が定義する。
◎
CSS Values 4 § 2 Value Definition Syntax defines how to specify a grammar for properties and other CSS syntactic constructions.
</p>

		<section id="block-contents">
<h3 title="Defining Block Contents: the &lt;block-contents&gt;, &lt;declaration-list&gt;, &lt;qualified-rule-list&gt;, &lt;declaration-rule-list&gt;, and &lt;rule-list&gt; productions">7.1. ~block内容の定義-法： `block-contents^t, `declaration-list^t, `qualified-rule-list^t, `declaration-rule-list^t, `rule-list^t 生成規則</h3>

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

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

<p>
付随している注釈文は、
次を定義しなければナラナイ：
◎
Accompanying prose must＼
</p>
<ul>
	<li>
当の文脈において何が妥当で何が無効になるか。
◎
define what is valid and invalid in this context.＼
</li>
	<li>
妥当な`宣言$が`~prop宣言$である場合、
それは，`~cascade$とヤリトリするか否か
— ヤリトリする場合、
その`詳細度＠~CASCADE#cascade-specificity$，それは `!important^css をどう利用するか。
◎
If any declarations are valid, and are property declarations, it must define whether they interact with the cascade; if they do, it must define their specificity and how they use !important.
</li>
</ul>

<p>
しかしながら，多くの事例では、
~blockは，所与の型を成す どの構成子も妥当に包含できるわけではない。
これらの事例を より明示的に表現するためとして、
次に挙げる生成規則を利用してもヨイ：
◎
In many cases, however, a block can’t validly contain any constructs of a given type. To represent these cases more explicitly, the following productions may be used
</p>
<ul>
	<li>
`declaration-list@t
⇒
`宣言$は許容され，［
`~at-規則$, `有修飾~規則$
］は自動的に無効になる。
◎
&lt;declaration-list&gt;: only declarations are allowed; at-rules and qualified rules are automatically invalid.
</li>
	<li>
`qualified-rule-list@t
⇒
`有修飾~規則$は許容され，［
`宣言$, `~at-規則$
］は自動的に無効になる。
◎
&lt;qualified-rule-list&gt;: only qualified rules are allowed; declarations and at-rules are automatically invalid.
</li>
	<li>
`at-rule-list@t
⇒
`~at-規則$は許容され，［
`宣言$, `有修飾~規則$
］は自動的に無効になる。
◎
&lt;at-rule-list&gt;: only at-rules are allowed; declarations and qualified rules are automatically invalid.
</li>
	<li>
`declaration-rule-list@t
⇒
［
`宣言$, `~at-規則$
］は許容され，
`有修飾~規則$は自動的に無効になる。
◎
&lt;declaration-rule-list&gt;: declarations and at-rules are allowed; qualified rules are automatically invalid.
</li>
	<li>
`rule-list@t
⇒
［
`有修飾~規則$, `~at-規則$
］は許容され，
`宣言$は自動的に無効になる。
◎
&lt;rule-list&gt;: qualified rules and at-rules are allowed; declarations are automatically invalid.
</li>
</ul>

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

<div class="example">
<p>
様々な生成規則の例：
◎
Some examples of the various productions:
</p>
<ul>
	<li>
~top-levelの `media$at は，
自身の~block用に `rule-list$t を利用する。
一方で，入子にされた `media$at `CSS-NESTING-1$r は
`block-contents$t を利用する。
◎
A top-level @media uses &lt;rule-list&gt; for its block, while a nested one [CSS-NESTING-1] uses &lt;block-contents&gt;.
</li>
	<li>
`~style規則$は
`block-contents$t を利用する。
◎
Style rules use &lt;block-contents&gt;.
</li>
	<li>
`font-face$at は
`declaration-list$t を利用する。
◎
@font-face uses &lt;declaration-list&gt;.
</li>
	<li>
`page$at は
`declaration-rule-list$t を利用する。
◎
@page uses &lt;declaration-rule-list&gt;.
</li>
	<li>
`keyframes$at は
`qualified-rule-list$t を利用する。
◎
@keyframes uses &lt;qualified-rule-list&gt;
</li>
</ul>
</div>

<div class="example">
<p>
例えば， `font-face$at 用の文法は、
次のように書ける：
◎
For example, the grammar for @font-face can be written as:
</p>

<pre class="prod">
`font-face$at
	= @font-face { `declaration-list$t }
</pre>

<p>
付随している注釈文は、
~block内で許容される妥当な`記述子$を定義する。
◎
and then accompanying prose defines the valid descriptors allowed in the block.
</p>

<p>
例えば， `keyframes$at 用の文法は、
次のように書ける：
◎
The grammar for @keyframes can be written as:
</p>

<pre class="prod">
`keyframes$at
	= @keyframes { `qualified-rule-list$t }
`keyframe-rule^t
	= `keyframe-selector$t { `declaration-list$t }
</pre>

<p>
付随している注釈文は、
次を定義する
⇒
`keyframes$at 内に許容されるものは `keyframe-rule^t に限られる。
各 `keyframe-rule^t は、
~CSS~propのうち［
~animate可能なものすべて,
`animation-timing-function$p
］を受容するが，それらは~cascadeとはヤリトリしない。
◎
and then accompanying prose defines that only &lt;keyframe-rule&gt;s are allowed in @keyframes, and that &lt;keyframe-rule&gt;s accept all animatable CSS properties, plus the animation-timing-function property, but they do not interact with the cascade.
</p>
</div>

		</section>
		<section id="any-value">
<h3 title="Defining Arbitrary Contents: the &lt;declaration-value&gt; and &lt;any-value&gt; productions">7.2. 任意の内容を定義するもの： `declaration-value^t, `any-value^t 生成規則</h3>

<p>
文法によっては、
任意の適理な入力を受容して，その~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).
</p>

<p class="example">
例えば，`~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 &lt;general-enclosed&gt; production in Media Queries defines the bounds of what future syntax MQs will allow, and uses special logic to deal with "unknown" values.
</p>

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

<dl>
	<dt>`declaration-value@t</dt>
	<dd>
<p>
この生成規則は、
`任意の^em［
1 個以上の~tokenたちが成す連列
］に
— その連列が次に挙げるものを包含していないならば —
合致する：
◎
The &lt;declaration-value&gt; production matches any sequence of one or more tokens, so long as the sequence does not contain＼
</p>
<div>
		<ul>
			<li>
`bad-string$tok
</li>
			<li>
`bad-url$tok
</li>
			<li>
対になっていない［
`close-paren$Tok ／
`close-square$Tok ／
`close-curly$Tok
］
</li>
			<li>
~top-levelの `semicolon$tok
</li>
			<li>
`!^l を.値にとる `delim$tok
</li>
		</ul>

◎
&lt;bad-string-token&gt;, &lt;bad-url-token&gt;, unmatched &lt;)-token&gt;, &lt;]-token&gt;, or &lt;}-token&gt;, or top-level &lt;semicolon-token&gt; tokens or &lt;delim-token&gt; tokens with a value of "!".＼
</div>
	</dd>
	<dd>
これは、
その並び全体として［
妥当な宣言がとり得る値
］を表現する。
◎
It represents the entirety of what a valid declaration can have as its value.
</dd>

	<dt>`any-value@t</dt>
	<dd>
この生成規則は、［
~top-levelの `semicolon$tok ／
`!^l を.値にとる `delim$tok
］も許容されることを除いて， `declaration-value$t と一致する。
◎
The &lt;any-value&gt; production is identical to &lt;declaration-value&gt;, but also allows top-level &lt;semicolon-token&gt; tokens and &lt;delim-token&gt; tokens with a value of "!".＼
</dd>
	<dd>
これは、
それ全体として［
何らかの文脈の下で，妥当な~CSSになり得るもの
］を表現する。
◎
It represents the entirety of what valid CSS can be in any context.
</dd>
</dl>

		</section>
	</section>
	<section id="css-stylesheets">
<h2 title="CSS stylesheets">8. ~CSS~stylesheet</h2>

<div class="algo">
<p>
`~CSS~stylesheetを構文解析する@
~algoは、
所与の
( ~stylesheet %入力 )
に対し：
</p>
<ol>
	<li>
%結果 ~LET `~stylesheetを構文解析する$( %入力 )
</li>
	<li>
%結果 を成す
~EACH( ~top-levelの`有修飾~規則$ %規則 )
に対し
⇒
%規則 を，以下に定義するように`~style規則$として解釈する
</li>
</ol>
◎
To parse a CSS stylesheet, first parse a stylesheet. Interpret all of the resulting top-level qualified rules as style rules, defined below.
</div>

<p>
［
`無効$な~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.
</p>

		<section id="style-rules">
<h3 title="Style rules">8.1. ~style規則</h3>

<p>
`~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.
</p>

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

<p>
有修飾~規則の~blockの内容は、
`declaration-list$t として構文解析される。
この~block内の有修飾~規則も`~style規則$である。
別の仕様やこの仕様の将来~levelにて定義されない限り、
この~list内の~at-規則は`無効$であり，無視するモノトスル。
◎
The content of the qualified rule’s block is parsed as a &lt;declaration-list&gt;. Qualified rules in this block are also style rules. Unless defined otherwise by another specification or a future level of this specification, at-rules in that list are invalid and must be ignored.
</p>

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

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

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

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

<p class="example">
例えば、［
`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.
</p>

		</section>
		<section id="at-rules">
<h3 title="At-rules">8.2. ~at-規則</h3>

<p>
`~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.
</p>

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

<p>
`~at-規則$は、
自身に特有な規則と目的に依存して多くの形をとり得るが，次の 2 種に大別される：
◎
At-rules take many forms, depending on the specific rule and its purpose, but broadly speaking there are two kinds:＼
<p>
<ul>
	<li>
`一文~at-規則@
（ `statement at-rule^en, “~blockを伴わない” ~at-規則）
⇒
これは、
`~block~at-規則$より単純な，~semicolonで終端する構成子である。
◎
statement at-rules which are simpler constructs that end in a semicolon,＼
</li>
	<li>
`~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.
</li>
</ul>

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

<p>
`記述子@
は，`~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.
</p>

		</section>
		<section id="charset-rule">
<h3 title="The @charset Rule">8.3. `charset^at 規則</h3>

<p>
~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".
</p>

<p>
しかしながら、
名前
`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.
</p>

<p class="note">注記：
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.
</p>

		</section>
	</section>
	<section id="serialization">
<h2 title="Serialization">9. 直列化</h2>

<p>
この仕様にて述べられる~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.
</p>

<p>
この仕様は、
~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.
</p>

<p>
直列化に課される唯一の要件は、
構文解析と “往復-” できなければナラナイことである。
すなわち，~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 &lt;whitespace-token&gt;s, which may be collapsed into a single token.
</p>

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

<div class="note" id="serialization-tables">

<p>
この要件を満たすためには：
◎
To satisfy this requirement:
</p>
<ul>
	<li>
［
`5C^U を.値にとる `delim$tok
］は、［
`5C^U, `改行文字$
］が成す並びとして直列化されなければナラナイ。
（~tokenizerが その種の~tokenを発するときは、
必ず［
改行文字から開始する `whitespace$tok
］を後続させる。）
◎
A &lt;delim-token&gt; 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 &lt;whitespace-token&gt; that starts with a newline.)
</li>
	<li>
`hash$tok であって［
.型~flag ~EQ `無制約^i
］なるものに要する~escapeが，同じ~tokenであって［
.型~flag ~EQ `id^i
］なるものより多くなることはない。
◎
A &lt;hash-token&gt; with the "unrestricted" type flag may not need as much escaping as the same token with the "id" type flag.
</li>
	<li>
`dimension$tok の.単位は、
科学的記数法と区別するために，~escapeを要し得る。
◎
The unit of a &lt;dimension-token&gt; may need escaping to disambiguate with scientific notation.
</li>
	<li>
<p id="_put-a-comment-between-tokens">
下の表tの中で，チェック（ ✗ ）が入っている欄と同じ［
列, 行
］の見出しに示されている 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.
</p>

<p>
~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.)
</p>

<div style="overflow:auto;">
<table id="_ser-table1">
<caption>
見出しに挙げる~tokenのうち， 1 個の文字からなるものは、
それを.値に伴う `delim$tok を表現する。
◎
Single characters in the row and column headings represent a &lt;delim-token&gt; with that value, except for "(", which represents a (-token.
</caption>
<thead>
<tr><td>
<th>`ident$tok
<th>`function$tok
<th>`url$tok
<th>`bad-url$tok
<th>`-^c
<th>`number$tok
<th>`percentage$tok
<th>`dimension$tok
<th>`CDC$tok
<th>`(^c
<th>`*^c
<th>`%^c
<tbody>

<tr><th>`ident$tok
`✗✗✗✗✗✗✗✗✗✗__^cK

<tr><th>`at-keyword$tok
`✗✗✗✗✗✗✗✗✗___^cK

<tr><th>`hash$tok
`✗✗✗✗✗✗✗✗✗___^cK

<tr><th>`dimension$tok
`✗✗✗✗✗✗✗✗✗___^cK

<tr><th>`#^c
`✗✗✗✗✗✗✗✗✗___^cK

<tr><th>`-^c
`✗✗✗✗✗✗✗✗✗___^cK

<tr><th>`number$tok
`✗✗✗✗_✗✗✗✗__✗^cK

<tr><th>`@^c
`✗✗✗✗✗___✗___^cK

<tr><th>`.^c
`_____✗✗✗____^cK

<tr><th>`+^c
`_____✗✗✗____^cK

<tr><th>`/^c
`__________✗_^cK
</table>
</div>
	</li>
</ul>
</div>

		<section id="serializing-anb">
<h3 title="Serializing &lt;an+b&gt;">9.1. ~anb の直列化-法</h3>

<div class="algo">
<p>
`~anb 値を直列化する@
~algoは、
所与の
( `周期$ %A, `~offset$ %B )
に対し：
</p>
<ol>
	<li>
~IF［
%A ~EQ 0
］
⇒
~RET %B を直列化した結果
</li>
	<li>
%結果 ~LET %A に応じて
⇒＃
1 ならば 空~文字列 ／
−1 ならば `-^l ／
~ELSE_ %A を直列化した結果
</li>
	<li>
%結果 に `n^l を付加する
</li>
	<li>
~IF［
%B ~EQ 0
］
⇒
~RET %結果
</li>
	<li>
~IF［
%B ~GT 0
］
⇒
%結果 に `+^l を付加する
</li>
	<li>
%結果 に %B を直列化した結果を付加する
</li>
	<li>
~RET %結果
</li>
</ol>
◎
To serialize an &lt;an+b&gt; value, with integer values A and B:
• 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.
</div>

		</section>
	</section>
	<section id="privacy">
<h2 title="Privacy Considerations">~privacyの考慮点</h2>

<p>
この仕様が導入する新たな~privacyの懸念は無い。
◎
This specification introduces no new privacy concerns.
</p>

	</section>
	<section id="security">
<h2 title="Privacy and Security Considerations">~privacyの考慮点</h2>

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

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

	</section>
	<section id="changes">
<h2 title="Changes">変更点</h2>

◎非規範的

<p class="trans-note">【
変更~箇所の引用は省略する。
】</p>

		<section id="changes-CR-20211224">
<h3 title="Changes from the 24 December 2021 Candidate Recommendation Draft">2021年 12月 24日 勧告候補~草案からの変更点</h3>

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

		</section>
		<section id="changes-CR-20190716">
<h3 title="Changes from the 16 August 2019 Candidate Recommendation">2019年 8月 16日 勧告候補からの変更点</h3>

<p>
~~主要な変更点は：
◎
The following substantive changes were made:
</p>
<ul>
	<li>
`§ ~commaで分離された~listを ある~CSS文法に則って構文解析する＠#parse-comma-list$
~algoを新たに追加した。
◎
Added a new § 5.4.2 Parse a comma-separated list according to a CSS grammar algorithm.
</li>
	<li>
<p>
［
~style~blockの内容を構文解析する~algo,
それに対応する `style-block^t 生成規則
］†を新たに追加した。
`~style規則$は、
これらを利用するものと定義した。
</p>

<p class="trans-note">【†
これらは、今や［
`~blockの内容を構文解析する$, `block-contents$t
］として定義し直された。
】</p>
◎
Added a new "Parse a style block’s content" algorithm and a corresponding &lt;style-block&gt; production, and defined that style rules use it.
</li>
	<li>
`~stylesheetを構文解析する$ ~algoを Fetch 仕様に関係する `shenanigans^en に揃えた。
（
`commit＠https://github.com/w3c/csswg-drafts/commit/64becb59fe678760608a6f2a8d6bfb3a334500c9#diff-9d409f899ee6e2cc8cd87356d0e2a0ff739c5aa9663d83f49c951c379a38f1f6$
を見よ。）
◎
Aligned parse a stylesheet with the Fetch-related shenanigans. (See commit.)
◎
To parse a stylesheet from an input given an optional url location :
• ...
• Create a new stylesheet , with its location set to location (or null, if location was not passed).
• ... 
</li>
</ul>

<p>
編集上の変更点は：
◎
The following editorial changes were made:
</p>
<ul>
	<li>
［
`~at-規則$,
`一文~at-規則$,
`~block~at-規則$,
`記述子$
］用の定義を供するため，
`§ ~at-規則＠#at-rules$ を追加した
（ `課題 #5633＠~CSSissue/5633$ ）。
◎
Added § 8.2 At-rules to provide definitions for at-rules, statement at-rules, block at-rules, and descriptors. (5633)
</li>
	<li>
`宣言$用の定義~textを改善した。
［
`~prop宣言$, `記述子~宣言$
］用の定義を追加した。
◎
Improved the definition text for declaration, and added definitions for property declarations and descriptor declarations.
</li>
	<li>
何箇所かで利用していた用語 “名前” に代えて、
一貫して`~ident$を参照rするよう切替えた。
◎
Switched to consistently refer to ident sequence, rather than sometimes using the term “name”.
</li>
	<li>
~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).
</li>
	<li>
“`~tokenの合間に~commentを挟む＠#_put-a-comment-between-tokens$”
表tに~entryを追加して、［
~identは、
今や `--^c から開始し得る事実
］を適正に取扱うようにした。
（ `pull #6874＠https://github.com/w3c/csswg-drafts/pull/6874$ ）
◎
Added more entries to the "put a comment between them" table, to properly handle the fact that idents can now start with --. (6874)
</li>
</ul>

		</section>
		<section id="changes-CR-20140220">
<h3 title="Changes from the 20 February 2014 Candidate Recommendation">2014年 2月 20日 勧告候補からの変更点</h3>

<p>
~~主要な変更点は：
◎
The following substantive changes were made:
</p>
<ul>
	<li>
`urange^t 生成規則を創出する支持を受けて，
`unicode-range$tok は除去した【が，戻された（以下も同様）】。
◎
Removed &lt;unicode-range-token&gt;, in favor of creating a &lt;urange&gt; production.
</li>
	<li>
文字列を包含する `url^f 関数は、
今や，通常通り `function$tok として構文解析される。
“生の” ~URLを包含する `url^f 関数は、
依然として `url$tok として特別に構文解析される。
◎
url() functions that contain a string are now parsed as normal &lt;function-token&gt;s. url() functions that contain "raw" URLs are still specially parsed as &lt;url-token&gt;s.
</li>
	<li>
文字列を消費するよう試みる前に引用符を消費していなかった，
“~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.
</li>
	<li>
［［
現在の／次回の
］入力~token, それが消費される時機
］に関する，いくつかの構文解析器~algoの~bugを修正した。
◎
Fixed a bug in several of the parser algorithms related to the current/next token and things getting consumed early/late.
</li>
	<li>
~token化と構文解析~algoにおける いくつかの~bugを修正した。
◎
Fix several bugs in the tokenization and parsing algorithms.
</li>
	<li>
~identに類する~tokenの定義を［
`--^c から開始する~ident
］も許容するように変更した
【`参照＠#would-start-an-identifier$】
。
その~~一環として、［
`~tokenを消費する$ときの `2D^U 段を成す段たち
］を配列し直して，
`CDC$tok が
— `--^c `ident-token$t にはならずに —
そう認識されるようにした。
◎
Change the definition of ident-like tokens to allow "--" to start an ident. As part of this, rearrange the ordering of the clauses in the "-" step of consume a token so that &lt;CDC-token&gt;s are recognized as such instead of becoming a -- &lt;ident-token&gt;.
</li>
	<li>
`~anb$ の`周期$ ~IN { 1, −1 } のときは、
その数字は直列化しないようにした。
◎
Don’t serialize the digit in an &lt;an+b&gt; when A is 1 or -1.
</li>
	<li>
すべての~tokenは
`表現^dfn
を持つように定義した
【が、廃された（ “.元の~text” に置換された）】
。
◎
Define all tokens to have a representation.
</li>
	<li>
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 &lt;delim-token&gt;.
</li>
	<li>
`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)
</li>
	<li>
構文解析の間に，宣言の.値の［
先頭／末尾
］にある空白~並びは削るようにした。
◎
Trimmed whitespace from the beginning/ending of a declaration’s value during parsing.
</li>
	<li>
~WGによる解決にしたがって、
`Selectors^cite に特有な~tokenは除去した。
◎
Removed the Selectors-specific tokens, per WG resolution.
</li>
	<li>
~WGによる解決にしたがって、
入力~stream内の`~surrogate$は~filterするようにした。
この仕様~全体は、
今や，`~scalar値$のみに演算する。
◎
Filtered surrogates from the input stream, per WG resolution. Now the entire specification operates only on scalar values.
</li>
</ul>

<p>
編集上の変更点は：
◎
The following editorial changes were made:
</p>
<ul>
	<li>
“文字列を消費する” ~algoは、
明示的な終端~符号位置を指定せずに~callできるようにされた。
その場合、
現在の~tokenが代わりに利用される。
これにより， 3 箇所の~call元に変更が加えられた。
◎
The "Consume a string token" algorithm was changed to allow calling it without specifying an explicit ending token, so that it uses the current token instead. The three call-sites of the algorithm were changed to use that form.
</li>
	<li>
編集上の，~algoにおける小さな~~再構成。
◎
Minor editorial restructuring of algorithms.
</li>
	<li>
構文解析-~API用の入口として、
次を追加した
⇒＃
`~CSS文法に則って構文解析する$,
`~commaで分離された成分~値~listを構文解析する$
◎
Added the parse and parse a comma-separated list of component values API entry points.
</li>
	<li>
次に挙げる生成規則を追加した
⇒＃
`declaration-value$t,
`any-value$t
◎
Added the &lt;declaration-value&gt; and &lt;any-value&gt; productions.
</li>
	<li>
次に挙げる定義は、
`INFRA$r による定義に一致するので，除去した
⇒＃
“符号位置”,
“~surrogate符号位置”
◎
Removed "code point" and "surrogate code point" in favor of the identical definitions in the Infra Standard.
</li>
	<li>
どの【符号位置】範囲も `inclusive^en であることを明確化した。
◎
Clarified on every range that they are inclusive.
</li>
	<li>
`%^l `delim$tok ~tokenの次に出現する `number$tok を取扱うため、
`~comment挿入~表t＠#serialization-tables$に列を追加した。
◎
Added a column to the comment-insertion table to handle a number token appearing next to a "%" delim token.
</li>
</ul>

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

		</section>
		<section id="changes-WD-20131105">
<h3 title="Changes from the 5 November 2013 Last Call Working Draft">2013年 11月 5日 最終~作業草案からの変更点</h3>

<ul>
	<li>
`§ 直列化＠#serialization$は、
“往復-” の要件のみが規範的になるように書き直され、
それを得るための方法の詳細は注記に移動された。
これらの詳細~における，いくつかの際どい事例は解消された。
◎
The Serialization section has been rewritten to make only the "round-trip" requirement normative, and move the details of how to achieve it into a note. Some corner cases in these details have been fixed.
</li>
	<li>
参照文献（規範）に `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.
</li>
	<li>
<p>
~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 &lt;meta charset&gt; and makes sure the size of the sequence is bounded. This only makes a difference with leading or trailing whitespace in the encoding label:
</p>

<pre class="lang-css">
@charset "   <em title="(lots of whitespace)">…多量の空白…</em>   utf-8";
</pre>
	</li>
</ul>

		</section>
		<section id="changes-WD-20130919">
<h3 title="Changes from the 19 September 2013 Working Draft">2013年 9月 19日 作業草案からの変更点</h3>

<ul>
	<li>

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

		</section>
		<section id="changes-css21">
<h3 title="Changes from CSS 2.1 and Selectors Level 3">`CSS 2.1^cite, `Selectors Level 3^cite からの変更点</h3>

<p class="note">注記：
この仕様の要点は、
実態に合致させることである
— 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.
</p>

<p>
~byte~streamからの復号-法における変更点：
◎
Changes in decoding from a byte stream:
</p>
<ul>
	<li>
~ASCII互換~byte~patternの中では、
`charset$at 規則のみが検出される。
◎
Only detect @charset rules in ASCII-compatible byte patterns.
</li>
	<li>
~ASCII互換でない符号化法を指定する `charset$at 規則は、
規則それ自身を適正に復号できなくするので，無視される。
◎
Ignore @charset rules that specify an ASCII-incompatible encoding, as that would cause the rule itself to not decode properly.
</li>
	<li>
文字~符号化法は、
IANA ~registryではなく， `ENCODING$r を参照rするようにされた。
◎
Refer to [ENCODING] rather than the IANA registry for character encodings.
</li>
</ul>

<p>
~token化における変更点：
◎
Tokenization changes:
</p>
<ul>
	<li>
~CSS~source内の `00^U `符号位置$はすべて， `FFFD^U に置換される
◎
Any U+0000 NULL code point in the CSS source is replaced with U+FFFD REPLACEMENT CHARACTER.
</li>
	<li>
`\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.
</li>
	<li>
`非~ASCII~ident符号位置$の定義は、
~HTMLの`妥当な~custom要素~名$に整合するよう変更された。
◎
The definition of non-ASCII ident code point was changed to be consistent with HTML’s valid custom element names.
</li>
	<li>
~token化は、
もはや［
`COMMENT^c ／ `BAD_COMMENT^c
］~tokenを発することはない。
`BAD_COMMENT^c は今や，（~errorではない）通常の~tokenと同じものと見なされる。
分離される必要がある~token
— 例えば 連続する 2 個の `ident$tok など —
の合間に，必要yなだけ~commentを挿入することは、
`§ 直列化＠#serialization$が責を負う。
◎
Tokenization does not emit COMMENT or BAD_COMMENT tokens anymore. BAD_COMMENT is now considered the same as a normal token (not an error). Serialization is responsible for inserting comments as necessary between tokens that need to be separated, e.g. two consecutive &lt;ident-token&gt;s.
</li>
	<li>
<p>
`unicode-range$tok を除去した。
価値が低い割に，ときには有害になるので
（例えば、
`u+a { font-weight: bold; }^css は，`無効な選択子$にされていた…）。
◎
The &lt;unicode-range-token&gt; was removed, as it was low value and occasionally actively harmful. (u+a { font-weight: bold; } was an invalid selector, for example...)
</p>

<p>
代わりに，~token~patternに基づく `urange^t 生成規則が追加された。
それは、
CSS 2.1 で許容されていたものより，形上では緩い（任意個数の数字や `?^c ）が、
実施におけるその利用には影響iない筈である。
◎
Instead, a &lt;urange&gt; 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.
</p>
	</li>
	<li>
~tokenizerにおいては`~EOF~errorの取扱い規則$が適用され、
`~EOF$iに際しては
— `BAD_STRING^c や `BAD_URI^c ではなく —
通常の `string$tok や `url$tok が発される。
◎
Apply the EOF error handling rule in the tokenizer and emit normal &lt;string-token&gt; and &lt;url-token&gt; rather than BAD_STRING or BAD_URI on EOF.
</li>
	<li>
`BAD_URI^c ~token（今や `bad-url$tok ）は “自己完結的” である。
言い換えれば、［
~tokenizerにおいて， `url$tok ではなく `bad-url$tok の中であることが~~判明した時点
］で，
単に閉じられる箇所を見つけるために，他のすべてを無視して前方検索する。
この挙動は、［
それを `function$tok の様に扱って，
開いた~blockに類するものに注意を払う
］より単純である。
この挙動は WebKit だけが呈するが、
それによる互換性~bugは生じていないように見受けられる。
◎
The BAD_URI token (now &lt;bad-url-token&gt;) is "self-contained". In other words, once the tokenizer realizes it’s in a &lt;bad-url-token&gt; rather than a &lt;url-token&gt;, it just seeks forward to look for the closing ), ignoring everything else. This behavior is simpler than treating it like a &lt;function-token&gt; 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.
</li>
	<li>
`comma$tok が追加された。
◎
The &lt;comma-token&gt; has been added.
</li>
	<li>
［
`number$tok,
`percentage$tok,
`dimension$tok
］は、
前置された`正負符号$を値の一部に含むように変更された
（他の仕様で言及される度に，手動で取扱う必要がある，別々な `delim$tok としてではなく）。
これによる唯一の帰結は、
符号とその実数の合間には，もはや~commentを挿入し得なくなったことである。
◎
&lt;number-token&gt;, &lt;percentage-token&gt;, and &lt;dimension-token&gt; have been changed to include the preceding +/- sign as part of their value (rather than as a separate &lt;delim-token&gt; 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.
</li>
	<li>
~WGによる解決に従って、
~SVGに合わせるため，［
実数／百分率／次元
］における科学的記数法も~supportされる。
◎
Scientific notation is supported for numbers/percentages/dimensions to match SVG, per WG resolution.
</li>
	<li>
［
`~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.
</li>
</ul>

<p>
構文解析における変更点：
◎
Parsing changes:
</p>
<ul>
	<li>
~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 &lt;semicolon-token&gt; and lets the next declaration begin.
</li>
	<li>
<p>
文法~内の様々な箇所に現れる，諸々の “特別な” ~token
（対になっていない `close-curly$Tok など）
の取扱いは、
少なくとも 1 つ以上の~browserに見られる，ある種の適理な挙動により指定された。
その種の~tokenが伴われた~stylesheetは、
以前までは，単に ~stylesheet文法に まったく合致しないものとされており、
その取扱いは，まったく定義されていなかった。
特定的には、
今や：
◎
The handling of some miscellaneous "special" tokens (like an unmatched &lt;}-token&gt;) 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:
</p>
		<ul>
			<li>
［
`角括弧~block$ ／ `丸括弧~block$ ／ `関数$
］は、［
`波括弧~block$,
`at-keyword$tok,
`semicolon$tok,
］のいずれをも包含し得る
◎
[] blocks, () blocks and functions can now contain {} blocks, &lt;at-keyword-token&gt;s or &lt;semicolon-token&gt;s
</li>
			<li>
有修飾~規則の.導入部は、
~semicolonを包含し得る
◎
Qualified rule preludes can now contain semicolons
</li>
			<li>
［
有修飾~規則 ／ ~at-規則の.導入部
］は、
`at-keyword$tok 包含し得る。
◎
Qualified rule and at-rule preludes can now contain &lt;at-keyword-token&gt;s
</li>
		</ul>
	</li>
</ul>

<p>
~AnB における， `Selectors Level 3^cite `SELECT$r からの変更点：
◎
An+B changes from Selectors Level 3 [SELECT]:
</p>
<ul>
	<li>
<p>
~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:
</p>
		<ul>
			<li>
一部の場合には、
負符号や数字を
（それらが `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 &lt;dimension-token&gt; or &lt;ident-token&gt;).
</li>
		</ul>
	</li>
</ul>

		</section>
	</section>
	<section>
<h2 id="acknowledgments">謝辞</h2>

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

<p lang="en">
	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.
</p>

	</section>
</main></div>