css-values-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>CSS の値と単位 — CSS Values and Units Module Level 4 （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-css.css" type="text/css">
<style>
img {
	background: white;
}
</style>

<style>

samp {
	margin-left: 0.6em;
	margin-right: 0.6em;
	white-space: nowrap;
}

.math-matrix td, 
.math-matrix th {
	min-width: 5em;
	text-align: center;
	white-space: nowrap;
}

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

#propvalues {
	grid-template-columns: 12em 1fr;
	min-width: 30em;
	tr {
		grid-template-areas:
			"prop 値定義"
			"prop 値例"
		;
		> *:nth-child(1) {
			grid-area: prop;
			border-left: none;
		}
		> *:nth-child(2) {
			grid-area: 値定義;
		}
		> *:nth-child(3) {
			grid-area: 値例;
			background: var(--bg-color-1);
		}
	}
}
}
</style>


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

<script>

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

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

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

	function create_html(match, key, indicator, klass){
if(!key) {//%
	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 'r':
	text = `[${key}]`;
	href = `#biblio-${key.toLowerCase()}`;
	break;
case 'tp': // property value type
	text = `&lt;'<code class="property">${key}</code>'&gt;`
	href = link_map[`p.${key}`];
	break;
case 'f':
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
	} else {
		text = `${key}()`;
	}
	break;
case 't':
	text = `&lt;${key}&gt;`;
	key = key.replace(/\s*\[.+/, '');
	break;
case 'p':
	{
		const i = key.indexOf(':');
		if( i > 0 ){
			key = text.slice(0, i);
			text = `${key}: <code class="value">${text.slice(i+1)}</code>`;
		}
	}
	break;
case 'at':
	text = `@${key}`;
	break;
case 'l':
	text = `"<code class="literal">${text}</code>"`;
	break;
case 'U':
	text = `U+${key}`
	break;
case 'en':
	return `<span lang="en">${key}</span>`
	break;
case 'issue':
	href = `~CSSissue/${key}`;
	text = `課題 #${key}`;
	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;

	}
}
</script>

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


●●options

spec_title:CSS Values and Units Module Level 4
spec_date:2025-03-04
trans_update:2025-03-05
source_checked:231218
page_state_key:CSS
original_url:https://drafts.csswg.org/css-values-4/
spec_status:ED
ref_id_prefix:biblio-
ref_id_lowercase:true
conformance:css
copyright:2025,permissive
trans_1st_pub:2012-07-17


●●class_map
p:property
d:descriptor
css:css
tp:type
t:type
g:prod
u:unit
at:at-rule
f:func
v:value
jv:js-value
e:element
a:attr
U:code-point
cn:cp-name

●●tag_map
p:code
d:code
t:var
tp:var
at:code
css:code
v:code
e:code
a:code
f:code
g:code
u:code
c:code
U:span
cn:span
i:i
em:em
jv:code
I:code
cite:cite

●●words_table1

0N:0⁻
0P:0⁺
NaN:NaN
vA:<var>A</var>
vB:<var>B</var>
vC:<var>C</var>
AMP:&amp;
autoS:auto

●●words_table


	●単位／値
	`px^u:pixel
Hertz::::ヘルツ
KiloHertz::::キロヘルツ
inch::::インチ
計量:metrics:~
測度:measure:~
pica::::パイカ
hash::::ハッシュ
feet::::フィート
milli:milli-:ミリ

centi:centi-:::センチ
meter::::メートル
	millimeter
	millimeters
	quarter-millimeters
	quarter-millimeter
	centimeter

radian::::ラジアン
grade::::グラード
gradian::::グラジアン
gon::::ゴン
point::::ポイント
dot::::ドット
alpha:
算出法:computation:~
数値:number::~
実数:number::~
	実数:real number
小数部:fractional component::~
	小数部:fractional portion
数量:quantity:~
数量-:numeric:~
	数量-値をとる:numeric-valued
数的:numeric:~
数量的:numerical:~
視野角:visual angle:~
音高:sound pitch:~
低音域:bass sound:~
高音域:treble sound:~

gradient:
	graphicな:graphical
解像度:resolution::~
方位角:bearing angle::~

周波数:frequency::~
二次元な:2D::~
三次元な:3D::~
多次元:N-dimensional::~
視聴距離:viewing distance::~
密度:density::~
固定d:fixed:固定
固定的:fixed:~
安定的:stable:~
円:circle:~
比率:ratio::~
科学的記数法:scientific notation:~
基数:base:~
	基数 10:base-ten
英数字:alphanumeric character:~
欧州の:European:~
CJK:
字l:letter::字°

	絶対~化:absolutize
	度:degrees
	度数:degrees
	単位を外した:cast down
	単位なしの:unitless
	単位なしで:without units
	継承されない:non-inherited
	解決し直す:re-resolve
	別の解決-法:alternate resolution mechanics
	検査-法:checking
	範囲~外:out-of-range

	●算術／数式
拡縮-:scale::~
縮尺:scale::~
	縮尺に依存しない:not scale-dependent
拡縮ng:scaling::拡縮
基準:reference:~
基準に:refer:~
	~~基準に:against
	~~基準に:with respect to
	負な値を~~基準に:negative basis
	に対して／に基づくように:against
	指す:refer
	表す:refer
	-:refer
近似-:approximate:~
近似的:approximate:~
	近似:approximate
近似:approximation:~
	約:approximately
	約:approximately equal to
開区間:open interval::~
閉区間:closed interval::~

	閉区間を成す:closed
	閉区間を成す:open

切詰ng:clamping::切り詰め
切詰める:clampする::切り詰める
切詰めら:clampさ::切り詰めら
切詰めた:clampした::切り詰めた
丸めら:roundさ::~
丸める:roundする::~
丸めた:roundした::~
丸ng:rounding::丸め

代数的:algebraic::~
代数:algebra::~
算術:arithmetic::~
簡約-:reduce::~

係数:factor:~
	±∞:infinities
中央-:central::~
	最小:min
	最大:max
最小v:<var>MIN</var>:<var>最小</var>
最大v:<var>MAX</var>:<var>最大</var>
値v:<var>VAL</var>:<var>値</var>

値A:<var>V</var><sub>A</sub>
値B:<var>V</var><sub>B</sub>
	%結果値:<var>V<sub>result</sub>

分解-:decompose::~
	分解-法:decomposing
累積-:accumulate::~
累積:accumulation::~
easing:
加重平均:weighted sum::~
平均:average:~
外挿-:extrapolate::~
外挿:extrapolation::~
中間-:intermediate:~
最終-:final:~
行列:matrix::~
差分:delta::~
math:
calc:
数学的:mathematical:~
数学:mathematics:~
数学体系:mathematical system:~
式:expression::~
下位式:sub-expression::~
	~math式:math expression
数値式:numeric expression::~
乗算的-:multiplicative::乗算
乗算済み:premultiplied::~
逆数に:invert::~
逆数:reciprocal::~
	0 による除算:division-by-zero
加法的:additive::~
累積的:accumulative::~
反数:negation::~
	反数:negated
総和:sum::~
積:product::~
可換:commutative::~
分配-:distribute:~
計算式:calculation:~
	予め計算-済み:pre-calculated
演算子:operator::~
IEEE-754:
有符号:signed::~
無符号:unsigned::~
符号n:sign::符号
正負:sign::~
	正負が一致する:are positive or both are negative
	正負が一致しない:opposite sides of zero
換算-:convert:~
	等しい:equal
剰余:modulus::~
段差:step::~
三角-:trigonometric::~
	三角-:trig
二進-:binary:~
浮動小数点:floating-point:~
対数:logarithm:~
	対数:log
	対数~化:logarithmed
底e:base:底
指数-:exponential:~
指数:exponent:~
二乗:square:~
	二乗:squaring
平方根:square-root:~
三乗根:cube-root:~
逆-:inverse:~
冪乗:power::~
	〜乗:raising A to the power of B
	累乗
	-:extreme
漸近:asymptote:~
	漸近~値:asymptote
漸近的:asymptotic:~
策:strategy::~
退化な:degenerateな:退化した
線形:linear::~
退化-:degenerate::~
比較関係:comparative relationship:~
留める:snapする:~
超越数:transcendental:~
同化-:censor:~

	丸めと剰余:stepped-value／:stepped value
	∞
	〜の 2 乗:²
	〜の 3 乗:³
	^i:Sum
	^i:Product
	^i:Invert
	^i:Negate
	^i:Min
	^i:Cos

	無限大:infinite
	無限大:infinite value
	NaN:NaN value
	量:amount
	~~相殺-:cancel-out
	~~相殺-:canceling
	奇数:odd integer
	偶数:-
	偶数:even
	奇数:odd
	以下:less than or equal to
	2 つある場合は〜近い方:halfway between adjacent 〜 towards
	逆算-:reverse the math
	“逆”:"arc" or "inverse"
	ごく近い:very close
	かけ離れ:very different
	巨大な:very large
	との差が〜の整数倍:〜and all values a multiple
	絶対~値:absolute difference from 0
	差（絶対~値として）:absolute difference
	差が等しい:both have an equal difference (A is exactly between the two values)
	整数倍:whole number of
	整数倍:multiple of／multiples of
	整数倍:integer multiple
	整数倍:integer number of
	整数倍:as a border width
	丸めた結果〜減算した結果:the difference between A
	円周率:ratio of a circle’s circumference to its diameter
	以上または以下:above or below
	〜 以上 〜 未満:[〜, 〜)
	10 進表記における桁数:count the number of digit
	~bit数:counting the number of bits
	^i:e
	^i:π
	中間点:halfway
	およそ:roughly
	大きさ:magnitude
	`補間-$した結果:interpolation
	下回る:below
	上回る:above
	近付く:approach
	^en:tangent
	十分近い:sufficiently close
	^en:not a number

	●構文
percent-::: %-
backslash::::バックスラッシュ
ampersand::::アンパサンド
asterisk::::アスタリスク
dash:
	空白:white space
二重:double::~
一重:single::~
縦棒:bar::~
	引用符で括られた／引用符~付き:quoted
角括弧:square bracket::~
	角括弧:bracket
角括弧付き:bracketed::~
	角括弧で括られ:bracketed
波括弧:curly braces::~
	波括弧:braces
山括弧:angle bracket::~
丸括弧:parenthesis::~
	丸括弧:parentheses
	丸括弧:parenthesized 〜
	左~丸括弧:left parenthesis
	左~丸括弧:open parenthesis
	右~丸括弧:right parenthesis
	右~丸括弧:close parenthesis
	右~丸括弧:literal closing parenthesis
	記号:mark／:sign
	10 進数:decimal
	16 進数:hexadecimal
	~literalに:literally
	~escape法:escaping
	class:group
	~group化:grouping
alphabet:::アルファベット
	alphabet順:alphabetical
attr:
複化子:multiplier::~
	複化子を伴わない:unmultiplied
改変子:modifier::~
非末端型:non-terminal::~
末端:terminal::~
	項:term
百分率-:percent:~
大小:case::~
大小法:casing:~
大小変換:casing::~
文字大小比較:case-sensitivity::文字大小の区別
	常に文字大小区別になる:all the case-sensitivity that implies
	codepoint
	構文解析-時:parsing
	識別:identifying
	構文単位:type, word, or group
文:statement::~
	並べて:alongside
貪欲:greedy:~
	greedily
	予約-済み:reserved
選択肢:option:~
排他的選択肢:alternative:排他的な選択肢
相互排他的:mutually exclusive:排他的
裸の:bare:~
深く:deepに:~
繰返n:repetition:繰り返し
切落n:truncation:切り落とし
連結-:concatenate:~
	連結-:join

	接頭されていない:unprefixed
	分類:category
	分類-:
	分類-:categorize
	分類される:fit into this category
	書式:formatted
	包装して:wrapper
	〜で包装-:function wrapper
	括られ:delimited
	括られ:surrounded
	括った上で:surrounded by
	〜で括って:between 〜
	括って:enclose
	前後に:surrounded by
	前後:before, after
	後続-:follow
	現れる:appear
	現れさ:appear
	〜あたりの〜数:number of occurrences per 〜
	回数:how many times the repetition occurs
	逆にする:reverse
	並び:sequence
	一連の:sequence
	~~細切れ:piecemeal
	そのまま:literal
	-:trim
	^f:attr
	名前空間~付き:namespaced
	無い:do not contain
	算出d値:computed-value
	`ident-token$t:ident
	な方を:whichever of
	ずらし:shifted
	入るよう:bring／:bringing
	~escapeされてない:unescaped
	棄てられ:thrown out
	重ねて記され:stacked
	少な過ぎ:too few
	多過ぎ:too many
	~list値をとる:list-valued
	個目の:th
	接頭辞を伴わない:unprefixed
	接頭辞を伴う:prefixed
	先頭:initial
	1 個目が省略された:empty starting value
	結合則を満たさない:not associative
	予め整形-済み:preformatted
	わたり:stretch across
	裸の:naked
	文法~上の:grammatical

	●layout / typeset
	size:width and height／:widths and heights
	長さの様なもの:length-like
高さ:height:~
	〜幅:wide
	〜幅:width
	〜~~高さ:tall
	縦長:tall
	横長:wide
横:horizontal::~
縦:vertical::~
植字-:typeset::~
送幅:advance measure::送り幅
	送幅:advance
	行:row
正立:upright::~
Latin:
x-:
cap-:
	~x-高さ:x-height
	~cap-高さ:cap-height
	^en:narrow
	^en:fullwidth
表語文字:ideographic::~
等幅:monospace::~
均衡幅:proportional::~
大字:capital letter:大文字
typographic::::タイポグラフィック
serif:
ascender::::アセンダ
descender::::ディセンダ
ascent::::アセント
限界:bounding::~
埋める:fillする:~
埋め:fillし:~
	埋め尽くす:fill／fill 〜 perfectly
	整形-法:formatting
収まる:fitする:~
余分:extra:~
	占める:take up
	周り:around
	~lay-outし直す:re-laying out

	●幾何
変形-:transform::~
変形:transform::~
並進-:translate::~
縦横比:aspect ratio::~
平面:plane:~
円錐:cone:~
投射-:project:~
正方形:square:~
	ほぼ正方形な:square or somewhat rectangular
形状付け:shaping:~
	~text形状付け:shaping

	左上隅:top left corner
	~~移動:travel
	~~移動:between an element’s starting and ending positions
	対頂線:the main diagonal
	各辺の:side
	小さくなる get smaller
	わずかに大きく:slightly greater
	点:point
	離れて:further away move
	元位置:starting point
	X 軸:X-axis
	時計回りに同様になる:and so on around the circle
描線幅:stroke width:~

	●CSS
基底線:baseline::~::ベースライン
全域:wide:~
CSSOM:
	表示域~百分率:viewport-percentage
連続的:continuous::~
不連続:discontinuous::~
協調-:coordinate:~
視野な:scopedな::~
	~tree視野な:tree-scoped
書字:writing::~
	下位prop:longhand
	色~channel:color-channel

	●UI
展開-:expand:~
展開:expansion:~
収納-:retract:~
収納:retraction:~
背後:behind:~
遮る:obscureする:~
遮られ:obscureされ:~
scrolling::::スクロール操作
toolbar::::ツールバー
footer::::フッタ
スマホ:phone:::~
動的性質:dynamism:~
ズラさな:shiftしな::ずらさな
妨げる:disturbする:~
妨げた:disturbした:~

	見栄えに劣る:not 〜 most attractive
	上層に重ねる:overlay
	~screen上:on-screen
	頻度が高い:frequent
	〜し始め:start 〜
	示す:show
	示され:shown
	隠す:hide
	隠され:hideされ
	~UI:interface
	~UI:chrome
	Safari
	出し入れする:shifting in and out
	変化しない:unchanged
	有無:presence
	小綺麗:prettier
	~~区画:real-estate
	~sizeし直:resize

	●処理
伝染的:infectious:~
一時的:temporary:~
組立てら:assembleさ:組み立てら
為す:makeする:~

	%~CORS~mode:corsMode
	%応答の処理n:processResponse
	%~byte~stream:byteStream
	%構文解析した~URL:parsedUrl
	%要請:req
	%応答:res
	%環境~設定群:environmentSettings
	応答の本体を消費する処理n:processResponseConsumeBody
	%長さ:len
	%~stylesheet:sheet
	%基底:base
	%~URL値:urlValue
	%~URL:url
	%基底:base
	%入力:input
	%別の型:-

	●保安
漏出-:exfiltrate:~

	●仕様
版:edition:~
後継版:successor:~
自明:trivial:~
複雑化-:complicate:複雑に
複雑:complicated:~
	複階的なので:complexities
理論的:theoretical:~
不可能:impossible:~
簡便さ:convenience:~
不便:inconvenient:~
名目上の:nominalな:~
不用意:accidental:~
自由:free:~
方策:strategy:~
理想上は:idealには:~
理想的:ideal:~
現実世界:real-world:~
現実の:reality:~
乖離:divergence:~
稀:rare:~
許容d:allowed:許容
指名-:designate:指定
定義済み:pre-defined:~
依存性:dependency:~
関係付ける:relateする:~
	~~換算-:relate
	を通して:related
拡張p:expansion:拡張
緩めら:relaxさ:~
勝つ:winする:~
表記-:denote:~
変種n:variation:変種
変種:variant:~
競合-:conflict:~
競合:conflict:~
読易い:readableな:読み易い
	読んで／読める-:read
	記され:written
	記せる:written
	記せない:written
	書く:write
	書く／書かれ:written
	書ける／書いた:write
	書いて:writing
	書ける:written
	書いた時点:At the time of writing
	書き出す:writing out
周知:well-known:~
規定-:dictate:~
分岐-:diverge:~
定期的:regular:~
調査-:study:~
賭ける:gambleする:~
前処理器:preprocessor::~::プリプロセッサ
衝突-:clash:~
綴る:spellする:~
綴られ:spellされ:~
特質:property:~
利用度:usage:~
考案-:invent:~
寄与-:contribute:~
相当な:substantialな:~
	~~有意な:substantialな
critical:
有益:beneficial:~
切替える:switchする:切り替える
切替えた:switchした:切り替えた
図画化-:depict:~
過度:excessive:~
尊重-:respect:~
取込んだ:importした:取り込んだ
明白:obvious:~
生来:natural:~
場当的:ad-hoc:場当たり的
扱い:treatment:~
慣例:convention:~
	慣例により:conventionally
推論:inference:~
復旧-:restore:~

	~~適する:reasonable
	〜下:at risk
	規範的でない:informative
	位置に応じて多義的になる:positionally-ambiguous
	~~不明瞭:less clear
	主要な:major
	ちょうど／片方だけ:exact に
	単純~化:simplification／simplify
	単純~性:simplicity
	一般~目的の:general-purpose
	汎用~的に:generically
	し難く:hard
	追跡し難く:hard-to-track-down
	難しくなる:harder
	~~機能上は:Functionality-wise
	制限されない:unlimited
	~~制限を~~緩める:make them any less binding
	広く:wide
	であっても:still
	~~理由:because
	別法として:Alternately
	誤り:mistakes
	価する:worth
	価するほど十分:enough
	十分:enough
	足る:sufficiently
	ごく少数に限られ:sufficiently few
	~~形に:fashion
	-:You
	-:occasional point
	一方で:whilst
	すなわち:that is
	すなわち:meaning
	〜種の:classes of
	さもなければ:otherwise／:or else
	〜を除いて:otherwise
	別として:aside from
	が、:altho
	厄介の元:troublesome
	にもかかわらず:despite
	少なからずある:not uncommon
	できなくする:prevent
	惑わす:confusing
	答え:answer
	-:realm
	いずれにせよ:either
	そのままに:leaving the 〜 alone
	何に基づくのか:provenance
	-:indeed
	かまわない:fine
	戻って:again
	日が浅い:new
	ほぼ確実に:almost certain
	作者:you
	見受けられる:it appears to be that
	点:matter
	問わず:no matter
	問われない:not matter
	どのみち:anyway
	見込まれ:likely
	選ばれ:chosen
	常用されない:corner
	アリな所すべてで:to the extent possible
	〜な限り:to the extent
	〜所までに限り:to the extent
	~~隅々まで:eagerly
	編集者:I
	能力がある:capable of
	通例の〜と同じく:as usual
	直感的でない:unintuitive
	一目では:at first glance
	まったく:perfectly
	主として:mostly

	局所~化:localize
	覆す:breaking
	存在しない:non-existent
	許容される範囲:allowable
	見よ:check
	間違っている:wrong-
	突然:suddenly
	〜したい:want
	として与えられた:state
	もたらす:create／cause
	編集時:editting
	余計:excess
	-:find
	必要に応じて:as needed
	該当:claim
	未だ充足されていない:unfulfilled
	から免れる:sidesteps
	悩まされ:suffer
	作者にとって:leaving you with
	沿わない:clashing
	仕事を成す:work out
	誰にとっても~~支障ない:won’t bite anyone
	待つ:wait
	解き明かす:figure out
	~~確保する:make sure
	課す:imposeする
	しようと:try
	真意が見え:obscure
	その誰か:reader
	dependent
	~~考えて:think
	選ぶ:pick する
	選ぶ:chooseする
	まとめる手間を要する:must be put together more manually
	手で打ち込まずに済む:Rather than require authors to manually type out
	まとめる:put together
	まかなう:cater
	の略:short for
	単に:just 〜immediately
	事実，:fact
	ようにした式:hacky way to say
	おそれ:fear
	可能性:possibility／may
	自らの手で:manually 〜 on their own
	何物にも:anything
	別の~library:Library2
	~tool法:tooling
	不幸にも:unfortunate
	以前の:earlier
	過去の:earlier
	-:Right now
	変わり:vary
	前述の:preceding
	ごく:quite
	-:would seem to indicate
	明瞭でない所もある:not entirely clear
	~costがかかる:costly
	貴重:premium
	原因／-:cause
	より安全:safer
	失われた:lost
	~UA既定の:UA-default
	~~安定して:steady
	いくつかある:different
	何らかの方法:somehow
	誤り:error
	アテガわれ:assignment
	逆になって:invert
	最新:latest
	ぼやかし:can blur
	差異:distinction
	ものになり得る:can potentially
	汎用~化:genericize
	元々:originally
	代替として:alternatively
	次の~algoにより:in a specific fashion
	〜が及ぶ視野:scoped
	結果:answer
	該当する:true
	見込みも低い:unlikely
	在るだけで:mere presence
	ときには，:sometimes
	言い直した:rephrase
	~~意見を募って:interested to hear
	生じる:causing
	きちんと:well-
	総じて:overall
	例えば:say,
	~~先送り:punt

	●言い換え
	〜を皮切りに:following 〜’s lead
	それに応じて:accordingly
	言えるか？:we're wondering
	同じになる:share
	しないよう:avoiding
	〜でも:in terms of
	の下で:in terms of
	子を持たない:leaf
	優先される:favoring
	優先度の高い:stronger
	~~結合度が高い:bind tighter than
	そのまま:unchanged
	除去する:discard
	前段落:preceding paragraph
	対応する~JS関数:it finds itself in
	互換:similar
	総称:general term
	~linkにあてがう:linking
	指す:pointer
	再度~要請:re-requesting
	~scrollbar:scroll bar
	分離-:separate out into
	~~内側の:inner
	様々な:many different
	同じになる:identical
	同じこと:identical
	省略時の既定:defaulting
	異なる:not shared
	逆~変換:converted back to...
	比率を成す 2 値の順序に関して:over "wide" and "tall" variants
	-:slightly taller than a 3 / 1 ratio
	戻ってくる:bring it back
	意味論的に明瞭に:clear semantic
	~animation用には:for this duration
	~~上限なし:no upper bound
	以下に挙げる~prop:certain properties
	上に挙げた~prop:the affected properties
	過去互換~用の:quirky
	過去互換~mode `quirks$r:Quirks Mode
	過去互換~mode$:Quirks Mode
	要素:the element they refer to
	~~通常どおり:continue to
	~vB が整数なら，:Aka
	全体を成していない:is not the sole
	値~全体を成す:sole value of
	伴わずに:absence of
	~URL:url
	個目~以降の値:excess values at the end of
	媒体~素片＠:Media Fragment
	^en:fuzzy
	~vA:X
	ぶつかり:hit
	値 0 をとる:zero-valued
	より優先される:supersede
	剥がされる:ripped~out
	値A 〜 値B:the two values 〜 second
	予め見做され:presume
	~Web互換性:Web-compat
	違反する:violation of
	新たな行lから:on its own line
	諮られ:contact
	これら:All of these locations
	の中へ直に入子にされた:Directly nested … (forming a
	その根を成す:top-most

	●未分類
覆う:coverする:~
覆われ:coverされ:~
	にわたる:coverする
敷詰めら:tileさ:敷き詰めら
混在な:mixされた:混在した
	混在な値:mix
混合-:mix:~
入替える:swapする:入れ替える
超過-:exceed:~
描く:drawする:~
種類:kind:~
葉:leaf::~::リーフ
枝分かれ:branch::~::ブランチ
所在指定子:locator::~
printer::::プリンタ
laser::::レーザ
monitor::::モニタ
時計回り:clockwise:~
欄:field:~
優先順位:precedence:~
生の:raw:~
完璧:perfect:完全
対称的:symmetrical:~
内包-:include:~
出版:publishing:~
clean:
red:
green:
blue:
URI:
維持-:retain:~
新規:fresh:~
側:side:~
body:

	得られ:yeilds
	組合でき:combinable
	異なる:different／differs
	外す:discard／drop
	最中に:in the middle of
	形を変える:shapeをchangeする
	なる:become
	であり続ける:stay as
	得られ:gain
	外へ~~漏れ:escape
	合間に~~挟まれ:nestled／:intersperse
	左から右の順:left-to-right
	居座る:stay
	築き上げる:building up
	戻す:send it back
	-:wrapper
	得る／得られ:yield
	-:happen
	戻-:back
	-:encounter
	転換され:turned into
	転換-:turn
	が:Although
	~~形:shape／
	高-:high-
	低-:low-
	高い:high
	低い／低:low
	低いB:lower B
	高いB:upper B
	-:capacity
	欄
	potentially
	個数:count
	^en:word cloud
	~font~size:font-size
	ただ記す:just putting an
	何桁もの数:enormous number
	~JS:JS
	欠いて:lack
	無い:lack
	まさにこの~~不安を抱えた:exactly this fraught
	一部も成す:subset
	〜に反して:contrary to
	残って:left at
	し始める:start
	同時に:simultaneously
	〜以下, 〜以上:equivalent to 〜 intermediary
	下位-画素:subpixel
	住まう:live
	同じ名前を伴う:correspondingly-named
	来る:come
	一つだけの:singular
	現時点では:at this point
	~data喪失:dataloss
	〜が置かれた場所:if substituted in its place
	引数:own
	先頭の:leading
	以前／前の:previous
	部分:part
	普通の:ordinaryな
	~~普通でない:unusual
	他の:cross-
	過ぎない:just
	最も近い:nearest
	最も近い:closest
	単に:just／merely
	近い:closer
	最~小:smallest
	小さい方:smallest
	小さい方:smaller
	小さい:small
	より小さ:smaller
	大きい:large
	より大きい:larger
	大きい方:larger
	最も大きい:largest
	に大きく:largely
	巨大:large
	〜だけ大きくなる:grow as large as 〜
	合間に入る:between
	異種の:disparate
	以降:or later
	何か:anything／:any
	節:section／:chapter
	左側:left
	右側:right
	時点:time
	時点:point
	-:as a whole
	所:somewhere
	どこでも:any place
	いくつも:many
	他の部分:elsewhere
	~~内側の:inner
	~top-levelの:outer
	他と同じく:continue
	以外はすべて:everything but
	から:start with
	だけ:just
	誰か:someone
	後で:later
	反対の:opposite
	正反対:opposite
	-:themselves
	それ自体:itself
	そのままに:on its own
	上の〜:preceding
	-:at-least
	-:distinct
	最後に:finally
	多い:many times
	これまでの:earlier
	何もかも:everything-
	より高-:higher
	種々の:various
	隣に:next to
	次に〜:next
	留めた:pin

●●original_id_map

	length-advance-measure:advance-measure
	math:calc-notation
	visual-angle-unit:pixel-unit

●●mdn_urls

identifier-value:CSS/custom-ident
typedef-ident:CSS/ident
string-value:CSS/string
url-value:CSS/url
number-value:CSS/number
integer-value:CSS/integer
percentage-value:CSS/percentage
typedef-dimension:CSS/dimension
length-value:CSS/length
typedef-length-percentage:CSS/length-percentage
resolution-value:CSS/resolution
angle-value:CSS/angle
typedef-angle-percentage:CSS/angle-percentage
time-value:CSS/time
typedef-time-percentage:CSS/time-percentage
frequency-value:CSS/frequency
typedef-frequency-percentage:CSS/frequency-percentage
typedef-position:CSS/position_value
	typedef-url-modifier:CSS/？
	zero-value:CSS/zero
	typedef-calc-product:CSS/calc-product
	typedef-calc-sum:CSS/？
	typedef-calc-value:CSS/？
	typedef-calc-keyword:CSS/？
	typedef-rounding-strategy:CSS/？

funcdef-url:CSS/url()
funcdef-abs:CSS/abs()
	funcdef-acos:CSS/acos
	funcdef-asin:CSS/asin
	funcdef-atan2:CSS/atan2
	funcdef-atan:CSS/atan
funcdef-calc:CSS/calc()
funcdef-clamp:CSS/clamp()
	funcdef-cos:CSS/cos
	funcdef-exp:CSS/exp
	funcdef-hypot:CSS/hypot
	funcdef-log:CSS/log
funcdef-max:CSS/max()
funcdef-min:CSS/min()
	funcdef-mod:CSS/mod
	funcdef-pow:CSS/pow
	funcdef-rem:CSS/rem
	funcdef-round:CSS/round
	funcdef-sign:CSS/sign
	funcdef-sin:CSS/sin
	funcdef-sqrt:CSS/sqrt
	funcdef-tan:CSS/tan

Hz:CSS/frequency#Hz
q:CSS/length#q
cap:CSS/length#cap
ch:CSS/length#ch
cm:CSS/length#cm
deg:CSS/angle#deg
dpcm:CSS/resolution#dpcm
dpi:CSS/resolution#dpi
dppx:CSS/resolution#dppx
em:CSS/length#em
ex:CSS/length#ex
grad:CSS/angle#grad
ic:CSS/length#ic
in:CSS/length#in
kHz:CSS/frequency#kHz
lh:CSS/length#lh
mm:CSS/length#mm
ms:CSS/time#ms
pc:CSS/length#pc
pt:CSS/length#pt
px:CSS/length#px
rad:CSS/angle#rad
rem:CSS/length#rem
rlh:CSS/length#rlh
s:CSS/time#s
turn:CSS/angle#turn
vb:CSS/length#vb
dvb:CSS/length#vb
lvb:CSS/length#vb
svb:CSS/length#vb
vh:CSS/length#vh
dvh:CSS/length#vh
lvh:CSS/length#vh
svh:CSS/length#vh
vi:CSS/length#vi
dvi:CSS/length#vi
lvi:CSS/length#vi
svi:CSS/length#vi
vmax:CSS/length#vmax
dvmax:CSS/length#vmax
lvmax:CSS/length#vmax
svmax:CSS/length#vmax
vmin:CSS/length#vmin
dvmin:CSS/length#vmin
lvmin:CSS/length#vmin
svmin:CSS/length#vmin
vw:CSS/length#vw
dvw:CSS/length#vw
lvw:CSS/length#vw
svw:CSS/length#vw
x:CSS/resolution#x


●●link_map

	●IDL
I.CSSMathValue:~CSSTOM1#cssmathvalue
I.CSSStyleSheet:~CSSOM1#cssstylesheet
I.RequestDestination:~FETCH#requestdestination
I.ShadowRoot:~DOM4#shadowroot
I.Document:~DOM4#document

c.CSS.supports():~CSSCOND#dom-css-supports
	:~CSSCOND#dom-css-supports-conditiontext

	●SYNATX
t.at-keyword-token:~CSSSYN#typedef-at-keyword-token
t.ident-token:~CSSSYN#typedef-ident-token
t.whitespace-token:~CSSSYN#typedef-whitespace-token
t.delim-token:~CSSSYN#typedef-delim-token
t.dimension-token:~CSSSYN#typedef-dimension-token
t.string-token:~CSSSYN#typedef-string-token
t.url-token:~CSSSYN#typedef-url-token
t.number-token:~CSSSYN#typedef-number-token
t.percentage-token:~CSSSYN#typedef-percentage-token
t.function-token:~CSSSYN#typedef-function-token

	●types
t.angle-percentage:#typedef-angle-percentage
t.angle:#angle-value

t.ident:#typedef-ident
t.custom-ident:#identifier-value
t.dashed-ident:#typedef-dashed-ident
t.dimension:#typedef-dimension
t.frequency-percentage:#typedef-frequency-percentage
t.frequency:#frequency-value
t.integer:#integer-value
t.length-percentage:#typedef-length-percentage
t.length:#length-value
t.number:#number-value
t.percentage:#percentage-value
t.quirky-length:#typedef-quirky-length
t.ratio:#ratio-value
t.resolution:#resolution-value
t.string:#string-value
t.time-percentage:#typedef-time-percentage
t.time:#time-value
t.url-modifier:#typedef-url-modifier
t.url:#url-value
t.zero:#zero-value

t.calc-product:#typedef-calc-product
t.calc-sum:#typedef-calc-sum
t.calc-value:#typedef-calc-value
t.calc-keyword:#typedef-calc-keyword
t.rounding-strategy:#typedef-rounding-strategy

t.any-value:~CSSSYN#typedef-any-value
t.flex:~CSSGRID#typedef-flex
t.image:~CSSIMAGE#typedef-image
t.color:~CSSCOLOR#typedef-color
	t.color:~CSSCOLOR5#typedef-color
t.position:#typedef-position
t.easing-function:~CSSEASING#typedef-easing-function
t.filter-value-list:~FILTERS#typedef-filter-value-list

	●prop

p.all:~CASCADE#propdef-all
p.animation-iteration-count:~CSSANIM#propdef-animation-iteration-count
p.animation-name:~CSSANIM#propdef-animation-name
p.animation-timing-function:~CSSANIM#propdef-animation-timing-function
p.animation:~CSSANIM#propdef-animation
p.background-attachment:~CSSBG#propdef-background-attachment
p.background-image:~CSSBG#propdef-background-image
p.background-position:~CSSBG#propdef-background-position
p.background:~CSSBG#propdef-background
p.block-step-round:~CSSWG/css-rhythm-1/#propdef-block-step-round
p.block-step-size:~CSSWG/css-rhythm-1/#propdef-block-step-size
p.border-bottom-width:~CSSBG#propdef-border-bottom-width
p.border-collapse:~CSS2TABLE#propdef-border-collapse
p.border-color:~CSSBG#propdef-border-color
p.border-left-width:~CSSBG#propdef-border-left-width
p.border-right-width:~CSSBG#propdef-border-right-width
p.border-spacing:~CSS2TABLE#propdef-border-spacing
	p.border-spacing:~CSSWG/css2/#propdef-border-spacing
p.border-top-width:~CSSBG#propdef-border-top-width
p.border-width:~CSSBG#propdef-border-width
p.bottom:~CSSPOS#propdef-bottom
p.box-shadow:~CSSBG#propdef-box-shadow
p.box-sizing:~SIZING#propdef-box-sizing
p.clip:~MASKING1#propdef-clip
p.font-family:~CSSFONT#propdef-font-family
p.font-size:~CSSFONT#propdef-font-size
p.font:~CSSFONT#propdef-font
p.height:~SIZING#propdef-height
p.image-resolution:~CSSIMAGE4#propdef-image-resolution
p.left:~CSSPOS#propdef-left
p.letter-spacing:~CSSTEXT#propdef-letter-spacing
p.line-height:~CSSINLINE#propdef-line-height
	p.line-height:~CSS2J#propdef-line-height
p.margin-bottom:~CSSBOX#propdef-margin-bottom
p.margin-left:~CSSBOX#propdef-margin-left
p.margin-right:~CSSBOX#propdef-margin-right
p.margin-top:~CSSBOX#propdef-margin-top
p.margin:~CSSBOX#propdef-margin
p.max-height:~SIZING#propdef-max-height
p.max-lines:~CSSOVERFLOW4#propdef-max-lines
p.max-width:~SIZING#propdef-max-width
p.min-height:~SIZING#propdef-min-height
p.min-width:~CSS2J#propdef-min-width
p.min-width:~SIZING#propdef-min-width
p.opacity:~CSSCOLOR#propdef-opacity
p.orphans:~CSSBREAK#propdef-orphans
p.outline-color:~CSSUI#propdef-outline-color
p.overflow:~CSSOVERFLOW3#propdef-overflow
p.padding-bottom:~CSSBOX#propdef-padding-bottom
p.padding-left:~CSSBOX#propdef-padding-left
p.padding-right:~CSSBOX#propdef-padding-right
p.padding-top:~CSSBOX#propdef-padding-top
p.padding:~CSSBOX#propdef-padding
p.right:~CSSPOS#propdef-right
p.scrollbar-gutter:~CSSOVERFLOW3#propdef-scrollbar-gutter
p.tab-size:~CSSTEXT#propdef-tab-size
p.text-align:~CSSTEXT#propdef-text-align
p.text-decoration:~CSSTEXTDECOR#propdef-text-decoration
p.text-indent:~CSSTEXT#propdef-text-indent
p.text-orientation:~CSSWM#propdef-text-orientation
p.top:~CSSPOS#propdef-top
p.transform-origin:~TRANSFORM#propdef-transform-origin
p.vertical-align:~CSSINLINE#propdef-vertical-align
p.width:~SIZING#propdef-width
p.word-spacing:~CSSTEXT#propdef-word-spacing
p.writing-mode:~CSSWM#propdef-writing-mode

	●units
u.Hz:#Hz
u.Q:#q
u.cap:#cap
u.ch:#ch
u.cm:#cm
u.deg:#deg
u.dpcm:#dpcm
u.dpi:#dpi
u.dppx:#dppx
u.dvb:#dvb
u.dvh:#dvh
u.dvi:#dvi
u.dvmax:#dvmax
u.dvmin:#dvmin
u.dvw:#dvw
u.em:#em
u.ex:#ex
u.fr:~CSSGRID#valdef-flex-fr
u.grad:#grad
u.ic:#ic
u.in:#in
u.kHz:#kHz
u.lh:#lh
u.lvb:#lvb
u.lvh:#lvh
u.lvi:#lvi
u.lvmax:#lvmax
u.lvmin:#lvmin
u.lvw:#lvw
u.mm:#mm
u.ms:#ms
u.pc:#pc
u.pt:#pt
u.px:#px
u.q:#q
u.rad:#rad
u.rcap:#rcap
u.rch:#rch
u.rem:#rem
u.rex:#rex
u.ric:#ric
u.rlh:#rlh
u.s:#s
u.svb:#svb
u.svh:#svh
u.svi:#svi
u.svmax:#svmax
u.svmin:#svmin
u.svw:#svw
u.turn:#turn
u.vb:#vb
u.vh:#vh
u.vi:#vi
u.vmax:#vmax
u.vmin:#vmin
u.vw:#vw
u.x:#x

	●val

	#valdef-mix-percentage

v.disc:~CSSCOUNTER#disc
	？box:~CSSCOUNTER#box
	css2/generate.html

v.vertical-rl:~CSSWM#valdef-writing-mode-vertical-rl
v.vertical-lr:~CSSWM#valdef-writing-mode-vertical-lr
v.upright:~CSSWM#valdef-text-orientation-upright

v.unset:~CASCADE#valdef-all-unset
v.inherit:~CASCADE#valdef-all-inherit
v.initial:~CASCADE#valdef-all-initial

v.ease-in:~CSSEASING#valdef-cubic-bezier-easing-function-ease-in
v.ease-out:~CSSEASING#valdef-cubic-bezier-easing-function-ease-out

v.inset:~CSSBG#shadow-inset

v.~autoS:~SIZING#valdef-width-auto

v.nearest:#valdef-rounding-strategy-nearest
v.up:#valdef-rounding-strategy-up
v.down:#valdef-rounding-strategy-down
v.to-zero:#valdef-rounding-strategy-to-zero

v.e:#valdef-calc-e
v.pi:#valdef-calc-pi
v.-infinity:#valdef-calc--infinity
v.infinity:#valdef-calc-infinity
v.NaN:#valdef-calc-nan
v.none:#valdef-clamp-none

	●func
f.var:~CSSVAR#funcdef-var
f.rgba:~CSSCOLOR#funcdef-rgba
f.hsl:~CSSCOLOR#funcdef-hsl

f.linear-gradient:~CSSIMAGE#funcdef-linear-gradient

f.url:#funcdef-url
f.src:#funcdef-src
f.mix:~CSSVAL5#funcdef-mix

f.abs:#funcdef-abs
f.acos:#funcdef-acos
f.asin:#funcdef-asin
f.atan2:#funcdef-atan2
f.atan:#funcdef-atan
f.calc:#funcdef-calc
f.clamp:#funcdef-clamp
f.cos:#funcdef-cos
f.exp:#funcdef-exp
f.hypot:#funcdef-hypot
f.log:#funcdef-log
f.max:#funcdef-max
f.min:#funcdef-min
f.mod:#funcdef-mod
f.pow:#funcdef-pow
f.rem:#funcdef-rem
f.round:#funcdef-round
f.sign:#funcdef-sign
f.sin:#funcdef-sin
f.sqrt:#funcdef-sqrt
f.tan:#funcdef-tan

	f.rect:~CSSCHAPES#funcdef-basic-shape-rect
f.rect:~MASKING1#funcdef-clip-rect
f.media-progress:~CSSVAL5#funcdef-media-progress

t.url():#funcdef-url
t.src():#funcdef-src

t.abs():#funcdef-abs
t.acos():#funcdef-acos
t.asin():#funcdef-asin
t.atan():#funcdef-atan
t.atan2():#funcdef-atan2
t.calc():#funcdef-calc
t.clamp():#funcdef-clamp
t.cos():#funcdef-cos
t.exp():#funcdef-exp
t.hypot():#funcdef-hypot
t.log():#funcdef-log
t.max():#funcdef-max
t.min():#funcdef-min
t.mod():#funcdef-mod
t.pow():#funcdef-pow
t.rem():#funcdef-rem
t.round():#funcdef-round
t.sign():#funcdef-sign
t.sin():#funcdef-sin
t.sqrt():#funcdef-sqrt
t.tan():#funcdef-tan


	●他

e.base:~HEmetadata#the-base-element

at.media:~CSSCOND#at-ruledef-media
at.supports:~CSSCOND#at-ruledef-supports
at.import:~CASCADE#at-ruledef-import
at.color-profile:~CSSCOLOR5#at-ruledef-profile
at.font-face:~CSSFONT#at-font-face-rule

d.resolution:~MQ5#descdef-media-resolution

	●構文
g.#:#component-multipliers
g.,:#comb-comma
g.||:#comb-any
g.~AMP~AMP:#comb-all
g.|:#comb-one
g.!:#mult-req
g.#:#mult-comma
g.+:#mult-one-plus
g.*:#mult-zero-plus
g.?:#mult-opt
	{A}:mult-num
	{A,B}:mult-num-range

値~定義の構文:#css-value-definition-syntax
関数-記法:#functional-notation
複化子:#component-multipliers
結合子:#component-combinators
~textな~data型:#css-textual-data-types
数量-~data型:#numeric-data-types
角括弧付き範囲~記法:#css-bracketed-range-notation
~CSS文法~生成規則~block:#css-grammar-production-block

	●用語
実数:#number
整数:#integer
百分率:#percentage
次元:#dimension
比率:#ratio
退化な比率:#degenerate-ratio

最も近い整数に丸められ:#css-round-to-the-nearest-integer
最も近い整数に丸める:#css-round-to-the-nearest-integer

~keyword:#css-keyword
定義済み~keyword:#css-keyword
~CSS全域~keyword:#css-wide-keywords
~CSS識別子:#css-css-identifier
	~CSS識別子:~CSSSYN#ident-sequence

物理-単位:#physical-unit
互換:#compatible-units
正準-単位:#canonical-unit
相対~長さ単位:#relative-length
絶対~長さ単位:#absolute-length
指定d長さ:#specified-length
算出d長さ:#computed-length
~anchor単位:#anchor-unit
長さを機器~画素の整数倍に留める:#snap-a-length-as-a-border-width

表示域~百分率:#viewport-percentage
表示域~百分率による長さ:#viewport-percentage-lengths
既定の表示域~用の百分率~単位:#default-viewport-percentage-units
動的な表示域~用の百分率~単位:#dynamic-viewport-percentage-units
動的な表示域~size:#dynamic-viewport-size
大きい表示域~用の百分率~単位:#large-viewport-percentage-units
大きい表示域~size:#large-viewport-size
小さい表示域~用の百分率~単位:#small-viewport-percentage-units
小さい表示域~size:#small-viewport-size

視野角~単位:#visual-angle-unit
~pixel単位:#visual-angle-unit
	~pixel単位:#pixel-unit
機器~画素:#device-pixel

局所~URLか:#url-local-url-flag

基準~pixel:#reference-pixel
方位角:#bearing-angle
~comma:#comb-comma
~fontに相対的な長さ:#font-relative-length
~fontに相対的な長さ（局所的）:#local-font-relative-lengths
~fontに相対的な長さ（根）:#root-font-relative-lengths
送幅:#length-advance-measure
文字~送幅:#length-advance-measure

~math関数:#math-function
有符号 0:#css-signed-zero
無限大:#css-infinity
~NaN:#css-nan
計算式:#calc-calculation
計算式~tree:#calculation-tree
計算式を構文解析する:#parse-a-calculation
計算式~treeを単純~化する:#simplify-a-calculation-tree
計算式~treeを単純~化:#simplify-a-calculation-tree
計算式~treeを直列化する:#serialize-a-calculation-tree
~math関数を直列化する:#serialize-a-math-function
演算子~node:#calculation-tree-operator-nodes
~calc演算子~node:#calculation-tree-calc-operator-nodes
~top-levelの計算式:#top-level-calculation
型を決定-:#determine-the-type-of-a-calculation
型を決定する:#determine-the-type-of-a-calculation
根の子たちを~sortする:#sort-a-calculations-children
	合間:#between-zero-and-b

結合-:#combine
補間:#interpolation
補間-:#interpolation
加算:#addition
加算-:#addition
累積:#accumulation
累積-:#accumulation
加法的でない:#not-additive

§ 型の検査-法:#calc-type-checking
一貫した型を有して:#_css-consistent-type
一貫した型:#css-consistent-type
百分率を包含して:#css-contain-a-percentage
型を入力と一貫させる:#css-make-a-type-consistent

~style資源を~fetchする:#fetch-a-style-resource
~URLの要請~改変子~用の手続き:#url-request-modifier-steps

協調している~list~prop~group:#coordinating-list-property
協調される値~list:#coordinated-value-list
協調している基底~list~prop:#coordinating-list-base-property

~level 5:#biblio-css-values-5

	●外部（CSS

離散的:~WANIM#discrete

型:~CSSTOM1#cssnumericvalue-type
基底~型:~CSSTOM1#cssnumericvalue-base-type
対応する基底~型:~CSSTOM1#_base-type-for
型を作成する:~CSSTOM1#cssnumericvalue-create-a-type
型を加算する:~CSSTOM1#cssnumericvalue-add-two-types
型を乗算する:~CSSTOM1#cssnumericvalue-multiply-two-types
型を逆数にする:~CSSTOM1#cssnumericvalue-invert-a-type
合致する:~CSSTOM1#cssnumericvalue-match
百分率-~hint:~CSSTOM1#cssnumericvalue-percent-hint
百分率-~hintを適用する:~CSSTOM1#apply-the-percent-hint
内部~表現:~CSSTOM1#css-internal-representation

無視する:~CSSSYN#css-ignored
~at-規則:~CSSSYN#at-rule
~escape法:~CSSSYN#escape-codepoint

算出d値:~CASCADE#computed-value
使用~値:~CASCADE#used-value
指定d値:~CASCADE#specified-value
実際の値:~CASCADE#actual-value
初期~値:~CASCADE#initial-value
解決d値:~CSSOM1#resolved-values

継承:~CASCADE#css-inheritance
略式~prop:~CASCADE#shorthand-property
下位prop:~CASCADE#longhand

~custom~prop:~CSSVAR#custom-property

~escape:~CSSSYN#escape-codepoint
	~escape:~CSS22/syndata.html#escaped-characters

~easing関数:~CSSEASING#easing-function

包含塊:~CSSDISP#containing-block
初期~包含塊:~CSSDISP#initial-containing-block
整形~文脈:~CSSDISP#formatting-context
根~要素:~CSSDISP#root-element

行内-軸:~CSSWM#inline-axis
塊-軸:~CSSWM#block-axis
塊~size:~CSSWM#block-size

成分~値:~CSSSYN#component-value
丸括弧~block:~CSSSYN#paren-block
	単純~block:~CSSSYN#simple-block
	関数:~CSSSYN#function
空白:~CSSSYN#whitespace
	:~CSSSYN#consume-a-url-token

~tree視野な参照:~CSSSCOPING#css-tree-scoped-reference
~tree視野な名前:~CSSSCOPING#css-tree-scoped-name

媒体~特能:~MQ5#media-feature
媒体~query:~MQ5#media-query
連続的~媒体:~MQ5#continuous-media
~paged媒体:~MQ5#paged-media

~page区画:~CSSPAGE#page-area

直列化-:~CSSOM1#serializing-css-values

背景~位置決め区画:~CSSBG#background-positioning-area

ss.所在:~CSSOM1#concept-css-style-sheet-location
ss.~stylesheet基底~URL:~CSSOM1#concept-css-style-sheet-stylesheet-base-url
ss.生成元~cleanか:~CSSOM1#concept-css-style-sheet-origin-clean-flag

可用な最初の~font:~CSSFONT#first-available-font

現代の色~構文:~CSSCOLOR#modern-color-syntax
相対~色~構文:~CSSCOLOR5#relative-color
色~関数:~CSSCOLOR#color-functions

	●外部（他

実装定義:~INFRA#implementation-defined
符号位置:~INFRA#code-point
文字列:~INFRA#string
~ASCII大小無視:~INFRA#ascii-case-insensitive
連結する:~INFRA#string-concatenate
~list:~INFRA#list
付加する:~INFRA#list-append

過去互換~mode:~DOM4#concept-document-quirks
~node~tree:~DOM4#concept-node-tree
~tree順序:~DOM4#concept-tree-order
~ID:~DOM4#concept-id
~shadow~host:~DOM4#element-shadow-host

~URL:~URL1#concept-url
~URL構文解析する:~URL1#concept-url-parser
~URLを直列化する:~URL1#concept-url-serializer
url.素片:~URL1#concept-url-fragment

応答:~FETCH#concept-response
要請:~FETCH#concept-request
rq.行先:~FETCH#concept-request-destination
rq.~URL:~FETCH#concept-request-url
rq.~mode:~FETCH#concept-request-mode
rq.生成元:~FETCH#concept-request-origin
rq.資格証~mode:~FETCH#concept-request-credentials-mode
rq.~URL資格証を利用するか:~FETCH#concept-request-use-url-credentials-flag
rq.~referrer:~FETCH#concept-request-referrer
rq.~client:~FETCH#concept-request-client
rq.起動元~種別:~FETCH#request-initiator-type
~fetchする:~FETCH#concept-fetch
i.応答の本体を消費する処理n:~FETCH#process-response-end-of-body

関連な設定群~obj:~WAPI#relevant-settings-object
enV.~API用~基底~URL:~WAPI#api-base-url
enV.生成元:~WAPI#concept-settings-object-origin

指示された要素を見出す:~HTMLnav#find-a-potential-indicated-element

●●images
＠css-values/
Typography_Line_Terms｜height:9em｜｜.svg
pixel1｜height:360px;｜｜.png
pixel2｜height:321px;｜｜.png

●●ref_key_map
CSS3BACKGROUND:CSSBACKGROUNDS3
CSS3FONTS:CSSFONTS3
CSS3IMAGES:CSSIMAGES3
MEDIAQ:MEDIAQUERIES4

●●ref_normative

[CSS-2023]
    Chris Lilley; et al. ＜CSS Snapshot 2023＞. URL: https://drafts.csswg.org/css-2023/
[CSS-BOX-4]
    Elika Etemad. ＜CSS Box Model Module Level 4＞. URL: https://drafts.csswg.org/css-box-4/
[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-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-CONDITIONAL-3]
    Chris Lilley; David Baron; Elika Etemad. ＜CSS Conditional Rules Module Level 3＞. URL: https://drafts.csswg.org/css-conditional-3/
[CSS-COUNTER-STYLES-3]
    Tab Atkins Jr.. ＜CSS Counter Styles Level 3＞. URL: https://drafts.csswg.org/css-counter-styles/
[CSS-DISPLAY-4]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Display Module Level 4＞. URL: https://drafts.csswg.org/css-display/
[CSS-EASING-2]
    ＜CSS Easing Functions Level 2＞. URL: https://drafts.csswg.org/css-easing/
[CSS-FONTS-4]
    Chris Lilley. ＜CSS Fonts Module Level 4＞. URL: https://drafts.csswg.org/css-fonts-4/
[CSS-FONTS-5]
    Chris Lilley. ＜CSS Fonts Module Level 5＞. URL: https://drafts.csswg.org/css-fonts-5/
[CSS-GRID-2]
    Tab Atkins Jr.; Elika Etemad; Rossen Atanassov. ＜CSS Grid Layout Module Level 2＞. URL: https://drafts.csswg.org/css-grid-2/
[CSS-IMAGES-4]
    Tab Atkins Jr.; Elika Etemad; Lea Verou. ＜CSS Images Module Level 4＞. URL: https://drafts.csswg.org/css-images-4/
[CSS-INLINE-3]
    Elika Etemad. ＜CSS Inline Layout Module Level 3＞. URL: https://drafts.csswg.org/css-inline-3/
[CSS-MASKING-1]
    Dirk Schulze; Brian Birtles; Tab Atkins Jr.. ＜CSS Masking Module Level 1＞. URL: https://drafts.fxtf.org/css-masking-1/
[CSS-OVERFLOW-3]
    Elika Etemad; Florian Rivoal. ＜CSS Overflow Module Level 3＞. URL: https://drafts.csswg.org/css-overflow-3/
[CSS-PAGE-3]
    Elika Etemad. ＜CSS Paged Media Module Level 3＞. URL: https://drafts.csswg.org/css-page-3/
[CSS-POSITION-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Positioned Layout Module Level 3＞. URL: https://drafts.csswg.org/css-position-3/
[CSS-SCOPING-1]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Scoping Module Level 1＞. URL: https://drafts.csswg.org/css-scoping/
[CSS-SHAPES-1]
    Rossen Atanassov; Alan Stearns. ＜CSS Shapes Module Level 1＞. URL: https://drafts.csswg.org/css-shapes/
[CSS-SIZING-3]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Box Sizing Module Level 3＞. URL: https://drafts.csswg.org/css-sizing-3/
[CSS-SYNTAX-3]
    Tab Atkins Jr.; Simon Sapin. ＜CSS Syntax Module Level 3＞. URL: https://drafts.csswg.org/css-syntax/
[CSS-TEXT-4]
    Elika Etemad; et al. ＜CSS Text Module Level 4＞. URL: https://drafts.csswg.org/css-text-4/
[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-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-2]
    ＜CSS Custom Properties for Cascading Variables Module Level 2＞. Editor's Draft. URL: https://drafts.csswg.org/css-variables-2/
[CSS-WRITING-MODES-4]
    Elika Etemad; Koji Ishii. ＜CSS Writing Modes Level 4＞. URL: https://drafts.csswg.org/css-writing-modes-4/
[CSS2]
    Bert Bos; et al. ＜Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification＞. URL: https://drafts.csswg.org/css2/
[CSS3-BACKGROUND]
    Elika Etemad; Brad Kemper. ＜CSS Backgrounds and Borders Module Level 3＞. URL: https://drafts.csswg.org/css-backgrounds/
[CSS3-FONTS]
    John Daggett; Myles Maxfield; Chris Lilley. ＜CSS Fonts Module Level 3＞. URL: https://drafts.csswg.org/css-fonts-3/
[CSS3-IMAGES]
    Tab Atkins Jr.; Elika Etemad; Lea Verou. ＜CSS Images Module Level 3＞. URL: https://drafts.csswg.org/css-images-3/
[CSSOM]
    Daniel Glazman; Emilio Cobos Álvarez. ＜CSS Object Model (CSSOM)＞. URL: https://drafts.csswg.org/cssom/
[DOM]
    Anne van Kesteren. ＜DOM Standard＞. Living Standard. URL: https://dom.spec.whatwg.org/
[FETCH]
    Anne van Kesteren. ＜Fetch Standard＞. Living Standard. URL: https://fetch.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/
[MEDIAQUERIES-5]
    Dean Jackson; et al. ＜Media Queries Level 5＞. URL: https://drafts.csswg.org/mediaqueries-5/
[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
[UNICODE]
    ＜The Unicode Standard＞. URL: https://www.unicode.org/versions/latest/
[URL]
    Anne van Kesteren. ＜URL Standard＞. Living Standard. URL: https://url.spec.whatwg.org/
[WEB-ANIMATIONS-1]
    Brian Birtles; et al. ＜Web Animations＞. URL: https://drafts.csswg.org/web-animations-1/

●●ref_informative

[CSS-ANIMATIONS-1]
    David Baron; et al. ＜CSS Animations Level 1＞. URL: https://drafts.csswg.org/css-animations/
[CSS-BREAK-3]
    Rossen Atanassov; Elika Etemad. ＜CSS Fragmentation Module Level 3＞. URL: https://drafts.csswg.org/css-break/
[CSS-CASCADE-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 3＞. URL: https://drafts.csswg.org/css-cascade-3/
[CSS-COLOR-3]
    Tantek Çelik; Chris Lilley; David Baron. ＜CSS Color Module Level 3＞. URL: https://drafts.csswg.org/css-color-3/
[CSS-GRID-1]
    Tab Atkins Jr.; et al. ＜CSS Grid Layout Module Level 1＞. URL: https://drafts.csswg.org/css-grid/
[CSS-OVERFLOW-4]
    David Baron; Florian Rivoal; Elika Etemad. ＜CSS Overflow Module Level 4＞. URL: https://drafts.csswg.org/css-overflow-4/
[CSS-RHYTHM-1]
    Koji Ishii; Elika Etemad. ＜CSS Rhythmic Sizing＞. URL: https://drafts.csswg.org/css-rhythm/
[CSS-TEXT-3]
    Elika Etemad; Koji Ishii; Florian Rivoal. ＜CSS Text Module Level 3＞. URL: https://drafts.csswg.org/css-text-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-UI-4]
    Florian Rivoal. ＜CSS Basic User Interface Module Level 4＞. URL: https://drafts.csswg.org/css-ui-4/
[MEDIAQ]
    Florian Rivoal; Tab Atkins Jr.. ＜Media Queries Level 4＞. URL: https://drafts.csswg.org/mediaqueries-4/
[QUIRKS]
    Simon Pieters. ＜Quirks Mode Standard＞. Living Standard. URL: https://quirks.spec.whatwg.org/
[RFC6694]
    S. Moonesamy, Ed.. ＜The "about" URI Scheme＞. August 2012. Informational. URL: https://www.rfc-editor.org/rfc/rfc6694


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより編集者草案として公開された
<a href="~SPEC_URL">CSS Values and Units Module Level 4</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/css-values-4/
公表履歴
	https://www.w3.org/standards/history/css-values-4/
フィードバック
	<a href="https://github.com/w3c/csswg-drafts/labels/css-values-4">CSSWG Issues Repository</a>

編集
	<a href="http://xanthir.com/contact/">Tab Atkins</a> (Google)
	<a href="http://fantasai.inkedblade.net/contact">Elika J. Etemad / fantasai</a> (Apple)

Suggest an Edit for this Spec
	<a href="https://github.com/w3c/csswg-drafts/blob/main/css-values-4/Overview.bs">GitHub Editor</a>
テスト一式
	https://wpt.fyi/results/css/css-values/
commit 履歴
	https://github.com/w3c/csswg-drafts/commits/main/css-values-4

</script>

<body>

<header>
	<hgroup>
<h1>CSS の値と単位 — CSS Values and Units Module Level 4</h1>
	</hgroup>
</header>

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

<p>
この~CSS~moduleは、
~CSS~propに受容される共通な値と単位，および
~CSS~prop定義の中でそれらの値と単位を述べるために利用される構文について述べる。
◎
This CSS module describes the common values and units that CSS properties accept and the syntax used for describing them in CSS property definitions.
</p>

~CSSisaLANG

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

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

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

<p>
各種~CSS~propの定義~表tにおける値~定義の欄には、
~keyword, ~data型（山括弧 `&lt;^c, `&gt;^c で括られて現れる）, および
それらをどう組合せるかについての情報を包含している。
この仕様では、
多くの~propから利用できる，汎用~data型
（最も広く利用されている `length$t など）について述べる。
より特定な~data型（例えば `spacing-limit^t ）は、
対応している~moduleにて述べられる。
◎
The value definition field of each CSS property can contain keywords, data types (which appear between &lt; and &gt;), and information on how they can be combined. Generic data types (&lt;length&gt; being the most widely used) that can be used by many properties are described in this specification, while more specific data types (e.g., &lt;spacing-limit&gt;) are described in the corresponding modules.
</p>

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

<p>
この~moduleは `CSS2$r の［
`§ 1.4.2.1＠~CSS22/about.html#value-defs$,
`§ 4.3＠~CSS22/syndata.html#values$,
`§ A.2＠~CSS22/aural.html#aural-intro$
］にて定義される~data型を置換し, 拡張する。
◎
This module replaces and extends the data type definitions in [CSS2] sections 1.4.2.1, 4.3, and A.2.
</p>

		</section>
	</section>
	<section id="value-defs">
<h2 title="Value Definition Syntax">2. 値~定義の構文</h2>

<p>
ここに述べる
`値~定義の構文@
は、
~CSS~prop用の妥当な値が成す集合
（および，~CSSにおける他の多くの部分を成す妥当な構文）
を定義するために利用される。
そのように述べられた値は、
1 個以上の成分からなり得る。
◎
The value definition syntax described here is used to define the set of valid values for CSS properties (and the valid syntax of many other parts of CSS). A value so described can have one or more components.
</p>

		</section>
		<section id="component-types">
<h3 title="Component Value Types">2.1. 成分~値の型</h3>

<p>
~propの成分~値の型は、
その値~定義において，以下に挙げる仕方で指名される：
◎
Component value types are designated in several ways:
</p>
<dl>
	<dt>
`~keyword$値
◎
Keyword values (such as auto, disc, etc.)＼
</dt>
	<dt>
`~at-規則$の開始を表現している~at-~keyword
◎
and at-keywords representing the start of an at-rule,
</dt>
	<dd>
これらは、
引用符や山括弧を伴わずに，~literalに現れる
（~keywordの例： `auto^v, `disc$v, 等々／
~at-~keywordの例： `media^at ）。
◎
which appear literally, without quotes (e.g. auto or @media).
</dd>
	<dd class="note">注記：
`~escape法$を用いて，`~CSS識別子$を その.値が［
`(^c で終了~する／ <code>@</code> から開始する
］ように構築することもアリである。
そのような~tokenは、
`ident-token$t (すなわち，`~keyword$）であり，
`function-token$t でも `at-keyword-token$t でもない。
◎
Note: It is possible, with escaping, to construct a CSS identifier whose value ends with ( or starts with @. Such a token is an &lt;ident-token&gt; (i.e. a keyword), not a &lt;function-token&gt; or an &lt;at-keyword-token&gt;.
</dd>

	<dt>
基本~data型
◎
Basic data types,＼
</dt>
	<dd>
これらは、
山括弧（ `&lt;^g, `&gt;^g ）で括られて現れる
（例： `length$t, `percentage$t, 等々）。
◎
which appear between &lt; and &gt; (e.g., &lt;length&gt;, &lt;percentage&gt;, etc.).＼
</dd>
	<dd>
`数量-~data型$に対しては、
下に述べる`角括弧付き範囲~記法$を利用して，この型~記法に範囲~制約を注釈できる。
◎
For numeric data types, this type notation can annotate any range restrictions using the bracketed range notation described below.
</dd>

	<dt>
［
ある~propが とり得る値の範囲
］と同じ~patternを成す値を表現するもの
◎
Property value ranges, which represent the same pattern of values as a property bearing the same name.＼
</dt>
	<dd>
これらは、
当の~propの名前を一重~引用符で括った上で，
さらに山括弧（ `&lt;^g, `&gt;^g ）で括って記される
（例： `border-width$tp, `background-attachment$tp, 等々）。
◎
These are written as the property name, surrounded by single quotes, between &lt; and &gt;, e.g., &lt;'border-width'&gt;, &lt;'background-attachment'&gt;, etc.
</dd>
	<dd>
これらの型は、
`~CSS全域~keyword$
— `inherit$v など —
を`含まない^em。
◎
These types do not include CSS-wide keywords such as inherit.＼
</dd>
	<dd>
<p>
これらの型は、［
当の~prop用の値の文法が~commaで分離された繰返nである場合
］には，［
~top-levelの~commaで分離された~list
］用の複化子（ `#^g ）を含まない
（例：
`pairing^p と命名された~propの値が
<span class="prod">[ `custom-ident$t `integer$t? ]#</span>
として定義されている場合、
`pairing^tp は，
<span class="prod">[ `custom-ident$t `integer$t? ]</span>
と等価になる
—
<span class="prod">[ `custom-ident$t `integer$t? ]#</span>
ではなく）。
◎
Additionally, if the property’s value grammar is a comma-separated repetition, the corresponding type does not include the top-level comma-separated list multiplier. (E.g. if a property named pairing is defined as [ &lt;custom-ident&gt; &lt;integer&gt;? ]#, then &lt;'pairing'&gt; is equivalent to [ &lt;custom-ident&gt; &lt;integer&gt;? ], not [ &lt;custom-ident&gt; &lt;integer&gt;? ]#.)
</p>

<details class="note">
<summary>
なぜ複化子を除去するのか？
◎
Why remove the multiplier?
</summary>

<p>
これらの値~型から~top-levelの複化子が~~剥がされるわけは、
~top-levelの~commaで分離された繰返nは，
ほとんどが`協調している~list~prop~group$用に利用されるからである
— ある略式~propが，
そのような~propをいくつか組合せるとき、
`自前の^em ~commaで分離された繰返nを構築できるよう，
複化子を伴わない文法が必要になる。
◎
The top-level multiplier is ripped out of these value types because top-level comma-separated repetitions are mostly used for coordinating list properties, and when a shorthand combines several such properties, it needs the unmultiplied grammar so it can construct its own comma-separated repetition.
</p>

<p>
この特別な扱いが無い下では、
どの下位propに対しても
— 内縁な値~用の生成規則と同じように —
場当的な生成規則で定義する必要が生じる結果，
文法を理解するのが総じて難しくなる。
◎
Without this special treatment, every such longhand would have to be defined with an ad-hoc production just for the inner value, which makes the grammars harder to understand overall.
</p>
</details>

	</dd>
	<dt>
関数-記法と その引数たち
◎
Functional notations and their arguments.＼
</dt>
	<dd>
これらは、
`§ 関数-記法の定義＠#component-functions$
にて定義されるとおり~literalに記されても，
非末端型により参照されてもヨイ
— 後者は、［
関数の名前, 後続する空な丸括弧~pair
］を山括弧（ `&lt;^g, `&gt;^g ）で括って記され
（例： `calc()$t ），
同じ名前を伴う`関数-記法$を参照する。
◎
These may be written literally as defined in § 2.6 Functional Notation Definitions, or referenced by a non-terminal using the function’s name, followed by an empty parentheses pair, between &lt; and &gt;, e.g. &lt;calc()&gt;, and references the correspondingly-named functional notation.
</dd>

	<dt>
他の非末端型
【他の型や個々の値を組合せて定義される型】
◎
Other non-terminals.＼
</dt>
	<dd>
これらは、
【基本~data型と同じく，】
その名前を山括弧（ `&lt;^g, `&gt;^g ）で括って記される
（例： `spacing-limit^t ）。
◎
These are written as the name of the non-terminal between &lt; and &gt;, as in &lt;spacing-limit&gt;.＼
</dd>
	<dd>
`border-width^t と `border-width$tp の差異に注意：
後者は， `border-width$p ~propの文法を表現する一方、
前者は，他のどこかで明示的に拡張pが定義される必要がある。
非末端型の定義は、
概して，仕様の中でそれが最初に現れる近辺に示される。
◎
Notice the distinction between &lt;border-width&gt; and &lt;'border-width'&gt;: the latter represents the grammar of the border-width property, the former requires an explicit expansion elsewhere. The definition of a non-terminal is typically located near its first appearance in the specification.
</dd>

	<dt>
区切子
◎
Delimiters,＼
</dt>
	<dd>
対応する~tokenを表現する。
◎
which represent their corresponding tokens.＼
</dd>
	<dd>
次に挙げる区切子は、
~literalに記される
⇒＃
~slash（ `/^c ）,
~comma（ `,^c ）,
~colon（ `:^c ）,
~semicolon（ `;^c ）,
丸括弧（ `(^c, `)^c ）,
波括弧（ `{^c, `}^c ）
◎
Slashes (/), commas (,), colons (:), semicolons (;), parentheses (( and )), and braces ({ and }) are written literally.＼
</dd>
	<dd>
他の区切子（ `+^c など）は、
一重~引用符で括って（ `'+'^c のように）記されなければナラナイ。
◎
Other delimiters must be written enclosed in single quotes (such as '+').
</dd>
</dl>

<p>
文法において指定された
`~comma@
（ `,^g ）は、
省略可能な項を分離するために利用されたときは，
一部の状況下では `暗黙的に省略-可能になる^em。
また，文法において［
~propや他の~CSS値の中の~top-levelの~list, あるいは
関数の引数~list
］の中に指定された~commaは、
次に挙げる場合には，省略しなければナラナイ：
◎
Commas specified in the grammar are implicitly omissible in some circumstances, when used to separate optional terms in the grammar. Within a top-level list in a property or other CSS value, or a function’s argument list, a comma specified in the grammar must be omitted if:
</p>

<ul>
	<li>
~commaに先行するすべての項が省略された場合
◎
all items preceding the comma have been omitted
</li>
	<li>
~commaに後続するすべての項が省略された場合
◎
all items following the comma have been omitted
</li>
	<li>
~commaに挟まれた項が省略されると，複数の~commaが（`空白$や~commentを無視して）連続することになる場合
◎
multiple commas would be adjacent (ignoring white space/comments), due to the items between the commas being omitted.
</li>
</ul>

<div class="example">
<p>
例えば，［
どれも省略可能な， 3 個の引数
］を受容する関数の文法は、
次の様に記せる：
◎
For example, if a function can accept three arguments in order, but all of them are optional, the grammar can be written like:
</p>

<pre class="prod">
example( first`?$g `,$g second`?$g `,$g third`?$g )
</pre>

<p>
この文法の下では、
`example(first, second, third)^v
は妥当であり，
`example(first, second)^v ／
`example(first, third)^v ／
`example(second)^v
も同様である。
一方で，
`example(first, , third)^v
は、
無効になる。
~commaには、
2 つの選択肢を分離することが要求されるので。
同じ理由から、
`example(,second)^v ／
`example(first,)^v ／
`example(first second)^v
も無効になる。
◎
Given this grammar, writing example(first, second, third) is valid, as is example(first, second) or example(first, third) or example(second). However, example(first, , third) is invalid, as one of those commas are no longer separating two options; similarly, example(,second) and example(first,) are invalid. example(first second) is also invalid, as commas are still required to actually separate the options.
</p>

<p>
~commaが暗黙的に省略し得ないものであったなら、
省略し得る引数を適正に表出するための文法は，ずっと複雑になり，
その特能の単純~性も損なわれるであろう。
◎
If commas were not implicitly omittable, the grammar would have to be much more complicated to properly express the ways that the arguments can be omitted, greatly obscuring the simplicity of the feature.
</p>
</div>

<hr>

<div>
<p>
すべての~CSS~propには、
~prop値の単独の成分として，
`~CSS全域~keyword$値が受容される。
可読性のため、
これらの~prop値は，構文~定義には明示的に挙げられない。
例えば，
`border-color$p の全部的な定義は
（その定義~表tには <samp class="css">`color^t{1,4}</samp> と示されているが）、
`CSS-CASCADE-3$r の下では，次になる
⇒
<span class="prod">
[ `color^t{1,4} ] | `inherit$v | `initial$v | `unset$v
</span>
◎
All CSS properties also accept the CSS-wide keyword values as the sole component of their property value. For readability these are not listed explicitly in the property value syntax definitions. For example, the full value definition of border-color under CSS Cascading and Inheritance Level 3 is &lt;color&gt;{1,4} | inherit | initial | unset (even though it is listed as &lt;color&gt;{1,4}).
</p>
</div>

<p class="note">注記：
したがって、
一般に，同じ宣言の中で これらの~keywordが他の成分~値と組合された場合、
その宣言は無効になる。
例えば
`background:url(corner.png) no-repeat, inherit$p
は、
無効になる。
◎
Note: This implies that, in general, combining these keywords with other component values in the same declaration results in an invalid declaration. For example, background: url(corner.png) no-repeat, inherit; is invalid.
</p>

		<section id="component-combinators">
<h3 title="Component Value Combinators">2.2. 成分~値の結合子</h3>

<p>
~propの値~定義においては、
各~成分~値が次の組合nで配列される：
◎
Component values can be arranged into property values as follows:
</p>

<dl>
	<dt>
（結合子を挟まずに）並記された成分
◎
Juxtaposing components＼
</dt>
	<dd>
それらの成分すべてが，示された順序で現れなければナラナイ。
◎
means that all of them must occur, in the given order.
</dd>

	<dt id="comb-all">
二重~ampersand（ `~AMP~AMP^g ）
◎
A double ampersand (&amp;&amp;)＼
</dt>
	<dd>
複数個の成分を分離する
— それらの成分すべてが現れなければナラナイが，その順序は任意である。
◎
separates two or more components, all of which must occur, in any order.
</dd>

	<dt id="comb-any">
二重~縦棒（ `||^g ）
◎
A double bar (||)＼
</dt>
	<dd>
複数個の選択肢を分離する
— それらのうち 1 個以上が現れなければナラナイが，その順序は任意である。
◎
separates two or more options: one or more of them must occur, in any order.
</dd>

	<dt id="comb-one">
縦棒（ `|^g ）
◎
A bar (|)＼
</dt>
	<dd>
複数個の排他的選択肢を分離する
— それらのうち正確に 1 個だけ現れなければナラナイ。
◎
separates two or more alternatives: exactly one of them must occur.
</dd>

	<dt>
角括弧（ `[<var>…</var>]^g ）
◎
Brackets ([ ])＼
</dt>
	<dd>
~group化を表す。
◎
are for grouping.
</dd>
</dl>

<p>
これらの結合順位は優先度の高いものから、［
並記, 二重~ampersand, 二重~縦棒, 縦棒
］の順になる。
したがって，次の 2 つの行は等価になる：
◎
Juxtaposition is stronger than the double ampersand, the double ampersand is stronger than the double bar, and the double bar is stronger than the bar. Thus, the following lines are equivalent:
</p>

<pre class="prod">
  %a %b   |   %c ||   %d ~AMP~AMP   %e %f
[ %a %b ] | [ %c || [ %d ~AMP~AMP [ %e %f ]]]
</pre>

<p>
並び替え可能な結合子（ `||$g, `~AMP~AMP$g ）においては、
文法における順序は問われない
— 同じ~group内の各~成分は、
どの順序で記されてもヨイ。
したがって、
次の 2 つの行は，等価になる：
◎
For reorderable combinators (||, &amp;&amp;), ordering of the grammar does not matter:
components in the same grouping may be interleaved in any order. Thus, the following lines are equivalent:
</p>

<pre class="prod">
%a || %b || %c
%b || %a || %c
</pre>

<div class="note">
<p>注記：
結合子は，`結合則＠https://ja.wikipedia.org/wiki/%E7%B5%90%E5%90%88%E6%B3%95%E5%89%87$を`満たさない^emので、
~group化は有意になる。
例えば、
次の 2 つの行は，別個な文法を成す：
</p>

<pre class="prod">
%a || %b || %c
%a || [ %b || %c ]
</pre>

<p>
一行目は， <code class="value">%b %a %c</code> の様な値を許容する一方で、
二行目は，許容しない。
</p>
◎
Note: Combinators are not associative, so grouping is significant. For example, a || b || c and a || [ b || c ] are distinct grammars: the first allows a value like b a c, but the second does not.
</div>

		</section>
		<section id="component-multipliers">
<h3 title="Component Value Multipliers">2.3. 成分~値の複化子</h3>

<p>
どの［
値~型 ／ ~keyword ／ 角括弧で括られた~group
］にも
— 以下、
これらを “構文単位” と総称する —
次に挙げるいずれかの改変子を後置してヨイ：
◎
Every type, keyword, or bracketed group may be followed by one of the following modifiers:
</p>

<dl>
	<dt id="mult-zero-plus">
~asterisk（ `*^g ）
◎
An asterisk (*)＼
</dt>
	<dd>
直前の構文単位が 0 回以上 生じることを指示する。
◎
indicates that the preceding type, word, or group occurs zero or more times.
</dd>

	<dt id="mult-one-plus">
正符号（ `+^g ）
◎
A plus (+)＼
</dt>
	<dd>
直前の構文単位が 1 回以上 生じることを指示する。
◎
indicates that the preceding type, word, or group occurs one or more times.
</dd>

	<dt id="mult-opt">
疑問符（ `?^g ）
◎
A question mark (?)＼
</dt>
	<dd>
直前の構文単位が省略可能である（すなわち， 0 回または 1 回 生じる）ことを指示する。
◎
indicates that the preceding type, word, or group is optional (occurs zero or one times).
</dd>

	<dt id="mult-num">
波括弧で括られた整数（ `{~vA}^g ）
◎
A single number in curly braces ({A})＼
</dt>
	<dd>
直前の構文単位が ~vA 回 生じることを指示する。
◎
indicates that the preceding type, word, or group occurs A times.
</dd>

	<dt id="mult-num-range">
波括弧で括られ，~commaで分離された整数の~pair（ `{~vA,~vB}^g ）
◎
A comma-separated pair of numbers in curly braces ({A,B})＼
</dt>
	<dd>
直前の構文単位が ~vA 回~以上 ~vB 回~以下 生じることを指示する。
~vB は省略してもヨイ（ `{~vA,}^g ）
— その場合、
~vA 回以上 ~~上限なしに生じることを指示する。
◎
indicates that the preceding type, word, or group occurs at least A and at most B times. The B may be omitted ({A,}) to indicate that there must be at least A repetitions, with no upper bound on the number of repetitions.
</dd>

	<dt id="mult-comma">
~hash記号（ `#^g ）
◎
A hash mark (#)＼
</dt>
	<dd>
直前の構文単位が~comma~tokenで分離された上で 1 回以上 生じることを指示する
（~commaの前後に`空白$や~commentが現れてもヨイ）。
これには、
上述した省略可能な波括弧~形が後続し得る
（例： <code class="prod">`length$t#{1,4}</code> ）。
その場合、
より精確な回数を指示する。
◎
indicates that the preceding type, word, or group occurs one or more times, separated by comma tokens (which may optionally be surrounded by white space and/or comments). It may optionally be followed by the curly brace forms, above, to indicate precisely how many times the repetition occurs, like &lt;length&gt;#{1,4}.
</dd>

	<dt id="mult-req">
~groupの直後にある感嘆符（ `!^g ）
◎
An exclamation point (!) after a group＼
</dt>
	<dd>
当の~groupは必須であり， 1 個以上の値を生産しなければナラナイことを指示する。
すなわち、
~groupの中の各項は文法により個別的に省略し得るとしても，
全体としては成分~値~すべてを省略してはナラナイ。
◎
indicates that the group is required and must produce at least one value; even if the grammar of the items within the group would otherwise allow the entire contents to be omitted, at least one component value must not be omitted.
</dd>
</dl>

<p>
複化子［
`+^g, `#^g
］は、
`+#^g のように重ねて記されてもヨイ。
類似に，複化子［
`#^g, `?^g
］も、
`#?^g のように重ねて記されてもヨイ。
いずれも，各~複化子を記された順に適用することを表現する。
（~group化を利用しても同じことは表現できるが、
これらを用いれば，角括弧の個数を減らして複階的な文法の可読性を上げれるようになる。）
【例： `~vA+#^g は、 `[~vA+]#^g を表現する。】
◎
The + and # multipliers may be stacked as +#; similarly, the # and ? multipliers may be stacked as #?. These stacks each represent the later multiplier applied to the result of the earlier multiplier. (These same stacks can be represented using grouping, but in complex grammars this can push the number of brackets beyond readability.)
</p>

<p>
繰返される（ `*$g, `+$g, `#$g で指示される）成分~値に対しては、
~UAは，少なくとも 20 回以上の繰返nを~supportするモノトスル。
~prop値が，~supportする個数を超える成分の繰返nを包含する場合、
当の宣言は，無効であったかのように無視するモノトスル。
◎
For repeated component values (indicated by *, +, or #), UAs must support at least 20 repetitions of the component. If a property value contains more than the supported number of repetitions, the declaration must be ignored as if it were invalid.
</p>

		</section>
		<section id="combinator-multiplier-patterns">
<h3 title="Combinator and Multiplier Patterns">2.4. 結合子と複化子の~pattern</h3>

<p>
複数個の独立な`成分~値$を特定の個数と順序で組合せるための，共通的な仕方がいくつかある。
特に、
【仕様~策定者が】次を表出したいと求めることは，共通的にある
⇒
作者は、
ある［
成分~値たちが成す集合
］の中から［
文法に指定された順序で，あるいは任意の順序で
］［
0 個以上を／ 1 個以上を／すべてを
］選定しなければナラナイ
◎
There are a small set of common ways to combine multiple independent component values in particular numbers and orders. In particular, it’s common to want to express that, from a set of component value, the author must select zero or more, one or more, or all of them, and in either the order specified in the grammar or in any order.
</p>

<p>
これらはすべて、
`結合子$や`複化子$による単純な~patternを利用して，容易に表出できる：
◎
All of these can be easily expressed using simple patterns of combinators and multipliers:
</p>

<table><thead>
<tr><th><th title="in order">指定された順序
<th title="any order">任意の順序
<tbody>

<tr><th title="zero or more">0 個以上
<td>`~vA? ~vB? ~vC?^g
<td>`~vA? || ~vB? || ~vC?^g

<tr><th title="one or more">1 個以上
<td>`[ ~vA? ~vB? ~vC? ]!^g
<td>`~vA || ~vB || ~vC^g

<tr><th title="all">すべて
<td>`~vA ~vB ~vC ^g
<td>`~vA ~AMP~AMP ~vB ~AMP~AMP ~vC^g
</table>

<p>
“任意の順序” に挙げたものは，どれも結合子を利用して表出される一方、
“指定された順序” に挙げたものは，どれも並記になっていることに注意。
◎
Note that all of the "any order" possibilities are expressed using combinators, while the "in order" possibilities are all variants on juxtaposition.
</p>

		</section>
		<section id="component-whitespace">
<h3 title="Component Values and White Space">2.5. 成分~値と空白</h3>

<p>
`空白$や~commentは、
他が指定されない限り，上の［
`結合子$や`複化子$
］を利用して結合された各~成分の前後に現れてもヨイ。
◎
Unless otherwise specified, white space and/or comments may appear before, after, and/or between components combined using the above combinators and multipliers.
</p>

<p class="note">注記：
多くの事例では、
成分どうしの合間には
— 互いを判別するため —
~spaceが~~実際に`要求される^em。
例えば，値 `1em2em^v は、
数字 `1^v と無効な単位~識別子 `em2em^u を伴う，単独の `dimension-token$t として構文解析されることになる。
この場合、
2 個の長さ値［
`1em^v, `2em^v
］として構文解析されるためには，数字 `2^v の前に~spaceが要求される。
◎
Note: In many cases, spaces will in fact be required between components in order to distinguish them from each other. For example, the value 1em2em would be parsed as a single &lt;dimension-token&gt; with the number 1 and the identifier em2em, which is an invalid unit. In this case, a space would be required before the 2 to get this parsed as the two lengths 1em and 2em.
</p>

		</section>
		<section id="component-functions">
<h3 title="Functional Notation Definitions">2.6. 関数-記法の定義</h3>

<p>
`関数-記法$の構文は、
次が成す連列として定義される：
◎
The syntax of a functional notation is defined as a sequence of:
</p>
<ol>
	<li>
<p>
当の関数の名前
— 次に挙げるいずれかとして記される：
</p>
		<ul>
			<li>
識別子と，それに後続する左~丸括弧（例： `example(^g ）
</li>
			<li>
`function-token$t 生成規則
— これは、
任意な名前を伴う関数を指示する。
</li>
		</ul>
◎
The function’s name written as an identifier followed by an open parenthesis (such as example(), or the &lt;function-token&gt; production to indicate a function with an arbitrary name.
</li>
	<li>
当の関数の引数たち（もしあれば）
— `値~定義の構文$を利用して表出される。
◎
The function’s arguments, if any, expressed using the value definition syntax.
</li>
	<li>
右~丸括弧
◎
A literal closing parenthesis.
</li>
</ol>

<p>
関数の引数は、
`暗黙的に~group化される^emと見なされる
— 角括弧（ `[ ... ]^g ）で括られたかのように。
◎
The function’s arguments are considered implicitly grouped, as if surrounded by brackets ([ ... ]).
</p>

<div class="example">
<p>
例えば，次の様な文法は：
◎
For example, a grammar like:
</p>

<pre class="prod">
example( `length^t , `length^t )
</pre>

<p>
次を満たす関数に合致することになる
⇒
［
名前 `example^l を伴う
］~AND［
引数は［
<span class="prod">`length$t , `length$t</span>
］に合致する
］
◎
will match a function whose name is "example" and whose arguments match "&lt;length&gt; , &lt;length&gt;".
</p>
</div>

<div class="example">
<p>
例えば， `Selectors^cite は、
疑似類の文法を汎用に定義する
— 先頭の~colonの後に，どの関数~名も許容するよう：
◎
For example, the Selectors grammar defines pseudo-classes generically, allowing any possibly function name after the initial colon:
</p>

<pre class="prod">
`pseudo-class-selector^t
	= : `ident-token^t
	| : `function-token^t `any-value^t )
</pre>

<p>
これは、
引数として `any-value$t を伴う，`どの関数~名も^em表現する。
◎
This represents any function name, with &lt;any-value&gt; as the function arguments.
</p>
</div>

<div class="example">
<p>
`関数-記法$は，その内容を`暗黙的に~group化する^emので、
内側にある結合子の効果が及ぶ視野は，関数の引数たちになる。
例えば，`関数-記法$を成す構文~定義
<span class="prod">example( foo | bar )</span>
は、
<span class="prod">example( [ foo | bar ] )</span>
と等価になる。
◎
Since the functional notation implicitly groups its contents, the effect of any combinator inside it is scoped to the function’s argument. For example, the functional notation syntax definition example( foo | bar ) is equivalent to example( [ foo | bar ] ).
</p>
</div>

		</section>
		<section id="value-examples">
<h3 title="Property Value Examples">2.7. ~prop値の例</h3>

<p>
いくつかの~propについて，対応する値~定義の欄, および値の例を下に示す：
◎
Below are some examples of properties with their corresponding value definition fields
</p>

<div class="example">
<table id="propvalues" class="grid-table"><thead>
<tr><th title="Property">~prop
<th title="Value definition field">値~定義の欄
<th title="Example value">値の例
<tbody>

<tr><td>`orphans$p
<td class="prod">`integer^t
<td>`3^v

<tr><td>`text-align$p
<td class="prod">`left^v | `right^v | `center^v | `justify^v
<td>`center^v

<tr><td>`padding-top$p
<td class="prod">`length^t | `percentage^t
<td>`5%^v

<tr><td>`outline-color$p
<td class="prod">`color^t | `invert^v
<td>`#fefefe^v

<tr><td>`text-decoration$p
<td class="prod">`none^v | `underline^v || `overline^v || `line-through^v || `blink^v
<td>`overline underline^v

<tr><td>`font-family$p
<td class="prod">[ `family-name^t | `generic-family^t ]#
<td>`"Gill Sans", Futura, sans-serif^v

<tr><td>`border-width$p
<td class="prod">[ `length^t | `thick^v | `medium^v | `thin^v ]{1,4}
<td>`2px medium 4px^v

<tr><td>`box-shadow$p
<td class="prod">[ `inset^v? ~AMP~AMP `length^t{2,4} ~AMP~AMP `color^t? ]# | `none^v
<td>`3px 3px rgba(50%, 50%, 50%, 50%), lemonchiffon 0 0 4px inset^v
</table>
</div>

		</section>
		<section id="production-blocks">
<h3 title="Non-Terminal Definitions and Grammar Production Blocks">2.8. 非末端型の定義と文法~生成規則~block</h3>

<p>
`position$t や `calc$f の様な非末端型を成す精確な文法は、
`~CSS文法~生成規則~block@
内で指定されることが多い。
これらは、
慣例により，次の様な定義を成す予め整形-済みな【 `pre^e 要素による】~block内で表現される：
◎
The precise grammar of non-terminals, like &lt;position&gt; or &lt;calc()&gt;, is often specified in a CSS grammar production block. These are conventionally represented in a preformatted block of definitions like this:
</p>

<div class="example">
<p>
`foo^t 構文は、
次に従って定義される：
◎
The &lt;foo&gt; syntax is defined as follows:
</p>

<pre class="prod">
`foo^t = keyword | `bar^t |
        some-really-long-pattern-of-stuff
`bar^t = `length^t
</pre>
</div>

<p>
各~定義は：
◎
Each definition＼
</p>

<ul>
	<li>
新たな行lから開始される。
◎
starts on its own line,＼
</li>
	<li>
順に，［
定義される非末端型,
`=^g,
`値~定義の構文$を成す断片
］からなる
— 当の非末端型は，この断片へ展開される。
◎
and consists of the non-terminal to be defined, followed by an =, followed by the fragment of value definition syntax to which it expands.＼
</li>
	<li>
複数~行lにわたり得る。
◎
A definition can stretch across multiple lines,＼
</li>
	<li>
次のうちいずれか（最初に来る方）で終了する
⇒＃
次に新たな文法~生成規則を開始する行lの前／
当の生成規則~blockの終端
◎
and terminates before the next line that starts a new grammar production or at the end of the grammar production block (whichever comes first).
</li>
</ul>

<div class="example">
<p>
上の例では、
定義 `foo^t は 2 行lにわたる。
3 行l目は `bar^t 用の新たな定義で開始される。
（`値~定義の構文$においては，裸の `=^c は決して妥当でないので、
新たな行lが新規な定義を開始するかどうかは一義的になる。）
◎
In the above example, the &lt;foo&gt; definition covers two lines. The third line starts a new definition for &lt;bar&gt;. (A naked = is never valid in value definition syntax, so it’s unambiguous when a new line starts a fresh definition.)
</p>
</div>

<div class="trans-note">
<p>【
この~siteの各~日本語訳では、
生成規則~blockは，次の様に `=^g 以降を字下げして整形される
— 各~定義は、
常に，字下げされない行lから開始する：
】</p>

<pre class="prod">
`foo^t
	= keyword
	| `bar^t
	| some-really-long-pattern-of-stuff
`bar^t
	= `length^t
</pre>
</div>

		</section>
	</section>
	<section id="combining-values">
<h2 title="Combining Values: Interpolation, Addition, and Accumulation">3. 値の結合-法： 補間, 加算, 累積</h2>

<p>
例えば［
`遷移＠~TRANSITION$ ／
`~animation＠~CSSANIM$
］などにおける一部の手続-は、
2 個の~CSS~prop値を
`結合-@
する。
所与の，ある~propの 2 個の`算出d値$
( 値A, 値B )
を結合して，算出d値 %結果値 を得る演算†として、
次に挙げるものが定義される。
演算が可換でない場合
（例えば，行列の乗算／合致していない変形~listたちが成す累積）、［
値A, 値B
］の順序も有意になる：
◎
Some procedures, for example transitions and animations, combine two CSS property values. The following combining operations—on the two computed values VA and VB yielding the computed value Vresult—are defined. For operations that are not commutative (for example, matrix multiplication, or accumulation of mismatched transform lists) VA represents the first term of the operation and VB represents the second.
</p>

<p class="trans-note">【†
実際には、
演算の種別
— 具体的な演算-法は、
一般に，個々の値~型ごとに定義される。
】</p>

<dl>
	<dt>
`補間@
（ `interpolation^en ）
</dt>
	<dd>
<p>
実数 %p に対し，［
距離 %p における，区間 [ 値A, 値B ] 内の中間-値
］を表す %結果値 を生産する
— ［
%p ~EQ 0 ならば 値A になる ／ %p ~EQ 1 ならば 値B になる
］ように~~拘束される下で。
◎
Given two property values VA and VB, produces an intermediate value Vresult at a distance of p along the interval between VA and VB such that p = 0 produces VA and p = 1 produces VB.
</p>

<p>
`~easing関数$の効果に因り， %p の範囲は開区間 (−∞, ∞) にわたる。
よって，この手続-は、
閉区間 [0, 1] の外側にある %p に対しても外挿の挙動を定義しなければナラナイ。
◎
The range of p is (−∞, ∞) due to the effect of timing functions. As a result, this procedure must also define extrapolation behavior for p outside [0, 1].
</p>
	</dd>

	<dt>
`加算@
（ `addition^en ）
</dt>
	<dd>
( 値A, 値B )
の総和として %結果値 を返す。
◎
Given two property values VA and VB, returns the sum of the two properties, Vresult.
</dd>
	<dd class="note">注記：
`加算$は、
`補間$の定義に利用される加重平均~関数と同じ用語に基づいて表出できることが多いが，
常に該当するとは限らない。
例えば，変形-行列の補間は 行列~成分の分解-法と補間-法を孕む一方で、
それらの加算は 行列の乗算に依拠する。
◎
Note: While addition can often be expressed in terms of the same weighted sum function used to define interpolation, this is not always the case. For example, interpolation of transform matrices involves decomposing and interpolating the matrix components whilst addition relies on matrix multiplication.
</dd>

	<dd>
次に該当する値~型の`加算$における %結果値 は、
単純に 値B で与えられるとする
⇒
`加算$用に特定の手続-を定義していない ／
`加法的でない@
ものと定義されている
◎
If a value type does not define a specific procedure for addition or is defined as not additive, its addition operation is simply Vresult = VB.
</dd>

	<dt>
`累積@
（ `accumulation^en ）
</dt>
	<dd>
［
値B は 値A からの差分として扱われる
］ように結合して得られる %結果値 を返す。
◎
Given two property values VA and VB, returns the result, Vresult, of combining the two operands such that VB is treated as a delta from VA.
</dd>
	<dd class="note">注記：
実数や長さなど，多くの型の~animation用の`累積$は、
`加算$と一致するように定義される。
この 2 つの定義が相違する共通的な事例として，~listに基づく型がある
— そこでは、
`加算$は ~listに付加するものとして,
`累積$は 成分ごとの加算として定義されることもある。
例えば，~filter~list値【 `filter-value-list$t 】［
`blur(2)^v, `blur(3)^v
］は、
`加算-$されるときは `blur(2) blur(3)^v を生産する一方で，
`累積-$されるときは `blur(5)^v を生産することになる。
◎
Note: For many types of animation such as numbers or lengths, accumulation is defined to be identical to addition.
◎
A common case where the definitions differ is for list-based types where addition may be defined as appending to a list whilst accumulation may be defined as component-based addition. For example, the filter list values blur(2) and blur(3), when added together would produce blur(2) blur(3), but when accumulated would produce blur(5).
</dd>
	<dd>
`累積$用に特定の手続-を定義しない値~型の`累積$は、
その型の`加算$に一致するとする。
◎
If a value type does not define a specific procedure for accumulation, its accumulation operation is identical to addition.
</dd>
</dl>

<p>
これらの演算は、
`算出d値$に限り定義される
（その結果、
例えば `length$t 値［
`15pt^v, `5em^v
］を加算する方法を定義することは，必要yでない
— そのような値は、
上の手続-に渡される前に`正準-単位$による値に解決されることになるので）。
◎
These operations are only defined on computed values. (As a result, it is not necessary to define, for example, how to add a &lt;length&gt; value of 15pt with 5em since such values will be resolved to their canonical unit before being passed to any of the above procedures.)
</p>

		<section id="combining-range">
<h3 title="Range Checking">3.1. 範囲の検査-法</h3>

<p>
補間は、
その入力は妥当であっても，
結果の値は，ある~prop用の妥当な範囲の外側になり得る
— これはとりわけ， %p が範囲 [0, 1] の外側にあるとき起こるが、
一部の`~easing関数$は，この範囲に入るときでも これを生じさせる。
［
補間／加算／累積
］の`後^emにおける最終-結果が，
それが利用される~target文脈~用には範囲~外の値になるとしても、
当の宣言は，無効にはならない。
代わりに，値は、
~target文脈において許容される範囲に
— `~math関数$と正確に同じに（`§ 範囲の検査-法＠#calc-range$を見よ） —
切詰めるモノトスル。
◎
Interpolation can result in a value outside the valid range for a property, even if all of the inputs to interpolation are valid; this especially happens when p is outside the [0, 1] range, but some easing functions can cause this to occur even within that range. If the final result after interpolation, addition, and accumulation is out-of-range for the target context the value is being used in, it does not cause the declaration to be invalid. Instead, the value must be clamped to the range allowed in the target context, exactly the same as math functions (see § 10.12 Range Checking).
</p>

<p class="note">注記：
［
加算／累積
］においては、
補間の【途中】結果が範囲~外の値になったとしても，
範囲の中に戻ってくるよう結果が “正される” こともある。
したがって，切詰ngが適用されるのは、
補間に関係する演算をすべて適用した`最終-結果^emに限られる。
◎
Note: Even if interpolation results in an out-of-range value, addition/accumulation might "correct" the result and bring it back into range. Thus, clamping is only applied to the final result of applying all interpolation-related operations.
</p>

		</section>
	</section>
	<section id="textual-values">
<h2 title="Textual Data Types">4. ~textな~data型</h2>

<p>
`~textな~data型@
は、［
様々な~keyword,
識別子,
文字列（`string$t）,
~URL（ `url$t ）
］を含む。
［
`定義済み~keyword$の大小変換／所与の~prop用に明示的に定義されたもの
］は別として、
~Unicode正規化も含め，いかなる正規化も遂行されない
— ~propの［
`指定d値$, `算出d値$
］は、
正確に，供された~Unicode値を構文解析した結果になる
（他の文字~集合【文字~符号化法】からの変換, `~escape法＠~CSSSYN#escaping$を含む）。
`UNICODE$r `CSS-SYNTAX-3$r
◎
The textual data types include various keywords and identifiers as well as strings (&lt;string&gt;) and URLs (&lt;url&gt;). Aside from the casing of pre-defined keywords or as explicitly defined for a given property, no normalization is performed, not even Unicode normalization: the specified and computed value of a property are exactly the provided Unicode values after parsing (which includes character set conversion and escaping). [UNICODE] [CSS-SYNTAX-3]
</p>

<p>
`~CSS識別子@
は、
`ident-token$t `CSS-SYNTAX-3$r に適合する文字~並びからなり，
汎用~的には
`ident@t
で表記される。
識別子は、
引用符で括れない
— さもなければ、
文字列として解釈されることになる。
~CSS~propは、
2 種の`~CSS識別子$
— `定義済み~keyword$, `接頭辞を伴わない作者~定義な識別子＠#custom-idents$ —
を受容する。
◎
CSS identifiers, generically denoted by &lt;ident&gt;, consist of a sequence of characters conforming to the &lt;ident-token&gt; grammar. [CSS-SYNTAX-3] Identifiers cannot be quoted; otherwise they would be interpreted as strings. CSS properties accept two classes of identifiers: pre-defined keywords and author-defined identifiers.
</p>

<p class="note">注記：
`ident$t 生成規則は、
~prop値の定義~用に意味されたものではない
— 代わりに `custom-ident$t を利用するベキである。
`ident$t は、
他の構文-構成子を簡便に定義するためとして供される。
◎
Note: The &lt;ident&gt; production is not meant for property value definitions—&lt;custom-ident&gt; should be used instead. It is provided as a convenience for defining other syntactic constructs.
</p>

<p>
~textな~data型は、
すべて`離散的$に`補間-$され，`加法的でない$。
◎
All textual data types interpolate as discrete and are not additive.
</p>

		<section id="keywords">
<h3 title="Pre-defined Keywords">4.1. 定義済み~keyword</h3>

<p>
値~定義の欄の中では、
定義済みな意味を伴う
`~keyword@
は，~literalに現れる。
~keywordは、
`~CSS識別子$であり，`~ASCII大小無視$の下で解釈される
（すなわち、
a 〜 z と A 〜 Z は等価になる）。
◎
In the value definition fields, keywords with a pre-defined meaning appear literally. Keywords are identifiers and are interpreted ASCII case-insensitively (i.e., [a-z] and [A-Z] are equivalent).
</p>

<div class="example">
<p>
例えば，
`border-collapse$p
~propの値~定義は、
次で与えられる：
◎
For example, here is the value definition for the border-collapse property:
</p>

◎名 `border-collapse^p
◎値 `collapse^v | `separate^v
◎表終

<p>
その用例：
◎
And here is an example of its use:
</p>

<pre class="lang-css">
table { border-collapse: separate }
</pre>
</div>

			<section id="common-keywords">
<h4 title="CSS-wide keywords: initial, inherit and unset">4.1.1. ~CSS全域~keyword： `initial^v, `inherit^v, `unset^v</h4>

<p>
`§ 成分~値の型＠#component-types$に定義したとおり、
すべての~propは
`~CSS全域~keyword@
を受容する。
これらの~keywordは、
すべての~CSS~propに共通な値の算出法を表現し，
`~CSSの~cascade法と継承＠~CASCADE$cite
~moduleにて規範的に定義される†。
◎
As defined above, all properties accept the CSS-wide keywords, which represent value computations common to all CSS properties. These keywords are normatively defined in the CSS Cascading and Inheritance Module.
</p>

<p class="trans-note">【†
`all$p ~propを見よ
（便宜上，~level 5 の日本語訳へ~linkしているが、
特定の~levelは指定されないので，
どの~keywordが~supportされるかは実装が~supportする~levelに依存し得る）。
】</p>

<p>
他の~CSS仕様も追加的な~CSS全域~keywordを定義し得る。
◎
Other CSS specifications can define additional CSS-wide keywords.
</p>

<p class="trans-note">【
新たな全域~keywordが追加された場合、
`接頭辞を伴わない作者~定義な識別子＠#custom-idents$と競合することから，
`後方-互換性の問題＠#dashed-idents$も生じ得ることになるが。
】</p>

			</section>
		</section>
		<section id="custom-idents">
<h3 title="Unprefixed Author-defined Identifiers: the &lt;custom-ident&gt; type">4.2. 接頭辞を伴わない作者~定義な識別子： `custom-ident^t 型</h3>

<p>
一部の~propは、
成分~値として，作者~定義な任意な識別子を受容する。
この汎用~data型は
`custom-ident@t
で表記され、
その~propの値~定義による`定義済み~keyword$に解釈されないような，
任意の妥当な`~CSS識別子$を表現する。
その種の識別子の`文字~大小は区別される＠~INFRA#string-is$
（例えば `example^v と `EXAMPLE^v は、
異なる, 無関係な, 作者~定義な識別子である）。
◎
Some properties accept arbitrary author-defined identifiers as a component value. This generic data type is denoted by &lt;custom-ident&gt;, and represents any valid CSS identifier that would not be misinterpreted as a pre-defined keyword in that property’s value definition. Such identifiers are fully case-sensitive (meaning they’re compared using the "identical to" operation), even in the ASCII range (e.g. example and EXAMPLE are two different, unrelated user-defined identifiers).
</p>

<p>
`~CSS全域~keyword$は，妥当な `custom-ident$t ではない。
予約-済みな全域~keyword `default^v もまた，
【現時点では定義されていないが】妥当な `custom-ident$t ではない。
`custom-ident$t を利用する各~仕様は、
どの~keywordが `custom-ident$t から除外されるベキかを明瞭に指定しなければナラナイ
— 例えば、
“その~propの値~定義にて`定義済み~keyword$は除外される”
と記すなど。
除外される~keywordと`~ASCII大小無視$で合致するもの【！ASCII case permutations】も除外される。
◎
The CSS-wide keywords are not valid &lt;custom-ident&gt;s. The default keyword is reserved and is also not a valid &lt;custom-ident&gt;. Specifications using &lt;custom-ident&gt; must specify clearly what other keywords are excluded from &lt;custom-ident&gt;, if any—for example by saying that any pre-defined keywords in that property’s value definition are excluded. Excluded keywords are excluded in all ASCII case permutations.
</p>

<p>
~prop値における位置に応じて多義的になる~keywordを構文解析するとき、
`custom-ident$t 生成規則が 当の~keywordに該当し得るのは，［
当の~keywordに該当し得るような，未だ充足されていない生成規則
］が他に無い場合に限られる。
◎
When parsing positionally-ambiguous keywords in a property value, a &lt;custom-ident&gt; production can only claim the keyword if no other unfulfilled production can claim it.
</p>

<p class="example">
例えば、
`略式~prop$による宣言
<code class="css">`animation$p: `ease-in ease-out^v;</code>
は，`下位prop$による宣言
<code class="css">`animation-timing-function$p: `ease-in$v;</code>
<code class="css">`animation-name$p: `ease-out$v;</code>
と等価になる。
`ease-in$v は， `animation-timing-function$p に属する `easing-function$t 生成規則に該当する結果、
`ease-out$v は， `animation-name$p に属する `custom-ident$t 生成規則に該当するようになる。
◎
For example, the shorthand declaration animation: ease-in ease-out is equivalent to the longhand declarations animation-timing-function: ease-in; animation-name: ease-out;. ease-in is claimed by the &lt;easing-function&gt; production belonging to animation-timing-function, leaving ease-out to be claimed by the &lt;custom-ident&gt; production belonging to animation-name.
</p>

<p class="note">注記：
`custom-ident$t を伴う文法を設計するときは、
~prop内のどの~keyword値とも競合し得なくなるよう，［
`custom-ident$t は、
常に “位置に応じて多義的にならない”
］ようにするベキである。
そのような競合は、
代替として `dashed-ident$t を利用することにより避けれる。
◎
Note: When designing grammars with &lt;custom-ident&gt;, the &lt;custom-ident&gt; should always be “positionally unambiguous”, so that it’s impossible to conflict with any keyword values in the property. Such conflicts can alternatively be avoided by using &lt;dashed-ident&gt;.
</p>

		</section>
		<section id="dashed-idents">
<h3 title="Prefixed Author-defined Identifiers: the &lt;dashed-ident&gt; type">4.3. 接頭辞を伴う作者~定義な識別子： `dashed-ident^t 型</h3>

<p>
一部の文脈は、［
作者~定義な識別子, ~CSS定義な識別子
］`どちらも^em受容する。
これは、
注意深く取扱わないと，~CSS定義な新たな値を追加するときに困難さを伴い得る
— ~UAは、
既存の利用度について［
利用-中にある作者~定義な識別子のうち，~CSS定義な新たな識別子に合致しているものは、
ごく少数に限られるかどうか
］を調査して，［
新たな値に~CSS定義な特別な意味を与えても，既存の~pageを非互換化しない
］ことに賭ける必要がある。
◎
Some contexts accept both author-defined identifiers and CSS-defined identifiers. If not handled carefully, this can result in difficulties adding new CSS-defined values; UAs have to study existing usage and gamble that there are sufficiently few author-defined identifiers in use matching the new CSS-defined one, so giving the new value a special CSS-defined meaning won’t break existing pages.
</p>

<p>
~CSSには、［
まさにこの~~不安を抱えた仕方で，この 2 つの値~空間を混合する
］ような多くの旧来の事例がある
— `dashed-ident$t 型は、［
作者~定義な識別子, ~CSS定義な識別子
］を判別する容易な仕方になることが意味される。
◎
While there are many legacy cases in CSS that mix these two values spaces in exactly this fraught way, the &lt;dashed-ident&gt; type is meant to be an easy way to distinguish author-defined identifiers from CSS-defined identifiers.
</p>

<p>
`dashed-ident@t
生成規則は、
`custom-ident$t であり，常に文字大小区別になる
— 加えて，［
2 個の~dash（ `002D^U `HYPHEN-MINUS^cn ）から開始しなければナラナイ
］とする制約も伴う。
◎
The &lt;dashed-ident&gt; production is a &lt;custom-ident&gt;, with all the case-sensitivity that implies, with the additional restriction that it must start with two dashes (U+002D HYPHEN-MINUS).
</p>

<p>
`dashed-ident$t は、
もっぱら作者~定義な名前~用の利用に予約される。
~CSSは、
`dashed-ident$t 【に合致する何か】を自前の利用-用に定義することは決してない。
◎
&lt;dashed-ident&gt;s are reserved solely for use as author-defined names. CSS will never define a &lt;dashed-ident&gt; for its own use.
</p>

<div class="example">
<p>
例えば，`~custom~prop$は、
~CSS定義な~propから判別-可能になる必要がある
— ~CSSには、
新たな~propが定期的に追加されるので。
これを許容するため、
`~custom~prop$の名前は `dashed-ident$t になることが要求される
— 次の例のように：
◎
For example, custom properties need to be distinguishable from CSS-defined properties, as new properties are added to CSS regularly. To allow this, custom property names are required to be &lt;dashed-ident&gt;s, as in this example:
</p>

<pre class="lang-css">
.foo {
  --fg-color: blue;
}
</pre>
</div>

<div class="example">
<p>
`dashed-ident$t は，
`color-profile$at 規則~内でも利用され、
作者~定義な色~profileを `device-cmyk^v の様な定義済みなそれと分離することに加え、
~CSSが［
作者~定義な~profileと衝突するおそれなく，
将来にも定義済みな（かつ上書き可能な）~profileを さらに定義する
］ことを許容する：
◎
&lt;dashed-ident&gt;s are also used in the @color-profile rule, to separate author-defined color profiles from pre-defined ones like device-cmyk, and allow CSS to define more pre-defined (but overridable) profiles in the future without fear of clashing with author-defined profiles:
</p>

<pre class="lang-css">
@color-profile --foo { src: url(https://example.com/foo.icc); }
.foo {
  color: color(--foo 1 0 .5 / .2);
}
</pre>
</div>

<div class="example">
<p>
将来には，~CSSは、
作者により制御される構文を追加するに伴い，
`dashed-ident$t をもっと利用することになる。
~CSS著作~tool
— ~customな構文を標準な~CSSに転換するような前処理器など —
も、
将来の~CSS設計と衝突するのを避けるよう，
`dashed-ident$t を利用する`ベキ^emである。
◎
CSS will use &lt;dashed-ident&gt; more in the future, as more author-controlled syntax is added. CSS authoring tools, such as preprocessors that turn custom syntax into standard CSS, should use &lt;dashed-ident&gt; as well, to avoid clashing with future CSS design.
</p>

<p>
例えば，~CSS前処理器が “~customな” 新たな~at-規則を追加する場合、
それを `custom^at と綴る`ベキでない^em
— これは、
将来に公式的な `custom^at 規則が~CSSに追加されたとき，衝突することになるので。
代わりに， `--custom^at を利用するベキである
— そうすれば、
~CSSが定義する何物にも決して衝突しないことが保証される。
◎
For example, if a CSS preprocessor added a new "custom" at-rule, it shouldn’t spell it @custom, as this would clash with a future official @custom rule added by CSS. Instead, it should use @--custom, which is guaranteed to never clash with anything defined by CSS.
</p>

<p>
さらに良くするには、
`--library1-custom^at を利用するベキである
— 別の~libraryが（ `--library2-custom^at と綴られる） “~customな” 自前の~at-規則を追加しても，衝突する可能性がないよう。
理想的には、
~tool法にて許容されるなら，この接頭辞も
— 作者が自らの手で衝突-を避けれるよう —
~custom化-可能になるベキである。
◎
Even better, it should use @--library1-custom, so that if Library2 adds their own "custom" at-rule (spelled @--library2-custom), there’s no possibility of clash. Ideally this prefix should be customizable, if allowed by the tooling, so authors can manually avoid clashes on their own.
</p>
</div>

		</section>
		<section id="strings">
<h3 title="Quoted Strings: the &lt;string&gt; type">4.4. 引用符~付き文字列： `string^t 型</h3>

<p>
`文字列$は
`string@t
で表記され、
~literalには，一重~引用符または二重~引用符で括られた文字~並びとして記される。
それは、
`string-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。
【これは、 “~CSS文字列” と称されることもある。】
◎
Strings are denoted by &lt;string&gt;. When written literally, they consist of a sequence of characters delimited by double quotes or single quotes, corresponding to the &lt;string-token&gt; production in the CSS Syntax Module [CSS-SYNTAX-3].
</p>

<p>
二重~引用符は、
（ `"\""^c または `"\22"^c として）`~escape$されない限り，
二重~引用符の内側に現れることはできない。
一重~引用符も同様である（ `'\''^c または `'\27'^c ）：
◎
Double quotes cannot occur inside double quotes, unless escaped (as "\"" or as "\22"). Analogously for single quotes ('\'' or '\27').
</p>

<div class="example">
<pre class="lang-css">
content: "これは '文字列'。";
content: "これは \"文字列\"。";
content: 'これは "文字列"。';
content: 'これは \'文字列\'。';
</pre>
<!-- 
content: "this is a 'string'.";
content: "this is a \"string\".";
content: 'this is a "string".';
content: 'this is a \'string\'.';
-->
</div>

<p>
美観その他の理由で，文字列を複数~行lに分断することもアリである。
ただし，そのような場合、
改行文字~自身が~backslash（ \ ）で~escapeされる必要がある。
それらの改行文字は、
後で文字列から除去される。
例えば、
次の 2 つの選択子は正確に同じになる：
◎
It is possible to break strings over several lines, for aesthetic or other reasons, but in such a case the newline itself has to be escaped with a backslash (\). The newline is subsequently removed from the string. For instance, the following two selectors are exactly the same:
</p>

<div class="example">
<pre class="lang-css">
a[title="そんなに長いタイ\
トルではないが"] {/*...*/}

a[title="そんなに長いタイ<!-- \ -->トルではないが"] {/*...*/}
</pre>
<!-- 
a[title="a not s\
o very long title"] {/*...*/}
a[title="a not so very long title"] {/*...*/}
-->
</div>

<p>
文字列は，改行文字を直に表現できないので、
改行文字を含めるためには "`\A^c" ~escapeを利用する。
（ 16 進数 A は，~Unicodeにおいては文字 `000A^U `LINE FEED^cn であるが、
~CSSにおいては，汎用な観念としての “改行文字” を表現する。）
◎
Since a string cannot directly represent a newline, to include a newline in a string, use the escape "\A". (Hexadecimal A is the line feed character in Unicode (U+000A), but represents the generic notion of "newline" in CSS.)
</p>

		</section>
		<section id="urls">
<h3 title="Resource Locators: the &lt;url&gt; type">4.5. 資源の所在指定子： `url^t 型</h3>

<p>
`url$t 型は、［
`url@f
関数／
`src@f
関数
］で記され，ある資源を指す`~URL$を表現する。
◎
The &lt;url&gt; type, written with the url() and src() functions, represents a URL, which is a pointer to a resource.
</p>

<p>
`url$t の構文は：
◎
The syntax of &lt;url&gt; is:
</p>

<pre class="prod">
`url@t
	= `url()$t
	| `src()$t

`url()$t
	= url( `string$t `url-modifier$t* )
	| `url-token$t
`src()$t
	= src( `string$t `url-modifier$t* )
</pre>

<div class="example">
<p>
背景~画像として利用される~URLの例：
◎
This example shows a URL being used as a background image:
</p>

<pre class="lang-css">
body { background: url("http://www.example.com/pinkish.gif") }
</pre>
</div>

<p>
`url$f は、
~URL値を括る引用符を省いて記せる
— その事例では、
`url-token$t として`特別に構文解析される＠~CSSSYN#consume-a-url-token$。
`CSS-SYNTAX-3$r
◎
A url() can be written without quotation marks around the URL value, in which case it is specially-parsed as a &lt;url-token&gt;; see CSS Syntax 3 § 4.3.6 Consume a url token. [CSS-SYNTAX-3]
</p>

<p class="note">注記：
この特別な構文解析-法があるので、
`url$f は，~literalな値しか表出できない。
`var$f などの関数により~URLを供するためには、
`src$f 記法を利用すること
— それには、
この特別な構文解析-法は無い。
◎
Note: Because of this special parsing, url() can only express its value literally. To provide a URL by functions such as var(), use the src() notation, which does not have this special parsing rule.
</p>

<div class="example">
<p>
例えば，次の 2 つの宣言は、
同じになる：
◎
For example, the following declarations are identical:
</p>

<pre class="lang-css">
background: url("http://www.example.com/pinkish.gif");
background: url(http://www.example.com/pinkish.gif);
</pre>

<p>
次に挙げるものも同じ意味になる：
◎
And these have the same meaning as well:
</p>

<pre class="lang-css">
background: src("http://www.example.com/pinkish.gif");
--foo: "http://www.example.com/pinkish.gif";
background: src(var(--foo));
</pre>

<p>
が、
次は`働かない^em：
◎
But this does not work:
</p>

<pre class="lang-css">
--foo: "http://www.example.com/pinkish.gif";
background: url(var(--foo));
</pre>

<p>
値~内の~escapeされてない `(^l により，構文解析-~errorになり、
宣言~全体が無効として棄てられるので。
◎
...because the unescaped "(" in the value causes a parse error, so the entire declaration is thrown out as invalid.
</p>
</div>

<p class="note">注記：
引用符なしの `url$f 構文は、
`url-modifier$t 引数を受容しないことに加え、
~URLの中の［
括弧,
`空白$,
引用符（ `'^c ／ `"^c ）
］は，~backslash（ `\^c ）で~escapeしなければナラナイ
— 例：
`url(open\(parens)^v ／
`url(close\)parens)^v
（引用符~付きな `string$t をとる `url$f においては、
~escapeする必要があるのは［
改行文字, 当の文字列を括るために利用した引用符
］に限られる）。
~URLの種別にもよるが、
これらの文字を
— `URL$r に述べられるとおり —
~URL~escapeで記すこともアリである
（例えば，先の例に対する
`url(open%28parens)^v ／
`url(close%29parens)^v
）。
◎
Note: The unquoted url() syntax cannot accept a &lt;url-modifier&gt; argument and has extra escaping requirements: parentheses, whitespace characters, single quotes (') and double quotes (") appearing in a URL must be escaped with a backslash, e.g. url(open\(parens), url(close\)parens). (In quoted &lt;string&gt; url()s, only newlines and the character used to quote the string need to be escaped.) Depending on the type of URL, it might also be possible to write these characters as URL-escapes (e.g. url(open%28parens) or url(close%29parens)) as described in [URL].
</p>

<p id="_bare-url">
一部の~CSS文脈（ `import$at など）では、
`url$t を関数で包装せずに，裸の `string$t で表現することも許容される。
そのような事例における文字列は、
それを包含している `url$f 関数と同じに挙動する。
◎
Some CSS contexts (such as @import) also allow a &lt;url&gt; to be represented by a bare &lt;string&gt;, without the function wrapper. In such cases the string behaves identically to a url() function containing that string.
</p>

<div class="example">
<p>
例えば，次の 2 つの文は、
同じに動作する：
◎
For example, the following statements act identically:
</p>

<pre class="lang-css">
@import url("base-theme.css");
@import "base-theme.css";
</pre>
</div>

			<section id="relative-urls">
<h4 title="Relative URLs">4.5.1. 相対~URL</h4>

<p>
資源の絶対的な所在に依存しない ~module化された~stylesheetを作成するためには、
作者は，相対~URLを利用するベキである。
（ `URL$r にて定義される）相対~URLは、
基底~URLを利用して全部的な~URLに解決される。
この処理n用の規範的な~algoは、
RFC 3986, § 3 にて定義されている。
~CSS~stylesheetにおいては、
基底~URLは
— ~source文書のそれではなく —
~stylesheet自身のそれである。
文書~内に埋込まれた~stylesheetの基底~URLは、
その文書に結付けられた基底~URLになる。
◎
In order to create modular style sheets that are not dependent on the absolute location of a resource, authors should use relative URLs. Relative URLs (as defined in [URL]) are resolved to full URLs using a base URL. RFC 3986, section 3, defines the normative algorithm for this process. For CSS style sheets, the base URL is that of the style sheet itself, not that of the styled source document. Style sheets embedded within a document have the base URL associated with their container.
</p>

<p class="note">注記：
~HTML文書においては、
`基底~URLは変異-可能＠~HTMLurl#dynamic-changes-to-base-urls$である。
◎
Note: For HTML documents, the base URL is mutable.
</p>

<p>
~propの算出d値に現れる `url$t は、
前段落で述べたように，絶対~URLに解決される。
~UAが~URLを絶対~URLに解決できない場合、
指定d値がその算出d値になる。
◎
When a &lt;url&gt; appears in the computed value of a property, it is resolved to an absolute URL, as described in the preceding paragraph. The computed value of a URL that the UA cannot resolve to an absolute URL is the specified value.
</p>

<div class="example">
<p>
例えば，次の規則が：
◎
For example, suppose the following rule:
</p>

<pre class="lang-css">
body { background: url("tile.png") }
</pre>

<p>
次の~URLで指名される~stylesheetの中に在るとするとき：
◎
is located in a style sheet designated by the URL:
</p>

<pre>
http://www.example.org/style/basic.css
</pre>

<p>
~source文書の `body^e の背景は、
次の~URLで指名される資源の画像で敷詰められることになる：
◎
The background of the source document’s &lt;body&gt; will be tiled with whatever image is described by the resource designated by the URL:
</p>

<pre>
http://www.example.org/style/tile.png
</pre>

<p>
`body^e を包含している~source文書の~URLに関わらず，同じ画像が利用されることになる。
◎
The same image will be used regardless of the URL of the source document containing the &lt;body&gt;.
</p>
</div>

				<section id="local-urls">
<h5 title="Fragment URLs">4.5.1.1. 素片~URL</h5>

<p>
要素~ID参照が，~CSSにおいて［
基底~URLの変化／~shadow~DOMかどうか
］に関わらず働くことを可能化するため、
素片のみを包含する `url$t には，特別な挙動がある。
◎
To enable element ID references to work in CSS regardless of base URL changes or shadow DOM, &lt;url&gt;s have special behavior when they contain only a fragment.
</p>

<p>
`url$t の値が文字 `0023^U `NUMBER SIGN^cn （ `#^c ）から開始する場合、
当の~URLの
`局所~URLか@
は ~T に設定され【既定は ~F 】、
当の~URLは，当の`素片$url用の`~tree視野な参照$になる。
◎
If a &lt;url&gt;’s value starts with a U+0023 NUMBER SIGN (#) character, then the URL additionally has its local url flag set, and is a tree-scoped reference for the URL’s fragment.
</p>

<p>
`url$t のうち［
その`局所~URLか$ ~EQ ~T
］を満たすものを他と照合するときは、
当の~URLの素片に応じて：
◎
When matching a &lt;url&gt; with the local url flag set:
</p>
<ul>
	<li>
<p>
要素~ID参照である場合：
◎
if the URL’s fragment is an element ID reference＼
↓↓ (rather than, say, a media fragment),＼
</p>
		<ul>
			<li>
当の~URLを`~tree視野な参照$として解決する
— `~tree視野な名前$として，~tree内の~IDを対象にする下で。
特定的には、
当の`~node~tree$を成す子孫~要素のうち［
その`~ID$ ~EQ ~URLの`素片$url
］を満たすもののうち［
`~tree順序$で最初のもの
］に解決する。
（加えて，`~tree視野な参照$との照合は、
通例通り，必要なら~host【`~shadow~host$】が属する~treeへ継続するとする）。
◎
resolve it as a tree-scoped reference with the tree’s IDs as the associated tree-scoped names: specifically, resolve to the first element in tree order among the associated node tree’s descendants with the URL’s fragment as its ID. (And, as usual for tree-scoped references, continuing up to the host’s tree if needed.)
</li>
			<li>
該当する要素が見出されなかった場合、
当の~URLを解決することに失敗するとする。
◎
If no such element is found, the URL fails to resolve.
</li>
		</ul>
	</li>
	<li>
他の場合
（例：`媒体~素片＠~TR/media-frags/$）
⇒
当の素片を現在の文書を~~基準に解決する。
◎
otherwise, resolve the fragment against the current document.
</li>
</ul>

<p class="issue">
これは、
場合によっては，`指示された要素を見出す$手続きを参照するが、
それは， `ShadowRoot$I ではなく `Document$I 用に特定的に定義されている。
◎
Possibly reference find a potential indicated element, but that is defined specifically for Documents, not ShadowRoots.
</p>

<p class="note">注記：
このことは、
そのような素片【要素~ID参照である素片？】は，現在の文書の内容
（あるいは，~shadow~DOMが孕まれている場合は、
当の~stylesheetが住まう`~node~tree$）
を~~基準に解決されることを意味する
— そのような相対~URLが他所で どう解決されるかに関わらず
（例えば、
`base$e 要素により基底~URLが変更されようが，あるいは［
~linkされた~stylesheet内の相対~URLが，当の~stylesheetの~URLを~~基準に解決される
］ことも無視して）。
◎
Note: This means that such fragments will resolve against the contents of the current document (or whichever node tree the stylesheet lives in, if shadow DOM is involved) regardless of how such relative URLs would resolve elsewhere (ignoring, for example, base elements changing the base URL, or relative URLs in linked stylesheets resolving against the stylesheet’s URL).
</p>

<div class="example">
<p>
次の例では、
`#anchor^v は `http://example.com/^v を~~基準に解決される一方で，
`#image^v は 当の~HTML文書~内の要素~自身を~~基準に解決されることになる：
◎
In the following example, #anchor will resolve against http://example.com/ whereas #image will resolve against the elements in the HTML document itself:
</p>

<pre class="lang-html">&lt;!DOCTYPE html&gt;
&lt;base href="http://example.com/"&gt;
...
&lt;a href="#anchor" style="background-image: url(#image)"&gt;link&lt;/a&gt;
</pre>
</div>

<p>
`url$t のうち，その`局所~URLか$が ~T に設定されたものに対しては、
それを`直列化-$した結果は，当の素片だけになるモノトスル。
◎
When serializing a url() with the local url flag set, it must serialize as just the fragment.
</p>

<p class="trans-note">【
この節は， `url$t にしか触れていないが、
一部の文脈で許容される裸の~URLにも，`適用されよう＠#_bare-url$。
】</p>

				</section>
			</section>
			<section id="url-empty">
<h4 title="Empty URLs">4.5.2. 空な~URL</h4>

<p>
`url$t 内の値が（ `url("")^v や `url()^v の様に）空~文字列である場合、
その~URLは，無効な資源に解決するモノトスル
（ `about:invalid＠#about-invalid$c のような~URLに対するとき類似に）
◎
If the value of the &lt;url&gt; is the empty string (like url("") or url()), the url must resolve to an invalid resource (similar to what the url about:invalid does).
</p>

<p>
それの算出d値は、［
`url("")^v ／ `src("")^v
］のうち指定された方になり，
そのままに直列化するモノトスル。
◎
Its computed value is url("") or src(""), whichever was specified, and it must serialize as such.
</p>

<p class="note">注記：
これにより、［
~web~platformの他所における，埋込d資源に対する空な~URLの挙動
］に合致することに加え、［
編集時の誤りで `url$f 値が空なままにされたことに因り，~stylesheetや~host文書が再度~要請される
］ような，余計な流通は避けられ、
`url$f がどこに現れようが，資源は ほぼ確実に無効になるであろう。
~web~platformにおいては，~linkに空な~URLをあてがうことも`許容される^emので、
~CSSに~hyperlinkを制御する何らかの機能性が加わったときには、
この制約は，その種の文脈においては緩められ得る。
◎
Note: This matches the behavior of empty urls for embedded resources elsewhere in the web platform, and avoids excess traffic re-requesting the stylesheet or host document due to editing mistakes leaving the url() value empty, which are almost certain to be invalid resources for whatever the url() shows up in. Linking on the web platform does allow empty urls, so if/when CSS gains some functionality to control hyperlinks, this restriction can be relaxed in those contexts.
</p>

			</section>
			<section id="url-modifiers">
<h4 title="URL Modifiers">4.5.3. ~URL改変子</h4>

<p>
`url$t は、
`url-modifier@t
たちを追加的に指定することも~supportする
— それは、
~URLの意味や解釈をいくぶん変更する。
`url-modifier$t は、［
`ident$t ／ `関数-記法$
］いずれかである。
◎
&lt;url&gt;s support specifying additional &lt;url-modifier&gt;s, which change the meaning or the interpretation of the URL somehow. A &lt;url-modifier&gt; is either an &lt;ident&gt; or a functional notation.
</p>

<p>
この仕様は、
`url-modifier$t を定義しない
— 他の仕様が定義するであろう。
◎
This specification does not define any &lt;url-modifier&gt;s, but other specs may do so.
</p>

<p class="note">注記：
`url$t のうち［
引用符で括られていないもの／
`url$f 【や `src$f 】で包装されていないもの
］は、
`url-modifier$t を受容しない。
◎
Note: A &lt;url&gt; that is either unquoted or not wrapped in url() notation cannot accept any &lt;url-modifier&gt;s.
</p>

			</section>
			<section id="url-processing">
<h4 title="URL Processing Model">4.5.4. ~URL処理~model</h4>

<div class="algo">
<p>
~URLから
`~style資源を~fetchする@
~algoは、
所与の
⇒＃
［ `~URL$／ `url$t ］ %~URL値,
`CSSStyleSheet$I ~obj %~stylesheet,
文字列 %行先,
文字列 %~CORS~mode,
~algo %応答の処理n
◎終
に対し：
◎
To fetch a style resource from a url or &lt;url&gt; urlValue, given a CSSStyleSheet sheet, a string destination matching a RequestDestination, a "no-cors" or "cors" corsMode, and an algorithm processResponse accepting a response and a null, failure or byte stream:
</p>
<ol>
	<li>
~Assert
⇒＃
%行先 は `RequestDestination$I 値である／
%~CORS~mode ~IN { `no-cors^l, `cors^l } ／
%応答の処理n は ( `応答$, ［ ~NULL／ `失敗^i ／~byte~stream ］) を受容する
◎
↑</li>
	<li>
%環境~設定群 ~LET %~stylesheet に`関連な設定群~obj$
◎
Let environmentSettings be sheet’s relevant settings object.
</li>
	<li>
%基底 ~LET %~stylesheet の`~stylesheet基底~URL$ss
`CSSOM$r
◎
Let base be sheet’s stylesheet base URL＼
</li>
	<li>
~IF［
%基底 ~EQ ~NULL
］
⇒
%環境~設定群 の`~API用~基底~URL$enV
◎
if it is not null, otherwise environmentSettings’s API base URL. [CSSOM]
</li>
	<li>
<p>
%~URL文字列 ~LET %~URL値 に応じて
⇒＃
`~URL$であるならば `~URLを直列化する$( %~URL値 ) ／
`url$t であるならば その最初の引数
</p>

<p class="trans-note">【
この場合分けは、
この訳による補完。
】</p>
	</li>
	<li>
%構文解析した~URL ~LET `~URL構文解析する$( %~URL文字列, %基底 )
◎
Let parsedUrl be the result of the URL parser steps with urlValue’s url and base.＼
</li>
	<li>
~IF［
%構文解析した~URL ~EQ `失敗^i
］
⇒
~RET
◎
If the algorithm returns an error, return.
</li>
	<li>
%要請 ~LET 新たな`要請$
— その
⇒＃
`~URL$rq ~SET %構文解析した~URL,
`行先$rq ~SET %行先,
`~mode$rq ~SET %~CORS~mode,
`生成元$rq ~SET %環境~設定群 の`生成元$enV,
`資格証~mode$rq ~SET `same-origin^l,
`~URL資格証を利用するか$rq ~SET ~T,
`~client$rq ~SET %環境~設定群,
`~referrer$rq ~SET %環境~設定群 の`~API用~基底~URL$enV
◎
Let req be a new request whose url is parsedUrl, whose destination is destination, mode is corsMode, origin is environmentSettings’s origin, credentials mode is "same-origin", use-url-credentials flag is set, client is environmentSettings, and whose referrer is environmentSettings’s API base URL.
</li>
	<li>
<p>
%要請 に適用される
`~URLの要請~改変子~用の手続き@
があれば，それを適用する。
◎
Apply any URL request modifier steps that apply to this request.
</p>

<p class="note">注記：
この仕様は，~URLの要請~改変子~用の手続きを定義しないが、
他の仕様は，それを行い得る。
◎
Note: This specification does not define any URL request modification steps, but other specs may do so.
</p>

<p class="trans-note">【
~URLの要請~改変子~用の手続きは、
例えば，`~level 5$ の `§ 要請~URL改変子＠~CSSVAL5#request-url-modifiers$
にて定義されている。
そこで利用される `request-url-modifier^t （ “要請~URL改変子” ）は、
`url-modifier$t の一部を成し，それも同じ節で定義されている
（ %~URL値 が `url$t でない場合、
`request-url-modifier^t は無いので，この段は適用し得ないことになる）。
】</p>

	</li>
	<li>
~IF［
%要請 の`~mode$rq~EQ `cors^l
］
⇒
%要請 の`~referrer$rq ~SET %~stylesheet の`所在$ss
`CSSOM$r
◎
If req’s mode is "cors", set req’s referrer to sheet’s location. [CSSOM]
</li>
	<li>
~IF［
%~stylesheet の`生成元~cleanか$ss ~EQ ~T
］
⇒
%要請 の`起動元~種別$rq ~SET `css^l
`CSSOM$r
◎
If sheet’s origin-clean flag is set, set req’s initiator type to "css". [CSSOM]
</li>
	<li>
%要請 を`~fetchする$
— 次を与える下で
⇒＃
`応答の本体を消費する処理n$i ~SET %応答の処理n
◎
Fetch req, with processresponseconsumebody set to processResponse.
</li>
</ol>
</div>

<p>
~CSS内で表出された~URLを解釈するときは、
当の~stylesheetの符号化法に関わらず，
`~URL構文解析する$際に %符号化法 引数を省略する
（すなわち，既定の~UTF-8を利用する）
モノトスル。
◎
When interpreting URLs expressed in CSS, the URL parser’s encoding argument must be omitted (i.e. use the default, UTF-8), regardless of the stylesheet encoding.
</p>

<p class="note">注記：
言い換えれば、
~CSS内に書かれた~URLは，
常に
— 当の~stylesheetの符号化法に関わらず —
`~URL$【！URL object】内の各~ASCIIでない符号位置を~UTF-8を利用して`~percent-符号化する＠~URL1#string-percent-encode-after-encoding$ことになる
（したがって、
例えば，当の`~URL$【！URL value】を~network要請~用に利用するときも）。
これは、
~stylesheetを~Unicode`符号位置$へ`復号した後＠~CSSSYN#input-byte-stream$に生じることに注意。
◎
Note: In other words, a URL written in CSS will always percent-encode non-ASCII codepoints using UTF-8 in the URL object (and thus whenever using the URL value for e.g. network requests), regardless of the stylesheet’s own encoding. Note that this occurs after decoding the stylesheet into Unicode code points.
</p>

			</section>
		</section>
	</section>
	<section id="numeric-types">
<h2 title="Numeric Data Types">5. 数量-~data型</h2>

<p>
数量-~data型は、［
数量／~index／位置
］などの値を表現するために利用される。
構文上は，数量（数的な側面）を表出する多くの変種nが存在し得るが、［
`指定d値$ ／ `算出d値$
］は，所与の数量-値における これらの変種nを判別しない
— それは、
構文上の表現ではなく，値の抽象的な数量を表現する。
◎
Numeric data types are used to represent quantities, indexes, positions, and other such values. Although many syntactic variations can exist in expressing the quantity (numeric aspect) in a given numeric value, the specified and computed value do not distinguish these variations: they represent the value’s abstract quantity, not its syntactic representation.
</p>

<p>
`数量-~data型@
は、［
`integer$t,
`number$t,
`percentage$t
］および［
次に挙げる様々な`次元$
］を含む
⇒
`length$t,
`angle$t,
`time$t,
`frequency$t,
`resolution$t
◎
The numeric data types include &lt;integer&gt;, &lt;number&gt;, &lt;percentage&gt;, and various dimensions including &lt;length&gt;, &lt;angle&gt;, &lt;time&gt;, &lt;frequency&gt;, and &lt;resolution&gt;.
</p>

<p class="note">注記：
一般~目的の`次元$は，ここに定義されるが、
他の一部の~moduleも，［
より局所~化された用法を伴う，追加的な~data型
］を定義する
（例： `css-grid-1$r は `fr$u 単位を導入する）。
◎
Note: While general-purpose dimensions are defined here, some other modules define additional data types (e.g. [css-grid-1] introduces fr units) whose usage is more localized.
</p>

<p>
~CSSにおける数量-値の［
精度, ~supportされる範囲
］は、
`実装定義$であり，当の値が利用される［
~prop／他の文脈
］に基づいて変わり得る。
しかしながら，~CSS仕様の中では、［
精度, 範囲
］どちらも無限と見做される。
実装は、［［
範囲／精度
］の制限に因り，明示的に~supportできない値
］に対しては，［
自身が~supportする最も近い値に変換する
］モノトスルが、［
実装が “最も近い” をどう定義するか
］も，`実装定義$である。
◎
The precision and supported range of numeric values in CSS is implementation-defined, and can vary based on the property or other context a value is used in. However, within the CSS specifications, infinite precision and range is assumed. When a value cannot be explicitly supported due to range/precision limitations, it must be converted to the closest value supported by the implementation, but how the implementation defines "closest" is implementation-defined as well.
</p>

<p>
`angle$t 値に対しては、
~supportされる実装定義な範囲を超過することに因り変換する必要があるときは，
当の値に最も近い［
~supportされる `360deg^v の整数倍
］に切詰めるモノトスル。
◎
If an &lt;angle&gt; must be converted due to exceeding the implementation-defined range of supported values, it must be clamped to the nearest supported multiple of 360deg.
</p>

		<section id="numeric-ranges">
<h3 title="Range Restrictions and Range Definition Notation">5.1. 範囲の制約と範囲~定義の記法</h3>

<p>
~propには、
数量-値を一定~範囲に制約するものもある。
許容d範囲~外の値を伴う宣言は
— 他が指定されない限り —
無効であり，`無視する$モノトスル。
数量-型~記法においては、
`角括弧付き範囲~記法@
を利用して，範囲~制約を注釈できる。
それは、
山括弧の合間にて，型を識別する~keywordの後に
`[最小v, 最大v]^g
と記され，閉区間を成す範囲 { 最小v 〜 最大v } を指示する。
例えば：
◎
Properties can restrict numeric values to some range. If the value is outside the allowed range, then unless otherwise specified, the declaration is invalid and must be ignored. Range restrictions can be annotated in the numeric type notation using CSS bracketed range notation—[min,max]—within the angle brackets, after the identifying keyword, indicating a closed range between (and including) min and max. For example,＼
</p>
<ul>
	<li>
`integer [0,10]$t は、
範囲 { `0^v 〜 `10^v } に入る整数を指示する。
◎
&lt;integer [0,10]&gt; indicates an integer between 0 and 10, inclusive,＼
</li>
	<li>
`angle [0,180deg]$t は、
範囲 { `0deg^v 〜 `180deg^v } に入る角度を指示する
（どの角度~単位でも表出し得る）。
◎
while &lt;angle [0,180deg]&gt; indicates an angle between 0deg and 180deg (expressed in any unit).
</li>
</ul>

<p class="trans-note">【
この記法を長さ単位に利用する場合、
相対~長さがあることに因り，制約がある（ `7584$issue ）。
】</p>

<p class="note">注記：
~CSS値は，一般に開区間を成す範囲を許容しないので、
角括弧~記法しか利用されない。
◎
Note: CSS values generally do not allow open ranges; thus only square-bracket notation is used.
</p>

<p>
~CSSは、
理論的には，すべての値~型に対し無限な［
精度, 範囲
］を~supportするが、
現実の実装においては有限になる。
~UAは、
適度に有用な［
精度, 範囲
］を~supportするベキである。
理想上は制限されない範囲は、［
∞, −∞
］のうち適切な方を利用して指示される。
例えば， `length [0,∞]$t は、
負でない長さを指示する。
◎
CSS theoretically supports infinite precision and infinite ranges for all value types; however in reality implementations have finite capacity. UAs should support reasonably useful ranges and precisions. Range extremes that are ideally unlimited are indicated using ∞ or −∞ as appropriate. For example, &lt;length [0,∞]&gt; indicates a non-negative length.
</p>

<p>
`角括弧付き範囲~記法$を利用して, あるいは~propの記述にて，範囲が指示されていない場合、
`[−∞,∞]^g
と見做される。
◎
If no range is indicated, either by using the bracketed range notation or in the property description, then [−∞,∞] is assumed.
</p>

<p>
値［
−∞ ／ ∞
］は、
当の値~型が単位を利用する場合でも，
単位なしで記さなければナラナイ。
値 0 は、
当の値~型が “単位なしの 0” を許容しない場合（ `time$t など）でも，
単位なしで記してもヨイ。
◎
Values of −∞ or ∞ must be written without units, even if the value type uses units. Values of 0 can be written without units, even if the value type doesn’t allow “unitless zeroes” (such as &lt;time&gt;).
</p>

<p class="note">注記：
これを書いた時点では，`角括弧付き範囲~記法$は まだ日が浅いので、
ほとんどの~CSS仕様は，範囲~制限を注釈文でしか述べていない
（例えば，
“負な値は許容されない”
や
“負な値は妥当でない（無効）”
は、
範囲
`[0, ∞]^g
を指示する）。
これは、~~制限を~~緩めるものではない。
◎
Note: At the time of writing, the bracketed range notation is new; thus in most CSS specifications any range limitations are described only in prose. (For example, “Negative values are not allowed” or “Negative values are invalid” indicate a [0,∞] range.) This does not make them any less binding.
</p>

		</section>
		<section id="integers">
<h3 title="Integers: the &lt;integer&gt; type">5.2. 整数： `integer^t 型</h3>

<p>
整数~値は
`integer@t
で表記される。
◎
Integer values are denoted by &lt;integer&gt;.
</p>

<p>
`整数@
は、
~literalには［
1 個以上の 10 進~数字（ `0^c 〜 `9^c ）が成す並び
］として記され，
`number-token$t 生成規則 `CSS-SYNTAX-3$r の下位集合に対応する。
整数の先頭には，正負を指示する［
`-^c ／ `+^c
］が前置されてもヨイ。
◎
When written literally, an integer is one or more decimal digits 0 through 9 and corresponds to a subset of the &lt;number-token&gt; production in the CSS Syntax Module [CSS-SYNTAX-3]. The first digit of an integer may be immediately preceded by - or + to indicate the integer’s sign.
</p>

<p>
他が指定されない限り，
各種~CSS仕様において
`最も近い整数に丸める@
所では、
小数部が正確に 0.5 のときには，
正な無限大（ +∞ ）に近い方へ丸めることが要求される。
（例えば、
`1.5^v は `2^v に丸められる一方，
`-1.5^v は `-1^v に丸められる。）
◎
Unless otherwise specified, in the CSS specifications rounding to the nearest integer requires rounding in the direction of +∞ when the fractional portion is exactly 0.5. (For example, 1.5 rounds to 2, while -1.5 rounds to -1.)
</p>

			<section id="combine-integers">
<h4 title="Computation and Combination of &lt;integer&gt;">5.2.1. `integer^t の算出と結合n</h4>

<p>
他が指定されない限り、
指定された `integer$t の`算出d値$は，指定された抽象-整数になる。
◎
Unless otherwise specified, the computed value of a specified &lt;integer&gt; is the specified abstract integer.
</p>

<p>
`integer$t の`補間$における %結果値 は、
次で定義される
⇒
`number$t の`補間-$を用いて得られた結果を`最も近い整数に丸める$ことにより，
`integer^t に変換した結果
◎
Interpolation of &lt;integer&gt; is defined as Vresult = round((1 - p) × VA + p × VB); that is, interpolation happens in the real number space as for &lt;number&gt;s, and the result is converted to an &lt;integer&gt; by rounding to the nearest integer.
</p>

<p>
`integer$t の`加算$における %結果値 は、
次で定義される
⇒
値A ~PLUS 値B
◎
Addition of &lt;integer&gt; is defined as Vresult = VA + VB
</p>

			</section>
		</section>
		<section id="numbers">
<h3 title="Real Numbers: the &lt;number&gt; type">5.3. 実数： `number^t 型</h3>

<p>
実数~値は
`number@t
で表記され、
小数部を伴い得る実数（ `real number^en ）を表現する。
◎
Number values are denoted by &lt;number&gt;, and represent real numbers, possibly with a fractional component.
</p>

<div class="p">
<p>
`実数@
は、
~literalには，`整数$として, または次が成す並びとして記される：
</p>
<ol>
	<li>
`整数$
</li>
	<li>
~dot（ `.^c ）
</li>
	<li>
1 個以上の 10 進~数字
</li>
	<li>
<p>
省略可能な，次が成す並び：
</p>
		<ol>
			<li>
文字［ `e^c または `E^c ］
</li>
			<li>
`整数$
</li>
		</ol>
<p>
これは、
`科学的記数法＠https://en.wikipedia.org/wiki/Scientific_notation$における基数 10 による指数を指示する。
</p>
	</li>
</ol>

<p>
`実数$は、
`number-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。
整数と同じく、
実数の先頭には，正負を指示する［
`-^c ／ `+^c
］が前置されてもヨイ
【指数~部を成す整数の先頭にも】。
</p>

<p class="trans-note">【
CSS2 では許容されていなかった指数~部は、
例えば， `CSS-TRANSFORMS-1$r にも利用される~prop
— 元々は~SVG用であった~prop —
に適応するために導入されたと見受けられる。
】【
`number^t を意味する `number^en は，より限定的に “~~実数” と訳している
（今後， `number^t が例えば虚数にまで拡張されることは、
まずないであろう）。
】</p>

◎
When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits; optionally, it can be concluded by the letter “e” or “E” followed by an integer indicating the base-ten exponent in scientific notation. It corresponds to the &lt;number-token&gt; production in the CSS Syntax Module [CSS-SYNTAX-3]. As with integers, the first character of a number may be immediately preceded by - or + to indicate the number’s sign.
</div>

<p>
値
`zero@t
は、
値 0 をとる，~literalな`実数$を表現する。
単に値 0 の `number$t に評価される式（例えば `calc(0)^v ）は、
`zero$t には合致しない
— 合致するのは~literalな `number-token$t に限られる。
【 `zero$t を成す~literalは、 `0^v 以外にも無数にある — `-000^v, `0.00^v, `0E+42^v 等々。】
◎
The value &lt;zero&gt; represents a literal number with the value 0. Expressions that merely evaluate to a &lt;number&gt; with the value 0 (for example, calc(0)) do not match &lt;zero&gt;; only literal &lt;number-token&gt;s do.
</p>

			<section id="combine-numbers">
<h4 title="Computation and Combination of &lt;number&gt;">5.3.1. `number^t の算出と結合n</h4>

<p>
他が指定されない限り、
指定された `number$t の`算出d値$は，指定された抽象-実数になる。
◎
Unless otherwise specified, the computed value of a specified &lt;number&gt; is the specified abstract number.
</p>

<p>
`number$t の`補間$における %結果値 は、
次で定義される
⇒
( 1 ~MINUS %p ) ~MUL 値A ~PLUS %p ~MUL 値B
◎
Interpolation of &lt;number&gt; is defined as Vresult = (1 - p) × VA + p × VB
</p>

<p>
`number$t の`加算$における %結果値 は、
次で定義される
⇒
値A ~PLUS 値B
◎
Addition of &lt;number&gt; is defined as Vresult = VA + VB
</p>

			</section>
		</section>
		<section id="dimensions">
<h3 title="Numbers with Units: dimension values">5.4. 単位を伴う実数： 次元~値</h3>

<p>
`次元@
（ `dimension^en, 測定の次元, ~~寸法）とは、
単位を伴う実数の総称であり，
`dimension@t
で表記される。
◎
The general term dimension refers to a number with a unit attached to it; and is denoted by &lt;dimension&gt;.
</p>

<p>
`次元$は、
~literalには［
`実数$, 単位~識別子
］が成す並びとして記され，
`dimension-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。
単位~識別子は、
`~CSS識別子$であり，~keywordと同様に`~ASCII大小無視$である。
◎
When written literally, a dimension is a number immediately followed by a unit identifier, which is an identifier. It corresponds to the &lt;dimension-token&gt; production in the CSS Syntax Module [CSS-SYNTAX-3]. Like keywords, unit identifiers are ASCII case-insensitive.
</p>

<p>
~CSSは、［
次に挙げるもの, その他の数量
］に `dimension$t を利用する
⇒＃
距離（ `length$t ）,
所要時間（ `time$t ）,
周波数（ `frequency$t ）,
解像度（ `resolution$t ）
◎
CSS uses &lt;dimension&gt;s to specify distances (&lt;length&gt;), durations (&lt;time&gt;), frequencies (&lt;frequency&gt;), resolutions (&lt;resolution&gt;), and other quantities.
</p>

			<section id="compat">
<h4 title="Compatible Units">5.4.1. 互換な単位</h4>

<p>
`算出d値$を`直列化-$するとき `CSSOM$r 、
単位を伴う値は，当の単位に`互換$な`正準-単位$を伴う値に
（ある静的な乗算的-係数を通して）換算される。
所与の単位どうしが
`互換@
であるとは、
ある係数
（例：
`px$u と `in$u との間では 96:1 ／
`em$u と `px$u との間では `font-size$p の算出d値）
で互いに換算できることを意味する。
各［
互いに`互換$な単位たちが成す~group
］においては、
その中のある単位が
`正準-単位@
として定義される。
◎
When serializing computed values [CSSOM], compatible units (those related by a static multiplicative factor, like the 96:1 factor between px and in, or the computed font-size factor between em and px) are converted into a single canonical unit. Each group of compatible units defines which among them is the canonical unit that will be used for serialization.
</p>

<p>
［
`解決d値$のうち，`使用~値$を与えるもの
］を直列化する際には、
長さを表現する すべての値~型（百分率, 実数, ~keyword, 等々）は，長さに`互換$と見なされる。
同様に，`使用~値$を返すような将来の~APIは、［
距離／所要時間／周波数／等々
］を表現するどの値も，関連な`次元$たちが成す~groupに`互換$と見なした上で，
それに則って正準-化するモノトスル。
◎
When serializing resolved values that are used values, all value types (percentages, numbers, keywords, etc.) that represent lengths are considered compatible with lengths. Likewise any future API that returns used values must consider any values that represent distances/durations/frequencies/etc. as compatible with the relevant class of dimensions, and canonicalize accordingly.
</p>

			</section>
			<section id="combine-dimensions">
<h4 title="Combination of Dimensions">5.4.2. 次元の結合n</h4>

<p>
`互換$な`次元$どうし（例えば， 2 個の `length$t 値）の`補間$における %結果値 は、
次で定義される
⇒
( 1 ~MINUS %p ) ~MUL 値A ~PLUS %p ~MUL 値B
◎
Interpolation of compatible dimensions (for example, two &lt;length&gt; values) is defined as Vresult = (1 - p) × VA + p × VB
</p>

<p>
`互換$な`次元$どうしの`加算$における %結果値 は、
次で定義される
⇒
値A ~PLUS 値B
◎
Addition of compatible dimensions is defined as Vresult = VA + VB
</p>
			</section>
		</section>
		<section id="percentages">
<h3 title="Percentages: the &lt;percentage&gt; type">5.5. 百分率： `percentage^t 型</h3>

<p>
百分率~値は
`percentage@t
で表記され、
別の基準~値に対する割合を指示する。
◎
Percentage values are denoted by &lt;percentage&gt;, and indicates a value that is some fraction of another reference value.
</p>

<p>
`百分率@
は、
~literalには［
`実数$,
百分率-記号（ `%^u ）
］が成す並びとして記される。
`百分率$は、
`percentage-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。
◎
When written literally, a percentage consists of a number immediately followed by a percent sign %. It corresponds to the &lt;percentage-token&gt; production in the CSS Syntax Module [CSS-SYNTAX-3].
</p>

<p class="trans-note">【
“割合” , “パーセンテージ” 等と訳されることも多いが、
単位に百分率-記号が利用されつつ 百分率でない尺度による割合を表すことは，
将来も含めて まず~~考えられないので、
より限定的に “百分率” と訳すことにする（語源的にも “`per-cent^en” ）。
】</p>

<p>
百分率~値は常に，例えば長さなど, 別の数量に相対的になる。
百分率を値に許容する 各種~propは、
それが基準にする数量も定義する。
この数量は、［
同じ要素の別の~prop,
先祖~要素の~prop,
`整形~文脈$における測定（例えば，`包含塊$の横幅）,
他の何か
］になり得る。
◎
Percentage values are always relative to another quantity, for example a length. Each property that allows percentages also defines the quantity to which the percentage refers. This quantity can be a value of another property for the same element, the value of a property for an ancestor element, a measurement of the formatting context (e.g., the width of a containing block), or something else.
</p>

			<section id="combine-percentages">
<h4 title="Computation and Combination of &lt;percentage&gt;">5.5.1. `percentage^t の結合n</h4>

<p>
他が指定されない限り†、
百分率の`算出d値$は，指定された百分率になる。
（† `font-size$p など
— それは、
`percentage$t 値を `length$t に算出する。）
◎
Unless otherwise specified (such as in font-size, which computes its &lt;percentage&gt; values to &lt;length&gt;), the computed value of a percentage is the specified percentage.
</p>

<p>
`percentage$t の`補間$における %結果値 は、
次で定義される
⇒
( 1 ~MINUS %p ) ~MUL 値A ~PLUS %p ~MUL 値B
◎
Interpolation of &lt;percentage&gt; is defined as Vresult = (1 - p) × VA + p × VB
</p>

<p>
`percentage$t の`加算$における %結果値 は、
次で定義される
⇒
値A ~PLUS 値B
◎
Addition of &lt;percentage&gt; is defined as Vresult = VA + VB
</p>

			</section>
		</section>
		<section id="mixed-percentages">
<h3 title="Mixing Percentages and Dimensions">5.6. 百分率と次元の混合-法</h3>

<p>
~prop文法において同じ`成分~値$位置に［
`percentage$t, `次元$
］が在って，前者が後者と同じ数量を表現できる事例では
（したがって， `calc$f 式の中でそれらを組合できる）、
次に挙げる簡便な記法を利用できる：
◎
In cases where a &lt;percentage&gt; can represent the same quantity as a dimension in the same component value position, and can therefore be combined with them in a calc() expression, the following convenience notations may be used in the property grammar:
</p>

<dl>
	<dt>`length-percentage@t</dt>
	<dd>
<span class="prod">[ `length$t | `percentage$t ]</span>
と等価
— この `percentage$t は `length$t に解決される。
◎
Equivalent to [ &lt;length&gt; | &lt;percentage&gt; ], where the &lt;percentage&gt; will resolve to a &lt;length&gt;.
</dd>

	<dt>`frequency-percentage@t</dt>
	<dd>
<span class="prod">[ `frequency$t | `percentage$t ]</span>
と等価
— この `percentage$t は `frequency$t に解決される。
◎
Equivalent to [ &lt;frequency&gt; | &lt;percentage&gt; ], where the &lt;percentage&gt; will resolve to a &lt;frequency&gt;.
</dd>

	<dt>`angle-percentage@t</dt>
	<dd>
<span class="prod">[ `angle$t | `percentage$t ]</span>
と等価
— この `percentage$t は `angle$t に解決される。
◎
Equivalent to [ &lt;angle&gt; | &lt;percentage&gt; ], where the &lt;percentage&gt; will resolve to an &lt;angle&gt;.
</dd>

	<dt>`time-percentage@t</dt>
	<dd>
<span class="prod">[ `time$t | `percentage$t ]</span>
と等価
— この `percentage$t は `time$t に解決される。
◎
Equivalent to [ &lt;time&gt; | &lt;percentage&gt; ], where the &lt;percentage&gt; will resolve to a &lt;time&gt;.
</dd>
</dl>

<div class="example">
<p>
例えば， `width$p ~propは、［
`length$t, `percentage$t
］を受容でき，どちらも距離の測度を表現する。
これは、
`width:calc(500px + 50%)^p が許容されることを意味する
— 2 つの値は、
百分率を絶対~長さに換算してから加算されることになる。
包含塊が `1000px^v 幅ならば、
`width^p に対する `50%^v は `500px^v と等価になり，
`width^p に対する `calc(50% + 500px)^v は `calc(500px + 500px)^v すなわち `1000px^v と等価になる。
◎
For example, the width property can accept a &lt;length&gt; or a &lt;percentage&gt;, both representing a measure of distance. This means that width: calc(500px + 50%); is allowed—both values are converted to absolute lengths and added. If the containing block is 1000px wide, then width: 50%; is equivalent to width: 500px, and width: calc(50% + 500px) thus ends up equivalent to width: calc(500px + 500px) or width: 1000px.
</p>

<p>
一方，
`hsl$f 関数の 2 個目, 3 個目の引数を表出できるのは、
`percentage$t しかない†。
`calc$f 生成規則は，その場所にも許容されるが、
その引数の中で組合できるのは百分率どうしに限られる
— `calc(10% + 20%)^v のように。
◎
On the other hand, the second and third arguments of the hsl() function can only be expressed as &lt;percentage&gt;s. Although calc() productions are allowed in their place, they can only combine percentages with themselves, as in calc(10% + 20%).
</p>

<p class="trans-note">【†
`現代の色~構文$では、
`number^t もアリにされた
— それでも、
`percentage^t と `number^t は組合できないと下に注記されているが。
】</p>
</div>

<p class="note">注記：
各~仕様は、
文法~内の`次元$を決して `percentage$t で代替するベキではない
— それらが`互換$でない限り。
◎
Note: Specifications should never alternate &lt;percentage&gt; in place of a dimension in a grammar unless they are compatible.
</p>

<p class="note">注記：
将来においては、
必要に応じて，他のある次元 `TYPE^t 用の `TYPE-percentage^t 生成規則も追加され得る。
`number-percentage^t が追加されることは決してない
— `calc$f 内では `number$t と `percentage$t は組合できないので。
◎
Note: More &lt;type-percentage&gt; productions can be added in the future as needed. A &lt;number-percentage&gt; will never be added, as &lt;number&gt; and &lt;percentage&gt; can’t be combined in calc().
</p>

			<section id="combine-mixed">
<h4 title="Computation and Combination of Percentage and Dimension Mixes">5.6.1. 混在な百分率と次元の算出と結合n</h4>

<p>
百分率と次元が混在な値の`算出d値$は、
次で定義される：
◎
The computed value of a percentage-dimension mix is defined as
</p>
<ul>
	<li>
百分率~成分 ~EQ 0 の場合
⇒
算出された次元
◎
a computed dimension if the percentage component is zero＼
</li>
	<li>
百分率~成分は次元~値に算出するよう，特定的に定義されている場合
⇒
算出された次元
◎
or is defined specifically to compute to a dimension value
</li>
	<li>
【他の場合，】次元~成分 ~EQ 0 の場合
⇒
算出された百分率
◎
a computed percentage if the dimension component is zero
</li>
	<li>
他の場合
⇒
`calc^f 式の`算出d値＠#calc-computed-value$
◎
a computed calc() expression otherwise
</li>
</ul>

<p>
百分率~値と次元~値の組合n
（例：
`length-percentage$t,
`frequency-percentage$t,
`angle-percentage$t,
`time-percentage$t,
その他の等価な記法）
の`補間$は、
次に従うものと定義される：
◎
Interpolation of percentage-dimension value combinations (e.g. &lt;length-percentage&gt;, &lt;frequency-percentage&gt;, &lt;angle-percentage&gt;, &lt;time-percentage&gt; or equivalent notations) is defined as
</p>

<ul class="switch">
	<li>
値A, 値B どちらも純粋な `length^t 値の場合
⇒
`length$t の`補間$と等価。
◎
equivalent to interpolation of &lt;length&gt; if both VA and VB are pure &lt;length&gt; values
</li>
	<li>
値A, 値B どちらも純粋な `percentage^t 値の場合
⇒
`percentage$t の`補間$と等価
◎
equivalent to interpolation of &lt;percentage&gt; if both VA and VB are pure &lt;percentage&gt; values
</li>
	<li>
他の場合の %結果値 は、
次で定義される
⇒
値A, 値B どちらも［
当の次元~型, 百分率
］（いずれも，場合によっては 0 ）の総和を表現している `calc$f 式に変換してから，
互いの次元~成分を［
`length$t ／ `frequency$t ／ `angle$t ／ `time$t
］として, および
互いの百分率~成分を `percentage$t として`補間-$した結果
◎
equivalent to converting both values into a calc() expression representing the sum of the dimension type and a percentage (each possibly zero) and interpolating each component individually (as a &lt;length&gt;/&lt;frequency&gt;/&lt;angle&gt;/&lt;time&gt; and as a &lt;percentage&gt;, respectively)
</li>
</ul>

<p>
百分率~値と次元~値の組合nの`加算$は、
各~成分を`補間-$する代わりに`加算-$することを除いて`補間$と同じとする。
◎
Addition of &lt;percentage&gt; is defined the same as interpolation except by adding each component rather than interpolating it.
</p>
			</section>
		</section>
		<section id="ratios">
<h3 title="Ratios: the &lt;ratio&gt; type">5.7. 比率： `ratio^t 型</h3>

<p>
比率~値は、
`ratio@t
で表記され，
2 個の数量-値の比率を表現する。
それは、
横幅（ 1 個目 ）と縦幅（ 2 個目 ）の縦横比を表現することが最も多い。
◎
Ratio values are denoted by &lt;ratio&gt;, and represent the ratio of two numeric values. It most often represents an aspect ratio, relating a width (first) to a height (second).
</p>

<p>
~literalに記される
`比率@
の構文は：
◎
When written literally, a ratio has the syntax:
</p>

<pre class="prod">
`ratio$t
	= `number [0,∞]$t [ / `number [0,∞]$t ]?
</pre>

<p>
2 個目の `number$t は，省略可能であり、
既定は `1^v になるとする。
しかしながら、
`ratio$t は常に，両~成分とも直列化される。
◎
The second &lt;number&gt; is optional, defaulting to 1. However, &lt;ratio&gt; is always serialized with both components.
</p>

<p>
`ratio$t の算出d値は、
供された 2 個の実数が成す~pairになる。
◎
The computed value of a &lt;ratio&gt; is the pair of numbers provided.
</p>

<p>
`ratio$t は、
~pairを成す どちらかの実数が［
0 または無限大【！無限】
］ならば，
`退化な比率@
を表現する（一般に，それに対し何も行えなくなる）。
◎
If either number in the &lt;ratio&gt; is 0 or infinite, it represents a degenerate ratio (and, generally, won’t do anything).
</p>

<p>
`ratio$t どうしを比較する必要がある場合、［
各 `ratio$t に対し，~pairを成す 1 個目の実数を 2 個目の実数で除算した結果
］を比較する。
例えば， `3/2^v は `2/1^v より小さい
— 前者は 1.5 に解決される一方，後者は 2 に解決されるので
（言い換えれば、
“縦長” な縦横比は “横長” な縦横比より小さい）。
◎
If two &lt;ratio&gt;s need to be compared, divide the first number by the second, and compare the results. For example, 3/2 is less than 2/1, because it resolves to 1.5 while the second resolves to 2. (In other words, “tall” aspect ratios are less than “wide” aspect ratios.)
</p>

			<section id="combine-ratio">
<h4 title="Combination of &lt;ratio&gt;">5.7.1. `ratio$t の結合n</h4>

<p>
`ratio$t の補間は、
次により定義される：
◎
The interpolation of a &lt;ratio&gt; is defined by＼
</p>
<ol>
	<li>
各 `ratio^t に対し
⇒
1 個目の値を 2 個目の値で除算して実数に変換してから（比率 `3 / 2^v は 1.5 になる），対数をとる（なので 1.5 は約 0.176 になる）
◎
converting each &lt;ratio&gt; to a number by dividing the first value by the second (so a ratio of 3 / 2 would become 1.5), taking the logarithm of that result (so the 1.5 would become approximately 0.176),＼
</li>
	<li>
前~段で得られた 2 個の対数を補間してから、
その結果を前~段の逆~変換により `ratio^t に戻す。
◎
then interpolating those values.＼
The result during the interpolation is converted back to a &lt;ratio&gt; by inverting the logarithm, then interpreting the result as a &lt;ratio&gt; with the result as the first value and 1 as the second value.
</li>
</ol>

<p>
どちらかの `ratio$t が`退化な比率$である場合、
それらは補間し得ない。
◎
If either &lt;ratio&gt; is degenerate, the values cannot be interpolated.
</p>

<div class="example">
<p>
例えば，［
`5/1^v から `3/2^v まで
］の中間点において【！linear】補間した結果の比率は、
約 `2.73 / 1^v になる
（およそ 11 ~DIV 4 【！slightly taller than a 3 / 1 ratio】）。
◎
For example, halfway through a linear interpolation from 5 / 1 to 3 / 2, the result is approximately the ratio 2.73 / 1 (roughly 11 / 4, slightly taller than a 3 / 1 ratio):
</p>

<pre class="lang-js">
%start  = log(5);   // ≈ 0.69897
%end    = log(1.5); // ≈ 0.17609
%interp = 0.69897*.5 + 0.17609*.5; // ≈ 0.43753
%final  = 10^%interp; // ≈ 2.73
</pre>
</div>

<p class="note">注記：
比率の対数に対し補間することで、
結果は縮尺に依存しなくなる
（上の例を［
`5 / 1^v から `300 / 200^v まで
］にしても，同じ結果を与える）。
また、
比率を成す 2 値の順序に関して対称的になる
（［
`1 / 5^v から `2 / 3^v まで
］を補間した場合、
中間点における比率は約 `1 / 2.73^v になる）
— 比率が縦横比を表すなら、［
横幅が固定的で縦幅がそれに対する比率に基づくか, その逆か
］に関して対称的になる。
これらの特質は、
他の多くのアリな補間~策とは異なる。
◎
Note: Interpolating over the logarithm of the ratio means the results are scale-independent (5 / 1 to 300 / 200 would give the same results as above), that they’re symmetrical over "wide" and "tall" variants (interpolating from 1 / 5 to 2 / 3 would give a ratio approximately equal to 1 / 2.73 at the halfway point), and that they’re symmetrical over whether the width is fixed and the height is based on the ratio or vice versa. These properties are not shared by many other possible interpolation strategies.
</p>

<p class="note">注記：
対数の特質に因り、
対数の底eには何を利用してもかまわない。
上の例では，底eに 10 を利用しているが、
自然~対数（底eは `e$v ）でも
— 中間-結果は異なるが —
最終-結果は同じになる。
◎
Note: Due to the properties of logarithms, any log can be used; the example here uses base-10 log, but if, say, the natural log and e was used, the intermediate results would be different but the final result would be the same.
</p>

<p>
`ratio$t の加算はアリでない。
◎
Addition of &lt;ratio&gt;s is not possible.
</p>

			</section>
		</section>
	</section>
	<section id="lengths">
<h2 title="Distance Units: the &lt;length&gt; type">6. 距離の単位： `length^t 型</h2>

<p>
長さは距離の測定を基準にし，~prop定義においては
`length@t
で表記される。
長さは 何らかの`次元$による量である。
◎
Lengths refer to distance measurements and are denoted by &lt;length&gt; in the property definitions. A length is a dimension.
</p>

<p>
長さが 0 のときは、
単位~識別子を省略できる（すなわち，構文上は
`number$t の `0^v として表現できる）。
ただし， `0^v は、
~propにおいて
`number$t, `length$t
のどちらにも構文解析できる場合（ `line-height$p など）には，
`number$t として構文解析するモノトスル。
◎
For zero lengths the unit identifier is optional (i.e. can be syntactically represented as the &lt;number&gt; 0). However, if a 0 could be parsed as either a &lt;number&gt; or a &lt;length&gt; in a property (such as line-height), it must parse as a &lt;number&gt;.
</p>

<p>
~propには、
長さを一定~範囲に制約するものもある。
許容d範囲~外の値を伴う宣言は無効であり，`無視する$モノトスル。
◎
Properties may restrict the length value to some range. If the value is outside the allowed range, the declaration is invalid and must be ignored.
</p>

<p class="trans-note">【
無効にさせたくない場合、
`~math関数$で包装する方法がある。
】</p>

<p>
一部の~propには，長さとして負な値も許容されるが、
これは整形-法を複雑化する可能性があり，実装に特有な制限sがあり得る。
実装は、
負な長さを~supportしないときは，
~support可能な最も近い値に変換するモノトスル。
◎
While some properties allow negative length values, this may complicate the formatting and there may be implementation-specific limits. If a negative length value is allowed but cannot be supported, it must be converted to the nearest value that can be supported.
</p>

<p>
~UAは、
長さを`使用~値$として~supportできない所では，
`実際の値$において それを近似するモノトスル。
◎
In cases where the used length cannot be supported, user agents must approximate it in the actual value.
</p>

<p>
長さの単位は、［
`相対~長さ単位$, `絶対~長さ単位$
］の 2 種に分類される。
◎
There are two types of length units: relative and absolute.＼
</p>

<p>
`指定d長さ@
（指定された長さ）
— 長さの`指定d値$ —
は、
その［
数量, 単位
］により表現される。
◎
The specified value of a length (specified length) is represented by its quantity and its unit.＼
</p>

<p>
`算出d長さ@
（算出された長さ）
— 長さの`算出d値$ —
は、
`指定d長さ$を絶対~長さに解決した結果になり，
その単位は判別されない
— それは、
どの`絶対~長さ単位$でも表現され得る
（が、
直列化されるときは，`正準-単位$ `px$u が利用されることになる）。
◎
The computed value of a length (computed length) is the specified length resolved to an absolute length, and its unit is not distinguished: it can be represented by any absolute length unit (but will be serialized using its canonical unit, px).
</p>

<p>
［
数量-値に対し~supportされる正確な精度
］および［
数量-値が，その精度に合致するよう どう丸められるか
］は、
一般に，`実装定義$であるが、
`border-width$p その他の少数の~propにおける `length$t は、
適度な視覚的~表示を確保するため，次の~algoにより丸められる
（この~algoは、
該当する個々の~propにより明示的に~callされる）。
◎
While the exact supported precision of numeric values, and how they are rounded to match that precision, is generally implementation-defined, &lt;length&gt;s in border-width and a few other properties are rounded in a specific fashion to ensure reasonable visual display. (This algorithm is called by individual properties explicitly.)
</p>

<div class="algo">
<p>
`長さを機器~画素の整数倍に留める@
~algoは、
所与の
( `length$t %長さ )
に対し：
◎
To snap a length as a border width given a &lt;length&gt; len:
</p>
<ol>
	<li>
~Assert：
%長さ ~GTE 0
◎
Assert: len is non-negative.
</li>
	<li>
%U ~LET 1 `機器~画素$の長さ
◎
↓</li>
	<li>
~IF［
0 ~LT %長さ ~LT %U
］
⇒
~RET %U
◎
↓If len is an integer number of device pixels, do nothing.
◎
If len is greater than zero, but less than 1 device pixel, round len up to 1 device pixel.
</li>
	<li>
~RET 次を満たす最大な値
⇒
［
%U の整数倍である
］~AND［
%長さ 以下である
］
◎
If len is greater than 1 device pixel, round it down to the nearest integer number of device pixels.
</li>
</ol>
</div>

		<section id="relative-lengths">
<h3 title="Relative Lengths">6.1. 相対~単位</h3>

<p>
`相対~長さ単位@
は、
別の長さに相対的な長さを指定する。
相対~単位を利用すれば、
~stylesheetをある出力~環境から別の環境に見合った縮尺に転用するのも容易になる。
◎
Relative length units specify a length relative to another length. Style sheets that use relative units can more easily scale from one output environment to another.
</p>

<p>
以下に挙げるものが相対~単位である：
◎
The relative units are:
</p>

<table class="data">
<caption>
相対~単位の要約（規範的でない）
【網羅的ではない】
◎
Informative Summary of Relative Units
</caption>
<thead>
<tr><th title="unit">単位
<th title="relative to">相対基準
<tbody>

<tr><td>`em$u
<td>
要素の~font~size
◎
font size of the element

<tr><td>`ex$u
<td>
要素の~fontの`~x-高さ^i
◎
x-height of the element’s font

<tr><td>`cap$u
<td>
要素の~fontの~cap-高さ（大字の名目上の高さ）
◎
cap height (the nominal height of capital letters) of the element’s font

<tr><td>`ch$u
<td>
要素の~fontにおける `narrow^en ~glyphの代表的な`文字~送幅$
— 文字 “0” （ `0030^U `ZERO^cn ）用の~glyphで表現される。
◎
typical character advance of a narrow glyph in the element’s font, as represented by the “0” (ZERO, U+0030) glyph

<tr><td>`ic$u
<td>
要素の~fontにおける `fullwidth^en ~glyphの代表的な`文字~送幅$
— 文字 “水” （~CJK表語文字, `6C34^U ）用の~glyphで表現される。
◎
typical character advance of a fullwidth glyph in the element’s font, as represented by the “水” (CJK water ideograph, U+6C34) glyph

<tr><td>`rem$u
<td>
`根~要素$の~font~size
◎
font size of the root element

<tr><td>`lh$u
<td>
要素の行l高さ
◎
line height of the element

<tr><td>`rlh$u
<td>
`根~要素$の行l高さ
◎
line height of the root element 

<tr><td>`vw$u
<td>
表示域の横幅の 1%
◎
1% of viewport’s width

<tr><td>`vh$u
<td>
表示域の縦幅の 1%
◎
1% of viewport’s height

<tr><td>`vi$u
<td>
表示域の~size
— `根~要素$の`行内-軸$におけるそれ —
の 1%
◎
vi 	1% of viewport’s size in the root element’s inline axis

<tr><td>`vb$u
<td>
表示域の~size
— `根~要素$の`塊-軸$におけるそれ —
の 1%
◎
vb 	1% of viewport’s size in the root element’s block axis

<tr><td>`vmin$u
<td>
表示域の小さい方の次元の 1%
◎
1% of viewport’s smaller dimension

<tr><td>`vmax$u
<td>
表示域の大きい方の次元の 1%
◎
1% of viewport’s larger dimension
</table>

<p>
~prop値の`継承$において，要素が継承するのは、
親に指定された相対~値ではなく，親の`算出d値$である。
◎
Child elements do not inherit the relative values as specified for their parent; they inherit the computed values.
</p>

			<section id="font-relative-lengths">
<h4 title="Font-relative Lengths: the em, rem, ex, rex, cap, rcap, ch, rch, ic, ric, lh, rlh units">6.1.1.  ~fontに相対的な長さ単位： `em^u, `rem^u, `ex^u, `rex^u, `cap^u, `rcap^u, `ch^u, `rch^u, `ic^u, `ric^u, `lh^u, `rlh^u</h4>

<p>
`~fontに相対的な長さ@
は、［
それが利用される要素／`根~要素$
］の~font計量を基準にする
— ［
前者に該当するものは
`~fontに相対的な長さ（局所的）@
／
後者に該当するもの【 `r*^u 】は
`~fontに相対的な長さ（根）@
］と称される。
◎
The font-relative lengths refer to the font metrics either of the element on which they are used (for the local font-relative lengths) or of the root element (for the root font-relative lengths).
</p>

<figure>
<div class="alt" hidden id="_dgm-Typography_Line_Terms">
<p>
単語 "Sphinx" には各種~font計量が注釈されている：
</p>
<ul>
	<li>
~ascender高さ（ `ascender height^en ）： "h" の~serifの上端
</li>
	<li>
~cap-高さ（ `cap-height^en ）：視覚的に "S" の上端~近く
</li>
	<li>
~x-高さ（ `x-height^en ）：視覚的に "x" の上端~近く
</li>
	<li>
基底線（ `baseline^en ）： "S", "h", "i", "n", "x" の下端を通る
</li>
	<li>
~descender高さ（ `descender height^en ）： "p" の下端
</li>
</ul>
◎
The word 'Sphinx' annotated with various font metrics: ascender height, to the top of the h's serif; cap height, to the visually approximate top of the S; the x height, to the visually approximate top of the x; the baseline, along the bottom of S, h, i, n, and x; and the descender height, to the bottom of the p.
</div>
<figcaption>
共通的な~typographic計量
◎
Common typographic metrics
</figcaption></figure>

<dl>
	<dt>`em@u</dt>
	<dd>
この単位が利用された要素の `font-size$p ~propの算出d値に等しい。
◎
Equal to the computed value of the font-size property of the element on which it is used.
</dd>
	<dd class="trans-note">【
`font-size^p 自身に利用された場合にどうなるかは、
下に述べられる。
以下に挙げる他の単位も同様。
】</dd>

	<dd class="example">
<p>
次の規則：
◎
The rule:
</p>

<pre class="lang-css">
h1 { line-height: 1.2em }
</pre>

<p>
は、
`h1^e 要素の行l高さが，
要素~自身の~font~sizeより 2 割大きくなることを意味する。
一方で：
◎
means that the line height of h1 elements will be 20% greater than the font size of h1 element. On the other hand:
</p>

<pre class="lang-css">
h1 { font-size: 1.2em }
</pre>

<p>
は、
`h1^e 要素の~font~sizeが，
`h1^e 要素に継承された~font~sizeの算出d値より 2 割大きくなることを意味する。
◎
means that the font size of h1 elements will be 20% greater than the computed font size inherited by h1 elements.
</p>
	</dd>

	<dt>`rem@u</dt>
	<dd>
`根~要素$の `em$u 単位の算出d値に等しい。
◎
Equal to the computed value of the em unit on the root element.
</dd>

	<dt>`ex@u</dt>
	<dd>
`可用な最初の~font$ `CSS3-FONTS$r に利用されている~x-高さに等しい。
~x-高さという呼称は，それが小文字 “x” の高さに等しくなることが多いことに由来するが、
文字 “x” を包含しない~fontにも， `ex$u は定義される。
◎
Equal to the used x-height of the first available font [CSS3-FONTS].＼
The x-height is so called because it is often equal to the height of the lowercase "x". However, an ex is defined even for fonts that do not contain an "x".＼
</dd>
	<dd>
~fontの~x-高さを見出す仕方は、
いくつかある。
~fontには、
~x-高さ用の依拠できる計量が可用なものもある。
可用でない場合、
~UAは小文字~glyphの高さから~x-高さを決定してもヨイ。
アリな経験則として、
小文字 "o" 用の~glyphの下端が基底線の下に突き出ている距離を調べて，
その値をその限界~boxの上端から減算して得る方法がある。
◎
The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box.＼
</dd>
	<dd>
~x-高さを決定するのは不可能, または実用的でない場合、
その値は `0.5em^v と見做すモノトスル。
◎
In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.
</dd>

	<dt>`rex@u</dt>
	<dd>
`根~要素$の `ex$u 単位の値に等しい。
◎
Equal to the value of the ex unit on the root element.
</dd>

	<dt>`cap@u</dt>
	<dd>
`可用な最初の~font$ `CSS3-FONTS$r に利用されている~cap-高さに等しい。
~cap-高さという呼称は，
~Latin大字（ `capital letter^en ）の高さに近似的に等しいことに由来するが、
~Latin大字を包含しない~fontにも， `cap$u は定義される。
◎
Equal to the used cap-height of the first available font [CSS3-FONTS].＼
The cap-height is so called because it is approximately equal to the height of a capital Latin letter. However, a cap is defined even for fonts that do not contain Latin letters.＼
</dd>
	<dd>
~fontの~cap-高さを見出す仕方は、
いくつかある。
~fontには、
~cap-高さ用の依拠できる計量が可用なものもある。
可用でない場合、
~UAは大文字~glyphの高さから~cap-高さを決定してもヨイ。
アリな経験則として、
大文字 "O" 用の~glyphの下端が基底線の下に突き出ている距離を調べて，
その値をその限界~boxの上端から減算して得る方法がある。
◎
The cap-height of a font can be found in different ways. Some fonts contain reliable metrics for the cap-height. If reliable font metrics are not available, UAs may determine the cap-height from the height of an uppercase glyph. One possible heuristic is to look at how far the glyph for the uppercase “O” extends below the baseline, and subtract that value from the top of its bounding box.＼
</dd>
	<dd>
~cap-高さを決定するのは不可能, または実用的でない場合、
~fontの~ascentを利用するモノトスル。
◎
In the cases where it is impossible or impractical to determine the cap-height, the font’s ascent must be used.
</dd>

	<dt>`rcap@u</dt>
	<dd>
`根~要素$の `cap$u 単位の値に等しい。
◎
Equal to the value of the cap unit on the root element.
</dd>

	<dt>`ch@u</dt>
	<dd>
欧州の英数字の代表的な`送幅$を表現する
— 描画-時に利用される~fontの文字 "0" （ `0030^U `ZERO^cn ）用の~glyphに利用される`送幅$として測定される。
（
`送幅@
とは、
要素の行内-軸における~glyphの送幅（ `advance measure^en ）†である。）
◎
Represents the typical advance measure of European alphanumeric characters, and measured as the used advance measure of the “0” (ZERO, U+0030) glyph in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)
</dd>
	<dd class="trans-note">【†
当の~glyph（この場合は "0" ）の始端から次の~glyph（同じ行lに描画されたとする）の始端までの距離。
】</dd>
	<dd class="note">注記：
この測定は，単独の `narrow^en ~glyphの`送幅$の近似であり
（等幅~fontでは，正確な測度になる）、
期待される~glyph個数に基づく測定を可能にする。
◎
Note: This measurement is an approximation (and in monospace fonts, an exact measure) of a single narrow glyph’s advance measure, thus allowing measurements based on an expected glyph count.
</dd>
	<dd class="note">注記：
~glyphの送幅は、
~font設定群のみならず，
`writing-mode$p, `text-orientation$p, 他，~glyphの［
選定／方位
］に影響する他の~propにも依存する。
◎
Note: The advance measure of a glyph depends on writing-mode and text-orientation as well as font settings, text-transform, and any other properties that affect glyph selection or orientation.
</dd>
	<dd>
“0” ~glyphの測度は不可能, または実用的でない場合、［
~~高さ `1em^v, 幅 `0.5em^v
］と見做すモノトスル。
したがって `ch$u 単位は、［
一般~事例では `0.5em^v ／
正立に植字されるとき
（すなわち、
`writing-mode$p は［
`vertical-rl$v ／ `vertical-lr$v
］,
`text-orientation$p は `upright$v
のとき）
は `1em^v
］に~fall-backする。
◎
In the cases where it is impossible or impractical to determine the measure of the “0” glyph, it must be assumed to be 0.5em wide by 1em tall. Thus, the ch unit falls back to 0.5em in the general case, and to 1em when it would be typeset upright (i.e. writing-mode is vertical-rl or vertical-lr and text-orientation is upright).
</dd>

	<dt>`rch@u</dt>
	<dd>
`根~要素$の `ch$u 単位の値に等しい。
◎
Equal to the value of the ch unit on the root element.
</dd>

	<dt>`ic@u</dt>
	<dd>
~CJK用の字lの代表的な`送幅$を表現する
— 描画-時に利用される~fontの文字 “水” （~CJK表語文字, `6C34^U ）用の~glyphに利用される`送幅$として測定される。
◎
Represents the typical advance measure of CJK letters, and measured as the used advance measure of the “水” (CJK water ideograph, U+6C34) glyph found in the font used to render it.
</dd>
	<dd class="note">注記：
この測定は，概して正確な測度であり
（ `fullwidth^en ~glyphが均衡幅であるような少数の~fontでは，近似になる）、
期待される~glyph個数に基づく測定を可能にする。
◎
Note: This measurement is a typically an exact measure (in the few fonts with proportional fullwidth glyphs, an approximation) of a single fullwidth glyph’s advance measure, thus allowing measurements based on an expected glyph count.
</dd>
	<dd>
表語文字 送幅を決定するのは不可能, または実用的でない場合、
`1em^v と見做すモノトスル。
◎
In the cases where it is impossible or impractical to determine the ideographic advance measure, it must be assumed to be 1em.
</dd>

	<dt>`ric@u</dt>
	<dd>
`根~要素$の `ic$u 単位の値に等しい。
◎
Equal to the value of the ic unit on the root element.
</dd>

	<dt>`lh@u</dt>
	<dd>
この単位が利用された要素の `line-height$p ~propの算出d値に等しい
— ここでは、
値 `normal^v も，`可用な最初の~font$の計量を利用して絶対~長さに変換する。
◎
Equal to the computed value of the line-height property of the element on which it is used, converting normal to an absolute length by using only the metrics of the first available font. 
</dd>

	<dt>`rlh@u</dt>
	<dd>
`根~要素$の `lh$u 単位の値に等しい。
◎
Equal to the value of the lh unit on the root element.
</dd>
	<dd class="note">注記：
要素の `height$p を［
`lh$u ／ `rlh$u
］単位を利用して設定しても，要素~内の実際の行l数~制御が可能化されるわけではない。
これらの単位が可能化するのは、［
理想的な空~行lの理論的な~size
］に基づく長さ計算に限られる
— 一連の行l~boxの実際の~size【`塊~size$】は、
内容に応じて相違し得る。
作者は、
要素~内の実際の行l数を制限するよう求まれる事例では，
代わりに `max-lines$p ~propを利用できる。
◎
Note: Setting the height of an element using either the lh or the rlh units does not enable authors to control the actual number of lines in that element. These units only enable length calculations based on the theoretical size of an ideal empty line; the size of actual lines boxes may differ based on their content. In cases where an author wants to limit the number of actual lines in an element, the max-lines property can be used instead.
</dd>
</dl>

<p>
`~fontに相対的な長さ$が，要素の `font-*^p ~propの値に利用されたときは、
要素に親が［
在るならば 親に算出される計量／
無いならば［
`font^p, `line-height^p
］~propの初期~値に対応して算出される計量
］を~~基準に解決される。
◎
When used in the value of any font-* property on the element they refer to, the font-relative lengths resolve against the computed metrics of the parent element—or against the computed metrics corresponding to the initial values of the font and line-height properties, if the element has no parent.＼
</p>

<p>
類似に，［
`lh$u ／ `rlh$u
］単位が，要素の［
`line-height$p ／ `font-*^p
］~prop（順不同）の値にて利用されたときは、
要素に親が［
在るならば 親に算出される［
`line-height$p, 要素~font計量
］／
無いならば［
`font^p, `line-height^p
］~propの初期~値に対応して算出される計量
］（順不同）を~~基準に解決される。
（他の`~fontに相対的な長さ$が `line-height$p に利用されたときは、
~~通常どおり，要素の自前の計量を~~基準に解決される。）
◎
Similarly, when lh or rlh units are used in the value of the line-height property or font-* properties on the element they refer to, they resolve against the computed line-height and font metrics of the parent element—or the computed metrics corresponding to the initial values of the font and line-height properties, if the element has no parent. (The other font-relative lengths continue to resolve against the element’s own metrics when used in line-height.)
</p>

<p>
`~fontに相対的な長さ$単位が要素の文脈の外側（`媒体~query$など）で利用されたときは、［
`font$p, `line-height$p
］~propの初期~値に対応する計量を基準にする。
◎
When used outside the context of an element (such as in media queries), the font-relative lengths units refer to the metrics corresponding to the initial values of the font and line-height properties.＼
</p>

<p>
類似に，`~fontに相対的な長さ（根）$が`根~要素$を伴わない文書~内に指定されたときは、［
`font$p, `line-height$p
］~propは初期~値をとると見做す下で解決される。
◎
Similarly, when specified in a document with no root element, the root font-relative lengths are resolved assuming the initial values of the font and line-height properties.
</p>

<p class="note">注記：
~fontに相対的な単位
— `ch$u, `ic$u など —
は、
要求される~fontが まだ読込まれてない場合，
~fontの~downloadを誘発し得る。
◎
Note: Font-relative units such as ch and ic can trigger font downloads, if a required font is not yet loaded.
</p>

<p>
`~fontに相対的な長さ$は、
~text形状付けを伴わずに計算される。
【参照：`5498$issue】
◎
The font-relative lengths are calculated in the absence of shaping.
</p>

<p>
一部の~UAは、［
文書~内の~font~sizeに追加的な制約を適用すること
］を利用者に許容する
— 最小~font~sizeを設定して可読性を確保するなど。
そのような制約は、
影響される~propの`使用~値$に限り，適用するモノトスル
— それらの~prop内に利用される`~fontに相対的な長さ$の解決には、
影響しないモノトスル。
しかしながら，そのような制約は、
他の文脈においては（`媒体~query$内など）
— 使用~font計量に影響iする所までに限り —
`~fontに相対的な長さ$の解決に`影響する^em。
◎
Some user-agents allow users to apply additional restrictions to font sizes in a document, such as setting minimum font sizes to ensure readability. Such restrictions must be applied to the used value of the affected properties only; they must not affect the resolution of font-relative lengths used in properties. However, in other contexts (such as in media queries), to the extent that they would impact the used font metrics, such restrictions do affect the resolution of font-relative lengths.
</p>

<p class="note">注記：
一般に，［
最小な~font~sizeの様な，利用者の選好
］は、
尊重されることが望ましい
— `(min-width: 40em)^v の様な媒体~queryには、
文書が表示されることになる実際の~font~sizeを利用するのが有用になる。
しかしながら，これらの選好が［
`ある要素の~prop^emにおいて，~fontに相対的な長さに影響する
］ようになると、
~web互換にならないことが見出されている
— あまりに多くの~pageが，［
これらの単位が
— 利用者-選好を適用した後の`実際の^em ~font~sizeではなく —
指定された `font-size$p の正確な整数倍になる
］ものと期待しているので。
◎
Note: In general, respecting a user’s preferences, like minimum font sizes, is desirable; it’s useful for a media query like (min-width: 40em) to use the actual font size the document will be displayed in. However, having these preferences affect font-relative lengths in properties on an element was found to not be Web-compatible; too many pages expect these units to be exact multiples of the specified font-size, rather than the actual font-size after applying user preferences.
</p>

<p>
一部の~UAは、
~form~controlの `line-height$p 値に対し，制約を適用する。
これらによる［
`lh$u, `rlh$u
］単位に対する効果は無いモノトスル。
しかしながら、
それらの子孫に対する効果は`実装定義$である。
◎
Some user-agents apply restrictions to the line-height values on form controls. These must have no effect on the lh and rlh units. The effect on their descendants, however, is implementation-defined.
</p>

			</section>
			<section id="viewport-relative-lengths">
<h4 title="Viewport-percentage Lengths: the *vw, *vh, *vi, *vb, *vmin, *vmax units">6.1.2. 表示域~百分率による長さ単位： `*vw^u, `*vh^u, `*vi^u, `*vb^u, `*vmin^u, `*vmax^u</h4>

<p>
`表示域~百分率による長さ@
は、
`初期~包含塊$の~sizeに相対的であり，その~size自体も［
（`連続的~媒体$用には）表示域／
（`~paged媒体$用には）`~page区画$
］の~sizeに基づく。
それらの長さは、
初期~包含塊の［
縦幅／横幅
］が変化すれば，それに応じて拡縮される。
◎
The viewport-percentage lengths are relative to the size of the initial containing block—which is itself based on the size of either the viewport (for continuous media) or the page area (for paged media). When the height or width of the initial containing block is changed, they are scaled accordingly.
</p>

				<section id="viewport-variants">
<h5 title="The Large, Small, and Dynamic Viewport Sizes">6.1.2.1. ［大きい／小さい／動的な］表示域~size</h5>

<p>
`表示域~百分率による長さ$の単位には、
4 ~~系統の変種がある
— これらは、［
3 種の（場合によっては一致する）表示域~sizeの観念
］に対応する：
◎
There are four variants of the viewport-percentage length units, corresponding to three (possibly identical) notions of the viewport size.
</p>
<dl>
	<dt>
大きい表示域
（ `large viewport^en ）
◎
large viewport
</dt>
	<dd>
［
`大きい表示域~用の百分率~単位@
（ `lv*^u ）／
`既定の表示域~用の百分率~単位@
（ `v*^u ）
］は、
`大きい表示域~size@
を~~基準に定義される
— 表示域は、［
~UAの~UIのうち動的に［
展開される／収納される
］ものは、
収納されている
］と見做して~sizeされる。
これは、［
表示域を埋め尽くすことが保証されるよう，内容を~sizeする
］ことを作者に許容する。
そのような内容は、
~UIが展開されたとき，~UIの背後に隠されるかもしれないことに注意。
◎
The large viewport-percentage units (lv*) and default viewport-percentage units (v*) are defined with respect to the large viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be retracted. This allows authors to size content such that it is guaranteed to fill the viewport, noting that such content might be hidden behind such interfaces when they are expanded.
</dd>
	<dd>
`大きい表示域~用の百分率~単位$の~sizeは、
表示域~自身が~sizeし直されない限り，固定的（したがって安定的）である。
◎
The sizes of the large viewport-percentage units are fixed (and therefore stable) unless the viewport itself is resized.
</dd>
	<dd class="example">
例えば、
スマホなど，~screenの~~区画が貴重な所では、
~browserは，［
利用者が~pageを~scrollし始めたとき，~titleや~URL~barを一部またはすべて隠す
］ことが多い。
`大きい表示域~用の百分率~単位$は［
そのように何もかも収納された大きい空間
］に相対的に~sizeされるので、
これらの単位を利用している内容は，［
そのような収納-可能な~UI要素が隠されたときは，可視な~page全体を埋め尽くす
］ことになる。
しかしながら，そのような~UI要素が示されたとき、
これらの単位を利用して［
~sizeされた／位置された
］内容は，遮られる。
◎
For example, on phones, where screen real-estate is at a premium, browsers will often hide part or all of the title and address bar once the user starts scrolling the page. The large viewport-percentage units are sized relative to this larger everything-retracted space, so content using these units will fill the entire visible page when these UI elements are hidden. However, when these retractable elements are shown, they can obscure content that is sized or positioned using these units.
</dd>

	<dt>
小さい表示域
（ `small viewport^en ）
◎
small viewport
</dt>
	<dd>
`小さい表示域~用の百分率~単位@
（ `sv*^u ）は、
`小さい表示域~size@
を~~基準に定義される：
表示域は、［
~UAの~UIのうち，動的に［
展開される／収納される
］ものは、
展開されている
］と見做して~sizeされる。
これは、［
そのような~UIが在っても、
内容を表示域の中に収まるよう~sizeする
］ことを作者に許容する
— そのような内容は、
~UIが収納されたとき，表示域を埋め尽くさないかもしれないことに注意。
◎
The small viewport-percentage units (sv*) are defined with respect to the small viewport size: the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be expanded. This allows authors to size content such that it can fit within the viewport even when such interfaces are present, noting that such content might not fill the viewport when such interfaces are retracted.
</dd>
	<dd>
`小さい表示域~用の百分率~単位$の~sizeは、
表示域~自身が~sizeし直されない限り，固定的（したがって安定的）である。
◎
The sizes of the small viewport-percentage units are fixed (and therefore stable) unless the viewport itself is resized.
</dd>
	<dd class="example">
<p>
例えば
`height:100svh$p として~sizeされている要素は、
~UAの動的な~UI要素が すべて示されているときでも、
どの内容も遮ることなく，~screenを埋め尽くすことになる。
◎
An element that is sized as height: 100svh, for example, will fill the screen perfectly, without any of its content being obscured, when all the dynamic UI elements of the UA are shown.
</p>

<p>
しかしながら，それらの~UI要素が隠されたときは、
要素の周りに余分な空間が生じる。
したがって、
`小さい表示域~用の百分率~単位$は，一般に “より安全” であるが、
利用者が~pageとヤリトリし始めたなら，生産される~layoutは見栄えが劣るかもしれない。
◎
Once those UI elements start being hidden, however, there will be extra space around the element. The small viewport-percentage units units are thus “safer” in general, but might not produce the most attractive layout once the user starts interacting with the page.
</p>
	</dd>

	<dt>
動的な表示域
（ `dynamic viewport^en ）
◎
dynamic viewport
</dt>
	<dd>
`動的な表示域~用の百分率~単位@
（ `dv*^u ）は、
`動的な表示域~size@
を~~基準に定義される：
表示域は、［
~UAの~UIのうち，動的に［
展開される／収納される
］もの
］を動的に考慮して~sizeされる。
これは、［
そのような~UIが在るときも無いときも，表示域の中に正確に収まるよう内容を~sizeする
］ことを作者に許容する。
◎
The dynamic viewport-percentage units (dv*) are defined with respect to the dynamic viewport size: the viewport sized with dynamic consideration of any UA interfaces that are dynamically expanded and retracted. This allows authors to size content such that it can exactly fit within the viewport whether or not such interfaces are present.
</dd>
	<dd>
`動的な表示域~用の百分率~単位$の~sizeは、
表示域~自身が変化しなくても`安定的でない^em。
これらの単位を利用すると，内容が
— 例えば，利用者が~pageを~scrollしている間に —
~sizeし直される原因になり得る。
用法にも依存するが、
これは，利用者を妨げたり処理能の~costがかかり得る。
◎
The sizes of the dynamic viewport-percentage units are not stable even while the viewport itself is unchanged. Using these units can cause content to resize e.g. while the user scrolls the page. Depending on usage, this can be disturbing to the user and/or costly in terms of performance.
</dd>
	<dd>
~UAには、
関連な~UIを［
展開して／収納して
］いる間に`動的な表示域~用の百分率~単位$を~animateすることは要求されない
— 代わりに，~UI~animationの間は、
関連な~UIは，全部的に［
展開された, 収納された
］どちらかであったかのように単位を計算してもヨイ。
（~UAには、［
~animation用には，全部的に収納された~sizeと見做す
］ことが推奨される。）
◎
The UA is not required to animate the dynamic viewport-percentage units while expanding and retracting any relevant interfaces, and may instead calculate the units as if the relevant interface was fully expanded or retracted during the UI animation. (It is recommended that UAs assume the fully-retracted size for this duration.)
</dd>
</dl>

<p>
特定0の~UIに対する［
展開／収納
］が次のどちらになるかは、
~UAに大きく依存する：
◎
Whether the expansion/retraction of a particular interface＼
</p>
<ul>
	<li>
(A) すべての`表示域~百分率による長さ$（および`初期~包含塊$）の~sizeを同時に変更する
◎
(A) changes the sizes of all of the viewport-percentage lengths (and the initial containing block) simultaneously or＼
</li>
	<li>
(B) `大きい表示域~size$と`小さい表示域~size$の相違に寄与する
◎
(B) contributes to the differences between the large viewport size and small viewport size is largely UA-dependent.＼
</li>
</ul>

<p>
しかしながら，~UAは、
~UIにおける変化のうち：
◎
However:
</p>
<ul>
	<li>
次に該当するものは、
後者 (B) に分類する`モノトスル^em
⇒
~scrolling~その他の［
頻度が高い，~pageとのヤリトリ
］の結果として起こるものであって、［
その結果が相当な~layout変化をもたらす場合，利用者を妨げる
］ことになるもの
◎
Changes in interface that happen as a result of scrolling or other frequent page interactions that would disturb the user if they resulted in substantial layout changes must be categorized as the latter (B).
</li>
	<li>
次に該当するものは、
前者 (A) に分類する`モノトスル^em
⇒
［
当の文書を調整された空間の中へ~lay-outし直す
］ことが利用者にとって有益になるに足るほど，状態が~~安定している
◎
Changes in interface that have a sufficiently steady state that re-laying out the document into the adjusted space would be beneficial to the user must be categorized as the former (A).
</li>
</ul>

<p>
~UAは、
他にも［
~layoutをズラさないよう意図的に内容の上層に重ねるような，
動的に示される
— したがって`表示域~百分率による長さ$に対する効果は無い —
何らかの~UI
］を備えることもある。
（~screen上の~keyboardは、
概して，これに分類される。）
◎
Additionally, UAs may have some dynamically-shown interfaces that intentionally overlay content and do not cause any shifts in layout—and therefore have no effect on any of the viewport-percentage lengths. (Typically on-screen keyboards will fit into this category.)
</p>

<p>
`根~要素$の［
`overflow$p ／ `scrollbar-gutter$p
］~propが，どちらかの軸において~scrollbarを無条件に現れさせる（あるいは，それ用の空間を予約させる）値をとる場合
（例えば、
`overflow^p が `scroll^v をとる場合は該当するが，
`auto^v をとる場合は該当しない）、
その軸における`表示域~百分率による長さ$の`算出d値$は、
すべての事例で，
`初期~包含塊$に則って抑制される。
他の場合, および`媒体~query$の事例においては常に、
`表示域~百分率による長さ$は，~scrollbarが存在しないものと見做して~sizeされる
（その結果，`初期~包含塊$から分岐する場合でも）。
◎
In all cases, if the value of overflow or scrollbar-gutter on the root element in either axis would cause scrollbars to appear (or space to be reserved for them) unconditionally (for example, overflow: scroll, but not overflow: auto), the computed values of the viewport-percentage lengths in that axis are reduced in accordance with the initial containing block. Otherwise, and always in the case of media queries, the viewport-percentage lengths are sized assuming that scrollbars do not exist (even if this diverges from the initial containing block).
</p>

<p class="note">注記：
`~body要素＠~HTMLdom#the-body-element-2$の `overflow$p の値は、
ときには，`根~要素$の~scrollbarの有無に影響し得るが、
それでも，表示域~単位の~sizeには`影響しない^em。
◎
Note: The value of overflow on the body element can sometimes affect the presence of scrollbars on the root element. This does not affect the size of viewport units, however.
</p>

				</section>
				<section id="viewport-relative-units">
<h5 title="The Various Viewport-relative Units">6.1.2.2. 表示域に相対的な単位</h5>

<p>
`表示域~百分率による長さ$単位は：
◎
The viewport-percentage length units are:
</p>

<dl>
	<dt>`vw@u</dt>
	<dt>`svw@u</dt>
	<dt>`lvw@u</dt>
	<dt>`dvw@u</dt>
	<dd>
順に，［
`大きい表示域~size$,
`小さい表示域~size$,
`大きい表示域~size$,
`動的な表示域~size$
］の横幅の 1% に等しい。
◎
Equal to 1% of the width of the large viewport size, small viewport size, large viewport size, and dynamic viewport size, respectively.
</dd>
	<dd class="example">
<p>
次の例において，表示域の横幅は 200mm ならば、
`h1^e 要素の~font~sizeは 16mm（ 200mm の 8% ）になる。
◎
In the example below, if the width of the viewport is 200mm, the font size of h1 elements will be 16mm (i.e. (8×200mm)/100).
</p>

<pre class="lang-css">
h1 { font-size: 8vw }
</pre>
	</dd>

	<dt>`vh@u</dt>
	<dt>`svh@u</dt>
	<dt>`lvh@u</dt>
	<dt>`dvh@u</dt>
<dd>
順に，［
`大きい表示域~size$,
`小さい表示域~size$,
`大きい表示域~size$,
`動的な表示域~size$
］の縦幅の 1% に等しい。
◎
Equal to 1% of the height of the large viewport size, small viewport size, large viewport size, and dynamic viewport size, respectively.
</dd>

	<dt>`vi@u</dt>
	<dt>`svi@u</dt>
	<dt>`lvi@u</dt>
	<dt>`dvi@u</dt>
	<dd>
順に，［
`大きい表示域~size$,
`小さい表示域~size$,
`大きい表示域~size$,
`動的な表示域~size$
］
— 当の~box【これらの単位を利用している~box】の`行内-軸$におけるそれ —
の 1% に等しい。
◎
Equal to 1% of the size of the large viewport size, small viewport size, large viewport size, and dynamic viewport size (respectively) in the box’s inline axis.
</dd>

	<dt>`vb@u</dt>
	<dt>`svb@u</dt>
	<dt>`lvb@u</dt>
	<dt>`dvb@u</dt>
	<dd>
順に，初期~包含塊†［
`大きい表示域~size$,
`小さい表示域~size$,
`大きい表示域~size$,
`動的な表示域~size$
］
— 当の~box【これらの単位を利用している~box】の`塊-軸$におけるそれ —
の 1% に等しい。
◎
Equal to 1% of the size of the initial containing block large viewport size, small viewport size, large viewport size, and dynamic viewport size (respectively) in the box’s block axis.
</dd>
	<dd class="trans-note">【†
“初期~包含塊” は、
余計な語と思われる
（他の記述と一貫でないことに加え，無かった場合と何が違うのかよくわからない）。
】</dd>

	<dt>`vmin@u</dt>
	<dt>`svmin@u</dt>
	<dt>`lvmin@u</dt>
	<dt>`dvmin@u</dt>
	<dd>
`*vw^u, `*vh^u
のうち小さい方に等しい。
◎
Equal to the smaller of *vw or *vh.
</dd>

	<dt>`vmax@u</dt>
	<dt>`svmax@u</dt>
	<dt>`lvmax@u</dt>
	<dt>`dvmax@u</dt>
	<dd>
`*vw^u, `*vh^u
のうち大きい方に等しい。
◎
Equal to the larger of *vw or *vh.
</dd>
</dl>

<p class="note">注記：
元の（ `s^css ／ `l^css ／ `d^css が接頭されていない）表示域~単位は、
`初期~包含塊$に相対的に`定義されていた＠~TR/css-values-3/#viewport-relative-lengths$
— それは、
`連続的~媒体$においては，常に（一つだけの）表示域~sizeに合致した。
後に、
~scrollしている間に出し入れするような動的性質を成す~browser~UIが考案された
— Safari を皮切りに，ほとんどの~UAは、
これらの単位を大きい方の~sizeへ対応付けた。
この仕方で定義することは，多くの事例で小綺麗になるが、
~criticalな内容を阻むこともある（~toolbar, ~header, ~footerなど）ので，
最善な対応付けかどうか明瞭でない所もある。
したがって、
この仕様の以前の版は，これらの既定の単位の対応付けを選ぶことを~UAに許容した。
しかしながら、
現時点では，［
~Web互換性を得るため、
`大きい表示域~用の百分率~単位$への対応付けが要求される
］ものと予め見做される。
◎
Note: The original (unprefixed) viewport units were defined relative to the initial containing block, which in continuous media always matched the (singular) viewport size. The dynamism of browser chrome shifting in and out during scrolling was invented later, and following Safari’s lead, most UAs mapped these units to the larger size. Defining it this way is prettier in many cases, but can also block critical content (such as toolbars, headers, and footers) in others. It’s therefore not entirely clear whether this was the best mapping, and thus earlier editions of this specifications allowed UAs to choose the mapping of these default units. However at this point the mapping to the large viewport-percentage units is presumed to be required for Web compatibility.
</p>

<p>
要素が無いか, まだ~styleされていない状況（`媒体~query$を評価するときなど）においては、［
`*vi^u ／ `*vb^u
］単位に対応する軸は，
`writing-mode$p ~propの初期~値を利用して決定される。
◎
In situations where there is no element or it hasn’t yet been styled (such as when evaluating media queries), the *vi and *vb units use the initial value of the writing-mode property to determine which axis they correspond to.
</p>

				</section>
			</section>
		</section>
		<section id="absolute-lengths">
<h3 title="Absolute Lengths: the cm, mm, Q, in, pt, pc, px units">6.2. 絶対~単位：`cm^u, `mm^u, `Q^u, `in^u, `pt^u, `pc^u, `px^u</h3>

<p>
各種
`絶対~長さ単位@
は、
互いが固定的な関係にある単位であり，
何らかの物理-測定に~anchorされる【~~基準にする】。
これは主に、
出力~環境が既知である場合に有用になる。
絶対~単位には
`物理-単位@
（ `in$u, `cm$u, `mm$u, `pt$u, `pc$u, `Q$u ）と
`視野角~単位@
（
<dfn>~pixel単位</dfn>
）（ `px$u ） —
がある：
◎
The absolute length units are fixed in relation to each other and anchored to some physical measurement. They are mainly useful when the output environment is known. The absolute units consist of the physical units (in, cm, mm, pt, pc, Q) and the visual angle unit (pixel unit) (px):
</p>

<div>
<table><thead>
<tr><th>単位
<th>名前
<th>他の単位との関係
<tbody>

<tr><td>`cm@u
<td>~centi~meter（ `centimeter^en ）
<td>1 `cm^u = ( 96 ÷ 2.54 ) `px^u

<tr><td>`mm@u
<td>~milli~meter（ `millimeter^en ）
<td>1 `mm^u = ( 1 ÷ 10 ) `cm^u

<tr><td>`Q@u
<td>四分~milli~meter（ `quarter-millimeter^en ）
<td>1 `Q^u = ( 1 ÷ 40 ) `cm^u

<tr><td>`in@u
<td>~inch（ `inch^en ）
<td>1 `in^u = 2.54 `cm^u = 96 `px^u

<tr><td>`pc@u
<td>~pica（ `pica^en ）
<td>1 `pc^u = ( 1 ÷ 6 ) `in^u = 12 `pt^u †

<tr><td>`pt@u
<td>~point（ `point^en ）
<td>1 `pt^u = ( 1 ÷ 72 ) `in^u

<tr><td>`px@u
<td>~pixel（ `pixel^en, “~~画素” ）
<td>1 `px^u = ( 1 ÷ 96 ) `in^u
</table>
◎
unit 	name 	equivalence
cm 	centimeters 	1cm = 96px/2.54
mm 	millimeters 	1mm = 1/10th of 1cm
Q 	quarter-millimeters 	1Q = 1/40th of 1cm
in 	inches 	1in = 2.54cm = 96px
pc 	picas 	1pc = 1/6th of 1in
pt 	points 	1pt = 1/72nd of 1in
px 	pixels 	1px = 1/96th of 1in
</div>

<p class="trans-note">【
`Q^u に限って大文字になっている理由は不明。
（文字大小無視なので、
`q^u と書いても妥当になるが。）
】</p>

<div class="example">
<pre class="lang-css">
h1 { margin: 0.5in }      /* <span class="comment" title="inches">~inch</span> */
h2 { line-height: 3cm }   /* <span class="comment" title="centimeters">~centi~meter</span> */
h3 { word-spacing: 4mm }  /* <span class="comment" title="millimeters">~milli~meter</span> */
h3 { letter-spacing: 1Q } /* <span class="comment" title="quarter-millimeters">四分~milli~meter</span> */
h4 { font-size: 12pt }    /* <span class="comment" title="points">~point</span> */
h4 { font-size: 1pc }     /* <span class="comment" title="picas">~pica</span> */
p  { font-size: 12px }    /* <span class="comment" title="px">~pixel</span> */
</pre>
</div>

<p class="note">注記：
出版~文脈における長さは、
`2p3^c の様に書かれることもある
— これは、
長さ
( 2 ~pica ~PLUS 3 ~point )
を指示する。
~CSSにおいては、
これは `calc(2pc + 3pt)^v として書ける
（ `§ 基本的な算術＠#calc-func$を見よ）。
◎
Note: Lengths in publishing contexts are sometimes written like 2p3, indicating a length of 2 picas and 3 points. These can be written in CSS as calc(2pc + 3pt) (see § 10.1 Basic Arithmetic: calc()).
</p>
<p>
すべての絶対~長さ単位どうしは`互換$である
— それらの`正準-単位$は `px$u とする。
◎
All of the absolute length units are compatible, and px is their canonical unit.
</p>

<p>
~CSSに基づいて描画する機器においては、
これらの次元の
`~anchor単位@
は，次のいずれかになる。
◎
For a CSS device, these dimensions are anchored either
</p>
<ul>
	<li>
`物理-単位$
— それを物理-測定に関係付けることにより
◎
by relating the physical units to their physical measurements, or
</li>
	<li>
`~pixel単位$
— それを`基準~pixel$に関係付けることにより
◎
by relating the pixel unit to the reference pixel.
</li>
</ul>

<p>
`~anchor単位$は：
◎
↓
</p>
<ul>
	<li>
［
典型的な視聴距離が想定されている印刷~媒体
］用には、
`物理-単位$（~inch, ~centi~meter, 等々）になるベキである。
◎
For print media at typical viewing distances, the anchor unit should be one of the physical units (inches, centimeters, etc).＼
</li>
	<li>
［
~screen媒体（高-解像度な機器も含む）／
低~解像度な機器／
~~普通でない視聴距離が想定されている機器
］用には、
`~pixel単位$が推奨される。
そのような機器においては、
`~pixel単位$は［
`基準~pixel$に最良に近似するような，`機器~画素$の整数倍
］を基準にすることが推奨される。
◎
For screen media (including high-resolution devices), low-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
</li>
</ul>

<p class="note">注記：
`~anchor単位$が`~pixel単位$である場合、
`物理-単位$は，物理的な測定に合致するとは限らない。
`~anchor単位$が`物理-単位$である場合、
`~pixel単位$は，`機器~画素$の整数倍に対応付けられるとは限らない。
◎
Note: If the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
</p>

<p class="note">注記：
この`~pixel単位$と`物理-単位$の定義は、
過去の CSS1, CSS2 による定義と異なる。
特に，以前の~versionでは、
~pixel単位と物理-単位は固定d比率で~~換算できなかった
— 物理的な単位は，常に その物理的な測定に結付けられていた一方、
~pixel単位は，［
基準~pixelに最も近似する，可変なもの
］とされていた。
（不幸にも，このように変更された~~理由は、
96dpi を前提にしている既存の内容があまりに多いため、
その前提を覆すと，それらの内容も非互換化してしまうからである。）
◎
Note: This definition of the pixel unit and the physical units differs from the earlier editions of CSS1 and CSS2. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This unfortunate change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)
</p>

<p class="note">注記：
単位は`~ASCII大小無視$であり，小文字に直列化される。
例えば `1Q^v は `1q^v に直列化される。
◎
Note: Units are ASCII case-insensitive and serialize as lowercase, for example 1Q serializes as 1q.
</p>

<p>
`基準~pixel@
とは、［
`機器~画素$の密度が 96dpi の機器において、
読み手の腕の長さだけ離れたとき
］の［
1 画素が占める視野角
］である。
名目上の腕の長さ約 71cm の下での視野角は，約 0.0213 度であり、
この腕の長さだけ離れた視点からの `1px^v は，
およそ 0.26mm （ 1÷96 ~inch）に相当する。
◎
The reference pixel is the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).
</p>

<p>
下の画像に、
視点からの距離が基準~pixelの~~実際の大きさに及ぼす効果を示す：
読み取り距離 71cm （ 28 ~inch）のときの基準~pixelは約 0.26mm になり，
3.5m （ 12 ~feet）のときの基準~pixelは約 1.3mm になる。
◎
The image below illustrates the effect of viewing distance on the size of a reference pixel: a reading distance of 71 cm (28 inches) results in a reference pixel of 0.26 mm, while a reading distance of 3.5 m (12 feet) results in a reference pixel of 1.3 mm.
</p>

<figure>
<p class="alt" hidden id="_dgm-pixel1">
この図式は、
~pixelの定義が利用者から表示画面（紙または~screen）までの距離に依存する様子を図画化する。
この画像は、
利用者から同じ方向に位置する 2 枚の平面（一方は距離 71 cm, もう一方は距離 3.5 m ）が重なって見えている様子を示している。
利用者の目の位置からは、
それらの平面に向けて，（前述の視野角により）次第に広がる円錐が投射されている。
円錐が［
前者／後者
］の平面に投射される所の 1 ~pixelの大きさは、［
0.26 mm ／ 1.4 mm
］になる。
◎
This diagram illustrates how the definition of a pixel depends on the users distance from the viewing surface (paper or screen).
The image depicts the user looking at two planes, one 28 inches (71 cm) from the user, the second 140 inches (3.5 m) from the user. An expanding cone is projected from the user's eye onto each plane. Where the cone strikes the first plane, the projected pixel is 0.26 mm high. Where the cone strikes the second plane, the projected pixel is 1.4 mm high.
</p>
<figcaption>
~pixelの大きさは、
視点からの距離に比例することになる。
◎
Showing that pixels must become larger if the viewing distance increases
</figcaption>

</figure>

<p>
次の図に、
機器の解像度が`~pixel単位$に与える効果を示す：
低~解像度の機器（例えば，典型的な~computer画面）では，
`1px^v 平方の区画が 1 個の~dotで覆われるのに対し、
高-解像度の機器（~printerなど）では，同じ区画に 16 ~dot入る。
◎
This second image illustrates the effect of a device’s resolution on the pixel unit: an area of 1px by 1px is covered by a single dot in a low-resolution device (e.g. a typical computer display), while the same area is covered by 16 dots in a higher resolution device (such as a printer).
</p>

<figure>
<p class="alt" hidden id="_dgm-pixel2">
この図式は、
基準~pixelと機器~画素（ “~dot” ）の関係を示す。
図左は 高-解像度（~dotの密度が高い）~laser~printerの出力，
図右は 低-解像度な~monitor~screen。
~laser~printerにおける 1 基準~pixel四方の区画は， 16 ~dotで占められている。
~monitor~screenにおける 1 基準~pixel四方の区画は， 1 ~dotで占められている。
◎
This diagram illustrates the relationship between the reference pixel and device pixels (called “dots” below). The image depicts a high resolution (large dot density) laser printer output on the left and a low resolution monitor screen on the right. For the laser printer, one square reference pixel is implemented by 16 dots. For the monitor screen, one square reference pixel is implemented by a single dot.
</p>

<figcaption>
機器の解像度が高くなるほど，（視覚的に同じ距離の）
`1px^v 平方を覆うのに必要な機器~画素（~dot）数は増える。
◎
Showing that more device pixels (dots) are needed to cover a 1px by 1px area on a high-resolution device than on a lower-resolution one (of the same approximate viewing distance)
</figcaption></figure>

<p>
`機器~画素@
は、［
機器~出力~上で全部的な範囲の色を表示する能力がある最~小な区画
］を成す単位である。
それは、
典型的な色~screen用には，［
~red, ~green, ~blue
］下位-画素を包含している ほぼ正方形な領域である。
伝統的でない出力には、
この定義を ぼやかし得るものも多く存在する
— 一部の色だけ他より高-解像度で表示するなど。
しかしながら，そのような機器でも、
“機器~画素” に等価な何らかの観念を公開する。
◎
A device pixel is the smallest unit of area on the device output capable of displaying its full range of colors. For typical color screens, it’s a square or somewhat rectangular region containing a red, green, and blue subpixel. Many non-traditional outputs exist that can blur this definition, such as by displaying some colors at higher resolutions. Such devices still expose some equivalent notion of "device pixel", however.
</p>

		</section>
	</section>
	<section id="other-units">
<h2 title="Other Quantities">7. その他の数量</h2>

		<section id="angles">
<h3 title="Angle Units: the <angle> type and deg, grad, rad, turn units">7.1. 角度の単位： `angle^t 型と `deg^u, `grad^u, `rad^u, `turn^u 単位</h3>

<p>
角度~値は `dimension$t 型であり、
`angle@t
で表記される。
角度~単位~識別子には次に挙げるものがある：
◎
Angle values are &lt;dimension&gt;s denoted by &lt;angle&gt;. The angle unit identifiers are:
</p>

<dl>
	<dt>`deg@u</dt>
	<dd>
度。
円の全周は 360 度。
◎
Degrees. There are 360 degrees in a full circle.
</dd>

	<dt>`grad@u</dt>
	<dd>
~gradian。
“~gon” あるいは “~grade” としても知られる。
円の全周は 400 gradian 。
◎
Gradians, also known as "gons" or "grades". There are 400 gradians in a full circle.
</dd>

	<dt>`rad@u</dt>
	<dd>
~radian。
円の全周は 2π ~radian。
◎
Radians. There are 2π radians in a full circle.
</dd>

	<dt>`turn@u</dt>
	<dd>
周回数（ `turn^en ）。
円の全周は 1 周回。
◎
Turns. There is 1 turn in a full circle.
</dd>
</dl>

<p>
例えば，直角は［
`90deg^v ／
`100grad^v ／
`0.25turn^v ／
約 `1.57rad^v
］に等しい。
◎
For example, a right angle is 90deg or 100grad or 0.25turn or approximately 1.57rad.
</p>

<p>
すべての `angle$t 単位どうしは`互換$である
— それらの`正準-単位$は `deg$u とする。
◎
All &lt;angle&gt; units are compatible, and deg is their canonical unit.
</p>

<p>
方向を表記する角度は、
概して
`方位角@
として解釈されるのが慣例である
— ここで、
`0deg^v は~screen上の “上方” あるいは “北” を指し，
角度は時計回りに大きくなる
（したがって
`90deg^v は
“右方” あるいは “東”
を指す）。
◎
By convention, when an angle denotes a direction in CSS, it is typically interpreted as a bearing angle, where 0deg is "up" or "north" on the screen, and larger angles are more clockwise (so 90deg is "right" or "east").
</p>

<p>
例えば、［
`linear-gradient$f 関数において~gradientの方向を決定する `angle$t 値
］は，方位角に解釈される。
◎
For example, in the linear-gradient() function, the &lt;angle&gt; that determines the direction of the gradient is interpreted as a bearing angle.
</p>

<p class="note">注記：
旧来の理由から、
`angle$t の一部の利用においては，
`0deg^v を意味する裸の `0^v も許容される。
しかしながら、
これは一般には成立せず，また、
将来における `angle$t 型の利用には生じない。
◎
Note: For legacy reasons, some uses of &lt;angle&gt; allow a bare 0 to mean 0deg. This is not true in general, however, and will not occur in future uses of the &lt;angle&gt; type.
</p>

		</section>
		<section id="time">
<h3 title="Duration Units: the &lt;time&gt; type and s, ms units">7.2. 所要時間の単位： `time^t 型と `s^u, `ms^u 単位</h3>

<p>
時間~値は
`time@t
で表記される`次元$である。
時間の単位~識別子には次に挙げるものがある：
◎
Time values are dimensions denoted by &lt;time&gt;. The time unit identifiers are:
</p>

<dl>
	<dt>`s@u</dt>
	<dd>
秒。
◎
Seconds.
</dd>

	<dt>`ms@u</dt>
	<dd>
~milli秒。
1 秒は 1000 ~milli秒。
◎
Milliseconds. There are 1000 milliseconds in a second.
</dd>
</dl>

<p>
すべての `time$t 単位どうしは`互換$である
— それらの`正準-単位$は `s$u とする。
◎
All &lt;time&gt; units are compatible, and s is their canonical unit.
</p>

<p>
~propには、
時間~値を一定~範囲に制約するものもある。
許容d範囲~外の値を伴う宣言は無効であり，`無視する$モノトスル。
◎
Properties may restrict the time value to some range. If the value is outside the allowed range, the declaration is invalid and must be ignored.
</p>

		</section>
		<section id="frequency">
<h3 title="Frequency Units: the &lt;frequency&gt; type and Hz, kHz units">7.3. 周波数の単位： `frequency^t 型と `Hz^u, `kHz^u 単位</h3>

<p>
周波数~値は
`frequency@t
で表記される`次元$である。
周波数の単位~識別子には次に挙げるものがある：
◎
Frequency values are dimensions denoted by &lt;frequency&gt;. The frequency unit identifiers are:
</p>

<dl>
	<dt>`Hz@u</dt>
	<dd>
~Hertz。
1 秒あたりの周波数を表現する。
◎
Hertz. It represents the number of occurrences per second.
</dd>

	<dt>`kHz@u</dt>
	<dd>
~KiloHertz。
1 ~KiloHertzは 1000 ~Hertz。
◎
KiloHertz. A kiloHertz is 1000 Hertz.
</dd>
</dl>

<p>
例えば 音高を表現する際の，
`200Hz^v（または `200hz^v ）は 低音域にあり, 
`6kHz^v（または `6khz^v ）は高音域にある。
◎
For example, when representing sound pitches, 200Hz (or 200hz) is a bass sound, and 6kHz (or 6khz) is a treble sound.
</p>

<p>
すべての `frequency$t 単位どうしは`互換$である
— それらの`正準-単位$は `Hz$u とする。
◎
All &lt;frequency&gt; units are compatible, and hz is their canonical unit.
</p>

<p class="note">注記：
単位は`~ASCII大小無視$であり，小文字に直列化される。
例えば `1Hz^v は `1hz^v に直列化される。
◎
Note: Units are ASCII case-insensitive and serialize as lowercase, for example 1Hz serializes as 1hz.
</p>

		</section>
		<section id="resolution">
<h3 title="Resolution Units: the &lt;resolution&gt; type and dpi, dpcm, dppx units">7.4. 解像度の単位： `resolution^t 型と `dpi^u, `dpcm^u, `dppx^u 単位</h3>

<p>
解像度の値は
`resolution@t
で表記される`次元$である。
解像度の単位~識別子には次に挙げるものがある：
◎
Resolution units are dimensions denoted by &lt;resolution&gt;. The resolution unit identifiers are:
</p>

<dl>
	<dt>`dpi@u</dt>
	<dd>
~inchあたりの~dot数
◎
Dots per inch.
</dd>

	<dt>`dpcm@u</dt>
	<dd>
~centi~meterあたりの~dot数
◎
Dots per centimeter.
</dd>

	<dt>`dppx@u</dt>
	<dt>`x@u</dt>
	<dd>
`px$u 単位あたりの~dot数
◎
Dots per px unit.
</dd>
</dl>

<p>
`resolution$t 単位は、
1 ~CSS［
`in$u ／ `cm$u ／ `px$u
］の中に収まる~dot数を指示することにより，
1 個の “~dot” の~graphicな表現における~sizeを表現する。
その利用については、
例えば［
`resolution$d 媒体~query `MEDIAQ$r ／
`image-resolution$p ~prop `CSS3-IMAGES$r
］を見よ。
◎
The &lt;resolution&gt; unit represents the size of a single "dot" in a graphical representation by indicating how many of these dots fit in a CSS in, cm, or px. For uses, see e.g. the resolution media query in [MEDIAQ] or the image-resolution property defined in [CSS3-IMAGES].
</p>

<p>
すべての `resolution$t 単位どうしは`互換$である
— それらの`正準-単位$は `dppx$u とする。
◎
All &lt;resolution&gt; units are compatible, and dppx is their canonical unit.
</p>

<p>
`resolution$t 値に許容される範囲からは、
負な値は`常に^emに除外される
— 明示的な範囲も指定され得るが，それに加えて。
◎
The allowed range of &lt;resolution&gt; values always excludes negative values, in addition to any explicit ranges that might be specified.
</p>

<p class="note">注記：
~CSS `in$u から~CSS `px$u への固定d比率 1:96 に因り， 
`1dppx^v は `96dpi^v と等価になる。
これは、
~CSSにて表示される画像の既定の解像度に対応する。
`image-resolution$p ~propを見よ 
◎
Note that due to the 1:96 fixed ratio of CSS in to CSS px, 1dppx is equivalent to 96dpi. This corresponds to the default resolution of images displayed in CSS: see image-resolution. 
</p>

<div class="example">
<p>
次の `media$at 規則は、
`Media Queries^cite `MEDIAQ$r を利用して，［
1 ~CSS `px$u 単位に 2 以上の機器~画素を利用する機器
］に特別な~style規則をアテガう：
◎
The following @media rule uses Media Queries [MEDIAQ] to assign some special style rules to devices that use two or more device pixels per CSS px unit:
</p>

<pre class="lang-css">
@media (min-resolution: 2dppx) { ... }
</pre>
</div>

		</section>
	</section>
	<section id="defined-elsewhere">
<h2 title="Data Types Defined Elsewhere">8. 他所で定義される~data型</h2>

<p>
他の~moduleにおける一部の~data型は、
その~module自身の中で定義されている。
ここでは，多くの仕様に最も共通的に利用されている例を挙げる。
◎
Some data types are defined in their own modules. This example talks about some of the most common ones used across several specifications.
</p>

		<section id="colors">
<h3 title="Colors: the &lt;color&gt; type">8.1.  色： `color^t 型</h3>

<p>
`color$t ~data型は、
`CSS-COLOR-4$r にて定義される。
~UAは、
そこに定義されるとおりに `color$t を解釈するモノトスル。
◎
The &lt;color&gt; data type is defined in [CSS-COLOR-4]. UAs must interpret &lt;color&gt; as defined therein.
</p>

			<section id="combine-colors">
<h4 title="Combination of &lt;color&gt;">8.1.1. `color^t の結合n</h4>

<p>
`color$t の`補間$は、
`CSS-COLOR-4$r `§ 補間＠~CSSCOLOR#interpolation$
にて定義される。
補間は、
同 `§ ~alphaを伴う色の補間-法＠~CSSCOLOR#interpolation-alpha$
に定義されるとおり，乗算済みな色どうしで行われる。
◎
Interpolation of &lt;color&gt; is defined in CSS Color 4 § 12 Color Interpolation. Interpolation is done between premultiplied colors, as defined in CSS Color 4 § 12.3 Interpolating with Alpha.
</p>

<p>
`color$t 型は、
`加法的でない$。
◎
The &lt;color&gt; type is not additive.
</p>

<p class="note">注記：
~CSS~WGは、
`color$t の加算~用の利用事例について`~~意見を募って＠~CSSissue/new$おり，
将来には `color$t を加法的にすることを考慮し得る。
◎
Note: the CSS WG is interested to hear use-cases for addition of &lt;color&gt;, and may consider making &lt;color&gt; additive in the future.
</p>

			</section>
		</section>
		<section id="images">
<h3 title="Images: the &lt;image&gt; type">8.2. 画像： `image^t 型</h3>

<p>
`image$t ~data型は、
`CSS3-IMAGES$r にて定義される。
CSS Images ~level 3 またはその後継版を~supportする~UAは、
その定義に従って `image$t を解釈するモノトスル。
そうでない~UAは、
`image$t を `url$t として解釈するモノトスル。
◎
The &lt;image&gt; data type is defined in [CSS3-IMAGES]. UAs that support CSS Images Level 3 or its successor must interpret &lt;image&gt; as defined therein. UAs that do not yet support CSS Images Level 3 must interpret &lt;image&gt; as &lt;url&gt;.
</p>

			<section id="combine-images">
<h4 title="Combination of &lt;image&gt;">8.2.1. `image^t の結合n</h4>

<p class="note">注記：
`image$t の補間は
`CSS3-IMAGES$r による
`§ 補間＠~CSSIMAGE#interpolation$
【ではなく，~level 4 の `§ 補間＠~CSSIMAGE4#interpolation$】
にて定義される。
◎
Note: Interpolation of &lt;image&gt; is defined in CSS Images 3 § 6 Interpolation.
</p>

<p>
画像は、
`加法的でない$。
◎
Images are not additive.
</p>

			</section>
		</section>
		<section id="position">
<h3 title="2D Positioning: the &lt;position&gt; type">8.3. 二次元な位置： `position^t 型</h3>

<p>
`position@t
値は、
位置決め区画（例：`背景~位置決め区画$）の内側における
~obj区画（例：背景~画像）の位置を指定する。
それは、
`background-position$p に指定されるとおりに算出され, 解釈される。
`CSS3-BACKGROUND$r
◎
The &lt;position&gt; value specifies the position of a object area (e.g. background image) inside a positioning area (e.g. background positioning area). It is computed and interpreted as specified for background-position. [CSS3-BACKGROUND]
</p>

<pre class="prod">
`position$t
	= [ `left^v | `center^v | `right^v | `top^v | `bottom^v | `length-percentage$t ]
	| [ `left^v | `center^v | `right ] &amp;&amp; [ top^v | `center^v | `bottom^v ]
	| [ `left^v | `center^v | `right^v | `length-percentage$t ]
	  [ `top^v | `center^v | `bottom^v | `length-percentage$t ]
	| [ [ `left^v | `right^v ] `length-percentage$t ] &amp;&amp;
	  [ [ `top^v | `bottom^v ] `length-percentage$t ]
</pre>

<p class="note">注記：
`background-position$p ~propは，成分~値 3 個の構文も受容するが、
汎用~的には許容されない
— ~prop値~内で他の［
長さ／百分率
］成分と組合されたとき，構文解析-時に多義性をもたらすので。
◎
Note: The background-position property also accepts a three-value syntax. This has been disallowed generically because it creates parsing ambiguities when combined with other length or percentage components in a property value.
</p>

			<section id="position-parsing">
<h4 title="Parsing &lt;position&gt;">8.3.1. `position^t の構文解析-法</h4>

<p>
文法~内で他の［
~keyword ／ `length$t ／ `percentage$t
］と並べて指定された `position$t は、
`貪欲に^em構文解析され，アリな限り多くの成分を消費する。
◎
When specified in a grammar alongside other keywords, &lt;length&gt;s, or &lt;percentage&gt;s, &lt;position&gt; is greedily parsed; it consumes as many components as possible.
</p>

<p class="example">
例えば `transform-origin$p は、
（実質的に）
<span class="prod">`position$t `length$t?</span>
として，三次元な位置を定義する。
`left 50px^v などの値は，［
z 成分が省略された，成分~値 2 個からなる `position$t
］として構文解析される一方、
`top 50px^v などの値は，［［
成分~値 1 個からなる `position$t
］, `length$t
］が成す並びとして構文解析されることになる。
◎
For example, transform-origin defines a 3D position as (effectively) &lt;position&gt; &lt;length&gt;?. A value such as left 50px will be parsed as a 2-value &lt;position&gt;, with an omitted z-component; on the other hand, a value such as top 50px will be parsed as a single-value &lt;position&gt; followed by a &lt;length&gt;.
</p>

			</section>
			<section id="position-serialization">
<h4 title="Serializing &lt;position&gt;">8.3.2. `position^t の直列化-法</h4>

<p>
`position$t の`指定d値$を直列化するときは、
指定された成分の個数に応じて：
◎
When serializing the specified value of a &lt;position&gt;:
</p>

<ul class="switch">
	<li>
1 個の成分
⇒
暗黙な~keyword `center＠~CSSBG#valdef-background-position-center$v が追加され，
2 個の成分からなる値として直列化される。
◎
If only one component is specified:
• The implied center keyword is added, and a 2-component value is serialized.
</li>
	<li>
<p>
2 個の成分：
◎
If two components are specified:
</p>
		<ul>
			<li>
各~keywordは、
~keywordとして直列化する。
◎
Keywords are serialized as keywords.
</li>
			<li>
各 `length-percentage$t は、
`length-percentage$t として直列化する。
◎
&lt;length-percentage&gt;s are serialized as &lt;length-percentage&gt;s.
</li>
			<li>
これらは、［
横~成分, 縦~成分
］の順に直列化する。
◎
Components are serialized horizontal first, then vertical.
</li>
		</ul>
	</li>
	<li>
<p>
4 個の成分
◎
If four components are specified:
</p>
		<ul>
			<li>
各［
~keyword, ~offset
］は、
どちらも直列化する。
◎
Keywords and offsets are both serialized.
</li>
			<li>
これらは、［
横~成分, 縦~成分
］の順に直列化する。
◎
Components are serialized horizontal first, then vertical.
</li>
		</ul>
	</li>
</ul>

<p class="note">注記：
`position$t 値が 1 個の成分からなる値として直列化されることは、
決してない
— そのような値が同じ挙動を生産するときでも。
これは、
`position$t が `length$t の隣に配置される一部の文法
— `transform-origin$p など —
において，構文解析の多義性が生じるのを避けるためである。
◎
Note: &lt;position&gt; values are never serialized as a single value, even when a single value would produce the same behavior, to avoid causing parsing ambiguities in some grammars where a &lt;position&gt; is placed next to a &lt;length&gt;, such as transform-origin.
</p>

<p class="note">注記：
`算出d値$は、
常に， 2 個の~offsetとして（~keywordを伴わずに）直列化される
— 算出d値は、
構文上の差異を保全しないので。
◎
Note: Computed values are always serialized as two offsets (without keywords) because the computed value does not preserve syntactic distinctions.
</p>

			</section>
			<section id="combine-positions">
<h4 title="Combination of &lt;position&gt;">8.3.3. `position^t の結合n</h4>

<p>
`position$t の`補間$は、
値を成す［
x, y
］各~成分ごとに独立に，［
左上隅からの~offsetに正規化された `length-percentage$t
］として`補間-$するものとして定義される。
◎
Interpolation of &lt;position&gt; is defined as the independent interpolation of each component (x, y) normalized as an offset from the top left corner as a &lt;length-percentage&gt;.
</p>

<p>
同様に `position$t の`加算$は、
値を成す［
x, y
］各~成分ごとに独立に，［
左上隅からの~offsetに正規化された `length-percentage$t
］として`加算-$するものとして定義される。
◎
Addition of &lt;position&gt; is likewise defined as the independent addition each component (x, y) normalized as an offset from the top left corner as a &lt;length-percentage&gt;.
</p>

			</section>
		</section>
	</section>
	<section id="functional-notations">
<h2 title="Functional Notations">9. 関数-記法</h2>

<p>
`関数-記法@
は、［
より複階的な型を表現する, あるいは特別な処理を呼出せる
］ような，成分~値の型である。
その構文は、［［
関数の名前,
左~丸括弧
］（すなわち `function-token$t ）,
引数たちが成す並び,
右~丸括弧
］が成す並びである。
~keywordと同様に、
関数の名前は`~ASCII大小無視$である。
［
左~丸括弧／右~丸括弧
］と［
引数たちが成す並び
］の合間には`空白$も許容される。
関数は、
~CSS~prop値に似た書式で記される引数を，複数個とり得る。
`§ 2.6 関数-記法の定義＠#component-functions$を見よ。
◎
A functional notation is a type of component value that can represent more complex types or invoke special processing. The syntax starts with the name of the function immediately followed by a left parenthesis (i.e. a &lt;function-token&gt;) followed by the argument(s) to the notation followed by a right parenthesis. Like keywords, function names are ASCII case-insensitive. White space is allowed, but optional, immediately inside the parentheses. Functions can take multiple arguments, which are formatted similarly to a CSS property value. See § 2.6 Functional Notation Definitions.
</p>

<p class="note">注記：
旧来の関数-記法のうち一部のもの
— `rgba$f など —
は，~commaを不必要に利用しているが、
一般には，~commaが利用されるのは［
~list内の~itemを分離するとき／
文法の一片から多義性を排するとき
］に限られる。
引数が~commaを利用して分離される場合、
~commaの前後には省略可能な`空白$も挿入できる。
◎
Note: Some legacy functional notations, such as rgba(), use commas unnecessarily, but generally commas are only used to separate items in a list, or pieces of a grammar that would be ambiguous otherwise. If a comma is used to separate arguments, white space is optional before and after the comma.
</p>

<div class="example">
<pre class="lang-css">
background: url(http://www.example.org/image);
color: rgb(100, 200, 50 );
content: counter(list-item) ". ";
width: calc(50% - 2em);
</pre>
</div>

<p>
`関数-記法$のうち，`~math関数$は以下に定義され、
他のものは，各自の自前の~moduleにて定義される
— 例えば，`色~関数$は、
`CSS-COLOR-4$r, `CSS-COLOR-5$r にて定義される。
◎
The math functions are defined below. Other functional notations are defined in their own modules; for example the &lt;color&gt; functions are defined in [CSS-COLOR-4] and [CSS-COLOR-5].
</p>

	</section>
	<section id="math">
<h2 title="Mathematical Expressions">10. 数学的な式</h2>

<p>
`~math関数@
（ `calc$f, `clamp$f, `sin$f, その他，この節に定義するもの）は、
数量-~CSS値を数学的な式として書けるようにする。
◎
The math functions (calc(), clamp(), sin(), and others defined in this chapter) allow numeric CSS values to be written as mathematical expressions.
</p>

<p>
`~math関数$は、
次に挙げるいずれかの数量-値, または［
`length-percentage$t 等々の複数の型が混在なもの
］を表現し，そのような値が妥当になる所ならどこでも利用できる
⇒＃
`length$t,
`frequency$t,
`angle$t,
`time$t,
`flex$t,
`resolution$t,
`percentage$t,
`number$t,
`integer$t
◎
A math function represents a numeric value, one of:
• &lt;length&gt;,
• &lt;frequency&gt;,
• &lt;angle&gt;,
• &lt;time&gt;,
• &lt;flex&gt;,
• &lt;resolution&gt;,
• &lt;percentage&gt;,
• &lt;number&gt;,
• &lt;integer&gt;
◎
...or the &lt;length-percentage&gt;/etc mixed types, and can be used wherever such a value would be valid.
</p>

<p class="trans-note">【
この節では、
`無限大$（−∞／+∞）に加えて，
`有符号 0$（ ~0N ／ ~0P ）も利用される。
したがって、
0 は ~0N, ~0P の総称を表すことになる
— 特に，［
~0N は負な数とは見なされない（ ~0N ~LT 0 ではない） ／
~0P は正な数とは見なされない（ ~0P ~GT 0 ではない）
］ことに注意。
一方で、
~0N と ~0P を比較するときは， ~0N ~LT ~0P と`見なされる＠#calc-ieee$ことにも注意。
】</p>

		<section id="calc-func">
<h3 title="Basic Arithmetic: calc()">10.1. 基本的な算術： `calc^f</h3>

<p>
`calc@f
関数は、［
加算（ `+^css ）,
減算（ `-^css ）,
乗算（ `*^css ）,
除算（ `/^css ）,
丸括弧
］を利用して［
数量的な値に対し，基本的な算術を遂行する
］ことを許容する`~math関数$である。
◎
The calc() function is a math function that allows basic arithmetic to be performed on numerical values, using addition (+), subtraction (-), multiplication (*), division (/), and parentheses.
</p>

<p>
`calc$f 関数は、
1 個の`計算式$を包含する。
`計算式@
（ `calculation^en ）は、
一連の値
— 合間に各種~演算子が挟まれ，場合によっては丸括弧で~group化されたそれら —
からなる（ `calc-sum$t 文法に合致する）。
それは、［
標準な演算子 優先順位~規則を利用して，式を評価した結果
］を表現する
（各~演算子は、［
`*^css, `/^css
］が［
`+^css, `-^css
］より~~結合度が高いことを除いて，左から右の順に評価される）。
`calc^f 関数は、
それが包含する`計算式$の結果を表現する。
◎
A calc() function contains a single calculation, which is a sequence of values interspersed with operators, and possibly grouped by parentheses (matching the &lt;calc-sum&gt; grammar), which represents the result of evaluating the expression using standard operator precedence rules (* and / bind tighter than + and -, and operators are otherwise evaluated left-to-right). The calc() function represents the result of its contained calculation.
</p>

<p>
`計算式$を成す各 成分は、［
~literal値（ `5px^v など）,
他の`~math関数$,
`var$f などの他の式
］のいずれかであって，
【式を利用している文脈において】妥当な引数~型（ `length$t など）に評価されるものをとれる。
◎
Components of a calculation can be literal values (such as 5px), other math functions, or other expressions, such as var(), that evaluate to a valid argument type (like &lt;length&gt;).
</p>

<div class="example">
<p>
`~math関数$は、［
異なる単位を利用する値たちを組合せる
］ために利用できる。
次の例では、
作者は［
各 `section^e の~margin~boxが空間の 1/3 を占める
］よう求めているので，
`100%/3^v から 要素の［
~borderと~margin
］分を減算する。
（ `box-sizing$p は，［
~borderと~padding
］に対しては この効果を自動的に達成できるが、
~marginを含めたいと求める場合，~math関数が必要になる。）
◎
Math functions can be used to combine value that use different units. In this example the author wants the margin box of each section to take up 1/3 of the space, so they start with 100%/3, then subtract the element’s borders and margins. (box-sizing can automatically achieve this effect for borders and padding, but a math function is needed if you want to include margins.)
</p>

<pre class="lang-css">
section {
  float: left;
  margin: 1em; border: solid 1px;
  width: calc(100% / 3 - 2 * 1em - 2 * 1px);
}
</pre>
</div>

<div class="example">
<p>
同様に，次の例の~gradientは、
要素の最初と最後の `20px^v 内に限り，色の遷移を示すことになる：
◎
Similarly, in this example the gradient will show a color transition only in the first and last 20px of the element:
</p>

<pre class="lang-css">
.fade {
  background-image: linear-gradient(
    silver 0%, white 20px, white calc(100% - 20px), silver 100%
  );
}
</pre>
</div>

<div class="example">
<p>
`~math関数$は、［
より自然かつ読易い~~形で値を表出するため
］だけでも［
ただの 10 進数より真意が見える
］ので有用になり得る。
次の例では、［
`35em^v がちょうど表示域に収まる
］よう `font-size$p を設定して，［
~screenの~sizeを問わず，
常に概ね同じ量の~textが~screenを埋める
］ことを確保している：
◎
Math functions can also be useful just to express values in a more natural, readable fashion, rather than as an obscure decimal. For example, the following sets the font-size so that exactly 35em fits within the viewport, ensuring that roughly the same amount of text always fills the screen no matter the screen size.
</p>

<pre class="lang-css">
:root {
  font-size: calc(100vw / 35);
}
</pre>

<p>
これは，［
"`font-size: 2.857vw^css" と書いても，~~機能上は同じになる
］が、
~codeを読んでいる誰かにとっては，
その意図（ `35em^v が表示域を埋める）はずっと~~不明瞭になる
— その誰かは、
後で逆算して，［
2.857 は 100/35 の近似が意味されたこと
］を解き明かすはめになる。
◎
Functionality-wise, this is identical to just writing font-size: 2.857vw, but then the intent (that 35em fills the viewport) is much less clear to someone reading the code; the later reader will have to reverse the math themselves to figure out that 2.857 is meant to approximate 100/35.
</p>
</div>

<div class="example">
<p>
標準な演算子 優先順位~規則が適用されるので、
`calc(2 + 3 * 4)^v は， `20^v ではなく `14^v に等しくなる。
◎
Standard mathematical precedence rules for the operators apply: calc(2 + 3 * 4) is equal to 14, not 20.
</p>

<p>
丸括弧を利用すれば、
優先順位を操作できる：
`calc((2 + 3) * 4)^v は， `20^v に等しくなる。
◎
Parentheses can be used to manipulate precedence: calc((2 + 3) * 4) is instead equal to 20.
</p>

<p>
丸括弧と［
追加的な `calc$f 関数を入子にする
］のとは等価になる。
上の `calc((2 + 3) * 4)^v は、
`calc(calc(2 + 3) * 4)^v と書いても等価になる。
これは、
次の例のように，
~~細切れな~~成分から `var$f を介して値を築き上げるときに有用になり得る：
◎
Parentheses and nesting additional calc() functions are equivalent; the preceding expression could equivalently have been written as calc(calc(2 + 3) * 4). This can be useful when building up values piecemeal via var(), such as in the following example:
</p>

<pre class="lang-css">
.aspect-ratio-box {
  --ar: calc(16 / 9);
  --w: calc(100% / 3);
  --h: calc(var(--w) / var(--ar));
  width: var(--w);
  height: var(--h);
}
</pre>

<p>
`--ar^p 【 “縦横比” 】の値は、
単純に `(16 / 9)^v と書く`こともできる^em。
一方で `--w^p は、
全部的な `calc^f 関数として書く必要がある
— `--ar^p と同じく `--h^p にて `calc$f 成分に利用されているが、
`width$p にも そのままに利用されているので，。
◎
Although --ar could have been written as simply --ar: (16 / 9);, --w is used both on its own (in width) and as a calc() component (in --h), so it has to be written as a full calc() function itself.
</p>
</div>

		</section>
		<section id="comp-func">
<h3 title="Comparison Functions: min(), max(), and clamp()">10.2. 比較~関数： `min^f, `max^f, `clamp^f</h3>

<p>
比較~関数
— `min$f, `max$f, `clamp$f —
は、
複数個の`計算式$を比較して，それらのうち 1 つの値を表現する。
◎
The comparison functions of min(), max(), and clamp() compare multiple calculations and represent the value of one of them.
</p>

<p>
［
`min@f
／
`max@f
］関数は、
~commaで分離された 1 個~以上の`計算式$を包含する
— それは、［
最も小さい（最も負な）／最も大きい（最も正な）
］項を表現する。
◎
The min() or max() functions contain one or more comma-separated calculations, and represent the smallest (most negative) or largest (most positive) of them, respectively.
</p>

<p>
`clamp@f
関数は、
3 個の`計算式$
— %最小, %中央-, %最大 —
を順にとり，
%中央- を { %最小 〜 %最大 } の範囲内に切詰める計算を表現する。
%最大 と %最小 が競合する場合は %最小 が優先される（すなわち，
`clamp( 最小v, 値v, 最大v )^v
は、
`max( 最小v, min( 値v, 最大v ) ) )^v
と正確に同じ値を表現する）。
◎
The clamp() function takes three calculations—a minimum value, a central value, and a maximum value—and represents its central calculation, clamped according to its min and max calculations, favoring the min calculation if it conflicts with the max. (That is, given clamp(MIN, VAL, MAX), it represents exactly the same value as max(MIN, min(VAL, MAX))).
</p>

<p>
［
%最小 ／ %最大
］は、
~keyword
`none@v
もとり得る。
この値は、
その側からは`切詰められない^emことを指示する
（すなわち、［
`clamp( 最小v, 値v, none )^v は `max( 最小v, 値v )^v と等価／
`clamp( none, 値v, 最大v )^v は `min( 値v, 最大v )^v と等価／
`clamp( none, 値v, none )^v は `calc( 値v )^v と等価
］になる）。
◎
Either the min or max calculations (or even both) can instead be the keyword none, which indicates the value is not clamped from that side. (That is, clamp(MIN, VAL, none) is equivalent to max(MIN, VAL), clamp(none, VAL, MAX) is equivalent to min(VAL, MAX), and clamp(none, VAL, none) is equivalent to just calc(VAL).)
</p>

<p>
これらの比較~関数は，いずれも、
引数にとる各`計算式$は［
`number$t,
`dimension$t,
`percentage$t
］いずれにも解決され得るが、
`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
その`一貫した型$になる。
◎
For all three functions, the argument calculations can resolve to any &lt;number&gt;, &lt;dimension&gt;, or &lt;percentage&gt;, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.
</p>

<div class="example">
<p>
［
`min$f ／ `max$f ／ `clamp$f
］は、［
値は “安全な” 制限-を超過しない
］ことを~~確保するために利用できる。
例えば， `font-size$p を表示域~単位で設定する “`responsive type^en 【表示域の~sizeに比例するような~~植字】” であっても，可読性を確保する最小~sizeが求まれるかもしれない：
◎
min(), max(), and clamp() can be used to make sure a value doesn’t exceed a "safe" limit: For example, "responsive type" that sets font-size with viewport units might still want a minimum size to ensure readability:
</p>

<pre class="lang-css">
.type {
  /* <span class="comment">
`font-size^p を表示域の縦幅と横幅の平均の 10/100 倍に設定するが、
`12px^v は~~下回らないようにする。
◎
Set font-size to 10x the average of vw and vh, but don’t let it go below 12px.
</span> */
  font-size: max(10 * (1vw + 1vh) / 2, 12px);
}
</pre>

<p class="note">注記：
どの引数にも全部的な~math式が許容されるので、
内側に `calc$f を入子にする必要はない。
適用する拘束が複数あるならば、
3 個~以上の引数も供せる。
◎
Note: Full math expressions are allowed in each of the arguments; there’s no need to nest a calc() inside! You can also provide more than two arguments, if you have multiple constraints to apply.
</p>
</div>

<div class="example">
<p>
何かに［
最小~値を課すときは `max$f ／
最大~値を課すときは `min$f
］を利用することになるが
（すなわち、
`min-width$p の様な~propは実質的に `max^f を利用する）、
これは，反対の関数に混同され易くもある
— 最小~sizeを追加するときに不用意に `min^f を利用してしまうなど。
`clamp$f を利用すれば、
値は 最小と最大の合間に~~挟まれるので，~codeはより自然に読めるようになる：
◎
An occasional point of confusion when using min()/max() is that you use max() to impose a minimum value on something (that is, properties like min-width effectively use max()), and min() to impose a maximum value on something; it’s easy to accidentally reach for the opposite function and try to use min() to add a minimum size. Using clamp() can make the code read more naturally, as the value is nestled between its minimum and maximum:
</p>

<pre class="lang-css">
.type {
  /* <span class="comment">
`font-size^p を `12px^v と `100px^v の合間に~~居座るよう強制する。
◎
Force the font-size to stay between 12px and 100px
</span> */
  font-size: clamp(12px, 10 * (1vw + 1vh) / 2, 100px);
}
</pre>

<p>
あるいは、
最小~sizeだけを課すよう求まれていて，
`font-size^p は求まれるだけ大きくなることを許容する場合：
◎
Or, if you only wanted to impose a minimum size, but allow the font-size to grow as large as it wants:
</p>

<pre class="lang-css">
.type {
  /* <span class="comment">
`font-size^p は `12px^v 以上になるよう強制する。
◎
Force the font-size to be at least 12px
</span> */
  font-size: clamp(12px, 10 * (1vw + 1vh) / 2, none);
}
</pre>
</div>

<div class="note">

<p>注記：
`clamp$f の最小~値は最大~値に
— その 2 つの “順序が間違っている” ときでも —
“勝つ” ことに注意
（他の部分は、
~CSS規約に合致しているとする）。
すなわち、
`clamp(100px, ..., 50px)^v は `100px^v に解決されることになる
— “最大” として与えられた `50px^v を超過して。
◎
Note that clamp(), matching CSS conventions elsewhere, has its minimum value "win" over its maximum value if the two are in the "wrong order". That is, clamp(100px, ..., 50px) will resolve to 100px, exceeding its stated "max" value.
</p>

<p>
別の解決-法が欲される場合、
`clamp$f と［
`min$f ／ `max$f
］を組合せれば達成できる：
◎
If alternate resolution mechanics are desired they can be achieved by combining clamp() with min() or max():
</p>

<dl>
	<dt>
最大v が 最小v に勝つようにするためには：
◎
To have MAX win over MIN:
</dt>
	<dd>
`clamp( min( 最小v, 最大v ), 値v, 最大v )^v
◎
clamp(min(MIN, MAX), VAL, MAX).＼
</dd>
	<dd>
最大v の計算を繰返すのを避けたいなら、
単に `clamp$f に定義した関数の入子ngを逆にする~~方法もある
⇒
`min( 最大v, max( 最小v, 値v ) )^v
◎
If you want to avoid repeating the MAX calculation, you can just reverse the nesting of functions that clamp() is defined against—min(MAX, max(MIN, VAL)).
</dd>

	<dt>
順序が間違っているときには、
最大vと最小v を “入替える” ようにするためには：
◎
To have MAX and MIN "swap" when they’re in the wrong order:
</dt>
	<dd>
`clamp( min( 最小v, 最大v ), 値v, max( 最小v, 最大v ) )^v
◎
clamp(min(MIN, MAX), VAL, max(MIN, MAX)).＼
</dd>
	<dd>
あいにく， 最小v, 最大v 項を繰返すことなく これを行う容易な仕方は無い。
◎
Unfortunately, there’s no easy way to do this without repeating the MIN and MAX terms.
</dd>
</dl>
</div>

		</section>
		<section id="round-func">
<h3 title="Stepped Value Functions: round(), mod(), and rem()">10.3. 丸ng関数と剰余~関数： `round^f, `mod^f, `rem^f</h3>

<p>
丸ng関数 `round$f と剰余~関数［
`mod$f ／ `rem$f
］は、
どれも，所与の値を別の “段差~値” に則って異なる仕方で変形する。
（これらは、
`stepped-value^en 関数【 “階段関数” 】と総称される）。
◎
The stepped-value functions, round(), mod(), and rem(), all transform a given value according to another "step value", in different ways.
</p>

<p>
`round(~vC?, ~vA, ~vB?)@f
関数は、
それが包含する［
丸ng策を表す省略可能な `rounding-strategy$t 値 ~vC,
丸められる`計算式$ ~vA,
精度を表す`計算式$ ~vB
］に対し， ~vA を［
~vB の整数倍
］のうち
— ~vC に則って，~vA 以上または以下の —
~vA に最も近い値に丸めた結果を返す。
◎
The round(&lt;rounding-strategy&gt;?, A, B) function contains an optional rounding strategy, and two calculations A and B, and returns the value of A, rounded according to the rounding strategy, to the nearest integer multiple of B either above or below A.＼
</p>

<p>
~vA, ~vB は［
`number$t,
`dimension$t,
`percentage$t
］いずれにも解決され得るが、
`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
その`一貫した型$になる。
◎
The argument calculations can resolve to any &lt;number&gt;, &lt;dimension&gt;, or &lt;percentage&gt;, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.
</p>

<p>
~vA が ~vB の整数倍に正確に等しい場合、
`round$f は正確に ~vA に解決される
（ ~vA が ~0N, ~0P どちらなのかも保全される）。
他の場合、
~vB の整数倍のうち ~vA に “最も近いもの” は［
−∞ に近い方 %低いB,
+∞ に近い方 %高いB
］の 2 つがある。
どちらを選ぶかは、
~vC に与える
`rounding-strategy@t
が規定する：
◎
If A is exactly equal to an integer multiple of B, round() resolves to A exactly (preserving whether A is 0⁻ or 0⁺, if relevant). Otherwise, there are two integer multiples of B that are potentially "closest" to A, lower B which is closer to −∞ and upper B which is closer to +∞. The following &lt;rounding-strategy&gt;s dictate how to choose between them:
</p>

<dl>
	<dt>`nearest@v</dt>
	<dd>
%低いB,
%高いB
のうち ~vA からの差が（絶対~値として）小さい方を選ぶ。
差が等しい場合は %高いB を選ぶ。
◎
Choose whichever of lower B and upper B that has the smallest absolute difference from A. If both have an equal difference (A is exactly between the two values), choose upper B.
</dd>

	<dt>`up@v</dt>
	<dd>
%高いB を選ぶ。
◎
Choose upper B.
</dd>

	<dt>`down@v</dt>
	<dd>
%低いB を選ぶ。
◎
Choose lower B.
</dd>

	<dt>`to-zero@v</dt>
	<dd>
%低いB, %高いB のうち絶対~値が小さい方を選ぶ。
◎
Choose whichever of lower B and upper B that has the smallest absolute difference from 0.
</dd>
</dl>

<p>
［
%低いB ／ %高いB
］は、
0 になる場合には，特定的に［
~0P ／ ~0N
］になるとする。
◎
If lower B would be zero, it is specifically equal to 0⁺; if upper B would be zero, it is specifically equal to 0⁻.
</p>

<p>
`rounding-strategy$t が省略された場合の既定は、
`nearest$v とする。
（ ~vB が整数なら，`最も近い整数に丸める$のと同じ。）
◎
If &lt;rounding-strategy&gt; is omitted, it defaults to nearest. (Aka rounding to the nearest integer.)＼
</p>

<p>
~vA の`型$が `number$t に合致する場合には、
~vB を省略してもヨイ
— その場合の既定は `1^v とする。
他の場合に ~vB を省略することは妥当でない。
◎
If the type of A matches &lt;number&gt;, then B may be omitted, and defaults to 1; omitting B is otherwise invalid.
</p>

<p class="issue">
~CSSOMは、
どう丸めるか指定する必要がある
— おそらく、
~CSS関数は，既定では同じ仕方で丸めるようにするのが良い。
どの挙動が利用されるべきか？
[`5689$issue]
◎
CSSOM needs to specify how it rounds, and it’s probably good for CSS functions to round the same way by default. What behavior should be used? [Issue #5689]
</p>

<div class="example">
<p>
~JSの様な，（整数に）丸める生来な “精度” を備える言語と違って、
~CSS値には，そのような精度は無い
— 値は様々な`互換$な単位で記され得るので。
なので、
精度は明示的に与える必要がある。
`round(var(--width), 50px)^v と書いたなら、
横幅（ `--width^p の値）を最も近い `50px^v の整数倍に丸めることになる。
◎
Unlike languages like JavaScript which have a natural "precision" to round to (integers), CSS values have no such precision because values can be written in many different compatible units. As such, the precision has to be given explicitly; to round a width to the nearest 50px, one can write round(var(--width), 50px).
</p>
</div>

<p class="note">注記：
~JSを含む~programming言語には、
各種 丸ng策を別々な丸ng関数に分離しているものもある。
~JSの［
`Math.floor()^c ／
`Math.ceil()^c ／
`Math.trunc()^c ／ 
`Math.round()^c 
］は、
~CSSの［
`round(down, …)^v ／
`round(up, …)^v ／
`round(to-zero, …)^v ／
`round(nearest, …)^v （あるいは単に `round(…)^v ）
］に等価になる。
◎
Note: JavaScript and other programming languages sometimes separate out the rounding strategies into separate rounding functions. JS’s Math.floor() is equivalent to CSS’s round(down, ...); JS’s Math.ceil() is equivalent to CSS’s round(up, ...); JS’s Math.trunc() is equivalent to CSS’s round(to-zero, ...); and JS’s Math.round() is equivalent to CSS’s round(nearest, ...), or just round(...).
</p>

<p class="note">注記：
`rounding-strategy$t を成す各~keywordは、
`block-step-round$p 【！ `block-step-size$p 】用の~keywordと同じであり，同じ挙動を備える（
`block-step-round^p は `to-zero$v だけ欠いているが
— `塊~size$は負になり得ず， `to-zero^v は `down$v に一致することになるので）。
◎
Note: The &lt;rounding-strategy&gt; keywords are the same as the keywords in block-step-size and have the same behavior. (block-step-size just lacks to-zero; since block sizes are always non-negative, to-zero and down would be identical.)
</p>

<p>
剰余~関数［
`mod(~vA, ~vB)@f
／
`rem(~vA, ~vB)@f
］
【 "mod" は “`modulus^en”  の略, "rem" は “`remainder^en” の略】
は：
◎
The modulus functions mod(A, B) and rem(A, B) similarly＼
</p>
<ul>
	<li>
次を包含する
⇒＃
~~被除数を表す`計算式$ ~vA,
段差を表す`計算式$ ~vB
◎
contain two calculations A and B,＼
</li>
	<li>
~vA から ~vA を丸めた結果
— ~vA 以上または以下の， ~vA に最も近い ~vB の整数倍 —
を減算した結果を返す。
◎
and return the difference between A and the nearest integer multiple of B either above or below A.＼
</li>
	<li>
~vA, ~vB は［
`number$t,
`dimension$t,
`percentage$t
］いずれにも解決され得るが、
`一貫した型を有して$いなければナラナイ
【！must have the same type（おそらく更新漏れ）】
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
その`一貫した型$になる
【！have the same type as the arguments（おそらく更新漏れ）】。
◎
The argument calculations can resolve to any &lt;number&gt;, &lt;dimension&gt;, or &lt;percentage&gt;, but must have the same type, or else the function is invalid; the result will have the same type as the arguments.
</li>
</ul>

<p>
この 2 つの関数はとても類似する：
◎
The two functions are very similar, and＼
</p>

<ul>
	<li>
<div class="p">
<p>
事実，引数 ~vA, ~vB の正負が一致する場合、
結果は一致する。
関数の値は、
その結果が次の範囲に入るよう，
~vA の値を ~vB のある整数倍でずらした結果に等しくなる：
</p>
		<ul id="between-zero-and-b">
			<li>
引数が負ならば
⇒
~vB ~LT 結果 ~LTE ~0N （ “負な範囲” ）
— 結果が 0 になる場合は ~0N を選ぶ
</li>
			<li>
引数が正ならば
⇒
~0P ~LTE 結果 ~LT ~vB （ “正な範囲” ）
— 結果が 0 になる場合は ~0P を選ぶ
</li>
		</ul>

◎
in fact return identical results if both arguments are positive or both are negative: the value of the function is equal to the value of A shifted by the integer multiple of B that brings the value between zero and B. (Specifically, the range includes zero and excludes B. More specifically, if B is positive the range starts at 0⁺, and if B is negative it starts at 0⁻.)
</div>

<div class="example">
<p>
例えば，
`mod(18px, 5px)^v
は、
値 `3px^v に解決される
— `18px^v から `5px^v の 3 倍 を減算すれば `3px^v が得られ，それが
`0px^v と `5px^v 【！3px】の合間に入る唯一の値なので。
◎
For example, mod(18px, 5px) resolves to the value 3px, because subtracting 5px * 3 from 18px yields 3px, which is the only such value between 0px and 3px.
</p>

<p>
同様に，
`mod(-140deg, -90deg)^v
は、
値 `-50deg^v に解決される
— `-140deg^v に `-90deg^v の 1 倍を加算すれば `-50deg^v が得られ，
それが `0deg^v と `-90deg^v の合間に入る唯一の値なので。
◎
Similarly, mod(-140deg, -90deg) resolves to the value -50deg, because adding -90deg * 1 to -140deg yields -50deg, which is the only such value between 0deg and -90deg.
</p>

<p>
これら各~例を `rem$f で評価した結果は、
正確に同じになる。
◎
Evaluating either of these examples with rem() yields the exact same results.
</p>
</div>

	</li>
	<li>
<p>
~vA, ~vB の正負が一致しない場合、
2 つの関数の挙動は分岐する：
◎
Their behavior diverges if the A value and the B step are on opposite sides of zero:＼
</p>
<ul>
			<li>
`mod$f は、
結果の範囲を ~vB の正負に基づいて選ぶ。
【 ~vB が 0 の事例は、下の下位節を見よ。】
◎
mod() (short for “modulus”) continues to choose the integer multiple of B that puts the value between zero and B, as above (guaranteeing that the result will either be zero or share the sign of B, not A), while＼
</li>
			<li>
`rem$f は、
結果の範囲を ~vA の正負に基づいて選ぶ。
【 ~vA が 0 の場合も， ~0N か ~0P かに応じて範囲を選ぶ（結果が同じ ~0N ／ ~0P になるよう）。】
◎
rem() (short for "remainder") chooses the integer multiple of B that puts the value between zero and -B, avoiding changing the sign of the value.
</li>
		</ul>

<p class="trans-note">【
これらの規則は、
引数の正負が一致する場合も包摂している。
】</p>

<div class="example">
<p>
例えば， `mod(-18px, 5px)^v は、
値 `2px^v に解決される
— `-18px^v に `5px^v の 4 倍を加算すれば `2px^v が得られ，それが
`0px^v と `5px^v の合間に入る。
◎
For example, mod(-18px, 5px) resolves to the value 2px: adding 5px * 4 to -18px yields 2px, which is between 0px and 5px.
</p>

<p>
他方， `rem(-18px, 5px)^v は、
値 `-3px^v に解決される
— `-18px^v に `5px^v の 3 倍を加算すれば，
`-18px^v と正負が同じ `-3px^v が得られ、
それが `0px^v と `-5px^v の合間に入る。
◎
On the other hand, rem(-18px, 5px) resolves to the value -3px: adding 5px * 3 to -18px yields -3px, which has the same sign as -18px but is between 0px and -5px.
</p>

<p>
同様に，
`mod(140deg, -90deg)^v は，値 `-40deg^v に解決されるが（
`140deg^v に `-90deg^v の 2 倍を加算すれば，
`0deg^v と `-90deg^v の合間に入る）、
`rem(140deg, -90deg)^v は，値 `50deg^v に解決される。
◎
Similarly, mod(140deg, -90deg) resolves to the value -40deg (adding -90deg * 2 to 140deg, bringing it to between 0deg and -90deg), but rem(140deg, -90deg) resolves to the value 50deg.
</p>
</div>

	</li>
</ul>

<details class="note">
<summary>
`mod$f, `rem$f
のどっちを選ぶべきか？
◎
When should I choose mod() vs rem()?
</summary>

<p>
この演算の利用者は、
概して，段差~値（ ~vB ）を制御して，未知な値 ~vA を改変する。
それゆえ，`通例的には^em、
~vA の正負に関わらず，結果は 0 と ~vB の合間に入る方が期待される
— すなわち， `mod$f が選ばれるべきである。
◎
Typically, users of this operation are in control of the step value (B), and are modifying an unknown value A. As a result, it’s usually more expected that the result is between 0 and B, regardless of A’s sign, meaning mod() should be chosen.
</p>

<p>
作者が例えば，ある長さが `px^u ~~単位で［
偶数, 奇数
］どちらになるか知りたいと求める場合
（ここでは、
長さは `px^u の整数倍であると見做す）、
`mod(~vA, 2px)^v は ~vA の値が何であれ，
`0px^v か `1px^v
を返すことになる。
他方，`rem(~vA, 2px)^v は、
~vA が偶数 `px^u なら `0px^v を返すが，奇数の場合は ~vA に依存して［
正ならば `1px^v ／負ならば `-1px^v
］を返すことになる。
◎
For example, if an author wants to know whether a length is an even or odd number of pixels, mod(A, 2px) will return either 0px or 1px (assuming the value is a whole number of pixels to begin with), regardless of the value of a. rem(A, 2px), on the other hand, will return 0px if A is an even number of pixels, but will return either 1px or -1px if it’s odd, depending on whether A is positive or negative.
</p>

<p>
しかしながら，反対の状況もあり【すなわち、 ~vB が未知】、
それをまかなうために `rem$f が供されている。
また、
`rem^f は~JSの `%^c 演算子の挙動を備えるので、
~CSSと~JS~codeとが正確に合致することが欲される場合には `rem^f が有用になり得る。
◎
The opposite situation does sometimes occur, however, and so rem() is provided to cater to that. As well, rem() is the behavior of JavaScript’s % operator, so if an exact match between CSS and JS code is desired, rem() can be useful.
</p>
</details>

<div class="note">
<p>注記：
`mod$f, `rem$f は、
他の関数でも直に定義できる：
</p>

<ul>
	<li>
<p>
`mod(~vA, ~vB)^v は、
次と等価になる
⇒
`calc(~vA - sign(~vB)*round(down, ~vA*sign(~vB), ~vB))^v
</p>
<p>
（ ~vB が［
正なら `calc(~vA - round(down, ~vA, ~vB))^v ／
負なら `calc(~vA - round(up, ~vA, ~vB))^v
］が得られるようにした式）
</p>
	</li>
	<li>
`rem(~vA, ~vB)^v は、
次と等価になる
⇒
`calc(~vA - round(to-zero, ~vA, ~vB))^v
</li>
</ul>

<p>
（これらの式は、
~0P, ~0N を常に正しく取扱うわけではないが
— ~0N の意味論は加算において可換でないので。）
</p>
◎
Note: mod() and rem() can also be defined directly in terms of other functions: mod(A, B) is equivalent to calc(A - sign(B)*round(down, A*sign(B), B)) (a hacky way to say "round(down) when B is positive, round(up) when B is negative), while rem(A, B) is equivalent to calc(A - round(to-zero, A, B)). (These expressions don’t always handle 0⁺ and 0⁻ correctly, though, because 0⁻ semantics aren’t commutative for addition.)
</div>

			<section id="round-infinities">
<h4 title="Argument Ranges">10.3.1. 引数の範囲</h4>

<p>
`round(~vC?, ~vA, ~vB)$f
においては：
◎
In round(A, B),＼
</p>

<ul>
	<li>
~vB ~IN { ~0N, ~0P } ならば，結果は ~NaN になる。
◎
if B is 0, the result is NaN.＼
</li>
	<li>
~vA ~IN { +∞, −∞ } ならば
⇒＃
~vB ~IN { +∞, −∞ } ならば，結果は ~NaN になる
他の場合，結果は ~vA になる
◎
If A and B are both infinite, the result is NaN.
◎
If A is infinite but B is finite, the result is the same infinity.
</li>
	<li>
<p>
他の場合， ~vB ~IN { +∞, −∞ } ならば、
結果は，次の表tで与えられる：
◎
If A is finite but B is infinite, the result depends on the &lt;rounding-strategy&gt; and the sign of A:
</p>

<div>
<table class="math-matrix">
<caption>
上端見出しは ~vA,
左端見出しは ~vC
の値を表す。
</caption>
<thead>
<tr><td>
<th>有限（負）
<th>~0N
<th>~0P
<th>有限（正）
<tbody>

<tr><th>`nearest$v
<td>~0N
<td>~0N
<td>~0P
<td>~0P

<tr><th>`to-zero$v
<td colspan="4">`nearest$v のときと同じ

<tr><th>`up$v
<td>~0N
<td>~0N
<td>~0P
<td>+∞

<tr><th>`down$v
<td>−∞
<td>~0N
<td>~0P
<td>~0P
</table>

◎
nearest
to-zero
• If A is positive or 0⁺, return 0⁺. Otherwise, return 0⁻.
◎
up
• If A is positive (not zero), return +∞. If A is 0⁺, return 0⁺. Otherwise, return 0⁻.
◎
down
• If A is negative (not zero), return −∞. If A is 0⁻, return 0⁻. Otherwise, return 0⁺.
</div>
	</li>
</ul>

<p>
［
`mod(~vA, ~vB)$f ／
`rem(~vA, ~vB)$f
］においては、
次のいずれかに該当する場合，結果は ~NaN になる：
</p>

<ul>
	<li>
~vB ~IN { ~0N, ~0P }
◎
In mod(A, B) or rem(A, B), if B is 0, the result is NaN.＼
</li>
	<li>
~vA ~IN { +∞, −∞ }
◎
If A is infinite, the result is NaN.
</li>
	<li>
<div class="P">
<p>
`mod(~vA, ~vB)$f の場合に限り：
</p>
		<ul>
			<li>
［
~vB ~EQ +∞
］~AND［［
~vA ~LT 0
］~OR［
~vA ~EQ ~0N
］］
</li>
			<li>
［
~vB ~EQ −∞
］~AND［［
~vA ~GT 0
］~OR［
~vA ~EQ ~0P
］］
</li>
		</ul>
◎
In mod(A, B) only, if B is infinite and A has opposite sign to B (including an oppositely-signed zero), the result is NaN.
</div>

<p class="note">注記：
他のすべての “無限な ~vB ” の事例は妥当であり、
単に ~vA を返す。
◎
Note: All other "infinite B" cases are valid, and just return A immediately.
</p>
	</li>
</ul>

			</section>
		</section>
		<section id="trig-funcs">
<h3 title="Trigonometric Functions: sin(), cos(), tan(), asin(), acos(), atan(), and atan2()">10.4. 三角-関数： `sin^f, `cos^f, `tan^f, `asin^f, `acos^f, `atan^f, `atan2^f</h3>

<p>
三角-関数
— `sin$f, `cos$f, `tan$f, `asin$f, `acos$f, `atan$f, `atan2$f —
は、
様々な基本的な三角-関係性を算出する。
◎
The trigonometric functions—sin(), cos(), tan(), asin(), acos(), atan(), and atan2()—compute the various basic trigonometric relationships.
</p>

<p>
［
`sin(~vA)@f
／
`cos(~vA)@f
／
`tan(~vA)@f
］関数は：
◎
The sin(A), cos(A), and tan(A) functions＼
</p>
<ul>
	<li>
いずれも、
1 個の`計算式$ ~vA を包含する。
◎
all contain a single calculation＼
</li>
	<li>
~vA は、［
`number$t ／ `angle$t
］に解決されなければナラナイ。
◎
which must resolve to either a &lt;number&gt; or an &lt;angle&gt;,＼
</li>
	<li>
~vA を~radian数として解釈する下で，
各自に対応している関数を算出した結果を返す
（すなわち，［
`sin(45deg)^v, `sin(.125turn)^v, `sin(3.14159 / 4)^v
］は、
どれも同じ値（約 `.707^v ）を表現する）。
◎
and compute their corresponding function by interpreting the result of their argument as radians. (That is, sin(45deg), sin(.125turn), and sin(3.14159 / 4) all represent the same value, approximately .707.)＼
</li>
	<li>
いずれも、
`number^t を表現する
— その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ) , ~vA の`型$ )
◎
They all represent a &lt;number&gt;, with the return type made consistent with the input calculation’s type.＼
</li>
	<li>
［
`sin$f ／ `cos$f
］は，常に −1 以上 1 以下の実数を返す。
◎
sin() and cos() will always return a number between −1 and 1,＼
</li>
	<li>
`tan$f は ±∞ も含むどの実数も返し得る
（`~math関数$が ∞ をどう取扱うかについての詳細は、
`§ 型の検査-法$を見よ）。
◎
while tan() can return any number between −∞ and +∞. (See § 10.9 Type Checking for details on how math functions handle ∞.)
</li>
</ul>

<p>
［
`asin(~vA)@f
／
`acos(~vA)@f
／
`atan(~vA)@f
］関数は、
“逆” 三角-関数
— 各自に対応する “通常の” 三角-関数に対する逆-関数 —
を表現する：
◎
The asin(A), acos(A), and atan(A) functions are the "arc" or "inverse" trigonometric functions, representing the inverse function to their corresponding "normal" trig functions.＼
</p>

<ul>
	<li>
いずれも， 1 個の`計算式$ ~vA を包含する。
◎
All of them contain a single calculation＼
</li>
	<li>
~vA は、
`number$t に解決されなければナラナイ。
◎
which must resolve to a &lt;number&gt;,＼
</li>
	<li>
~vA を `angle$t を表現している~radian数として解釈する下で，
各自に対応している関数を算出した結果を返す。
◎
and compute their corresponding function, interpreting their result as a number of radians, representing an &lt;angle&gt;＼
</li>
	<li>
その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ), ~vA の`型$ )
◎
with the return type made consistent with the input calculation’s type.＼
</li>
	<li>
次の範囲に正規化した角度を返すモノトスル
⇒＃
`asin$f 用には `-90deg^v 以上, `90deg^v 以下 ／
`acos$f 用には `0deg^v 以上, `180deg^v 以下 ／
`atan$f 用には `-90deg^v 以上, `90deg^v 以下
◎
The angle returned by asin() must be normalized to the range [-90deg, 90deg]; the angle returned by acos() to the range [0deg, 180deg]; and the angle returned by atan() to the range [-90deg, 90deg].
</li>
</ul>

<p>
`atan2(~vA, ~vB)@f
関数は：
◎
The atan2(A, B) function＼
</p>
<ul>
	<li>
~commaで分離された 2 個の`計算式$ ~vA, ~vB を包含する。
◎
contains two comma-separated calculations, A and B.＼
</li>
	<li>
~vA, ~vB は［
`number$t,
`dimension$t,
`percentage$t
］いずれにも解決され得るが、
`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
◎
A and B can resolve to any &lt;number&gt;, &lt;dimension&gt;, or &lt;percentage&gt;, but must have a consistent type or else the function is invalid.＼
</li>
	<li>
正な X 軸から点 ( ~vB, ~vA ) までの `angle$t を返す。
◎
The function returns the &lt;angle&gt; between the positive X-axis and the point (B,A),＼
</li>
	<li>
その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( "`deg$u" ), ( ~vA, ~vB ) の`一貫した型$ )
◎
with the return type made consistent with the input calculation’s type.＼
</li>
	<li>
`-180deg^v 以上, `180deg^v 未満の角度に正規化して返すモノトスル。
◎
The returned angle must be normalized to the interval (-180deg, 180deg] (that is, greater than -180deg, and less than or equal to 180deg).
</li>
</ul>

<p class="note">注記：
`atan2(~vA, ~vB)$f
は，`一般に^em
`atan(~vA / ~vB)$f
と等価になるが、
対応する点 ( ~vB, ~vA ) が負な成分を含み得るときには，
より良い答えを与える。
点 ( −1, 1 ) に対応する `atan2(1, -1)^v は `135deg^v を返す一方で、
点 ( 1, −1 ) に対応する `atan2(-1, 1)^v は `-45deg^v を返す。
対照的に
`atan(1 / -1)^v, `atan(-1 / 1)^v
は、
どちらも `-45deg^v を返す
— どちらも、
内部的な計算は `-1^v に解決されるので。
◎
Note: atan2(Y, X) is generally equivalent to atan(Y / X), but it gives a better answer when the point in question may include negative components. atan2(1, -1), corresponding to the point (-1, 1), returns 135deg, distinct from atan2(-1, 1), corresponding to the point (1, -1), which returns -45deg. In contrast, atan(1 / -1) and atan(-1 / 1) both return-45deg, because the internal calculation resolves to -1 for both.
</p>

			<section id="trig-infinities">
<h4 title="Argument Ranges">10.4.1. 引数の範囲</h4>

<p>
［
`sin(~vA)^v ／ `cos(~vA)^v ／ `tan(~vA)^v
］においては、
~vA が ±∞ ならば，結果は ~NaN になる。
（`~math関数$が ~NaN をどう取扱うかの詳細は、
`§ 型の検査-法$を見よ。）
◎
In sin(A), cos(A), or tan(A), if A is infinite, the result is NaN. (See § 10.9 Type Checking for details on how math functions handle NaN.)
</p>

<p>
［
`sin(~vA)^v ／ `tan(~vA)^v
］においては、
~vA ~EQ ~0N
ならば，結果は ~0N になる。
◎
In sin(A) or tan(A), if A is 0⁻, the result is 0⁻.
</p>

<p>
`tan(~vA)^v
において， ~vA が漸近~値（ `90deg^v, `270deg^v, 等）である場合の数量-結果は、
`実装定義$である。
実装が，これらの入力を正確に表現する能力がある場合、［
`90deg^v ／ `-90deg^v
］との差が `360deg^v の整数倍に漸近な所では［
+∞ ／ −∞
］を返す`ベキ^emであるが、
実装には，これらの入力を正確に表現-可能になることは要求されない
（表現できない場合、
何であれ［
自身が表現する能力がある，入力に最も近い近似
］に対する正しい数量-結果を返すことになる）。
作者は、［
`tan$f が，これらの入力に対し 特定0の値を返す
］ことに`依拠してはナラナイ^em。
◎
In tan(A), if A is one of the asymptote values (such as 90deg, 270deg, etc), the numeric result is implementation-defined. If an implementation is capable of exactly representing these inputs, it should return +∞ for the asymptotes at 90deg + N*360deg, and −∞ for the asymptotes at -90deg + N*360deg, but implementations are not required to be able to exactly represent these inputs (and if they can’t, will return whatever the correct numeric answer is for the closest approximation to the input they are capable of representing). Authors must not rely on tan() returning any particular value for these inputs.
</p>

<details class="note">
<summary>
なぜ`実装定義$なのか？
◎
Why are these implementation-defined?
</summary>

<p>
正接（ `tangent^en ）関数は、
漸近~値の所で`不連続^emになる：
それは、［
一方の側からは正な無限大，
他方の側からは負な無限大
］へ近付き，正確な漸近~値の所では定義されない。
◎
The tangent function is discontinuous at its asymptotes: it approaches infinity from one side and negative infinity from the other side, and isn’t defined at the exact values of the asymptote.
</p>

<p>
更には、
漸近的な値が実装において正確に表現-可能かどうかは、
実装が角度を内部的に どう格納して操作するかに依存する
— 当の値が度数で書かれたときは（ `90deg^v, 等々）単純だが、
~radianで書かれたときは（ `pi / 2^v, 等々），値は超越数になり，正確には表現し得ない。
なので、
これらの値に特有な挙動を定義することすら困難になる
— ある実装が内部的に~radianを利用する場合、
入力が漸近~値に`十分近い^emときには，
何らかの `fuzzy^en 照合を行って，定義された値を返す必要があろう。
◎
Further, whether or not the asymptotic values are exactly representable in implementations depends on how they internally store and manipulate angles; when written in degrees the values are simple (90deg, etc), but in radians the values are transcendental (pi / 2, etc) and cannot be exactly represented. So, even defining a specific behavior for these values is difficult; if an implementation uses radians internally, it would have to do some fuzzy matching to return the defined value when the input is sufficiently close to the asymptote.
</p>

<p>
~Web用の他の主要な言語，~JSは、
これらの関数を~radianしかとらないものとして公開するので，
正確な漸近~値には ぶつかり得ない
（このことは、
他の，ほとんどの~computer言語にも該当する）。
~JSで~codeを書いている作者は、
これらの値に特有な挙動には依拠できないし，
~CSSにおける作者たちの必要性が有意に異なる見込みも低い。
◎
The other major language for the Web, JavaScript, exposes these functions as taking radians only, so it can’t hit the exact asymptotes either (and this true for most other computer languages, too). Authors writing code in JS, then, can’t rely on any specific behavior for these values either, and it’s unlikely that their needs in CSS are significantly different.
</p>

<p>
漸近~値を正確に表現できる実装~用に示唆した挙動は、
`atan$f 関数が往復することを保全する：
この定義が与えられた下では、
`tan(atan(~vA))^v, `atan(tan(~vA))^v
は，
どちらも，アリなすべての値 ~vA に対し，
（近似的に）~vA を返すことになる。
それはまた、
実装が `atan^f 用に~supportする出力~範囲の中では，
この関数は，連続的になることを意味する。
◎
The suggested behavior for implementations that can exactly represent the asymptote values preserves round-tripping with the atan() function: tan(atan(X)) and atan(tan(X)) will both return (approximately) X for all possible X values, given this definition. It also means that within the supported output range of atan(), the function is continuous.
</p>
</details>

<p>
［
`asin(~vA)^v ／ `acos(~vA)^v
］においては、［
−1 ~LTE ~vA ~LTE 1
］でないならば，結果は ~NaN になる。
◎
In asin(A) or acos(A), if A is less than -1 or greater than 1, the result is NaN.
</p>

<p>
`acos(~vA)^v においては、
~vA ~EQ 1
ならば，結果は 0 になる。
◎
In acos(A), if A is exactly 1, the result is 0.
</p>

<p>
［
`asin(~vA)^v ／ `atan(~vA)^v
］においては、
~vA ~EQ ~0N
ならば，結果は ~0N になる。
◎
In asin(A) or atan(A), if A is 0⁻, the result is 0⁻.
</p>

<p>
`atan(~vA)^v
においては
⇒＃
~vA ~EQ +∞ ならば，結果は `90deg^v になる ／
~vA ~EQ −∞ ならば，結果は `-90deg^v になる
◎
In atan(A), if A is +∞, the result is 90deg; if A is −∞, the result is -90deg.
</p>

<p>
<code class="func">atan(%Y, %X)</code>
においては、
すべての［
通例でない引数の組合n
］の結果は，次の表tで与えられる：
◎
In atan2(Y, X), the following table gives the results for all unusual argument combinations:
</p>

<div>
<table class="math-matrix">
<caption>
左端見出しは %Y,
上端見出しは %X
の値を表す。
結果の数はすべて `deg$u 単位とする。
</caption>
<thead>
<tr><td>
<th>−∞
<th>有限（負）
<th>~0N
<th>~0P
<th>有限（正）
<th>+∞
<tbody>

<tr><th>−∞
<td>−135
<td>−90
<td>−90
<td>−90
<td>−90
<td>−45

<tr><th>有限（負）
<td>−180
<td>（通常）
<td>−90
<td>−90
<td>（通常）
<td>~0N

<tr><th>~0N
<td>−180
<td>−180
<td>−180
<td>~0N
<td>~0N
<td>~0N

<tr><th>~0P
<td>180
<td>180
<td>180
<td>~0P
<td>~0P
<td>~0P

<tr><th>有限（正）
<td>180
<td>（通常）
<td>90
<td>90
<td>（通常）
<td>~0P

<tr><th>+∞
<td>135
<td>90
<td>90
<td>90
<td>90
<td>45
</table>

◎
 ｜ X
 ｜ −∞ ｜ -finite ｜ 0⁻ ｜ 0⁺ ｜ +finite ｜ +∞
Y ｜ −∞ ｜ -135deg ｜ -90deg ｜ -90deg ｜ -90deg ｜ -90deg ｜ -45deg
-finite ｜ -180deg ｜ (normal) ｜ -90deg ｜ -90deg ｜ (normal) ｜ 0⁻deg
0⁻ ｜ -180deg ｜ -180deg ｜ -180deg ｜ 0⁻deg ｜ 0⁻deg ｜ 0⁻deg
0⁺ ｜ 180deg ｜ 180deg ｜ 180deg ｜ 0⁺deg ｜ 0⁺deg ｜ 0⁺deg
+finite ｜ 180deg ｜ (normal) ｜ 90deg ｜ 90deg ｜ (normal) ｜ 0⁺deg
+∞ ｜ 135deg ｜ 90deg ｜ 90deg ｜ 90deg ｜ 90deg ｜ 45deg
</div>

<p class="note">注記：
これらの関数の挙動はすべて、
ほとんどの~programming言語
— 特に~JS —
に実装されている “標準な” 定義に合致することが意図されている。
◎
Note: All of these behaviors are intended to match the "standard" definitions of these functions as implemented by most programming languages, in particular as implemented in JS.
</p>

			</section>
		</section>
		<section id="exponent-funcs">
<h3 title="Exponential Functions: pow(), sqrt(), hypot(), log(), exp()">10.5. 指数-関数： `pow^f, `sqrt^f, `hypot^f, `log^f, `exp^f</h3>

<p>
指数-関数
— `pow$f, `sqrt$f, `hypot$f, `log$f, `exp$f —
は、
引数から様々な指数-関数を算出する。
◎
The exponential functions—pow(), sqrt(), hypot(), log(), and exp()—compute various exponential functions with their arguments.
</p>

<p>
`pow(~vA, ~vB)@f
関数は：
◎
The pow(A, B) function＼
</p>

<ul>
	<li>
~commaで分離された 2 個の`計算式$ ~vA, ~vB を包含する。
◎
contains two comma-separated calculations A and B,＼
</li>
	<li>
~vA, ~vB は、
`number$t に解決されなければナラナイ。
◎
both of which must resolve to &lt;number&gt;s,＼
</li>
	<li>
~vA を ~vB 乗した結果の値を `number^t として返す。
◎
and returns the result of raising A to the power of B, returning the value as a &lt;number&gt;.＼
</li>
	<li>
~vA, ~vB は、
`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
その`一貫した型$になる。
◎
The input calculations must have a consistent type or else the function is invalid; the result’s type will be the consistent type.
</li>
</ul>

<p>
`sqrt(~vA)@f
関数は：
◎
The sqrt(A) function＼
</p>
<ul>
	<li>
1 個の`計算式$ ~vA を包含する。
◎
contains a single calculation＼
</li>
	<li>
~vA は `number$t に解決されなければナラナイ。
◎
which must resolve to a &lt;number&gt;,＼
</li>
	<li>
~vA の平方根を `number^t として返す
（ `sqrt(~vA)^v は、
`pow(~vA, .5)^v と基本的には等価だが，
一部の~errorの取扱いは相違する
— `sqrt$f は、
簡便さを供するに価するほど十分~共通的な関数である）。
◎
and returns the square root of the value as a &lt;number&gt;. (sqrt(X) and pow(X, .5) are basically equivalent, differing only in some error-handling; sqrt() is a common enough function that it is provided as a convenience.)
</li>
</ul>

<p>
`hypot(…)@f
関数は：
◎
The hypot(A, …) function＼
</p>
<ul>
	<li>
~commaで分離された 1 個以上の`計算式$を包含する。
◎
contains one or more comma-separated calculations,＼
</li>
	<li>
各`計算式$に等しい成分を伴う多次元~vectorの長さを返す
（すなわち、
各~引数の二乗の総和の平方根）。
◎
and returns the length of an N-dimensional vector with components equal to each of the calculations. (That is, the square root of the sum of the squares of its arguments.)＼
</li>
	<li>
引数にとる各`計算式$は［
`number$t,
`dimension$t,
`percentage$t
］いずれにも解決され得るが、
`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
その`一貫した型$になる。
◎
The argument calculations can resolve to any &lt;number&gt;, &lt;dimension&gt;, or &lt;percentage&gt;, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.
</li>
</ul>

<details class="note">
<summary>
`hypot$f は次元（単位を伴う値）を許容するのに、
なぜ， `pow$f, `sqrt$f は実数に限り働くのか？
◎
Why does hypot() allow dimensions (values with units), but pow() and sqrt() only work on numbers?
</summary>

<p>
作者には、
`hypot(30px, 40px)^v の様な式を書くことは許容され， `50px^v に解決されるが、
`sqrt(pow(30px, 2) + pow(40px, 2))^v
の様な式を書くのは許容されない
— ほとんどの数学体系においては、
この 2 つは等価であるにもかかわらず。
◎
You are allowed to write expressions like hypot(30px, 40px), which resolves to 50px, but you aren’t allowed to write the expression sqrt(pow(30px, 2) + pow(40px, 2)), despite the two being equivalent in most mathematical systems.
</p>

<p>
これには 2 つの理由
— 指数における数量-精度, 作者の期待に沿わないこと —
がある。
◎
There are two reasons for this: numeric precision in the exponents, and clashing expectations from authors.
</p>

<p>
まず、
数量的な精度について。
`length$t の様な~CSS生成規則に`合致する$ためには、
`型$は［
その指数が正確に 1 に設定された単独の単位
］からなる必要がある。
`pow(pow(30px, 3), 1/3)^v
の様な式の結果は、
理論的には，正確に次のように得られるべきである：
まず、
~~内側の `pow(30px, 3)^v を［
`型$ «[ `length^l → 3 ]» （ `length^t の 3 乗）
］を伴う値 27000 に解決する。
次に、
`pow(~vA, 1/3)^v により，
値の三乗根をとって 30 に戻すとともに指数に 1/3 を乗算する。
結果の型は、
«[ `length^l → 1 ]» になり，
`length^t に`合致する$。
◎
First, numerical precision. For a type to match a CSS production like &lt;length&gt;, it needs to have a single unit with its exponent set to exactly 1. Theoretically, expressions like pow(pow(30px, 3), 1/3) should result in exactly that: the inner pow(30px, 3) would resolve to a value of 27000 with a type of «[ "length" → 3 ]» (aka &lt;length&gt;³), and then the pow(X, 1/3) would cube-root the value back down to 30 and multiply the exponent by 1/3, giving «[ "length" → 1 ]», which matches &lt;length&gt;.
</p>

<p>
上述は，［
純粋~数学においては仕事を成す
］ことは保証されるが、［
二進-浮動小数点~算術を利用している~computerの現実世界
］においては，［
冪乗が正確に~~相殺されずに無効な`~math関数$になる事例
］もある
— それは、
作者を惑わすことに加え，理由も追跡し難くなる。
（~JSの例で言えば、
`Math.pow(Math.pow(30, 10/3), .1+.1+.1)^c
を評価した結果は，正確には 30 にならない
— `.1+.1+.1^c が正確には 3 ~DIV 10 にならず、
`(10/3) * (.1+.1+.1)^c は 1 より`わずかに大きく^emなるので。）
◎
In the realm of pure mathematics, that’s guaranteed to work out; in the real-world of computers using binary floating-point arithmetic, in some cases the powers might not exactly cancel out, leaving you with an invalid math function for confusing, hard-to-track-down reasons. (For a JS example, evaluate Math.pow(Math.pow(30, 10/3), .1+.1+.1); the result is not exactly 30, because .1+.1+.1 is not exactly 3/10. Instead, (10/3) * (.1 + .1 + .1) is slightly greater than 1.)
</p>

<p>
［
値から単位を外した生の実数~上ですべての~mathを行ってから，最後に欲される単位に戻す
］よう作者に要求することは、
不便にはなるが，数的な精度は誰にとっても~~支障ないことを確保する：
`calc(pow(pow(30px / 1px, 3), 1/3) * 1px)^v
は `length$t に解決され， 30 にごく近くなることは保証される
— 実際には、
数量的な精度により冪乗を正確に~~相殺できず，正確には 30 ではなくとも。
◎
Requiring authors to cast their value down into a number, do all the math on the raw number, then finally send it back to the desired unit, while inconvenient, ensures that numerical precision won’t bite anyone: calc(pow(pow(30px / 1px, 3), 1/3) * 1px) is guaranteed to resolve to a &lt;length&gt;, with a value that, if not exactly 30, is at least very close to 30, even if numerical precision actually prevents the powers from exactly canceling.
</p>

<p>
次に，期待に沿わないことについて。
作者が［
`pow(30px, 2)^v の結果は
— 単位はそのままに数量的な値だけ二乗して —
`900px^v になる
］ものと期待することは，少なからずある
（ Sass における`この課題＠https://github.com/sass/sass/issues/684$など）。
しかしながら、
これは，［
結果が，引数をどの単位で表出しているかに依存する
］ことを意味する。
例えば `1em^v が `16px^v に等しい場合、
`pow(1em, 2)^v は `1em^v を与える一方で，
`pow(16px, 2)^v は `256px^v （ `16em^v ）を与える
— 入力~引数が一致するときに、
このような かけ離れた値が得られるべきではない。
~CSSにおいては，一般に［
値を`正準-単位$へ自由に~~換算する
］ことが許容されるので、
この類の入力への依存性は，~CSSにとって厄介の元になる。
それは、［
`pow(2em + 10px, 2)^v の様な，より複階的な式
］の解釈を困難にしてしまう。
◎
Second, clashing expectations. It’s not uncommon for authors to expect pow(30px, 2) to result in 900px (such as in this Sass issue); that is, just squaring the numerical value and leaving the unit alone. This, however, means the result is dependent on what unit you’re expressing the argument in; if 1em is 16px, then pow(1em, 2) would give 1em, while pow(16px, 2) would give 256px, or 16em, which are very different values for what should otherwise be identical input arguments! This sort of input dependency is troublesome for CSS, which generally allows values to be canonicalized freely; it also makes more complex expressions like pow(2em + 10px, 2) difficult to interpret.
</p>

<p>
戻って、
値から単位を外してから，再び欲される単位に戻すよう作者に要求すれば、
これらの課題から免れることになる。
`pow(30, 2)^v は `900^v になり、
作者は自身が望む何にでも解釈できる。
◎
Again, requiring authors to cast their value down into a number and then back up again into the desired unit sidesteps these issues; pow(30, 2) is indeed 900, and the author can interpret that however they wish.
</p>

<hr>

<p>
他方， `hypot$f は、
これらの問題には悩まされない
— 入力も出力もすべて同じ型であり、
その演算の資質に因り，結果はいずれにせよ単位に依存しないので、
単位における数量的な精度は懸念にならない。
`hypot(3em, 4em)^v,
`hypot(48px, 64px)^v
どちらも、
`1em^v が `16px^v に等しいときの結果は，
同じ長さ `5em^v ~EQ `80px^v になる。
したがって、
作者が `hypot()^v 内に直に次元を利用できるようにしてもかまわない。
◎
On the other hand, hypot() doesn’t suffer from these problems. Numerical precision in units isn’t a concern, as the inputs and output all have the same type. The result isn’t unit-dependent, either, due to the nature of the operation; hypot(3em, 4em) and hypot(48px, 64px) both result in the same length when 1em equals 16px: 5em or 80px. Thus it’s fine to let author use dimensions directly in hypot().
</p>

</details>

<p>
`log(~vA, ~vB?)@f
関数は：
◎
The log(A, B?) function＼
</p>
<ul>
	<li>
次を包含する
⇒＃
対数~化される値を表現する`計算式$ ~vA,
対数の底eを表現する省略可能な`計算式$ ~vB （省略時の既定は `e$v とする）
◎
contains one or two calculations (representing the value to be logarithmed, and the base of the logarithm, defaulting to e),＼
</li>
	<li>
~vA, ~vB は `number$t に解決されなければナラナイ。
◎
which must resolve to &lt;number&gt;s,＼
</li>
	<li>
~vB を底eとする ~vA の対数を `number$t として返す。
◎
and returns the logarithm base B of the value A, as a &lt;number&gt;＼
</li>
	<li>
<p>
その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ), 入力~計算式†の`型$ )
</p>

<p class="trans-note">【†
~vA, ~vB どちらを指すか指定されていない。
ここは、
`pow(~vA, ~vB)$f と同様に記されるべきに思われる。
】</p>
◎
with the return type made consistent with the input calculation’s type.
</li>
</ul>

<p>
`exp(~vA)@f
関数は：
◎
The exp(A) function＼
</p>
<ul>
	<li>
1 個の`計算式$ ~vA を包含する。
◎
contains one calculation＼
</li>
	<li>
~vA は `number$t に解決されなければナラナイ。
◎
which must resolve to a &lt;number&gt;,＼
</li>
	<li>
`pow(e, ~vA)$f と同じ値を `number$t として返す。
◎
and returns the same value as pow(e, A) as a &lt;number&gt;＼
</li>
	<li>
その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ), ~vA の`型$ )
◎
with the return type made consistent with the input calculation’s type.
</li>
</ul>

<div class="example">
<p>
`pow$f 関数は、
`CSS Modular Scale＠https://www.modularscale.com/$
の様な，~page上のすべての~font~sizeを互いに固定d比率で関係付ける方策に有用になり得る。
◎
The pow() function can be useful for strategies like CSS Modular Scale, which relates all the font-sizes on a page to each other by a fixed ratio.
</p>

<p>
これらの~sizeは、
次の様に~custom~propの中にも容易に書ける：
◎
These sizes can be easily written into custom properties like:
</p>

<pre class="lang-css">
:root {
  --h6: calc(1rem * pow(1.5, -1));
  --h5: calc(1rem * pow(1.5, 0));
  --h4: calc(1rem * pow(1.5, 1));
  --h3: calc(1rem * pow(1.5, 2));
  --h2: calc(1rem * pow(1.5, 3));
  --h1: calc(1rem * pow(1.5, 4));
}
</pre>

<p>
値を `5.0625rem^v （ `calc(1rem * pow(1.5, 4))^v を解決した結果）の様な
— 何に基づくのか~~不明瞭な —
予め計算-済みな実数に書き出すことなく。
◎
...rather than writing out the values in pre-calculated numbers like 5.0625rem (what calc(1rem * pow(1.5, 4)) resolves to) which have less clear provenance when encountered in a stylesheet.
</p>
</div>

<div class="example">
<p>
1 個の引数を伴う `hypot$f は、
入力の絶対~値を与える。
［
`hypot(2em)^v, `hypot(-2em)^v
］は、
どちらも `2em^v に解決される。
◎
With a single argument, hypot() gives the absolute value of its input; hypot(2em) and hypot(-2em) both resolve to 2em.
</p>

<p>
複数個の引数を伴う場合、［
各辺の長さが各~引数により与えられた多次元~box
］の対頂線の~sizeを与える。
これは、
変形に関係するものに有用になり得る
— それは、
特定0の (X, Y, Z ) 量だけ並進されたとき，
要素が実際に~~移動する距離を与える。
◎
With more arguments, it gives the size of the main diagonal of a box whose side lengths are given by the arguments. This can be useful for transform-related things, giving the distance that an element will actually travel when it’s translated by a particular X, Y, and Z amount.
</p>

<p>
例えば， `hypot(30px, 40px)^v は、
`50px^v に解決され，［
`translate(30px, 40px)^v により要素が並進されたとき，要素が~~実際に~~移動する距離
］を与える。
作者は、
元位置から離れるほど要素を小さくしたいと求めるなら
（例えば，何らかの類の `word cloud^en 【単語の “重み”（出現頻度など）を可視化する図】を描くとき），
この距離を拡縮ng係数の計算に利用することもできる。
◎
For example, hypot(30px, 40px) resolves to 50px, which is indeed the distance between an element’s starting and ending positions when it’s translated by a translate(30px, 40px) transform. If an author wanted elements to get smaller as they moved further away from their starting point (drawing some sort of word cloud, for example), they could then use this distance in their scaling factor calculations.
</p>
</div>

<div class="example">
<p>
引数を 1 個だけ伴う `log$f は、
その引数の “自然~対数” を供する
— 対数の底eは ~JSと同じ `e^i になる。
◎
With a single argument, log() provides the “natural log” of its argument, or the log base e, same as JavaScript.
</p>

<p>
代わりに，［
10 を底eとする対数（例：値の 10 進表記における桁数） ／
2 を底eとする対数（例：値を成す~bit数）
］を求めるなら、［
`log(~vA, 10)^v ／
`log(~vA, 2)^v
］が，それを供する。
◎
If one instead wants log base 10 (to, for example, count the number of digits in a value) or log base 2 (counting the number of bits in a value), log(X, 10) or log(X, 2) provide those values.
</p>
</div>

			<section id="exponent-infinities">
<h4 title="Argument Ranges">10.5.1. 引数の範囲</h4>

<p>
`pow(~vA, ~vB)$f
においては、
次が満たされるならば，結果は ~NaN になる
⇒
［
~vA は有限
］~AND［
~vB は有限
］~AND［
~vA ~LT 0
］~AND［
~vB は整数でない
］
◎
In pow(A, B), if A is negative and finite, and B is finite, B must be an integer, or else the result is NaN.
</p>

<p>
他の場合、
~vA, ~vB どちらかは［
±∞／ 0
］ならば，結果は次に挙げる 2 つの表tで与えられる：
◎
If A or B are infinite or 0, the following tables give the results:
</p>

<div>
<table class="math-matrix">
<caption>
上端見出しは ~vA,
左端見出しは ~vB
の値を表す。
</caption>
<thead>
<tr><td>
<th>−∞
<th>~0N
<th>~0P
<th>+∞
<tbody>

<tr><th>奇数（負）
<td>~0N
<td>−∞
<td>+∞
<td>~0P

<tr><th>偶数（負）
<td>~0P
<td>+∞
<td>+∞
<td>~0P

<tr><th>0
<td colspan="4">常に 1

<tr><th>奇数（正）
<td>−∞
<td>~0N
<td>~0P
<td>+∞

<tr><th>偶数（正）
<td>+∞
<td>~0P
<td>~0P
<td>+∞
</table>

◎
 ｜A is −∞｜A is 0⁻｜A is 0⁺｜A is +∞
B is −finite｜0⁻ if B is an odd integer, 0⁺ otherwise｜−∞ if B is an odd integer, +∞ otherwise｜+∞｜0⁺
B is 0｜always 1
B is +finite｜−∞ if B is an odd integer, +∞ otherwise｜0⁻ if B is an odd integer, 0⁺ otherwise｜0⁺｜+∞
</div>

<div>
<table class="math-matrix">
<caption>
上端見出しは ~vA,
左端見出しは ~vB
の値を表す。
</caption>
<thead>
<tr><td>
<th>~vA ~LT −1
<th>−1
<th>−1 ~LT ~vA ~LT 1
<th>1
<th>1 ~LT ~vA
<tbody>

<tr><th>+∞
<td>+∞
<td>~NaN
<td>~0P
<td>~NaN
<td>+∞

<tr><th>−∞
<td>~0P
<td>~NaN
<td>+∞
<td>~NaN
<td>~0P
</table>

◎
 ｜A is &lt; -1｜A is -1｜-1 &lt; A &lt; 1｜A is 1｜A is &gt; 1
B is +∞｜result is +∞｜result is NaN｜result is 0⁺｜result is NaN｜result is +∞
B is −∞｜result is 0⁺｜result is NaN｜result is +∞｜result is NaN｜result is 0⁺ 
</div>

<p>
`sqrt(~vA)$f においては
⇒＃
~vA ~EQ +∞ ならば，結果は +∞ になる／
~vA ~EQ ~0N ならば，結果は ~0N になる／
~vA ~LT 0 ならば，結果は ~NaN になる
◎
In sqrt(A), if A is +∞, the result is +∞. If A is 0⁻, the result is 0⁻. If A is less than 0, the result is NaN.
</p>

<p>
`hypot(…)$f においては
⇒
入力のいずれかがが ±∞ ならば，結果は +∞ になる
◎
In hypot(A, …), if any of the inputs are infinite, the result is +∞.
</p>

<p>
`log(~vA, ~vB)$f
においては：
◎
In log(A, B),＼
</p>

<ul>
	<li>
<p>
［
~vB ~EQ 1 ／
~vB ~LT 0
］ならば，結果は ~NaN になる。
</p>

<p class="note">注記：
［
0 ~LT ~vB ~LT 1 ／
~vB ~GT 1
］であっても妥当である。
【当然？ ／ ~vB ~EQ +∞ の場合の結果は？】
</p>
◎
if B is 1 or negative,
＜B values between 0 and 1, or greater than 1, are valid.＞
the result is NaN.＼
</li>
	<li>
他の場合
⇒＃
~vA ~LT 0 ならば，結果は ~NaN になる／
~vA ~IN { ~0P, ~0N } ならば，結果は −∞ になる／
~vA ~EQ 1 ならば，結果は ~0P になる／
~vA ~EQ +∞ ならば，結果は +∞ になる
◎
If A is negative, the result is NaN. If A is 0⁺ or 0⁻, the result is −∞. If A is 1, the result is 0⁺. If A is +∞, the result is +∞.
</li>
</ul>

<p>
`exp(~vA)$f
においては
⇒＃
~vA ~EQ +∞ ならば，結果は +∞ になる／
~vA ~EQ −∞ ならば，結果は ~0P になる
◎
In exp(A), if A is +∞, the result is +∞. If A is −∞, the result is 0⁺.
</p>

<p>
（`~math関数$が ~NaN, ±∞ 【, ~0N, ~0P】をどう取扱うかの詳細は、
`§ 型の検査-法$を見よ。）
◎
(See § 10.9 Type Checking for details on how math functions handle NaN and infinities.)
</p>

<div class="note">
<p>注記：
これらの関数の挙動はすべて、
ほとんどの~programming言語
— 特に~JS —
に実装されている “標準な” 定義に合致することが意図されている。
◎
All of these behaviors are intended to match the "standard" definitions of these functions as implemented by most programming languages, in particular as implemented in JS.
</p>

<p>
等価な~JS関数の挙動からの唯一の乖離は、
~NaN は `どの関数^emにおいても “伝染的” である
— すなわち，ある引数~計算の結果が ~NaN になる場合、
関数は ~NaN を返すよう強制する —
ことにある。
◎
The only divergences from the behavior of the equivalent JS functions are that NaN is "infectious" in every function, forcing the function to return NaN if any argument calculation is NaN.
</p>

<details>
<summary>
~JSの挙動の詳細
◎
Details of the JS Behavior
</summary>

<p>
~math関数に対応する~JS関数において、
~NaN が “伝染的” にならない事例は 2 つある
⇒＃
`Math.hypot(Infinity, NaN)^c は `Infinity^jv を返す／
`Math.pow(NaN, 0)^c は `1^jv を返す
◎
There are two cases in JS where a NaN is not "infectious" to the math function it finds itself in:
• Math.hypot(Infinity, NaN) will return Infinity.
• Math.pow(NaN, 0) will return 1.
</p>

<p>
ここでの~logicは、
`NaN^jv を `どの数に置換しようが^em，返り値は同じになる点にあると見受けられる。
しかしながら，この~logicは、
各種 `Math^c 関数に一貫して適用されてもいない：
`Math.max(Infinity, NaN)^c は， `Infinity^jv ではなく `NaN^jv を返すし、
`Math.min(-Infinity, NaN)^c も，同様になる。
◎
The logic appears to be that, if you replace the NaN with any Number, the return value will be the same. However, this logic is not applied consistently to the Math functions: Math.max(Infinity, NaN) returns NaN, not Infinity; the same is true of Math.min(-Infinity, NaN).
</p>

<p>
［
これは、
~~常用されない~error事例であること／
~JSは、
この点について一貫でないこと／
`計算式$における ~NaN の認識や取扱いは、
内部~math関数~内ではなく，どのみち より高~levelな~CSSにて行われると見込まれる
］ことから、
~CSSにおける一貫性の方が重要であるとして選ばれた。
なので、
すべての関数において， ~NaN は “伝染的” になるよう定義されている。
◎
Because this is an error corner case, JS isn’t consistent on the matter, and NaN recognition/handling of calculations is likely done at a higher CSS level rather than in the internal math functions anyway, consistency in CSS was chosen to be more important, so all functions were defined to have "infectious" NaN.
</p>
</details>
</div>

			</section>
		</section>
		<section id="sign-funcs">
<h3 title="Sign-Related Functions: abs(), sign()">10.6. 正負に関係する関数： `abs^f, `sign^f</h3>

<p>
正負に関係する関数
— `abs$f, `sign$f —
は、
引数の正負に関係する関数を算出する。
◎
The sign-related functions—abs() and sign()—compute various functions related to the sign of their argument.
</p>

<p>
`abs(~vA)@f
関数は：
◎
The abs(A) function＼
</p>
<ul>
	<li>
1 個の`計算式$ ~vA を包含する。
◎
contains one calculation A,＼
</li>
	<li>
~vA の絶対~値を ~vA と同じ`型$の値として返す
— 結果の数量-値は、
~vA の数量-値に応じて
⇒＃
~0P または正ならば そのまま ~vA になる／
~0N または負ならば −1 ~MUL ~vA になる
◎
and returns the absolute value of A, as the same type as the input:＼
if A’s numeric value is positive or 0⁺, just A again; otherwise -1 * A.
</li>
</ul>

<p>
`sign(~vA)@f
関数は：
◎
The sign(A) function＼
</p>
<ul>
	<li>
1 個の`計算式$ ~vA を包含する。
◎
contains one calculation A,＼
</li>
	<li>
~vA の数量-値に応じて次を返す
⇒＃
負ならば −1 ／
正ならば +1 ／
~0P ならば ~0P ／
~0N ならば ~0N
◎
and returns -1 if A’s numeric value is negative, +1 if A’s numeric value is positive, 0⁺ if A’s numeric value is 0⁺, and 0⁻ if A’s numeric value is 0⁻.＼
</li>
	<li>
その`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ) , ~vA の`型$ )
◎
The return type is a &lt;number&gt;, made consistent with the input calculation’s type.
</li>
</ul>

<p class="note">注記：
どちらの関数も、［
引数を全部的に単純~化して解決した結果
］に対し演算する。
それは、
一目では直感的でない結果を与えることもある。
特に， `10%^v の様な式を解決した結果は、
式がどの値を~~基準に解決されるかに依存して，`正にも負にも^emなり得る。
例えば， `background-position$p においては、
背景~画像が背景~区画より大きい場合には，正な百分率は負な長さに
（逆に，負な百分率は正な長さに）
解決される。
したがって `sign(10%)$f は、
百分率がどう解決されるかに依存して，［
`1^v, `-1^v
］`どちらも返し得る^em
（長さ 0 を~~基準に解決される場合、
`0^v にもなる）。
◎
Note: Both of these functions operate on the fully simplified/resolved form of their arguments, which may give unintuitive results at first glance. In particular, an expression like 10% might be positive or negative once it’s resolved, depending on what value it’s resolved against. For example, in background-position positive percentages resolve to a negative length, and vice versa, if the background image is larger than the background area. Thus sign(10%) might return 1 or -1, depending on how the percentage is resolved! (Or even 0, if it’s resolved against a zero length.)
</p>

		</section>
		<section id="calc-keywords">
<h3 title="Numeric Keywords">10.7. 数量-~keyword</h3>

<p>
`計算式$内の~keywordは、
~literalとして表現するのが［
困難／不可能
］な値への~accessを供する。
各~keywordは、［
その値,
その`型を決定-$した結果,
いつ解決し得るか
］を定義する。
◎
Keywords in calculations provide access to values that are difficult or impossible to represent as literals. Each keyword defines its value, its type, and when it can be resolved.
</p>

			<section id="calc-constants">
<h4 title="Numeric Constants: e, pi">10.7.1. 数量-定数： `e^v, `pi^v</h4>

<p>
［
三角-関数／指数-関数
］は，多くの複階的な数量-演算を取扱うが、
計算式を適度にまとめる手間を要することに加え，
`e^i や `π^i などの周知な定数を含むことも多い。
◎
While the trigonometric and exponential functions handle many complex numeric operations, some reasonable calculations must be put together more manually, and many times these include well-known constants, such as e and π.
</p>

<p>
作者が これらの定数を成す一連の数字を手で打ち込まずに済むよう、
少数の定数は直に供される：
◎
Rather than require authors to manually type out several digits of these constants, a few of them are provided directly:
</p>

<dl class="val-def">
	<dt>`e@v</dt>
	<dd>
自然~対数の底eを表す。
約 2.7182818284590452354 。
◎
the base of the natural logarithm, approximately equal to 2.7182818284590452354.
</dd>

	<dt>`pi@v</dt>
	<dd>
円周率を表す。
約 3.1415926535897932 。
◎
the ratio of a circle’s circumference to its diameter, approximately equal to 3.1415926535897932.
</dd>
</dl>

<p>
これらの~keywordは、
いずれも `number$t であり，
構文解析-時点に解決される。
◎
Both of these keywords are &lt;number&gt;s, and resolve at parse time.
</p>

<p class="note">注記：
これらの~keywordが利用-可能になるのは、
`calc(pow(e, pi) - pi)^v や `min(pi, 5, e)^v
など，`計算式$の中に限られる。
計算式の外側で利用された場合、
他の~keywordと同様に扱われる：
`animation-name:pi^p は、
名前 `pi^l の~animationを指す。
`line-height:e^p は、
無効になる
（ `line-height:2.7^p に類似な何かにはならない
— `line-height:calc(e)^p と記す必要がある）。
◎
Note: These keywords are only usable within a calculation, such as calc(pow(e, pi) - pi), or min(pi, 5, e). If used outside of a calculation, they’re treated like any other keyword: animation-name: pi; refers to an animation named "pi"; line-height: e; is invalid (not similar to line-height: 2.7, but line-height: calc(e); is).
</p>

			</section>
			<section id="calc-error-constants">
<h4 title="Degenerate Numeric Constants: infinity, -infinity, NaN">10.7.2. 退化な値を表す数量-定数： `infinity^v, `-infinity^v, `NaN^v</h4>

<p>
`計算式$や その下位treeの結果が［
`無限大$【！infinite】／`~NaN$
］になるとき，もはや数量-値で表現することはアリでなくなる。
これら退化な値の直列化を援助するため、
追加的な~math定数として，次に挙げるものが定義される：
◎
When a calculation or a subtree of a calculation becomes infinite or NaN, representing it with a numeric value is no longer possible. To aid in serialization of these degenerate values, the following additional math constants are defined:
</p>

<dl class="valdef">
	<dt>`infinity@v</dt>
	<dd>
正な無限大（ +∞ ）を表す。
◎
infinity

the value positive infinity (+∞)
</dd>

	<dt>`-infinity@v</dt>
	<dd>
負な無限大（ −∞ ）を表す。
◎
-infinity

the value negative infinity (−∞)
</dd>

	<dt>`NaN@v</dt>
	<dd>
~NaN を表す。
◎
the value NaN
</dd>
</dl>

<p>
これらの~keywordは、
いずれも `number$t であり，
構文解析-時点に解決される。
◎
All of these keywords are &lt;number&gt;s, and resolve at parse time.
</p>

<p>
これらは、
通例の~CSS~keywordと同じく，`~ASCII大小無視$である。
<span class="note">
したがって， `calc(InFiNiTy)^v も まったく妥当である。
</span>
しかしながら， `NaN$v は、
この正準的な大小法で直列化するモノトスル。
◎
As usual for CSS keywords, these are ASCII case-insensitive. Thus, calc(InFiNiTy) is perfectly valid. However, NaN must be serialized with this canonical casing.
</p>

<p class="note">注記：
これらの~keywordは `number$t なので、
無限な長さを取得するためには，
例えば `calc(infinity * 1px)^v の様な式が要求される。
◎
Note: As these keywords are &lt;number&gt;s, to get an infinite length, for example, requires an expression like calc(infinity * 1px).
</p>

<p class="note">注記：
これらの定数は、
`主として^em［
無限大【！infinite】／~NaN
］の直列化をもっと単純かつ明白にするために定義されているが、
“アリな最も大きい値”
を指示するためにも`利用できる^em
— 無限大【！infinite value】は、
許容される範囲に切詰められることになるので。
これが~~適するのは稀であるが、
`infinity$v を利用すれば，~stylesheetに何桁もの数をただ記すより意図は明瞭になる。
◎
Note: These constants are defined mostly to make serialization of infinite/NaN values simpler and more obvious, but can be used to indicate a "largest possible value", since an infinite value gets clamped to the allowed range. It’s rare for this to be reasonable, but when it is, using infinity is clearer in its intent than just putting an enormous number in one’s stylesheet.
</p>

			</section>
			<section id="calc-variables">
<h4 title="Numeric Variables">10.7.3. 数量-変数</h4>


<p>
他の仕様は、
ある種の文脈において`計算式$内で利用-可能な~keywordを追加的に定義し得る。
例えば、
`相対~色~構文$は，色~channel~keywordをいくつか定義する
— それらは、
各~色~channelの値を `number$t として表現する。
◎
Other specifications can define additional keywords which are usable in calculations in certain contexts. For example, relative color syntax defines a number of color-channel keywords representing the value of each color channel as a &lt;number&gt;.
</p>

<p>
そのような~keywordを定義している各~仕様は、
各~keyword用に次に挙げるものを定義しなければナラナイ：
◎
Each specifications defining such keywords must define for each keyword:
</p>

<ul>
	<li>
その値
◎
its value
</li>
	<li>
その`型を決定-$した結果
（ `number$t, `length$t, 等々）
◎
its type (&lt;number&gt;, &lt;length&gt;, etc)
</li>
	<li>
それは，いつ解決されるか
（構文解析-時点／算出d値の時点／使用~値の時点）
◎
when it resolves (parse time, computed-value time, or used-value time)
</li>
</ul>

			</section>
		</section>
		<section id="calc-syntax">
<h3 title="Syntax">10.8. 構文</h3>

<p>
`~math関数$の構文は：
◎
The syntax of a math function is:
</p>

<pre class="prod">
`calc()$t
	= calc( `calc-sum$t )
`min()$t
	= min( `calc-sum$t# )
`max()$t
	= max( `calc-sum$t# )
`clamp()$t
	= clamp( `calc-sum$t#{3} )
`round()$t
	= round( `rounding-strategy$t?, `calc-sum$t, `calc-sum$t? )
`mod()$t
	= mod( `calc-sum$t, `calc-sum$t )
`rem()$t
	= rem( `calc-sum$t, `calc-sum$t )
`sin()$t
	= sin( `calc-sum$t )
`cos()$t
	= cos( `calc-sum$t )
`tan()$t
	= tan( `calc-sum$t )
`asin()$t
	= asin( `calc-sum$t )
`acos()$t
	= acos( `calc-sum$t )
`atan()$t
	= atan( `calc-sum$t )
`atan2()$t
	= atan2( `calc-sum$t, `calc-sum$t )
`pow()$t
	= pow( `calc-sum$t, `calc-sum$t )
`sqrt()$t
	= sqrt( `calc-sum$t )
`hypot()$t
	= hypot( `calc-sum$t# )
`log()$t
	= log( `calc-sum$t, `calc-sum$t? )
`exp()$t
	= exp( `calc-sum$t )
`abs()$t
	= abs( `calc-sum$t )
`sign()$t
	= sign( `calc-sum$t )
`calc-sum@t
	= `calc-product$t [ [ '+' | '-' ] `calc-product$t ]*
`calc-product@t
	= `calc-value$t [ [ '*' | / ] `calc-value$t ]*
`calc-value@t
	= `number$t
	| `dimension$t
	| `percentage$t
	| `calc-keyword$t
	| ( `calc-sum$t )
`calc-keyword@t
	= `e$v
	| `pi$v
	| `infinity$v
	| `-infinity$v
	| `NaN$v
`rounding-strategy$t
	= `nearest$v
	| `up$v
	| `down$v
	| `to-zero$v
</pre>

<p>
一部の文脈では、
追加的な `calc-keyword$t 値も妥当になるものと定義され得る。
（例えば、
`相対~色~構文$においては，適切な~channel~keywordが許容される。）
◎
In some contexts, additional &lt;calc-keyword&gt; values can be defined to be valid. (For example, in relative color syntax, appropriate channel keywords are allowed.)
</p>

<p>
加えて、
演算子［
`+^css ／ `-^css
］の両側には`空白$が要求される（演算子［
`*^css ／ `/^css
］の両側には要求されない）。
◎
In addition, whitespace is required on both sides of the + and - operators. (The * and / operators can be used without white space around them.)
</p>

<p class="trans-note">【
例えば `5 -5^v は、
2 個の実数~token並びとして構文解析され，引数として妥当でなくなる。
一方で `5*5^v は、
`*^css も含む 3 個の~token並びとして構文解析され，引数として妥当になる。
】</p>

<p>
上に挙げた~math関数のうちいくつかには、
`calc-sum$t 引数が包含し得るものに追加的な拘束がある。
詳細は、
個々の関数の定義を見よ。
◎
Several of the math functions above have additional constraints on what their &lt;calc-sum&gt; arguments can contain. Check the definitions of the individual functions for details.
</p>

<p>
~UAは、［
`計算式$を成す `calc-value$t 項として 32 個以上，
`計算式$における入子ng（丸括弧／関数）として 32 ~level以上
］は，~supportするモノトスル。
また，任意個数の引数を~supportする関数（ `min$f など）に対しては、
引数として 32 個以上は，~supportするモノトスル。
自身が~supportする数を超える［
項／引数／入子ng
］を包含している`計算式$は、
無効であったかのように扱うモノトスル。
◎
UAs must support calculations of at least 32 &lt;calc-value&gt; terms and at least 32 levels of nesting (parentheses and/or functions). For functions that support an arbitrary number of arguments (such as min()), it must also support at least 32 arguments. If a calculation contains more than the supported number of terms, arguments, or nesting it must be treated as if it were invalid.
</p>

		</section>
		<section id="calc-type-checking">
<h3 title="Type Checking">10.9. 型の検査-法</h3>

<p>
`~math関数$にアリな型
— `length$t, `number$t, 等々 —
には、
それが包含する`計算式$に依存して，下に定義されるように いくつもある。
~math関数は、
その型の値が許容される どこでも利用できる。
◎
A math function can be many possible types, such as &lt;length&gt;, &lt;number&gt;, etc., depending on the calculations it contains, as defined below. It can be used anywhere a value of that type is allowed.
</p>

<p class="example">
例えば， `width$p ~propは `length$t 値を受容するので、
`length$t に解決される`~math関数$
— `calc(5px + 1em)^v など —
は， `width^p に利用できる。
◎
For example, the width property accepts &lt;length&gt; values, so a math function that resolves to a &lt;length&gt;, such as calc(5px + 1em), can be used in width.
</p>

<p>
加えて， `number$t に解決される`~math関数$は、
`integer$t のみを受容する どこでも利用できる
— 値は、
解決されるに伴い，`最も近い整数に丸められ$る。
◎
Additionally, math functions that resolve to &lt;number&gt; can be used in any place that only accepts &lt;integer&gt;; the value is rounded to the nearest integer as it resolves.
</p>

<p>
演算子をとる下位式からは、
その引数に基づいて型が得られる。
◎
Operators form sub-expressions, which gain types based on their arguments.
</p>

<p class="note">注記：
この仕様の以前までの~versionでは、［
乗算／除算
］がとれる引数は制限されていた
— 複階的な中間-結果（ `1px * 1em^v の次元は `length$t の 2 乗になるなど）が生産されるのを避けるため ／
0 による除算を構文解析-時に検出-可能にするため。
この~versionでは、
その制約は緩められる。
◎
Note: In previous versions of this specification, multiplication and division were limited in what arguments they could take, to avoid producing more complex intermediate results (such as 1px * 1em, which is &lt;length&gt;²) and to make division-by-zero detectable at parse time. This version now relaxes those restrictions.
</p>

<p>
`計算式$は、
どこに配置されたかに依存して，何らかの “文脈” の下で評価される。
文脈は、［
単位がどう解決されるか, 百分率がどう扱われるか, 等々
］を決定する。
この文脈は、
既定では，当の計算式を利用している［
~prop／記述子／等々
］により定義される。
各~関数は、
それが包含している値~用に他と異なる文脈を定義し得る
（例えば， `media-progress$f は、
自身の`計算式$を それが言及する`媒体~特能$の文脈において評価する）。
`計算式~tree$の中へ直に入子にされた`~math関数$は、
常に，その根を成す`~math関数$の文脈を利用する
— なので、
当の計算式~treeは，全体が一貫する。
◎
Calculations are evaluated in terms of some "context", depending on where they are placed, which determines how units are resolved, how percentages are treated, etc. By default, this context is defined by the property/descriptor/etc that the calculation is being used in. Functions can define a different context for their contained values. (For example, media-progress() evaluates its calculations in the context of the media feature it mentions.) Directly nested math functions (forming a larger calculation tree) always use the context of their top-most math function, so the entire calculation tree is consistent.
</p>

<div class="algo">
<p>
`計算式$の
`型を決定する@
~algoは、
以下に従う
— 以下において，`型$を得る演算の結果が `失敗^i になった場合、
`計算式$の型は `失敗^i になるとする：
◎
To determine the type of a calculation:
</p>
<ul>
	<li>
［
`+^css ／ `-^css
］が成す下位式の`型$は、
次の結果で与えられる
⇒
`型を加算する$( 左側の引数の`型$, 右側の引数の`型$ )
◎
At a + or - sub-expression, attempt to add the types of the left and right arguments. If this returns failure, the entire calculation’s type is failure. Otherwise, the sub-expression’s type is the returned type.
</li>
	<li>
`*^css が成す下位式の`型$は、
次の結果で与えられる
⇒
`型を乗算する$( 左側の引数の`型$, 右側の引数の`型$ )
◎
At a * sub-expression, multiply the types of the left and right arguments. The sub-expression’s type is the returned result.
</li>
	<li>
`/^css が成す下位式の`型$は、
次の結果で与えられる
⇒
`型を乗算する$( 左側の引数の`型$, `型を逆数にする$( 右側の引数の`型$ ) )
◎
At a / sub-expression, let left type be the result of finding the types of its left argument, and right type be the result of finding the types of its right argument and then inverting it.
◎
The sub-expression’s type is the result of multiplying the left type and right type.
</li>
	<li>
<p>
他のものは末端~値であり，その`型$は、
次に従って決定される
（他が指定されない限り，その`百分率-~hint$は ~NULL になる）：
</p>
		<ol>
			<li>
<p>
~IF［
%値 は `calc-keyword$t である
］
⇒
~RET 当の~keywordに定義されたとおりの`型$
</p>

<p class="trans-note">【
現時点では、
どの~keywordも `number$t 型なので `number$t の場合と同じ結果を返すことになるが，
将来には他の`型$に解決される~keywordが追加されるかもしれない。
】</p>
			</li>
			<li>
%単位 ~LET %値 に応じて
⇒＃
`percentage$t ならば `percent^l ／
`number$t ならば `number^l ／
~ELSE_（ `dimension$t である） %値 の単位
</li>
			<li>
%型 ~LET `型を作成する$( %単位 )
</li>
			<li>
<p>
~IF［
%単位 ~EQ `percent^l
］：
</p>
				<ol>
					<li>
~IF［
%値 は［
この`計算式$を包含している`~math関数$が置かれた文脈
］において［
`number$t 以外の別の型の値
］に相対的に解決される
（例： `width$p における `percentage$t は、
ある `length$t を~~基準に解決される）
］
⇒
%型 ~SET `百分率-~hintを適用する$( %型, 別の型の単位に`対応する基底~型$ )
【！the type is determined as the other type, but with a percent hint set to that other type.】
</li>
					<li>
~ELSE
⇒
%型 の`百分率-~hint$ ~SET `percent^l
</li>
				</ol>
			</li>
			<li>
~RET %型
</li>
		</ol>
◎
Anything else is a terminal value, whose type is determined based on its CSS type. (Unless otherwise specified, the type’s associated percent hint is null.)
◎
&lt;number&gt;
&lt;integer&gt;
• the type is «[ ]» (empty map)
&lt;length&gt;
• the type is «[ "length" → 1 ]»
&lt;angle&gt;
• the type is «[ "angle" → 1 ]»
&lt;time&gt;
• the type is «[ "time" → 1 ]»
&lt;frequency&gt;
• the type is «[ "frequency" → 1 ]»
&lt;resolution&gt;
• the type is «[ "resolution" → 1 ]»
&lt;flex&gt;
• the type is «[ "flex" → 1 ]»
&lt;calc-keyword&gt;
• the type is as defined by the keyword
&lt;percentage&gt;
• If, in the context in which the math function containing this calculation is placed, &lt;percentage&gt;s are resolved relative to another type of value (such as in width, where &lt;percentage&gt; is resolved against a &lt;length&gt;), and that other type is not &lt;number&gt;, the type is determined as the other type, but with a percent hint set to that other type.
• Otherwise, the type is «[ "percent" → 1 ]», with a percent hint of "percent".
anything else
• The calculation’s type is failure.
</li>
</ul>
</div>

<div class="algo">
所与の値は
`百分率を包含して@
いるとは、
その`型$ %型 が次を満たすことをいう
⇒
［
%型 の`百分率-~hint$ ~NEQ ~NULL
］~OR［
%型 は `percentage$t に`合致する$【！is «[ "percent" → 1 ]»】
］
◎
A value contains a percentage if its type is type is «[ "percent" → 1 ]», or its type’s percent hint is non-null.
</div>

<div class="algo">
<p>
所与の複数個の`計算式$ %計算式たち が
`一貫した型を有して@
いるとは、［
次の結果 ~NEQ `失敗^i
］になることをいう
— 結果の`型$を指して， %計算式たち の
`一貫した型@
という：
</p>
<ol>
	<li>
%型~群 ~LET 新たな`~list$
</li>
	<li>
<p>
%計算式たち を成す
~EACH( %計算式 )
に対し：
</p>
		<ol>
			<li>
%型 ~LET %計算式 の`型を決定する$
</li>
			<li>
~IF［
%型 ~EQ `失敗^i
］
⇒
~RET `失敗^i
</li>
			<li>
%型~群 に %型 を`付加する$
</li>
		</ol>
	</li>
	<li>
~RET `型を加算する$( %型~群 )
</li>
</ol>

<p class="trans-note">【
原文では，ずっと短い記述で済ませているが、
この訳では，もっと厳密に述べる。
】【
原文では，
“一貫した型を有して” を “一貫した型” と同じ用語として定義しているが、
この訳では，これらを区別する。
】</p>
◎
Two or more calculations have a consistent type if adding the types doesn’t result in failure. The consistent type is the result of the type addition.
</div>

<div class="algo">
<p>
`型を入力と一貫させる@
~algoは、
所与の
( `型$ %基底, `型$ %入力 )
に対し：
◎
To make a type base consistent with another type input:
</p>
<ol>
	<li>
~IF［
%基底 の`百分率-~hint$ ~NEQ ~NULL
］~AND［
%入力 の`百分率-~hint$ ~NEQ ~NULL
］~AND［
%基底 の`百分率-~hint$ ~NEQ %入力 の`百分率-~hint$
］
⇒
~RET `失敗^i
◎
If both base and input have different non-null percent hints, they can’t be made consistent. Return failure.
</li>
	<li>
~IF［
%基底 の`百分率-~hint$ ~NEQ ~NULL
］
⇒
%基底 の`百分率-~hint$ ~SET %入力 の`百分率-~hint$
◎
If base has a null percent hint set base’s percent hint to input’s percent hint.
</li>
	<li>
~RET %基底
◎
Return base.
</li>
</ol>
</div>

<div class="algo">
<p>
`~math関数$自身も、
関数に応じて，それが包含する`計算式$に則って決定される`型$を持つ：
◎
Math functions themselves have types, according to their contained calculations:
</p>

<dl class="switch">
	<dt>`calc$f</dt>
	<dt>`abs$f</dt>
	<dd>
包含する`計算式$の`型$
◎
The type of its contained calculation.
</dd>

	<dt>`min$f</dt>
	<dt>`max$f</dt>
	<dt>`clamp$f</dt>
	<dt>`hypot$f</dt>
	<dt>`round$f</dt>
	<dt>`mod$f</dt>
	<dt>`rem$f</dt>
	<dd>
`型を加算する$( ~commaで分離された各`計算式$からなる~list )
◎
The result of adding the types of its comma-separated calculations.
</dd>

	<dt>`asin$f</dt>
	<dt>`acos$f</dt>
	<dt>`atan$f</dt>
	<dt>`atan2$f</dt>
	<dd>
`型を作成する$( "`deg$u" )
【！«[ `angle^l → 1 ]»】
◎
«[ "angle" → 1 ]».
</dd>

	<dt>`sign$f</dt>
	<dt>`sin$f</dt>
	<dt>`cos$f</dt>
	<dt>`tan$f</dt>
	<dt>`pow$f</dt>
	<dt>`sqrt$f</dt>
	<dt>`log$f</dt>
	<dt>`exp$f</dt>
	<dd>
`型を作成する$( `number^l )
【！«[ ]» （空な~map）】
◎
«[ ]» (empty map).
</dd>
</dl>

<p>
上の各~項において，結果の`型$が失敗になる場合、
当の`~math関数$は無効になるとする。
◎
For each of the above, if the type is failure, the math function is invalid.
</p>
</div>

<p>
`~math関数$は、
その`型$が［
`number$t ／ `length$t ／ `angle$t ／ `time$t ／ `frequency$t ／ `resolution$t ／ `flex$t ／ `percentage$t
］のうち どの生成規則に`合致する$かに則って，
合致したものが表す型に解決される
（この分類は相互排他的である）。
どれにも合致しない場合、
当の`~math関数$は無効になる。
◎
A math function resolves to &lt;number&gt;, &lt;length&gt;, &lt;angle&gt;, &lt;time&gt;, &lt;frequency&gt;, &lt;resolution&gt;, &lt;flex&gt;, or &lt;percentage&gt; according to which of those productions its type matches. (These categories are mutually exclusive.) If it can’t match any of these, the math function is invalid.
</p>

<p class="note">注記：
`~math関数$やそれが解決される型の妥当性は、
代数的な単純~化により影響されることはない。
例えば，
`calc(5px - 5px + 10s)^v
や
`calc(0 * 5px + 10s)^v
は、
いずれも長さと時間を加算しようと試みるので，無効になる。
◎
Note: Algebraic simplifications do not affect the validity of a math function or its resolved type. For example, calc(5px - 5px + 10s) and calc(0 * 5px + 10s) are both invalid due to the attempt to add a length and a time.
</p>

<p class="note">注記：
`number$t に相対的な `percentage$t 
（例： `opacity$p におけるそれ）は、
`number$t と組合できないことに注意
（例： `opacity: calc(.25 + 25%)^p は妥当でない）。
これを許容すると，
“単位~代数”
（ `dimension$t の乗算や除算を許容するための代数）
に有意な問題をもたらすので。
どの事例においても，それが新たな機能性を供することはない
（例えば、
`opacity:25%^p は `opacity:.25^p に一致する
— それは自明な構文~変形に過ぎない）。
それでも、
他の演算は遂行できる
— 例えば
`opacity:calc(100% / 3)^p
は妥当になる。
◎
Note: Note that &lt;percentage&gt;s relative to &lt;number&gt;s, such as in opacity, are not combinable with those numbers—opacity: calc(.25 + 25%) is invalid. Allowing this causes significant problems with "unit algebra" (allowing multiplication/division of &lt;dimension&gt;s), and in every case so far, doesn’t provide any new functionality. (For example, opacity: 25% is identical to opacity: .25; it’s just a trivial syntax transform.) You can still perform other operations with them, such as opacity: calc(100% / 3);, which is valid.
</p>

<p class="note">注記：
`number-token$t は，常に［
`number$t, `integer$t
］どちらかに解釈されるので、
`~math関数$内では `length$t を意図する単位なしの `0^v は~supportされない。
すなわち、
`width:0^p や `width:5px^p は妥当であっても，
`width:calc(0 + 5px)^p は妥当でない
— `number$t と `length$t を加算しようと試行するので。
◎
Note: Because &lt;number-token&gt;s are always interpreted as &lt;number&gt;s or &lt;integer&gt;s, "unitless 0" &lt;length&gt;s aren’t supported in math functions. That is, width: calc(0 + 5px); is invalid, because it’s trying to add a &lt;number&gt; to a &lt;length&gt;, even though both width: 0; and width: 5px; are valid.
</p>

<p class="note">注記：
~propには［
裸の `number$t が使用~値の時点で `length$t になるもの
］も少数あるが
（特定的には， `line-height$p, `tab-size$p ）、
`number$t は， `calc$f 内では
— 決して “長さの様なもの” にはならず —
常に `number$t であり続ける。
◎
Note: Although there are a few properties in which a bare &lt;number&gt; becomes a &lt;length&gt; at used-value time (specifically, line-height and tab-size), &lt;number&gt;s never become "length-like" in calc(). They always stay as &lt;number&gt;s.
</p>

<p class="note">注記：
過去互換~mode `QUIRKS$r においては、
通常は `length$t しか受容しない一部の~propは，
`number$t も受容して それらを `px$u 長さとして解釈するものと定義される。
単位なしの `0^v の様に、
これには`~math関数$の［
構文解析／挙動
］に対する効果は無い
— `number^t 値に解決される`~math関数$は、
過去互換~modeにおいては妥当になる
（その結果は `px^u 長さとして解釈される）
かもしれないが。
◎
Note: In Quirks Mode [QUIRKS], some properties that would normally only accept &lt;length&gt;s are defined to also accept &lt;number&gt;s, interpreting them as px lengths. Like unitless zeroes, this has no effect on the parsing or behavior of math functions, though a math function that resolves to a &lt;number&gt; value might become valid in Quirks Mode (and have its result interpreted as a px length).
</p>

			<section id="calc-ieee">
<h4 title="Infinities, NaN, and Signed Zero">10.9.1. 無限大, ~NaN, 有符号 0</h4>

<p>
`~math関数$は、
~IEEE-754の意味論に従う
— すなわち、
次に挙げる概念が認識される
⇒＃
正な 0,
負な 0,
正な無限大,
負な無限大,
~NaN（ `not a number^en ）。
◎
Math functions follow IEEE-754 semantics, which means they recognize the concepts of positive and negative zero, positive and negative infinity, and NaN (not a number).
</p>

<p>
しかしながら、
これらの概念が維持されるのは，`計算式~tree$の中に限られる。
`~top-levelの計算式@
— 別の`~math関数$の内側に直に入子にされてない`~math関数$ —
の結果が，これら特別な値いずれかになった場合、
以下に定義されるとおり，表現-可能な標準な値に “同化される” 。
◎
However, these concepts are only retained within a calculation tree; if a top-level calculation (a math function not nested directly inside of another math function) would result in one of these special values, they’re instead "censored" into a standard representable value, as defined below.
</p>

<p>
`有符号 0@
（ `signed zero^en ）
— ここでは、［
~0P ／ ~0N
］として指示される —
は、
~CSS内では直に記せない。
［
`0^v, `+0^v, `-0^v
］は、
いずれも標準な “無符号” 0 を生産する
— それらは、
これらの規則の目的においては
【言い換えれば，`~math関数$の中で記されたとしても】，
~0P と見なされる。
◎
Signed zeros (indicated here as 0⁺ or 0⁻) can not be written directly in CSS; 0, +0 and -0 all produce the standard "unsigned" zero, which is considered positive (0⁺) for the purposes of these rules.
</p>

<p>
`有符号 0$ は、
次に挙げる仕方で生産される：
◎
Signed zeroes are produced in the following ways:
</p>
<ul>
	<li>
［
~0N と ~0N を加算する／
~0N から ~0P を減算する
］演算は、
~0N を生産する
— 0 を生産する他の［
加算／減算
］は、
すべて ~0P を生産する。
◎
↓</li>
	<li>
<p>
［
何かと 0 を乗算する／
0 を何かで除算する／
何かを ±∞ で除算する
］演算は、
`~NaN$ を生産する場合を除き，
0 を生産する。
そのような演算は、［
引数のうち片方だけが［
負な値 ／ ~0N ／ −∞
］であるならば ~0N ／
~ELSE_ ~0P
］を生産する。
</p>

<p>
（例： `-5 * 0^v や `1 / -infinity^v は、
~0N を生産する。）
</p>

<p>
［
正な値 ／ 負な値
］を ~0N で除算するときは、［
−∞ ／ +∞
］を生産する。
</p>

<p>
（言い換えれば、
`有符号 0$ や`無限大$を引数にとる［
乗算／除算
］は，標準な符号n規則に従う。）
</p>

◎
Negative zero (0⁻) can be produced by a multiplication or division that produces zero with exactly one negative argument (such as -5 * 0 or 1 / -infinity).
◎
↑ 0⁻ + 0⁻ or 0⁻ - 0⁺ produces 0⁻. All other additions or subtractions that would produce a zero produce 0⁺.
◎
Multiplying or dividing 0⁻ with a positive number (including 0⁺) produces a negative result (either 0⁻ or −∞), while multiplying or dividing 0⁻ with a negative number produces a positive result.
◎
(In other words, multiplying or dividing with 0⁻ follows standard sign rules.)
</li>
	<li>
~0P と ~0N を比較するときは、
~0N ~LT ~0P
になるとする。
例えば，［
`min(~0P, ~0N)^v ／ `max(~0P, ~0N)^v ／ `clamp(~0P, ~0N, 1)^v
］は、［
~0N ／ ~0P ／ ~0P
］を生産する【！must】。
◎
When comparing 0⁺ and 0⁻, 0⁻ is less than 0⁺. For example, min(0⁺, 0⁻) must produce 0⁻, max(0⁺, 0⁻) must produce 0⁺, and clamp(0⁺, 0⁻, 1) must produce 0⁺.
</li>
	<li>
`~math関数$における，ある種の引数の組合nは、
~0N を生産するものと定義される
（例： `round(-1, infinity)^v ）。
他の演算のうち 0 を生産するものは、
すべて ~0P を生産する。
◎
Certain argument combinations in math functions are defined to produce 0⁻ (for example, round(-1, infinity)). All other operations that produce a zero produce positive zero (0⁺).
</li>
</ul>

<p>
`有符号 0$ は、
`~top-levelの計算式$から外へ~~漏れない
— それらは、
“無符号” 0 に同化される。
◎
Signed zeroes do not escape a top-level calculation; they’re censored into the "unsigned" zero.
</p>

<p>
`無限大@
（ `infinity^en ）
— ここでは、［
+∞ ／ −∞
］として【または総称的に ±∞ として】指示される —
は、
`~math定数＠#calc-error-constants$［
`infinity$v ／ `-infinity$v
］を利用して直に記せる。
また、
以下に挙げる計算の結果として生産される：
◎
Infinities (indicated here as +∞ or −∞) can be written directly using the math constants infinity and -infinity, or produced as a result of some calculations:
</p>
<ul>
	<li>
何かを 0 で除算するときは、
標準な符号n規則に則って［
+∞ ／ −∞
］を生産する。
◎
Dividing a value by zero produces either +∞ or −∞, according to the standard sign rules.
</li>
	<li>
次に挙げる演算は、
`無限大$のうち適切な方を生産する
⇒＃
何かと ±∞ を乗算するとき ／
何かと ±∞ を加算するとき ／
±∞ から何かを減算するとき ／
何かから ±∞ を減算するとき
◎
Adding or subtracting ±∞ to anything produces the appropriate infinity.
◎
Multiplying any value by ±∞ produces the appropriate infinity.
</li>
	<li>
何かを ±∞ で除算するときは、
0 【`有符号 0$ のうち適切な方】を生産する。
◎
Dividing any value by ±∞ produces zero.
</li>
	<li>
`~math関数$における，ある種の引数の組合nは、
`無限大$を生産するものと定義される
（例： `pow(0, -1)^v は +∞ を生産する）。
◎
Certain argument combinations in math functions are defined to produce infinities (for example, pow(0, -1) produces +∞).
</li>
</ul>

<p class="note">注記：
以下に与える `~NaN$ を生産するための規則は、
上に与えた`無限大$を生産する規則より優先される。
◎
Note: The rules for producing NaN, below, supersede the above rules for producing infinities.
</p>

<p>
`無限大$は、
`~top-levelの計算式$から外へ~~漏れない
— それらは、
`§ 範囲の検査-法＠#calc-range$
にて定義されるとおり，
当の文脈において許容される［
最小／最大
］な値に切詰められる。
◎
Infinities do not escape a top-level calculation; they’re clamped to the minimum or maximum value allowed in the context, as defined in § 10.12 Range Checking.
</p>

<p>
`~NaN@
（ "`not a number^en" の略）
は、
ある種の演算の結果のうち，きちんと定義された値が無いものを表す。
それは、
`~math定数＠#calc-error-constants$ `NaN$v を利用して直に記せる。
また、
以下に挙げる計算の結果として生産される：
◎
NaN (short for "not a number") is the result of certain operations that don’t have a well-defined value. It can be written directly using the math constants NaN, or produced as a result of some calculations:
</p>
<ul>
	<li>
<p>
次に挙げる演算は、
~NaN を生産する
⇒＃
0 を 0 で除算するとき ／
±∞ を ±∞ で除算するとき ／
0 と ±∞ を乗算するとき ／
+∞ と −∞ を加算するとき ／
±∞ から正負が同じ ±∞ を減算するとき
◎
Dividing zero by zero, dividing ±∞ by ±∞, multiplying 0 by ±∞, adding +∞ to −∞, or subtracting two infinities of the same sign produces NaN.
</p>

<p>
これらの規則は、
他の規則と競合する場合には，それを上書きする。
例えば `0 / 0^v は、
+∞ ではなく ~NaN になる。
◎
These rules override any other result, if there’s a conflict. For example, 0 / 0 is NaN, not +∞.
</p>
	</li>
	<li>
`~math関数$における，ある種の引数の組合nは、
`~NaN$ を生産するものと定義される
（例： `asin(2)^v は ~NaN を生産する）。
◎
Certain argument combinations in math functions are defined to produce NaN (for example, asin(2) produces NaN).
</li>
	<li>
どの演算も、
ある引数が ~NaN ならば ~NaN を生産する。
◎
Any operation with at least one NaN argument produces NaN.
</li>
</ul>

<p>
`~NaN$ は、
`~top-levelの計算式$から外へ~~漏れない
— それらは、
0 に同化される。
◎
NaN does not escape a top-level calculation; it’s censored into a zero value
</p>

<div class="example">
<p>
例えば，
`calc(-5 * 0)^v は ~0N に解決されるが、
`~top-levelの計算式$としては，無符号 0 に同化される。
◎
For example, calc(-5 * 0) produces an unsigned zero—the calculation resolves to 0⁻, but as it’s a top-level calculation, it’s then censored to an unsigned zero.
</p>

<p>
他方，
`calc(1 / calc(-5 * 0))^v は、
`calc(1 / (-5 * 0))^v と同じく，
−∞ を生産する。
~~内側の `calc^f は、
`~top-levelの計算式$ではないので， ~0N に解決される。
その結果は，そのまま~top-levelの `calc^f に渡され、
−∞ を生産することになる
— ~~仮に，そのままではなく無符号 0 に同化された場合、
+∞ を生産することになる。
◎
On the other hand, calc(1 / calc(-5 * 0)) produces −∞, same as calc(1 / (-5 * 0))—the inner calc resolves to 0⁻, and as it’s not a top-level calculation, it passes it up unchanged to the outer calc to produce −∞. If it was censored into an unsigned zero, it would instead produce +∞.
</p>
</div>

			</section>
		</section>
		<section id="calc-internal">
<h3 title="Internal Representation">10.10. 内部~表現</h3>
<p>
`~math関数$の`内部~表現$は、
`計算式~tree@
になる
— この~treeを成す各~nodeのうち：
◎
The internal representation of a math function is a calculation tree: a tree where＼
</p>

<ul>
	<li>
<p>
枝分かれ~node（子を持つ~node）には、
`演算子~node@
と総称される，次のいずれかが対応する
⇒＃
`~math関数$（ `Min^i, `Cos^i, `Sqrt^i, 等々）／
`計算式$内の演算子（ `Sum^i, `Product^i, `Negate^i, `Invert^i †）
</p>

<p>
後者は
`~calc演算子~node@
と総称される。
【† これらの各 名前は、 `CSSMathValue$I の各種 下位classの名前に対応する。】
</p>
◎
the branch nodes are operator nodes corresponding either to math functions (such as Min, Cos, Sqrt, etc) or to operators in a calculation (Sum, Product, Negate, and Invert, the calc-operator nodes), and＼
</li>
	<li>
葉~node（子を持たない~node）には、
次のいずれかが対応する
⇒＃
数量-値（実数, 次元, 百分率）／
`~math関数$でない ある数量-型に解決されるもの
◎
the leaf nodes are either numeric values (such as numbers, dimensions, and percentages) or non-math functions that resolve to a numeric type.
</li>
</ul>

<p>
`~math関数$は、
次に与える`計算式~tree$に転換される：
◎
Math functions are turned into calculation trees depending on the function:
</p>

<ul class="switch">
	<li>
`calc$f 関数の`内部~表現$は、
次の結果になる
⇒
`計算式を構文解析する$( その引数 )
◎
calc()
• The internal representation of a calc() function is the result of parsing a calculation from its argument.
</li>
	<li>
その他の`~math関数$の`内部~表現$は、
当の関数と同じ名前の`演算子~node$になる
⇒
その各~子は、
関数の各~引数が現れる順序で，［
各~引数に対する次の結果
］で与えられる
⇒
`計算式を構文解析する$( 引数 )
◎
any other math function
• The internal representation is an operator node with the same name as the function, whose children are the result of parsing a calculation from each of the function’s arguments, in the order they appear.
</li>
</ul>

<div class="algo">
<p>
`計算式を構文解析する@
~algoは、
所与の
( `計算式$を表現している`成分~値$の~list %値~list )
に対し，`計算式~tree$を返す：
◎
To parse a calculation, given a calculation values represented as a list of component values, and returning a calculation tree:
</p>
<ol>
	<li>
%値~list から `whitespace-token$t をすべて除去する
◎
Discard any &lt;whitespace-token&gt;s from values.
</li>
	<li>
<p>
この段の目的においては、
%値~list を成す各 %~item には，次に与える `演算子^i が結付けられる
⇒＃
%~item は `delim-token$t であって，その.値 ~IN { `+^l, `-^l, `*^l, `/^l } ならば それ ／
~ELSE_ ε
</p>

<p class="trans-note">【
この段では、
各［［
`*^l ／ `/^l
］で連結された成分たちが成す連なり
］を `Product^i ~nodeの中に収集する。
それに伴い、［
`-^l ／ `/^l
］が前置された各~成分は［
`Negate^i ／ `Invert^i
］~nodeの中に包装する。
】【
この段は、
原文の記述にかなり手を加えている（より~algo的に~~厳密化／~~整理集約など）
】</p>
		<ol>
			<li>
~Assert：
%値~list は［
`演算子^i ~NEQ ε のものと, それ以外のもの
］が交互に並んでいて、
最初, 最後の~itemの `演算子^i ~EQ ε
</li>
			<li>
%子~list ~LET 新たな~list
</li>
			<li>
%積~list ~LET 新たな~list
</li>
			<li>
%現在の演算子 ~LET ε
</li>
			<li>
<p>
%値~list を成す
~EACH( %~item )
に対し：
</p>
				<ol>
					<li>
<p>
~IF［
%~item の `演算子^i ~NEQ ε
］：
</p>
						<ol>
							<li>
%現在の演算子 ~SET %~item の `演算子^i
</li>
							<li>
~IF［
%現在の演算子 ~IN { `*^l ／ `/^l }
］~OR［
%積~list の~size ~EQ 0
］
⇒
~CONTINUE
</li>
						</ol>
					</li>
					<li>
<p>
~ELSE：
</p>
						<ol>
							<li>
~IF［
%現在の演算子 ~EQ `-^l
］
⇒
%~item ~SET %~item を子として包含している `Negate^i ~node
</li>
							<li>
~ELIF［
%現在の演算子 ~EQ `/^l
］
⇒
%~item ~SET %~item を子として包含している `Invert^i ~node
</li>
							<li>
%積~list に %~item を付加する
</li>
							<li>
~IF［
%~item は %値~list の最後の~itemでない
］
⇒
~CONTINUE
</li>
						</ol>
					</li>
					<li>
~IF［
%積~list の~size ~EQ 1
］
⇒
%子~list に %積~list[0] を付加する
</li>
					<li>
~ELSE
⇒
%子~list に［
%子~list を成す各~itemを子として持つ `Product^i ~node
］を付加する
</li>
					<li>
%積~list を空にする
</li>

				</ol>
			</li>
		</ol>
◎
An item in values is an “operator” if it’s a &lt;delim-token&gt; with the value "+", "-", "*", or "/". Otherwise, it’s a “value”.
◎
Collect children into Product and Invert nodes.
◎
For every consecutive run of value items in values separated by "*" or "/" operators:
• For each "/" operator in the run, replace its right-hand value item rhs with an Invert node containing rhs as its child.
• Replace the entire run with a Product node containing the value items of the run as its children.
◎
Collect children into Sum and Negate nodes.
• For each "-" operator item in values, replace its right-hand value item rhs with a Negate node containing rhs as its child.
</li>
	<li>
%根 ~LET %子~list を成す各~itemを子として持つ `Sum^i ~node
◎
↓</li>
	<li>
~IF［
%子~list は唯一の~itemからなる
］~AND［
その~itemは［
`Product^i ~node／`丸括弧~block$
］である
］
⇒
%根 ~SET その~item
◎
If values has only one item, and it is a Product node or a parenthesized simple block, replace values with that item.
◎
Otherwise, replace values with a Sum node containing the value items of values as its children.
</li>
	<li>
~Assert：
%根 を根とする~treeを成す~nodeのうち，子を持つ~nodeは［
`Sum^i ／
`Product^i／
`Negate^i／
`Invert^i
］~nodeであって，他の~node（葉~node）は そうでない。
◎
At this point values is a tree of Sum, Product, Negate, and Invert nodes, with other types of values at the leaf nodes. Process the leaf nodes.
</li>
	<li>
<p>
%根 を成す
~EACH( 子を持たない~node %葉 )
に対し：
◎
For every leaf node leaf in values:
</p>
		<ol>
			<li>
~IF［
%葉 は`丸括弧~block$である
］
⇒
%葉 を次の結果に置換する
⇒
`計算式を構文解析する$( %葉 の内容 )
◎
If leaf is a parenthesized simple block, replace leaf with the result of parsing a calculation from leaf’s contents.
</li>
			<li>
~IF［
%葉 は`~math関数$である
］
⇒
%葉 をその~math関数の`内部~表現$に置換する
◎
If leaf is a math function, replace leaf with the internal representation of that math function.
</li>
		</ol>
	</li>
	<li>
~RET `計算式~treeを単純~化する$( %根 )
◎
Return the result of simplifying a calculation tree from values.
</li>
</ol>
</div>

			<section id="calc-simplification">
<h4 title="Simplification">10.10.1. 単純~化</h4>

<p>
`~math関数$の`内部~表現$は、
標準な代数的な単純~化を利用して，~~隅々までアリな限り単純~化される
（乗算を総和に分配する, 単位が`互換$な値どうしを結合する, 等々）。
◎
Internal representations of math functions are eagerly simplified to the extent possible, using standard algebraic simplifications (distributing multiplication over sums, combining similar units, etc.).
</p>

<p>
`~math関数$は、
~prop以外の文脈（例えば `font-face$at 記述子）内で利用されたときは，
`指定d値$であったかのように単純~化される。
◎
When used in non-property contexts (such as in @font-face descriptors, for example), math functions are simplified as if they were specified values.
</p>

<div class="algo">
<p>
`計算式~treeを単純~化する@
~algoは、
所与の
( %根 )
に対し：
◎
To simplify a calculation tree root:
</p>
<ol>
	<li>
<p>
~IF［
%根 は数量-値である
］：
◎
If root is a numeric value:
</p>
		<ol>
			<li>
~IF［
%根 は ある次元の %別の値 を~~基準に解決される百分率であって，それを解決するに十分な情報は可用である
］
⇒
~RET  %根 を その次元の`正準-単位$に解決した結果の数量-値
◎
If root is a percentage that will be resolved against another value, and there is enough information available to resolve it, do so, and express the resulting numeric value in the appropriate canonical unit. Return the value.
</li>
			<li>
~IF［
%根 は ある次元の値であって，その単位は`正準-単位$でない
］~AND［
%根 を正準-単位による値に換算するに十分な情報は可用である
］
⇒
~RET %根 を正準-単位に換算した結果
◎
If root is a dimension that is not expressed in its canonical unit, and there is enough information available to convert it to the canonical unit, do so, and return the value.
</li>
			<li>
~IF［
%根 は `calc-keyword$t である
］~AND［
%根 は解決できる
］
⇒
~RET `計算式~treeを単純~化する$( %根 を解決した結果 )
◎
If root is a &lt;calc-keyword&gt; that can be resolved, return what it resolves to, simplified.
</li>
			<li>
~RET %根
◎
Otherwise, return root.
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%根 は他の葉~nodeである（演算子~nodeでない）
］：
◎
If root is any other leaf node (not an operator node):
</p>
		<ol>
			<li>
~IF［
%根 の数量-値を決定するに十分な情報は可用である
］
⇒
~RET 値を`正準-単位$で表出した結果
◎
If there is enough information available to determine its numeric value, return its value, expressed in the value’s canonical unit.
</li>
			<li>
~RET %根
◎
Otherwise, return root.
</li>
		</ol>
	</li>
	<li>
~Assert：
この時点で， %根 は`演算子~node$である。
◎
At this point, root is an operator node.＼
</li>
	<li>
%根 を成す
~EACH( `計算式$である子 %子 )
を次の結果に置換する
⇒
`計算式~treeを単純~化する$( %子 )
◎
Simplify all the calculation children of root.
</li>
	<li>
<p>
~IF［
%根 は`~calc演算子~node$でない
］~AND［
%根 の［
`計算式$である子†
］は どれも数量-値であって，
%根 が表現する演算を算出するに十分な情報を伴う
］
⇒
~RET ［
%根 の子たちを利用して %根 の演算を走らせた結果
］を値にとり，結果の`正準-単位$で表出される数量-値
◎
If root is an operator node that’s not one of the calc-operator nodes, and all of its calculation children are numeric values with enough information to compute the operation root represents, return the result of running root’s operation using its children, expressed in the result’s canonical unit.
</p>

<p class="trans-note">【†
“計算式である” は余計な句に見受けられる
（前~段で単純~化して置換したにもかかわらず，計算式である子に限定しているのはなぜ？
“計算式は数量-値である” とは？）。
】</p>

<div class="note">
<p>注記：
この時点で百分率が残っている場合、
それは，`通例的に^em ~nodeの単純~化を阻むことになる
— それは、［
現在は可用でない情報を利用している別の値
］を~~基準に解決する必要があるので
（他の場合、これまでの段で，百分率~以外に変換されたことになる）。
`min^op などの演算も，これに含まれる
— 百分率は，負な値を~~基準に解決されるかもしれず、
その比較関係は，生の百分率~値どうしとは正反対になるので。
◎
If a percentage is left at this point, it will usually block simplification of the node, since it needs to be resolved against another value using information not currently available. (Otherwise, it would have been converted to a different value in an earlier step.) This includes operations such as "min", since percentages might resolve against a negative basis, and thus end up with an opposite comparative relationship than the raw percentage value would seem to indicate.
</p>

<p>
しかしながら， “生の” 百分率であっても、
`opacity$p など別の値を~~基準に解決されないものについては，単純~化は阻まれないであろう。
◎
However, "raw" percentages—ones which do not resolve against another value, such as in opacity—might not block simplification.
</p>
</div>

	</li>
	<li>
<p>
%根 に応じて：
</p>
		<dl class="switch">
			<dt>
`Min^i ~node
◎
↓</dt>
			<dt>
`Max^i ~node
◎
If root is a Min or Max node,＼
</dt>
			<dd>
<p>
（次に従って，部分的に単純~化するよう試みる）：
◎
attempt to partially simplify it:
</p>
				<ol>
					<li>
~EACH( %根 の数量-値である子のうち，［
互いの単位が一致する, かつ
互いの大きさを比較するに十分な情報を伴うもの（前~段の注記を見よ）
］たちが成す集合 )
に対し
⇒
その集合を成す子たちを［
%根 に応じて適切な演算子
【 `Min^i ~nodeならば `min$f （最小~値をとる）等】
で結合した結果の数量-値
］に置換する
◎
For each node child of root’s children:
◎
If child is a numeric value with enough information to compare magnitudes with another child of the same unit (see note in previous step), and there are other children of root that are numeric values with the same unit, combine all such children with the appropriate operator per root, and replace child with the result, removing all other child nodes involved.
</li>
					<li>
~IF［
%根 の子は 1 個だけある
］
⇒
~RET 当の子
◎
If root has only one child, return the child.
</li>
					<li>
~RET %根
◎
Otherwise, return root.
</li>
				</ol>
			</dd>

			<dt>
`Negate^i ~node
◎
If root is a Negate node:
</dt>
			<dd>
				<ol>
					<li>
~IF［
%根 の子は数量-値である
］
⇒
~RET 0 ~MINUS その値
（すなわち反数）
◎
If root’s child is a numeric value, return an equivalent numeric value, but with the value negated (0 - value).
</li>
					<li>
~IF［
%根 の子は `Negate^i ~nodeである
］
⇒
~RET %根 の子の子
◎
If root’s child is a Negate node, return the child’s child.
</li>
					<li>
~RET %根
◎
Return root.
</li>
				</ol>
			</dd>

			<dt>
`Invert^i ~node
◎
If root is an Invert node:
</dt>
			<dd>
				<ol>
					<li>
~IF［
%根 の子は実数である（百分率でも次元でもない）
］
⇒
~RET 1 ~DIV その値（すなわち逆数）
◎
If root’s child is a number (not a percentage or dimension) return the reciprocal of the child’s value.
</li>
					<li>
~IF［
%根 の子は `Invert^i ~nodeである
］
⇒
~RET %根 の子の子
◎
If root’s child is an Invert node, return the child’s child.
</li>
					<li>
~RET %根
◎
Return root.
</li>
				</ol>
			</dd>

			<dt>
`Sum^i ~node
◎
If root is a Sum node:
</dt>
			<dd>
				<ol>
					<li>
%根 の子のうち `Sum^i ~nodeである
~EACH( %子 )
を %子 の子たちに置換する
◎
For each of root’s children that are Sum nodes, replace them with their children.
</li>
					<li>
<p>
~EACH( %根 の数量-値である子のうち，互いの単位が一致するものたちが成す集合 )
に対し
⇒
その集合を成す子たちを［
それらの総和が成す単独の数量-値
］に置換する
◎
For each set of root’s children that are numeric values with identical units, remove those children and replace them with a single numeric value containing the sum of the removed nodes, and with the same unit.
</p>

<p>
（例：［
実数どうし／百分率どうし／`px^u 値どうし
］を結合する）
◎
(E.g. combine numbers, combine percentages, combine px values, etc.)
</p>
					</li>
					<li>
~RET ［
%根 の子は 1 個だけならば %根 の子 ／
~ELSE_ %根
］
◎
If root has only a single child at this point, return the child. Otherwise, return root.
</li>
				</ol>

<p class="note">注記：
`Sum^i ~nodeからは、
値 0 をとる項を単純に除去できない
— それらは、
他の値のうち，単位が一致するものとしか結合できない
（ときには、
単位が在るだけでも
— 値 0 をとろうが —
挙動の変更を含意し得るので）。
◎
Note: Zero-valued terms cannot be simply removed from a Sum; they can only be combined with other values that have identical units. (This is because the mere presence of a unit, even with a zero value, can sometimes imply a change in behavior.)
</p>
			</dd>

			<dt>
`Product^i ~node
◎
If root is a Product node:
</dt>
			<dd>
				<ol>
					<li>
%根 の子のうち `Product^i ~nodeである
~EACH( %子 )
を %子 の子たちに置換する
◎
For each of root’s children that are Product nodes, replace them with their children.
</li>
					<li>
~IF［
%根 には実数である（百分率でも次元でもない）子~nodeが複数個ある
］
⇒
それらの~nodeを［
それらの積が成す単独の実数
］に置換する
◎
If root has multiple children that are numbers (not percentages or dimensions), remove them and replace them with a single number containing the product of the removed nodes.
</li>
					<li>
~IF［
%根 には子が 2 つだけある
］~AND［
一方の子は 実数 %N である（百分率でも次元でもない）
］~AND［
もう一方の子は `Sum^i ~node %S であって，その子たちは すべて数量-値である
］
⇒＃
%S の ~EACH( 子 ) に対し，その値に %N を乗算する；
~RET %S
◎
If root contains only two children, one of which is a number (not a percentage or dimension) and the other of which is a Sum whose children are all numeric values, multiply all of the Sum’s children by the number, then return the Sum.
</li>
					<li>
~IF［
%根 の子は どれも［
数量-値／数量-値を子とする `Invert^i ~node
］である
］
⇒
~IF［
`型を乗算する$( %根 のすべての子 )
の結果は 当の`~math関数$を解決できる型に`合致する$
（ `Invert^i ~nodeの型は `型を逆数にする$( その子の型 ) の結果になることに注意）
］
⇒
~RET ［
%根 のすべての子の値を乗算した結果
（ `Invert^i ~nodeの値は、
その子の値の逆数であることに注意）
］を値にとり，結果の`正準-単位$で表出される数量-値
◎
If root contains only numeric values and/or Invert nodes containing numeric values, and multiplying the types of all the children (noting that the type of an Invert node is the inverse of its child’s type) results in a type that matches any of the types that a math function can resolve to, return the result of multiplying all the values of the children (noting that the value of an Invert node is the reciprocal of its child’s value), expressed in the result’s canonical unit.
</li>
					<li>
~RET %根
◎
Return root.
</li>
				</ol>
			</dd>

			<dt>
その他の~node
</dt>
			<dd>
~Assert：
この事例は生じ得ない
</dd>
			<dd class="trans-note">【
この段は、
この訳による補完（未策定な事例があるかもしれない）。
】</dd>
		</dl>
	</li>
</ol>
</div>
			</section>
		</section>
		<section id="calc-computed-value">
<h3 title="Computed Value">10.11. 算出d値</h3>

<p>
`~math関数$の`算出d値$は、
算出d値の時点で可用なすべての情報
（ `em$u と `px$u の比率,
何らかの~propにおいて百分率を解決する方法,
等々）
を利用する下で，その`計算式~treeを単純~化$した結果になる。
◎
The computed value of a math function is its calculation tree simplified, using all the information available at computed value time. (Such as the em to px ratio, how to resolve percentages in some properties, etc.)
</p>

<p>
算出d値の時点で解決されない百分率は、
`~math関数$の中でも解決されない。
例えば，式 `calc(100% - 100% + 1px)^v は、
`1px^v ではなく， `calc(0% + 1px)^v に解決される。
百分率から算出d値を得るための特別な規則がある場合（例えば `height$p ~prop）、
その規則が`~math関数$に含まれるどの百分率にも適用される。
◎
Where percentages are not resolved at computed-value time, they are not resolved in math functions, e.g. calc(100% - 100% + 1px) resolves to calc(0% + 1px), not to 1px. If there are special rules for computing percentages in a value (e.g. the height property), they apply whenever a math function contains percentages.
</p>

<p>
`計算式~tree$は、
`使用~値$の時点でも，その時点の情報で再び単純~化される
— `~math関数$は常に，単独の数量-値に さらに単純~化される。
◎
The calculation tree is again simplified at used value time; with used value time information, a math function always simplifies down to a single numeric value.
</p>

<div class="example">
<p>
例えば， `font-size$p における百分率~値は、
`~fontに相対的な長さ$ 単位を算出できるよう，`算出d値$の時点で解決される。
一方で， `background-position$p における百分率~値は、
その挙動が~layoutに依存するため，使用~値の時点まで解決されない。
◎
For example, whereas font-size computes percentage values at computed value time so that font-relative length units can be computed, background-position has layout-dependent behavior for percentage values, and thus does not resolve percentages until used-value time.
</p>

<p>
このことに因り、
`background-position$p における算出では， `calc$f 内の百分率は保全される一方で、
`font-size$p では，そのような式は直に長さに算出される。
◎
Due to this, background-position computation preserves the percentage in a calc() whereas font-size will compute such expressions directly into a length.
</p>
</div>

<p>
~tableを成す［
~cellその他の要素
］の~size計算は複階的なので、
~tableの［
~col, ~col~group, ~row, ~row~group, ~cell
］の~sizeに対する~math式のうち［
百分率, 0 でない長さ
］が混在なものについては、
~table~layoutが自動（ `auto^v ）か固定的（ `fixed^v ）かに関わらず，
`~autoS$v が指定されていたかのように扱う`モノトスル^em。
◎
Given the complexities of width and height calculations on table cells and table elements, math expressions mixing both percentages and non-zero lengths for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MUST be treated as if auto had been specified.
</p>

		</section>
		<section id="calc-range">
<h3 title="Range Checking">10.12. 範囲の検査-法</h3>

<p>
構文解析-時には、
`~math関数$の中の値に対しては，範囲は検査されないので、
値が範囲~外であっても宣言は無効にならない。
しかしながら、
`~top-levelの計算式$による結果の値は，
当の文脈に許容される範囲に切詰めるモノトスル。
この切詰ngは、
`算出d値$に対しては，アリな所すべてで遂行され、
算出において範囲を検査するに足るまで式を単純~化できなかった場合には，
`使用~値$に対し遂行される。
（`指定d値$に対しては、
切詰ngは遂行されない。）
◎
Parse-time range-checking of values is not performed within math functions, and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from a top-level calculation must be clamped to the range allowed in the target context. Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking. (Clamping is not performed on specified values.)
</p>

<p class="note">注記：
したがって、
【！＊calc】`~math関数$を受容するすべての文脈において，
許容される値の範囲は（開区間ではなく）閉区間として定義することが要求される。
◎
Note: This requires all contexts accepting calc() to define their allowable values as a closed (not open) interval.
</p>

<p class="note">注記：
±∞ は、［
どの~propに対しても、
定義により，許容される範囲の外側にある
］ので，許容される［
最小／最大
］値に切詰められることになる。
`animation-iteration-count$p など，［
明示的に無限大を表現する~keyword値
］をとり得る~propであっても、
`~math関数$は，~prop構文の`数量-部分^emの［
最小／最大
］値に切詰められ，~keyword値には解決され得ない。
◎
Note: By definition, ±∞ are outside the allowed range for any property, and will clamp to the minimum/maximum value allowed. Even properties that can explicitly represent infinity as a keyword value, such as animation-iteration-count, will end up clamping ±∞, as math functions can’t resolve to keyword values; the numeric part of the property’s syntax still has a minimum/maximum value.
</p>

<p>
加えて， `number$t に解決される`~math関数$が `integer$t のみを受容する所に利用された場合、
その［
`算出d値$／ `使用~値$
］は，上の切詰ngと同じ方式で`最も近い整数に丸められ$る。
◎
Additionally, if a math function that resolves to &lt;number&gt; is used somewhere that only accepts &lt;integer&gt;, the computed value and used value are rounded to the nearest integer, in the same manner as clamping, above.
</p>

<div class="example">
<p>
`0px^v より小さい横幅は許容されないので、
次の 3 つは `width:0px$p と等価になる：
◎
Since widths smaller than 0px are not allowed, these three declarations are equivalent:
</p>

<pre class="lang-css">
width: calc(5px - 10px);
width: calc(-5px);
width: 0px;
</pre>

<p>
しかしながら、
`width:-5px$p と `width:calc(-5px)$p は，等価ではないことに注意。
`calc$f の`外側^emにある範囲~外の値は，構文上は無効であり、
宣言はまるごと落とされることになる。
◎
Note however that width: -5px is not equivalent to width: calc(-5px)! Out-of-range values outside calc() are syntactically invalid, and cause the entire declaration to be dropped.
</p>
</div>

		</section>
		<section id="calc-serialize">
<h3 title="Serialization">10.13. 直列化</h3>

<div class="algo">
<p>
`~math関数を直列化する@
~algoは、
所与の
( %fn )
に対し：
◎
To serialize a math function fn:
</p>
<ol>
	<li>
%根 ~LET %fn が表現する`計算式~tree$の根~node
</li>
	<li>
~IF［
%根 は数量-値（実数／百分率／次元）である
］~AND［
これが生産している直列化は`算出d値$かそれより後のものである
］
⇒
~RET 必要yなら，値を その文脈に許容される範囲に切詰めた上で、
値を通常通り直列化した結果
【すなわち、この~algoを適用し直す】
◎
If the root of the calculation tree fn represents is a numeric value (number, percentage, or dimension), and the serialization being produced is of a computed value or later, then clamp the value to the range allowed for its context (if necessary), then serialize the value as normal and return the result.
</li>
	<li>
<p>
~IF［
%fn は［
無限大【！infinite value】／~NaN
］を表現する
］：
◎
If fn represents an infinite or NaN value:
</p>
		<ul>
			<li>
%s ~LET 値を表現する適切な［
`infinity$v ／ `-infinity$v ／ `NaN$v
］~keywordを直列化した結果
◎
↓↓Let s be the string "calc(".
◎
Serialize the keyword infinity, -infinity, or NaN, as appropriate to represent the value, and append it to s.
</li>
			<li>
~IF［
%fn の`型$は `number$t を表現するもの（ «[ ]» と等価，無次元）でない
］
⇒
%s に次を順に付加する【！`型$が多重次元の場合は？】
⇒＃
` * 1^l,
%fn の`型$用の`正準-単位$（ `length$t 用には `px$u など）
◎
If fn’s type is anything other than «[ ]» (empty, representing a &lt;number&gt;), append " * " to s. Create a numeric value in the canonical unit for fn’s type (such as px for &lt;length&gt;), with a value of 1. Serialize this numeric value and append it to s.
</li>
			<li>
~RET 次を順に`連結する$
⇒＃
`calc(^l,
%s,
`)^l
◎
Append ")" to s, then return it.
</li>
		</ul>
	</li>
	<li>
%名前 ~LET %根 に応じて
⇒＃
数量-値であるならば `calc^l ／
`~calc演算子~node$であるならば `calc^l ／
~ELSE_ 小文字~化された %根 の名前（ `sin^l, `max^l など）
◎
If the calculation tree’s root node is a numeric value, or a calc-operator node, let s be a string initially containing "calc(".
◎
Otherwise, let s be a string initially containing the name of the root node, lowercased (such as "sin" or "max"), followed by a "(" (open parenthesis).
</li>
	<li>
%~list ~LET 新たな~list
◎
↓↓
</li>
	<li>
<p>
%根 の
~EACH( 子 %子 )
に対し：
</p>
		<ol>
			<li>
%直列化 ~LET `計算式~treeを直列化する$( %子 )
</li>
			<li>
~IF［
%直列化 の先頭の文字 ~EQ `(^l （左~丸括弧）
］~AND［
%直列化 の末尾の文字 ~EQ `)^l （右~丸括弧）
］
⇒
%直列化 から先頭, 末尾の文字を除去する
</li>
			<li>
%~list に %直列化 を付加する
</li>
		</ol>
◎
For each child of the root node, serialize the calculation tree. If a result of this serialization starts with a "(" (open parenthesis) and ends with a ")" (close parenthesis), remove those characters from the result.＼
</li>
	<li>
%引数~列 ~LET %~list を `, ^l （~comma, 後続する~space）で`連結する$
◎
Concatenate all of the results using ", " (comma followed by space), then append the result to s.
</li>
	<li>
~RET 次を順に`連結する$
⇒＃
%名前,
`(^l （左~丸括弧）,
%引数~列,
`)^l （右~丸括弧）
◎
Append ")" (close parenthesis) to s.
◎
Return s.
</li>
</ol>
</div>

<div class="algo">
<p>
`計算式~treeを直列化する@
~algoは、
所与の
( `計算式~tree$の根を与える~node %根 )
に対し：
◎
To serialize a calculation tree:
• Let root be the root node of the calculation tree.
</p>
<ol>
	<li>
~IF［
%根 は数量-値である
］~OR［
%根 は`~math関数$でない
］
⇒
~RET %根 用の通常の規則により %根 を直列化した結果
◎
If root is a numeric value, or a non-math function, serialize root per the normal rules for it and return the result.
</li>
	<li>
~IF［
%根 は［
`Sum^i, `Negate^i, `Product^i, `Invert^i
］以外の~nodeである
］
⇒
~RET `~math関数を直列化する$( %根 )
【！treating the ... 不要？】
◎
If root is anything but a Sum, Negate, Product, or Invert node, serialize a math function for the function corresponding to the node type, treating the node’s children as the function’s comma-separated calculation arguments, and return the result.
</li>
	<li>
~IF［
%根 は `Negate^i ~nodeである
］
⇒
~RET 次を順に`連結する$
⇒＃
`(-1 * ^l,
`計算式~treeを直列化する$( %根 の子 ),
`)^l
◎
If root is a Negate node:
• Let s be a string initially containing "(-1 * ".
• Serialize root’s child, and append it to s.
• Append ")" to s, then return it.
</li>
	<li>
~IF［
%根 は `Invert^i ~nodeである
］
⇒
~RET 次を順に`連結する$
⇒＃
`(1 / ^l,
`計算式~treeを直列化する$( %根 の子 ),
`)^l
◎
If root is an Invert node:
• Let s be a string initially containing "(1 / ".
• Serialize root’s child, and append it to s.
• Append ")" to s, then return it.
</li>
	<li>
<p>
~IF［
%根 は `Sum^i ~nodeである
］：
◎
If root is a Sum node:
</p>
		<ol>
			<li>
%s ~LET `(^l
◎
Let s be a string initially containing "(".
</li>
			<li>
%子~list ~LET `根の子たちを~sortする$( %根 )
◎
Sort root’s children.
</li>
			<li>
%s に次の結果を付加する
⇒
`計算式~treeを直列化する$( %子~list の最初の~item )
◎
Serialize root’s first child, and append it to s.
</li>
			<li>
<p>
%子~list を成す最初の~itemを除く
~EACH( %子 )
に対し：
◎
For each child of root beyond the first:
</p>
				<ol>
					<li>
~IF［
%子 は `Negate^i ~nodeである
］
⇒
%s に次を順に付加する
⇒＃
` - ^l,
`計算式~treeを直列化する$( %子 の子 )
◎
If child is a Negate node, append " - " to s, then serialize the Negate’s child and append the result to s.
</li>
					<li>
~ELIF［
%子 は 負な数量-値である
］
⇒
%s に次を順に付加する
⇒＃
` - ^l,
%子 の反数を通常通り直列化した結果
◎
If child is a negative numeric value, append " - " to s, then serialize the negation of child as normal and append the result to s.
</li>
					<li>
~ELSE
⇒
%s に次を順に付加する
⇒＃
` + ^l,
`計算式~treeを直列化する$( %子 )
◎
Otherwise, append " + " to s, then serialize child and append the result to s.
</li>
				</ol>
			</li>
			<li>
%s に `)^l を付加する
◎
Append ")" to s＼
</li>
			<li>
~RET %s
◎
and return it.
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%根 は `Product^i ~nodeである
］：
◎
If root is a Product node:
</p>
		<ol>
			<li>
%s ~LET `(^l 
◎
Let s be a string initially containing "(".
</li>
			<li>
%子~list ~LET `根の子たちを~sortする$( %根 )
◎
Sort root’s children.
</li>
			<li>
%s に次の結果を付加する
⇒
`計算式~treeを直列化する$( %子~list の最初の~item )
◎
Serialize root’s first child, and append it to s.
</li>
			<li>
<p>
%子~list を成す最初の~itemを除く
~EACH( %子 )
に対し：
◎
For each child of root beyond the first:
</p>
				<ol>
					<li>
~IF［
%子 は `Invert^i ~nodeである
］
⇒
%s に次を順に付加する
⇒＃
` / ^l を付加する,
`計算式~treeを直列化する$( %子 の子 )
◎
If child is an Invert node, append " / " to s, then serialize the Invert’s child and append the result to s.
</li>
					<li>
~ELSE
⇒
%s に次を順に付加する
⇒＃
` * ^l,
`計算式~treeを直列化する$( %子 )
◎
Otherwise, append " * " to s, then serialize child and append the result to s.
</li>
				</ol>
			</li>
			<li>
%s に `)^l を付加する；
◎
Append ")" to s＼
</li>
			<li>
~RET %s
◎
and return it.
</li>
		</ol>
	</li>
</ol>
</div>

<div class="algo">
<p>
`根の子たちを~sortする@
~algoは、
所与の
( %根 )
に対し，［
%根 の子たちを，次に従って~sortした結果
］を新たな~listとして返す：
◎
To sort a calculation’s children nodes:
</p>
<ul>
	<li>
次の順に~sortする
⇒＃
`実数$を包含する~node（高々 1 個）,
`百分率$を包含する~node（高々 1 個）,
`次元$を包含する~node,
その他の~node
◎
Let ret be an empty list.
◎
If nodes contains a number, remove it from nodes and append it to ret.
◎
If nodes contains a percentage, remove it from nodes and append it to ret.
</li>
	<li>
次元を包含する~nodeどうしは、
`~ASCII大小無視$の下で，それらの単位の~alphabet順に~sortする
◎
If nodes contains any dimensions, remove them from nodes, sort them by their units, ordered ASCII case-insensitively, and append them to ret.
</li>
	<li>
その他の~nodeどうしは、
元と同じ順序に従う
◎
If nodes still contains any items, append them to ret in the same order.
◎
Return ret.
</li>
</ul>
</div>

<div class="example">
<p>
例えば，
`calc(20px + 30px)^v は、
指定d値としては `calc(50px)^v に，
算出d値としては `50px^v に直列化する。
◎
For example, calc(20px + 30px) would serialize as calc(50px) as a specified value, or as 50px as a computed value.
</p>

<p>
`calc(20px + 0%)^v の様な値は、
`calc(0% + 20px)^v として直列化し，いずれの項も 直列化された値の中に保守する。
（ 0 値の項を保守することは重要である
— いずれかの値が一時的に 0 値になっても，遷移の最中に突然 `calc$f の “~~形が変わる” ことがないように。
また、
すべての項が 0 であるときに “単位を選ぶ” 必要もなくなる。）
◎
A value like calc(20px + 0%) would serialize as calc(0% + 20px), maintaining both terms in the serialized value. (It’s important to maintain zero-valued terms, so the calc() doesn’t suddenly "change shape" in the middle of a transition when one of the values happens to have a zero value temporarily. This also removes the need to "pick a unit" when all the terms are zero.)
</p>

<p>
`calc(20px + 2em)^v の様な値は、
指定d値としては
`calc(2em + 20px)^v に直列化する
（どちらの単位も、
指定d値の時点では互換でないので，~alphabet順に~sortした上で保守する）。
また、
算出d値としては
`52px^v の様な値に直列化する
（ `em$u 値は，算出d値の時点で絶対~長さに換算されるので、
`1em^v = `16px^v であったなら、
それらは `52px^v に結合した上で，包装している `calc$f を外す）。
◎
A value like calc(20px + 2em) would serialize as calc(2em + 20px) as a specified value (maintaining both units as they’re incompatible at specified-value time, but sorting them alphabetically), or as something like 52px as a computed value (em values are converted to absolute lengths at computed-value time, so assuming 1em = 16px, they combine into 52px, which then drops the calc() wrapper.)
</p>
</div>

<p>
`~math関数$は、
~prop以外の文脈（例えば `font-face$at 記述子）内で利用されたときは，
`指定d値$であったかのように単純~化される。
◎
When used in non-property contexts (such as in @font-face descriptors, for example), math functions are simplified as if they were specified values.
</p>

<p>
直列化についての更なる情報は、
`CSSOM$r を見よ。
◎
See [CSSOM] for further information on serialization.
</p>

		</section>
		<section id="combine-math">
<h3 title="Combination of Math Functions">10.14. ~math関数の結合n</h3>

<div class="p">
<p>
［
`~math関数$どうし／
数量-値と数量-値をとる関数
］の：
</p>

<ul>
	<li>
`補間$における %結果値 は、
次で定義される
⇒
<code class="value">calc((1 - %p) * %値A + %p * %値B)</code>
</li>
	<li>
`加算$における %結果値 は、
次で定義される
⇒
<code class="value">calc(%値A + %値B)</code>
</li>
</ul>

<p>
（いずれの場合も、
%結果値 の`計算式~treeを単純~化$した結果は，
式をより小さく単純な形に簡約し得る。）
</p>

◎
Interpolation of math functions, with each other or with numeric values and other numeric-valued functions, is defined as Vresult = calc((1 - p) * VA + p * VB). (Simplification of the value might then reduce the expression to a smaller, simpler form.)
◎
Addition of math functions, with each other or with numeric values and other numeric-valued functions, is defined as Vresult = calc(VA + VB). (Simplification of the value might then reduce the expression to a smaller, simpler form.)
</div>

		</section>
	</section>
	<section id="linked-properties">
<h2 title=" Appendix A: Coordinating List-Valued Properties">付録 A. 協調している~list値をとる~prop群</h2>

<p>
一部の~list値をとる~prop群には、
互いに協調する効果がある
— すなわち、
それらの値~list内の各~itemは，互いに別個な効果を適用する一方で、
各~propの値~list内の互いに対応している~entryたちは，すべて同じ効果を指す。
協調している値たちは、
~list値をとる`略式~prop$において単独の~entryとして一緒に指定できることも多い。
◎
Some list-valued properties have coordinated effects: each item in their value list applies to a distinct effect, and corresponding entries in each property’s list all refer to the same effect. Often the coordinating values can also be specified together as a single entry in a list-valued shorthand property.
</p>

<p>
代表的な例として、
~list値をとる各種 `background-*^p ~propがある。
それは、
`複数の背景~画像~層＠~CSSBG#layering$を指定する。
当の画像がどう［
~sizeされるか／敷詰められるか／配置されるか
］, 等々を制御している各~propに対し、
その~list内の %N 個目の~itemは，
%N 個目の背景~画像に適用される何らかの効果を述べる。
◎
A typical example is the list-valued background-* properties, which can specify multiple background image layers. For each property controlling how the image is sized, tiled, placed, etc., the Nth item in its list describes some effect that applies to the Nth background image.
</p>

<p>
`協調している~list~prop~group@
%~group は、
`協調される値~list@
%~list を作成する。
それは、
%~list を成す各~entry用に %~group 内の各~propから値をとり、
それらの値は，単独の効果
— 背景~画像~層や~animationなど —
を定義するために一緒に利用される。
%~list は、
次に従って組立てられる：
◎
A coordinating list property group creates a coordinated value list, which has, for each entry, a value from each property in the group; these are used together to define a single effect, such as a background image layer or an animation. The coordinated value list is assembled as follows:
</p>
<ul>
	<li>
%~list の長さは、［
`協調している基底~list~prop@
と称される，
%~group を成す特定0の~prop
（ `background-*^p の事例では、 `background-image$p ~prop）
］内に指定された~itemの個数として決定される。
◎
The length of the coordinated value list is determined by the number of items specified in one particular coordinating list property, the coordinating list base property. (In the case of backgrounds, this is the background-image property.)
</li>
	<li>
%~list を成す %N 個目の値は、
%~group を成す各~propの`使用~値$の %N 個目の値を収集することにより構築される。
◎
The Nth value of the coordinated value list is constructed by collecting the Nth use value of each coordinating list property
</li>
	<li>
<p>
%~group を成す ある~propに指定された値の個数が %~list の長さ %長さ より：
</p>
		<ul>
			<li>
多過ぎる場合、
その値~list内の［
%長さ ~PLUS 1
］個目~以降の値は，`使用~値$を成さない。
</li>
			<li>
少な過ぎる場合、
その値~listは，もっと`使用~値$を追加するよう繰返される。
【その上で、前項も適用する。】
</li>
		</ul>
<p>
%~group を成す各~propの`算出d値$は、
これらの切落nや繰返nにより影響されない。
</p>
◎
If a coordinating list property has too many values specified, excess values at the end of its list are not used.
◎
If a coordinating list property has too few values specified, its value list is repeated to add more used values.
◎
The computed values of the coordinating list properties are not affected by such truncation or repetition.
</li>
</ul>

	</section>
	<section id="iana">
<h2 title="Appendix B: IANA Considerations">付録 B. IANA 考慮点</h2>

		<section id="about-invalid">
<h3 title="Registration for the about:invalid URL scheme">B.1. `about:invalid^c ~URL~schemeの登録</h3>

<p>
この節では、
`RFC6694$r にて定義される登録~手続-に則って，
`about:invalid^c ~URLを定義して登録する。
◎
This sections defines and registers the about:invalid URL, in accordance with the registration procedure defined in [RFC6694].
</p>

<p>
この登録の公式的な記録は、
`"about" ~URI~token~registry＠~IANA-a/about-uri-tokens/about-uri-tokens.xhtml$cite
にて見出せる。
</p>

<div>
<table><tbody>

<tr><th style="min-width:10em;">
登録された~token
<td>`invalid^c

<tr><th>
意図される用法
<td>
`about:invalid^c ~URLは、
汎用~error条件を伴う，存在しない文書を参照する。
~URLが必要な所で，既定~値がいかなる型の文書にも解決-可能になるべきでないとき、
利用できる。

<tr><th>連絡先／変更~制御者
<td lang="en">CSS WG &lt;<a href="mailto:www-style@w3.org">www-style@w3.org</a>&gt; (on behalf of W3C)

<tr><th>仕様
<td>`CSS Values and Units Module Level 3＠~TR/css3-values/$cite
</table>

◎
Registered Token｜invalid
Intended Usage｜The about:invalid URL references a non-existent document with a generic error condition. It can be used when a URL is necessary, but the default value shouldn’t be resolvable as any type of document.
Contact/Change controller｜CSS WG &lt;www-style@w3.org&gt; (on behalf of W3C)
Specification｜CSS Values and Units Module Level 3
</div>

		</section>
	</section>
	<section id="deprecated-quirky-length">
<h2 title=" Appendix B: Quirky Lengths">付録 C. 過去互換~用の長さ</h2>

<p>
~CSSが`過去互換~mode$の下で構文解析されるときは、
以下に挙げる~propに限り，
`length$t 型の一種である
`quirky-length@t
が妥当になる：
◎
When CSS is being parsed in quirks mode, &lt;quirky-length&gt; is a type of &lt;length&gt; that is only valid in certain properties:
</p>

<ul>
<li>`background-position$p
<li>`border-spacing$p
<li>`border-top-width$p
<li>`border-right-width$p
<li>`border-bottom-width$p
<li>`border-left-width$p
<li>`border-width$p
<li>`bottom$p
<li>`clip$p
<li>`font-size$p
<li>`height$p
<li>`left$p
<li>`letter-spacing$p
<li>`margin-right$p
<li>`margin-left$p
<li>`margin-top$p
<li>`margin-bottom$p
<li>`margin$p
<li>`max-height$p
<li>`max-width$p
<li>`min-height$p
<li>`min-width$p
<li>`padding-top$p
<li>`padding-right$p
<li>`padding-bottom$p
<li>`padding-left$p
<li>`padding$p
<li>`right$p
<li>`text-indent$p
<li>`top$p
<li>`vertical-align$p
<li>`width$p
<li>`word-spacing$p
</ul>

<p>
`quirky-length$t は：
◎
↓</p>
<ul>
	<li>
<p>
次に挙げる所では，`妥当でない^em：
◎
It is not valid＼
</p>
		<ul>
			<li>
上に挙げた~propを［
内包する／参照する
］~prop
— 例： `background$p 略式~prop。
◎
in properties that include or reference these properties, such as the background shorthand,＼
</li>
			<li>
`calc$f などの`関数-記法$の内側
— ただし、
`clip$p ~propにおける `rect$f 内では許容するモノトスル。
◎
or inside functional notations such as calc(), except that they must be allowed in rect() in the clip property.
</li>
		</ul>
	</li>
	<li>
上に挙げた~propを `supports$at 規則~内で構文解析するときは、
`length$t として妥当になるモノトスル
— `CSS.supports()$c ~methodにて利用されたときは、
`妥当でない^em。
◎
Additionally, while &lt;quirky-length&gt; must be valid as a &lt;length&gt; when parsing the affected properties in the @supports rule, it is not valid for those properties when used in the CSS.supports() method.
</li>
</ul>

<p>
`quirky-length$t は、
構文上は `number-token$t に一致する
— それは、
同じ値を伴う `px$u 長さとして解釈される。
（言い換えれば、
`過去互換~mode$の下では，上に挙げた~propにおける `px$u 長さは
— 単位なしの `0^v 長さと類似に —
単位を~~省いて書くことも許容される。）
◎
A &lt;quirky-length&gt; is syntactically identical to a &lt;number-token&gt;, and is interpreted as a px length with the same value.
◎
(In other words, Quirks Mode allows all px lengths in the affected properties to be written without a unit, similar to unitless zero lengths.)
</p>

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

<p>
はじめに、
この~moduleの`以前の~levelに貢献されたすべての方々＠~TR/css-values-3/#acknowledgments$に感謝する。
◎
Firstly, the editors would like to thank all of the contributors to the previous level of this module.
</p>

<div>
<p>
この~level 4 を改善する~commentと示唆を寄せていただいた，次に挙げる各氏に：
</p>

<div lang="en">
Anthony Frehner,
Emilio Cobos Álvarez,
Guillaume Lebas,
Koji Ishii,
Noam Rosenthal,
Xidorn Quan
</div>
◎
Secondly, we would like to acknowledge  for their comments and suggestions, which have improved Level 4.
</div>

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

<p>
（［
`~level 3 からの変更点＠#_changes-from-L3$／
`~level 3 に対する追加＠#additions-L3$
］は、
そこに挙げられたもののみならず，以下すべてを含む。）
◎
Recent Changes
◎
(This is a subset of Additions Since Level 3.)
</p>

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

<dl>
	<dt>
`2023年 12 月 18日 作業草案＠~TR/2023/WD-css-values-4-20231218/$
からの~~有意な変更点
◎
Substantial changes since 18 December 2023 WD:
</dt>
	<dd>
`clamp$f 用の値 `none$v を追加した。
（ `9713$issue ）
◎
Added the none values to clamp(), (Issue 9713)
</dd>
	<dd>
型~推論において百分率を どう取扱うかを一般に修正した。
（ `10017$issue ）
◎
Generally fixed how type inference handles percentages. (Issue 10017)
</dd>
	<dd>
`表示域~百分率による長さ$の `overflow$p に対する依存性を復旧した。
加えて， `scrollbar-gutter$p に対する依存性を追加した
— これらの単位の 100 倍が実際に`初期~包含塊$に合致することをアリにするため。
（ `6026$issue ）
◎
Restored dependency of viewport-percentage lengths on overflow: scroll and added one on scrollbar-gutter to make it possible for 100 of these units to actually match the initial containing block. (Issue 6026)
</dd>
	<dd>
`round$f において、
~vA の型が `number$t の場合には，
~vB を省略することを許容した。
（ `9668$issue ）
◎
Allow B to be omitted in round() if the A’s type is &lt;number&gt;. (Issue 9668)
</dd>

	<dt>
`2023年 10 月 27日 作業草案＠~TR/2023/WD-css-values-4-20231027/$
からの~~有意な変更点
◎
Substantial changes since 27 October 2023 WD:
</dt>
	<dd>
既存の相互運用能, および~Web互換性の制約により、
`既定の表示域~用の百分率~単位$を`大きい表示域~用の百分率~単位$に留めた
— “既定では~data喪失を避けるとする原則” に違反するにもかかわらず。
（ `6452$issue ）
◎
Pinned the default viewport-percentage units to the large viewport-percentage units—despite violation of the “avoid dataloss by default principle”—given existing interoperability and presumed Web-compat restriction. (Issue 6452)
</dd>
	<dd>
`~CSS文法~生成規則~block$の慣例~用の明示的な定義を追加した。
（ `2921$issue ）
◎
Added an explicit definition for the CSS grammar production block convention. (Issue 2921)
</dd>
	<dd>
~percent-符号化された~URLの文字~符号化法を明確化した。
（ `9301$issue ）
◎
Clarified character encoding of percent-encoded URLs. (Issue 9301)
</dd>

	<dt>
`2023年 4月 6日 作業草案＠~TR/2023/WD-css-values-4-20230406/$
からの~~有意な変更点
◎
Substantial changes since 6 April 2023 WD:
</dt>
	<dd>
<p>
`mix$f を `~level 5$ へ~~先送りした。
（ `9343$issue ）
</p>

<p class="trans-note">【
したがって、
以下に現れる `mix^f に関する変更点も，今やこの~levelの一部を成さない。
】</p>

◎
Punted mix() to [css-values-5]. (Issue 9343)
</dd>
	<dd>
`color$t 型は`加法的でない$ものと定義した。
（ `8576$issue ）
◎
Color type defined to be non-additive. (Issue 8576)
</dd>
	<dd>
~prop以外の文脈においては、
`~math関数$を指定d値として扱うようにした。
（ `7964$issue ）
◎
Non-property contexts treat math functions as specified values. (Issue 7964)
</dd>
	<dd>
~CSSからの~URLは、
常に~UTF-8として伝送するものと指定した。
（ `9301$issue ）
◎
Specified that URLs from CSS are always transmitted as UTF-8. (Issue 9301)
</dd>
	<dd>
［
`加算$／`累積$
］が［
加法的／累積的
］でない場合に 値A を利用していたのを 値B を利用するよう修正した。
（ `9070$issue ）
◎
Fixed addition/accumulation to use the *second* value, when the two values aren’t additive/accumulative. (Issue 9070)
</dd>
	<dd>
`~fontに相対的な長さ$は、
`font-*^p ~prop内で利用されるときは，
常に親~要素を~~基準に解決されるものと指定した。
（ `8169$issue ）
◎
Specified that font-relative lengths are always resolved against the parent element when used in a font-* property. (Issue 8169)
</dd>
	<dd>
【`計算式~tree$において】［
`min$f ／ `max$f
］関数が引数を 1 個だけとる場合を単純~化した。
（ `9559$issue ）
◎
Simplify away single-argument min() and max() functions. (Issue 9559)
</dd>

	<dt>
`2022年 10月 19日 作業草案＠~TR/2022/WD-css-values-4-20221019/$
からの~~有意な変更点
◎
Substantial changes since 19 October 2022 WD:
</dt>
	<dd>
`§ 関数-記法の定義＠#component-functions$を追加して，
`関数-記法$の構文を定義する仕方を正式に定義した。
（ `2921$issue ）
◎
Added § 2.6 Functional Notation Definitions to formally define the way that functional notation syntaxes are defined. (Issue 2921)
</dd>
	<dd>
`長さを機器~画素の整数倍に留める$~algoを追加した
— 描線幅の描画が一貫するための相互運用可能な規則を反映するよう。
（`5210$issue）
◎
Added algorithm for snap as a border width, to reflect the interoperable rules for rendering consistent stroke widths. (Issue 5210)
</dd>
	<dd>
`mix$f の文法と`算出d値$を明確化した。
（`8096$issue）
◎
Clarified grammar and computed value of mix(). (Issue 8096)
</dd>
	<dd>
`tan$f の漸近~値における挙動を未定義とした。
（`8527$issue）
◎
Undefined the behavior of tan() at the asymptote values. (Issue 8527)
</dd>
	<dd>
負な `resolution$t 値は、［
定義により，範囲~外になる
］ことを指定した。
（`8532$issue）
◎
Specified that negative &lt;resolution&gt; values are out-of-range by definition. (Issue 8532)
</dd>
	<dd>
`mix$f の【 2 個目, 3 個目の】引数は、
全部的に省略されても妥当になることを明確化した。
（`8556$issue）
◎
Clarified that fully omitted mix() arguments are valid. (Issue 8556)
</dd>
	<dd>
【`計算式$において】範囲への切詰ngが起こるのは、
特定的に，`~top-levelの計算式$に限られることを明確化した
（不明瞭な用語 “式” ではなく）。
（`8158$issue）
◎
Clarified that range clamping happens specifically to top-level calculations (rather than the unclear term "expressions"). (Issue 8158)
</dd>
	<dd>
［
`url$f ／ `src$f
］用の正式な定義を追加した
（ `url$t に加えて）。
◎
Added formal definitions for &lt;url()&gt; and &lt;src()&gt; (in addition to &lt;url&gt;).
</dd>
	<dd>
素片のみの~URLを用語`~tree視野な参照$で言い直した。
（`3320$issue）
◎
Rephrased fragment-only URLs in terms of tree-scoped references. (Issue 3320)
</dd>

	<dt>
`2021年 12月 16日 作業草案＠~TR/2021/WD-css-values-4-20211216/$からの~~有意な変更点
◎
Substantial changes since 16 December 2021 WD:
</dt>
	<dd>
`url$f の`局所~URLか$ ~EQ ~T の場合には、
現在の`~node~tree$を基準に解決されるよう変更した
（文書の基底~URLが改変されようが）。
（ `3320$issue ）
◎
Changed resolution of a url() with the local url flag to reference the current node tree (regardless of document base URL modifications). (Issue 3320)
</dd>
	<dd>
`~math関数$から外へ~~漏れる `NaN$v は、
`infinity$v ではなく 0 に同化されるよう切替えた。
（ `7067$issue ）
◎
Switched censoring of NaN that escapes a math function from infinity to zero. (Issue 7067)
</dd>
	<dd>
`§ 協調している~list値をとる~prop群＠#linked-properties$を追加した
— この~prop~patternを容易に参照することを許容するため。
（ `7164$issue ）
◎
Added Appendix A: Coordinating List-Valued Properties to allow this property pattern to be easily referenced. (Issue 7164)
</dd>
	<dd>
`mix$f は、
宣言の値~全体を成すとするよう制約した。
（ `6700$issue ）
◎
Restricted mix() to be the sole value of a declaration. (Issue 6700)
</dd>
	<dd>
最新な `FETCH$r に合致するよう各種用語を更新した。
（ `Fetch PR #1413＠https://github.com/whatwg/fetch/pull/1413$,
`CSS PR #7160＠https://github.com/w3c/csswg-drafts/pull/7160$ ）
◎
Updated to match latest Fetch terminology. (Fetch PR 1413, CSS PR 7160)
</dd>
	<dd>
`~fontに相対的な長さ$は、
~text形状付けを伴わずに計算されることを明確化した。
◎
Clarified that the font-relative lengths are calculated without text shaping.
</dd>
	<dd>
空な~URLの直列化は `url("")^v になるものと定義した。
（ `6447$issue ）
◎
Defined serialization of empty urls to be url(""). (Issue 6447)
</dd>
	<dd>
`position$t の`指定d値$の直列化を定義した。
（ `2274$issue ）
◎
Defined serialization of &lt;position&gt; specified values. (Issue 2274)
</dd>
	<dd>
`実数$の定義を［
`decimal^en 【小数点を伴わない 10 進整数】にも，科学的記数法と組合せることを許容する
］よう修正した
— 元々意図されたとおり, および
`CSS-SYNTAX-3$r にて定義されたとおり。
（ `7248$issue ）
◎
Fixed definition of numbers to allow decimals in combination with scientific notation, as originally intended and as defined in [CSS-SYNTAX-3]. (Issue 7248)
</dd>
	<dd>
様々な関数を［
それらの`型$が «[ `number^l → 1 ]» に代えて空な~mapを返す
］よう正した。
（ `7486$issue ）
◎
Corrected various functions to return an empty map for their type instead of «[ "number" → 1 ]». (Issue 7486)
</dd>
	<dd>
［
`line-height$p, `lh$u, `rlh$u
］に対する［
~UAによる特別な制約
］による効果を明確化した。
（ `3257$issue ）
◎
Clarified effect of special UA restrictions on line-height on lh and rlh. (Issue 3257)
</dd>
	<dd>
`関数-記法$を指すための `function()^t 記法【 %function は任意の名前】を定義した。
（ `5728$issue ）
◎
Defined &lt;function()&gt; notation to refer to functional notations. (Issue 5728)
</dd>

	<dt>
`2021年 10月 16日 作業草案＠~TR/2021/WD-css-values-4-20211016/$
からの~~有意な変更点
◎
Substantial changes since 16 October 2021 WD:
</dt>
	<dd>
［
`*vi^u, `*vb^u
］単位を［
要素~自身の書字~modeの算出d値を~~基準に解決する
］よう切替えた。
（ `6873$issue ）
◎
Switched *vi and *vb units to resolve against the computed writing mode of the element itself. (Issue 6873)
</dd>
	<dd>
~CORSとの統合, 等々を定義するため、
`§ ~URL処理~model＠#url-processing$
を追加した。
（ `562$issue ）
◎
Added § 4.5.4 URL Processing Model to define integration with CORS, etc. (Issue 562)
</dd>
	<dd>
~UI変化の種別に応じてアテガわれる`表示域~百分率による長さ$の挙動（ (A) か (B) か）が，
逆になっていたのを修正した。
◎
Fixed the inverted assignment of viewport-percentage length behaviors to types of interface changes (A vs. B).
</dd>
	<dd>
`calc$f を成す［
項,
引数,
入子ng~level
］として~supportされる最小な数を 32 と定義した。
（ `3462$issue ）
◎
Defined minimum number of calc() terms, arguments, and nesting as 32. (Issue 3462)
</dd>
	<dd>
`mod(-0, infinity)^v は、
`NaN$v を返すものと定義した。
（ `4723$issue ）
◎
Defined that mod(-0, infinity) returns NaN. (Issue 4723)
</dd>
	<dd>
`toggle^f, `attr^f を`~level 5$ へ先送りした。
◎
Deferred toggle() and attr() to Level 5.
</dd>

	<dt>
`2021年 9月 30日 作業草案＠~TR/2021/WD-css-values-4-20210930/$
からの変更点
◎
Changes since 30 September 2021 WD:
</dt>
	<dd>
次に挙げる単位を追加した
⇒
`rex$u,
`rcap$u,
`rch$u,
`ric$u
◎
Added rex, rcap, rch, and ric units.
</dd>
	<dd>
`toggle^f は、
~semicolonを利用するよう切替えた
— `mix$f と合致するよう。
（ `6701$issue ）
◎
Switched toggle() to use semicolons, matching with mix(). (Issue 6701)
</dd>
	<dd>
`calc$f の定義における言い回しの誤りを修正した。
（ `6506$issue ）
◎
Fixed some wording errors in the definition of calc(). (Issue 6506)
</dd>
	<dd>
`QUIRKS$r から `quirky-length$t の定義を取込んだ。
（ `6100$issue ）
◎
Imported definition of &lt;quirky-length&gt; from [QUIRKS]. (Issue 6100)
</dd>

	<dt>
`2021年 7月 7日 作業草案＠~TR/2021/WD-css-values-4-20210715/$
からの変更点
◎
Changes since 7 July 2021 WD:
</dt>
	<dd>
補間された値を表現するためとして，
`mix$f 記法を追加した。
◎
Added mix() notation for representing interpolated values.
</dd>
	<dd>
［
`integer$t,
`number$t,
`percentage$t,
`length$t
］の算出を汎用~的に定義した。
◎
Defined generically the computation of &lt;integer&gt;, &lt;number&gt;, &lt;percentage&gt;, and &lt;length&gt;.
</dd>
	<dd>
［
百分率, 長さ
］が混在なもの【~math式】が［
~table~cellを `~autoS$v ~sizingに切替える
］のは、
長さが 0 でない場合に限られることを明確化した。
◎
Clarified that only non-zero lengths create a percentage+length mix that switches table cells to auto sizing.
</dd>

	<dt id="changes-recent">
`2020年 11月 11日 作業草案＠~TR/2020/WD-css-values-4-20201111/$
からの変更点
◎
Changes since 11 November 2020 WD:
</dt>
	<dd>
色の補間を `CSS-COLOR-3$r に代えて `CSS-COLOR-4$r を参照するよう更新した。
◎
Updated interpolation of colors to reference [CSS-COLOR-4] instead of [CSS-COLOR-3].
</dd>
	<dd>
<p>
次に挙げる単位を追加した
（ `4329$issue, `6113$issue ）：
</p>
		<ul>
			<li>
`小さい表示域~用の百分率~単位$
⇒＃
`svh$u,
`svw$u,
`svi$u,
`svb$u,
`svmin$u,
`svmax$u,
</li>
			<li>
`大きい表示域~用の百分率~単位$
⇒＃
`lvh$u,
`lvw$u,
`lvi$u,
`lvb$u,
`lvmin$u,
`lvmax$u,
</li>
			<li>
`動的な表示域~用の百分率~単位$
⇒＃
`dvh$u,
`dvw$u,
`dvi$u,
`dvb$u,
`dvmin$u,
`dvmax$u
</li>
		</ul>
◎
Added the svh, svw, svi, svb, svmin, and svmax small viewport-percentage units; lvh, lvw, lvi, lvb, lvmin, and lvmax large viewport-percentage units; and dvh, dvw, dvi, dvb, dvmin, and dvmax dynamic viewport-percentage units. (Issue 4329 and Issue 6113)
</dd>
	<dd>
過度に巨大な `angle$t 値は、
`360deg^v の整数倍に切詰めるようにした。
（ `6105$issue ）
◎
Clamped excessively large &lt;angle&gt; values to multiples of 360deg. (Issue 6105)
</dd>
	<dd>
`~CSS遷移＠~TR/css-transitions-1/$
仕様から移動する間に失われた
`結合された値に対する範囲の検査-法＠#combining-range$を追加して戻した。
（ `6097$issue ）
◎
Added back rules on range-checking combined values lost during move from the CSS Transitions specification. (Issue 6097)
</dd>
	<dd>
~UAが課す最小~font~sizeは、
`~fontに相対的な長さ$の解決ではなく，
`font-size$p の使用~値に適用するものと指定した。
（ `5858$issue ）
◎
Specified that UA-imposed minimum font sizes apply to the used font-size and not to resolution of font-relative lengths. (Issue 5858)
</dd>
	<dd>
［
`min$f ／ `max$f
］による百分率を部分的に どう単純~化できるかを明確化した。
（ `6293$issue ）
◎
Clarified how min() and max() percentages can partially simplify. (Issue 6293)
</dd>

	<dt id="_changes-from-L3">
`~level 3＠~TR/css-values-3/$
からの変更点
◎
Additions Since Level 3
◎
Changes since CSS Values and Units Level 3:
</dt>
	<dd>
数量-［
精度／範囲
］を明示的に未定義にした。
◎
Explicitly undefined numeric precision/range.
</dd>
	<dd>
各~値~型ごとに補間~用の規則を追加して，それらの算出d値を明確化した。
◎
Added rules for interpolation per value type, and their clarified computed values.
</dd>
	<dd>
色の補間を `CSS-COLOR-4$r を参照するよう更新した。
◎
Updated interpolation of colors to reference [CSS-COLOR-4].
</dd>

	<dt id="additions-L3">
`~level 3＠~TR/css-values-3/$
に対する追加
◎
Additions since CSS Values and Units Level 3:
</dt>
	<dd>
`dashed-ident$t 型を定義した。
◎
Defined the &lt;dashed-ident&gt; type.
</dd>
	<dd>
`ratio$t 型を定義した。
◎
Defined the &lt;ratio&gt; type.
</dd>
	<dd>
`url$t 型に `src$f を追加した。
◎
Added src() to the &lt;url&gt; type.
</dd>
	<dd>
長さ単位として次を追加した
⇒＃
`vi$u,
`vb$u,
`ic$u,
`cap$u,
`lh$u,
`rlh$u 
◎
Added the vi, vb, ic, cap, lh and rlh length units.
</dd>
	<dd>
<p>
次に挙げる単位を追加した：
</p>
		<ul>
			<li>
`小さい表示域~用の百分率~単位$
⇒＃
`svh$u,
`svw$u,
`svi$u,
`svb$u,
`svmin$u,
`svmax$u,
</li>
			<li>
`動的な表示域~用の百分率~単位$
⇒＃
`dvh$u,
`dvw$u,
`dvi$u,
`dvb$u,
`dvmin$u,
`dvmax$u
</li>
		</ul>
◎
Added the svh, svw, svi, svb, svmin, and svmax small viewport-percentage units and＼
dvh, dvw, dvi, dvb, dvmin, and dvmax dynamic viewport-percentage units.
</dd>
	<dd>
`dppx$u の別名として，
`x$u を追加した。
◎
Added the x alias to dppx.
</dd>
	<dd>
比較~関数として次を追加した
⇒＃
`min$f,
`max$f,
`clamp$f
◎
Added min(), max(), and clamp() comparison functions.
</dd>
	<dd>
次に挙げる~math関数を追加した
⇒＃
`round$f,
`mod$f,
`rem$f,
`sin$f,
`cos$f,
`tan$f,
`asin$f,
`acos$f,
`atan$f,
`atan2$f,
`pow$f,
`sqrt$f,
`hypot$f,
`log$f,
`exp$f,
`abs$f,
`sign$f
◎
Added round(), mod(), rem(), sin(), cos(), tan(), asin(), acos(), atan(), atan2(), pow(), sqrt(), hypot(), log(), exp(), abs(), sign() math functions.
</dd>
	<dd>
`calc$f における利用-用に，次に挙げる定数を追加した
⇒＃
`e$v,
`pi$v,
`infinity$v,
`-infinity$v,
`NaN$v
◎
Added e, pi, infinity, -infinity, NaN constants for use in calc().
</dd>
	<dd>
`calc$f に
`単位~代数＠#calc-type-checking$を追加して，
`次元$の乗算と除算を許容した。
◎
Added unit algebra to calc(), allowing multiplication and division of dimensions.
</dd>
	<dd>
［
`integer$t が要求される所で利用された `calc^f
］を解決した結果が整数でないときは、
自動的に`最も近い整数に丸められ$るとした。
◎
A non-integer in a calc() automatically rounds to the nearest integer when used where an &lt;integer&gt; is required.
</dd>
	<dd>
`~math関数$の`直列化＠#calc-serialize$を定義した。
◎
Defined serialization of math functions.
</dd>
	<dd>
汎用~化された`協調している~list~prop~group$の定義を追加した
— 各種 `background-*^p ~propの協調している挙動を より容易に参照するため。
◎
Added a genericized definition of coordinating list property groups, to make it easier to reference the coordinating behavior of the background properties.
</dd>
</dl>

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

<p>
この仕様が呈示する新たな~securityの考慮点は無い。
◎
This specification presents no new security considerations.
</p>

<p>
この仕様は、［
`url$f, `src$f
］関数（ `url$t ）を定義する
— それは、
~CSSから~network要請を為すことを許容する。
これらは、
どの特能において利用されるかに依存して，［
~network上の資源への~accessを利用者が有するかどうか,
それらの内容についての情報
］を公開するものになり得る
（~stylesheetの中の規則, 画像の~size, ~fontの計量など）。
また、
~URLを介して~dataが漏出することも許容し得る。
◎
This specification defines the url() and src() functions (&lt;url&gt;), which allow CSS to make network requests. Depending on what features they are used in, these can potentially expose whether or not the user has access to resources on a network, and expose information about their contents (such as the rules within a style sheet, the size of an image, the metrics of a font). They can also allow exfiltrating data via URL.
</p>

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

<p>
この仕様は、
利用者の［
~screen~size（`表示域~百分率による長さ$）,
既定の~font~size
］を公開する単位を定義する。
また、［
利用者の~systemにて，どの~fontが可用か
］について何らかの情報を公開し得る単位も定義する（`~fontに相対的な長さ$）。
◎
This specification defines units that expose the user’s screen size (the viewport-percentage lengths), default font size, and potentially some information about which fonts are available on the user’s system (the font-relative lengths).
</p>

<p>
この仕様は、［
`url$f, `src$f
］関数（ `url$t ）を定義する
— それは、
~CSSから~network要請を為すことを許容する。
これらは、
どの特能において利用されるかに依存して，［
~network上の資源への~accessを利用者が有するかどうか,
それらの内容についての情報
］を公開するものになり得る
（~stylesheetの中の規則, 画像の~size, ~fontの計量など）。
また、
~URLを介して~dataが漏出することも許容し得る。
◎
This specification defines the url() and src() functions (&lt;url&gt;), which allow CSS to make network requests. Depending on what features they are used in, these can potentially expose whether or not the user has access to resources on a network, and expose information about their contents (such as the rules within a style sheet, the size of an image, the metrics of a font). They can also allow exfiltrating data via URL.
</p>

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