1. 序論
各種~CSS~propの定義表における値~定義の欄には、 ~keyword, ~data型(山括弧 `<^c, `>^c で括られて現れる), および それらをどう組合せるかについての情報を包含している。 この仕様では、多くの~propから利用できる,汎用~data型(最も広く利用されている `length$t など)について述べる。 より特定な~data型(例えば `spacing-limit^t )は、対応している~moduleにて述べられる。 ◎ The value definition field of each CSS property can contain keywords, data types (which appear between < and >), and information on how they can be combined. Generic data types (<length> being the most widely used) that can be used by many properties are described in this specification, while more specific data types (e.g., <spacing-limit>) are described in the corresponding modules.
1.1. ~module間の相互作用
この~moduleは `CSS21$r の § 1.4.2.1, § 4.3, § A.2 にて定義される~data型を置換し, 拡張する。 ◎ This module replaces and extends the data type definitions in [CSS21] sections 1.4.2.1, 4.3, and A.2.
2. 値~定義の構文
ここに述べる `値~定義の構文@ は、~CSS~prop用の妥当な値が成す集合(および,~CSSにおける他の多くの部分を成す妥当な構文)を定義するために利用される。 そのように述べられた値は、 1 個以上の成分からなり得る。 ◎ The value definition syntax described here is used to define the set of valid values for CSS properties (and the valid syntax of many other parts of CSS). A value so described can have one or more components.
2.1. 成分~値の型
~propの成分~値の型は、その値~定義において,以下の仕方で指名される: ◎ Component value types are designated in several ways:
- 引用符や山括弧を伴わずに,~literalに現れるものは、`~keyword$値である( `auto^v, `disc$v, 等々)。 ◎ keyword values (such as auto, disc, etc.), which appear literally, without quotes (e.g. auto)
- 基本~data型は、山括弧( `<^g, `>^g )で括られて現れる( `length$t, `percentage$t, 等々)。 `数量-~data型$に対しては、下に述べる`角括弧付き範囲~記法$を利用して,この型~記法に範囲~制約を注釈できる。 ◎ basic data types, which appear between < and > (e.g., <length>, <percentage>, etc.). For numeric data types, this type notation can annotate any range restrictions using the bracketed range notation described below.
-
同じ名前を持つ~propと同じ範囲の値をとる,型(例えば `border-width$tp, `background-attachment$tp など)。 この場合、その型の名前は,山括弧の間の(引用符で完結する)~prop名になる。 ただし,この種の型は、次に該当するものは `含まない^em:
- `inherit$v などの `~CSS全域~keyword$値。 【どの~propも,この種の値をとれるものとされているので。】
- ~top-levelの~comma区切りの~list用の量指定子( `#^g )(すなわち,ある名前の~prop `pairing^p の値が [ `custom-ident$t `integer$t? ]# として定義されている場合、 `pairing^tp は [ `custom-ident$t `integer$t? ] に等価になる — [ `custom-ident$t `integer$t? ]# ではなく)。 【この規約は、様々な型の値~定義を簡素化できるようにするためにある。】
- 非末端型【他の型や個々の値を組合せて定義される型】は、~propと同じ名前を共有しない。 この場合の非末端型の名前は、 `spacing-limit^t のように,山括弧( `<^g, `>^g )で括られて現れる。 `border-width^t と `border-width$tp との間の差異に注意: 後者は, `border-width$p ~propがとり得る値として定義される一方、前者は,他のどこかで 明示的に拡張pが定義される必要がある。 非末端型の定義は、概して,仕様の中でそれが最初に現れる近辺に示される。 ◎ non-terminals that do not share the same name as a property. In this case, the non-terminal name appears between < and >, as in <spacing-limit>. Notice the distinction between <border-width> and <'border-width'>: the latter is defined as the value of the border-width property, the former requires an explicit expansion elsewhere. The definition of a non-terminal is typically located near its first appearance in the specification.
一部の~propの値~定義は、[ ~slash( `/^c )/~comma( `,^c )/丸括弧( `(^c, `)^c ) ]も~literalとして含むことがある。 これらは、対応する~tokenを表現する。 正符号( `+^c )など,他の成分~値に現れ得る~keywordでない~literal文字は、一重~引用符で括って記されなければナラナイ。 ◎ Some property value definitions also include the slash (/), the comma (,), and/or parentheses as literals. These represent their corresponding tokens. Other non-keyword literal characters that may appear in a component value, such as “+”, must be written enclosed in single quotes.
文法において指定された `~comma@ ( `,^g )は、省略可能な項を区切るために利用されたときは, 一部の状況下では `暗黙的に省略-可能になる^em。 また,文法において[ ~propや他の~CSS値の中の~top-levelの~list, あるいは 関数の引数~list ]の中に指定された~commaは、次に挙げる場合には,省略されなければナラナイ: ◎ Commas specified in the grammar are implicitly omissible in some circumstances, when used to separate optional terms in the grammar. Within a top-level list in a property or other CSS value, or a function’s argument list, a comma specified in the grammar must be omitted if:
- ~commaに先行するすべての項が省略された場合 ◎ all items preceding the comma have been omitted
- ~commaに後続するすべての項が省略された場合 ◎ all items following the comma have been omitted
- ~commaに挟まれた項が省略されると,複数の~commaが(`空白$や~commentを無視して)連続することになる場合 ◎ multiple commas would be adjacent (ignoring white space/comments), due to the items between the commas being omitted.
例えば,[ どれも省略可能な, 3 個の引数 ]を受容する関数の文法は、次の様に記せる: ◎ For example, if a function can accept three arguments in order, but all of them are optional, the grammar can be written like:
example( first`?$g `,$g second`?$g `,$g third`?$g )
この文法の下では、 `example(first, second, third)^v は妥当であり, `example(first, second)^v / `example(first, third)^v / `example(second)^v も同様である。 一方で, `example(first, , third)^v は、無効になる。 ~commaには、 2 つの選択肢を分離することが要求されるので。 同じ理由から、 `example(,second)^v / `example(first,)^v / `example(first second)^v も無効になる。 ◎ Given this grammar, writing example(first, second, third) is valid, as is example(first, second) or example(first, third) or example(second). However, example(first, , third) is invalid, as one of those commas are no longer separating two options; similarly, example(,second) and example(first,) are invalid. example(first second) is also invalid, as commas are still required to actually separate the options.
~commaが暗黙的に省略し得ないものであったなら、省略し得る引数を適正に表出するための文法は,ずっと複雑になり,その特能の単純~性も損なわれるであろう。 ◎ If commas were not implicitly omittable, the grammar would have to be much more complicated to properly express the ways that the arguments can be omitted, greatly obscuring the simplicity of the feature.
すべての~CSS~propには、~prop値の単独の成分として, `~CSS全域~keyword$値が受容される。 可読性のため、これらの~prop値は,構文~定義には明示的に挙げられない。 例えば, `border-color$p の値~定義は( `color^t{1,4} と示されているが),~~実際には: [ `color^t{1,4} ] | `inherit$v | `initial$v | `unset$v である。 ◎ All CSS properties also accept the CSS-wide keyword values as the sole component of their property value. For readability these are not listed explicitly in the property value syntax definitions. For example, the full value definition of border-color is <color>{1,4} | inherit | initial | unset (even though it is listed as <color>{1,4}).
【 `~CSS全域~keyword$の節に付記されているように,新たな全域~keywordが導入されれば、それらも追加されることになるであろう(しかしながら,仮に導入された場合、 作者~定義な識別子 との衝突から,後方-互換性の問題も生じ得ることになる)。 】
注記: したがって、一般に,同じ宣言の中で これらの~keywordが他の成分~値と組合された場合、その宣言は無効になる。 例えば `background$p: `url(corner.png) no-repeat, inherit^v; は、無効になる。 ◎ Note: This implies that, in general, combining these keywords with other component values in the same declaration results in an invalid declaration. For example, background: url(corner.png) no-repeat, inherit; is invalid.
2.2. 成分~値の結合子
~propの値~定義においては、各~成分~値が次の組合nで配列される: ◎ Component values can be arranged into property values as follows:
- (結合子を挟まずに)並記された成分
- それらの成分すべてが,示された順序で現れなければナラナイ。 ◎ Juxtaposing components means that all of them must occur, in the given order.
- 二重~ampersand( `~AMP~AMP^g )
- 複数個の成分の区切り — それらの成分すべてが現れなければナラナイが,その順序は任意である。 ◎ A double ampersand (&&) separates two or more components, all of which must occur, in any order.
- 二重~縦線( `||^g )
- 複数の選択肢の区切り — それらのうち 1 個以上が現れなければナラナイが,その順序は任意である。 ◎ A double bar (||) separates two or more options: one or more of them must occur, in any order.
- 縦線( `|^g )
- 複数の排他的選択肢の区切り: それらのうち,きっかり 1 個が現れなければナラナイ。 ◎ A bar (|) separates two or more alternatives: exactly one of them must occur.
- 角括弧( `[…]^g )
- ~group化を表す。 ◎ Brackets ([ ]) are for grouping.
これらの結合順位は優先度の高いものから、[ 並記, 二重~ampersand, 二重~縦線, 縦線 ]の順になる。 したがって,次の 2 つの行は等価になる: ◎ Juxtaposition is stronger than the double ampersand, the double ampersand is stronger than the double bar, and the double bar is stronger than the bar. Thus, the following lines are equivalent:
a b | c || d ~AMP~AMP e f [ a b ] | [ c || [ d ~AMP~AMP [ e f ]]]
並び替え可能な結合子( `||$g, `~AMP~AMP$g )に対しては、文法における順序は重要でない — 同じ~group内の各~成分は、どのような順序で記されてもヨイ。 したがって,次の 2 つの行は等価になる: ◎ For reorderable combinators (||, &&), ordering of the grammar does not matter: components in the same grouping may be interleaved in any order. Thus, the following lines are equivalent:
a || b || c b || a || c
2.3. 成分~値の量指定子
どの[ 値~型 / ~keyword / 角括弧で括られた~group ]にも — 以下、これらを “構文単位” と総称する — 次のいずれかの修飾子が後置され得る: ◎ Every type, keyword, or bracketed group may be followed by one of the following modifiers:
- ~asterisk( `*^g )
- 直前の構文単位の 0 回以上の出現を指示する。 ◎ An asterisk (*) indicates that the preceding type, word, or group occurs zero or more times.
- 正符号( `+^g )
- 直前の構文単位の 1 回以上の出現を指示する。 ◎ A plus (+) indicates that the preceding type, word, or group occurs one or more times.
- 疑問符( `?^g )
- 直前の構文単位が省略可能であること(すなわち 0 回または 1 回の出現)を指示する。 ◎ A question mark (?) indicates that the preceding type, word, or group is optional (occurs zero or one times).
- 波括弧に括られた整数( `{~vA}^g )
- 直前の構文単位の ~vA 回の出現を指示する。 ◎ A single number in curly braces ({A}) indicates that the preceding type, word, or group occurs A times.
- 波括弧に括られた~comma区切りの整数の組( `{~vA,~vB}^g )
- 直前の構文単位の ~vA 回から ~vB 回までの出現を指示する。 ~vB は省略されてもよく( `{~vA,}^g ),その場合は ~vA 回 以上, 上限なしの出現を指示する。 ◎ A comma-separated pair of numbers in curly braces ({A,B}) indicates that the preceding type, word, or group occurs at least A and at most B times. The B may be omitted ({A,}) to indicate that there must be at least A repetitions, with no upper bound on the number of repetitions.
- ~hash記号( `#^g )
-
直前の構文単位が~comma~tokenで区切られた上で 1 回以上 出現することを指示する(~commaの前後に`空白$や~commentが現れてもヨイ)。
これには省略可能な上述の波括弧 形が後続し得る(例えば
`length$t#{1,4}
)。 その場合、より精確な出現回数を指示する。 ◎ A hash mark (#) indicates that the preceding type, word, or group occurs one or more times, separated by comma tokens (which may optionally be surrounded by white space and/or comments). It may optionally be followed by the curly brace forms, above, to indicate precisely how many times the repetition occurs, like <length>#{1,4}. - ~groupの直後の感嘆符( `!^g )
- その~groupが必須であり, 1 個以上の値を生産しなければナラナイことを指示する。 すなわち、~group内の各項は文法により個別的に省略し得るとしても,全体としては成分~値をすべて省略してはならない。 ◎ An exclamation point (!) after a group indicates that the group is required and must produce at least one value; even if the grammar of the items within the group would otherwise allow the entire contents to be omitted, at least one component value must not be omitted.
繰返される( `*$g, `+$g, `#$g で指示される)成分~値に対しては、~UAは、少なくとも 20 回以上の繰返nを~supportするモノトスル。 ~prop値が,~supportする数を超える成分の繰返nを包含する場合、その宣言は,無効であったかのように無視するモノトスル。 ◎ For repeated component values (indicated by *, +, or #), UAs must support at least 20 repetitions of the component. If a property value contains more than the supported number of repetitions, the declaration must be ignored as if it were invalid.
2.4. 結合子と量指定子の~pattern
特定の個数と順序による,複数の独立な`成分~値$を組合せるための、共通な仕方がいくつかある。 特に、仕様の策定者が,[ 作者は、成分~値のある集合の中から,[ 文法に指定された順序,または任意の順序 ]で[ 0 個以上/ 1 個以上/すべて ]を選定しなければナラナイ ]ことを表出したいことは、よくある。 ◎ There are a small set of common ways to combine multiple independent component values in particular numbers and orders. In particular, it’s common to want to express that, from a set of component value, the author must select zero or more, one or more, or all of them, and in either the order specified in the grammar or in any order.
これらはすべて、`結合子$や`量指定子$による単純な~patternを利用して,容易に表出できる: ◎ All of these can be easily expressed using simple patterns of combinators and multipliers:
指定された順序 | 任意の順序 | |
---|---|---|
0 個以上 | `~vA? ~vB? ~vC?^g | `~vA? || ~vB? || ~vC?^g |
1 個以上 | `[ ~vA? ~vB? ~vC? ]!^g | `~vA || ~vB || ~vC^g |
すべて | `~vA ~vB ~vC ^g | `~vA ~AMP~AMP ~vB ~AMP~AMP ~vC^g |
順序が “任意” のものは,どれも結合子を利用して表出される一方、 “指定された順序” のものは,どれも並記になっていることに注意。 ◎ Note that all of the "any order" possibilities are expressed using combinators, while the "in order" possibilities are all variants on juxtaposition.
2.5. 成分~値と空白
他が指定されない限り、`空白$や~commentが,[ 上の`結合子$や`量指定子$を利用して結合された成分の前後や, その各~成分の合間 ]に現れてもヨイ。 ◎ Unless otherwise specified, white space and/or comments may appear before, after, and/or between components combined using the above combinators and multipliers.
注記: 多くの場合、互いの~tokenを判別するため,成分~間の~spaceが~~実際に`要求される^em。 例えば,値 `1em2em^v は、数字 `1^v と無効な単位~識別子 `em2em^u を伴う,単独の `dimension-token$t として構文解析されることになる。 この場合、 2 個の長さ値[ `1em^v, `2em^v ]として構文解析されるためには,数字 `2^v の前に~spaceが要求される。 ◎ Note: In many cases, spaces will in fact be required between components in order to distinguish them from each other. For example, the value 1em2em would be parsed as a single <dimension-token> with the number 1 and the identifier em2em, which is an invalid unit. In this case, a space would be required before the 2 to get this parsed as the two lengths 1em and 2em.
2.6. ~prop値の例
いくつかの~propについて,対応する値~定義の欄, および値の例を下に示す: ◎ Below are some examples of properties with their corresponding value definition fields
~prop | 値~定義の欄 | 値の例 |
---|---|---|
`orphans$p | `integer^t | `3^v |
`text-align$p | `left^v | `right^v | `center^v | `justify^v | `center^v |
`padding-top$p | `length^t | `percentage^t | `5%^v |
`outline-color$p | `color^t | `invert^v | `#fefefe^v |
`text-decoration$p | `none^v | `underline^v || `overline^v || `line-through^v || `blink^v | `overline underline^v |
`font-family$p | [ `family-name^t | `generic-family^t ]# | `"Gill Sans", Futura, sans-serif^v |
`border-width$p | [ `length^t | `thick^v | `medium^v | `thin^v ]{1,4} | `2px medium 4px^v |
`box-shadow$p | [ `inset^v? ~AMP~AMP `length^t{2,4} ~AMP~AMP `color^t? ]# | `none^v | `3px 3px rgba(50%, 50%, 50%, 50%), lemonchiffon 0 0 4px inset^v |
3. 値の結合-法: 補間, 加算, 累積
例えば[ 遷移 / ~animation ]などにおける一部の手続きは、 2 個の~CSS~prop値を `結合-@ する。 所与の,ある~propの 2 個の`算出d値$ ( 値a, 値b ) を結合して,算出d値 %結果値 を得る演算【の種別】として、次のものが定義される 【具体的な演算-法は、一般に,個々の値~型ごとに定義される】: ◎ Some procedures, for example transitions and animations, combine two CSS property values. The following combining operations—on the two computed values Va and VB yielding the computed value Vresult—are defined:
- `補間@ ( `interpolation^en )
-
実数 %p に対し,[ 区間 [ 値a, 値b ] 内の,距離 %p における中間-値 ]を表す %結果値 を生産する — [ %p ~EQ 0 ならば 値a になる / %p ~EQ 1 ならば 値b になる ]ように~~拘束される下で。 ◎ Given two property values Va and VB, produces an intermediate value Vresult at a distance of p along the interval between Va and VB such that p = 0 produces Va and p = 1 produces VB.
`~easing関数$の効果に因り, %p の範囲は開区間 (−∞, ∞) にわたる。 よって,この手続きは、閉区間 [0, 1] の外側にある %p に対しても外挿の挙動を定義しなければナラナイ。 ◎ The range of p is (−∞, ∞) due to the effect of timing functions. As a result, this procedure must also define extrapolation behavior for p outside [0, 1].
- `加算@ ( `addition^en )
- ( 値a, 値b ) の総和として %結果値 を返す。 加算が可換でない場合(例えば,行列の乗算)、これらの項の順序も有意になる。 ◎ Given two property values Va and VB, returns the sum of the two properties, Vresult. For addition that is not commutative (for example, matrix multiplication) Va represents the first term of the operation and VB represents the second.
- 注記: `加算$は、`補間$の定義に利用される加重平均~関数と同じ用語に基づいて表出できることが多いが,常に該当するとは限らない。 例えば,変形-行列の補間は 行列~成分の分解-法と補間-法を孕む一方で、それらの加算は 行列の乗算に依拠する。 ◎ Note: While addition can often be expressed in terms of the same weighted sum function used to define interpolation, this is not always the case. For example, interpolation of transform matrices involves decomposing and interpolating the matrix components whilst addition relies on matrix multiplication.
- `累積@ ( `accumulation^en )
- [ 値b は 値a からの差分として扱われる ]ように結合して得られる %結果値 を返す。 累積が可換でない場合(例えば,合致していない変形-~listの累積)、これらの項の順序も有意になる。 ◎ Given two property values Va and VB, returns the result, Vresult, of combining the two operands such that VB is treated as a delta from Va. For accumulation that is not commutative (for example, accumulation of mismatched transform lists) Va represents the first term of the operation and VB represents the second.
- 注記: 実数や長さなど,多くの型の~animation用の`累積$は、`加算$と一致するように定義される。 この 2 つの定義が相違する共通的な事例として,~listに基づく型がある — そこでは、`加算$は ~listに付加するものとして, `累積$は 成分ごとの加算として定義されることもある。 例えば,~filter~list値【 `filter-value-list$t 】[ `blur(2)^v, `blur(3)^v ]は、`加算-$されるときは `blur(2) blur(3)^v を生産する一方で,`累積-$されるときは `blur(5)^v を生産することになる。 ◎ Note: For many types of animation such as numbers or lengths, accumulation is defined to be identical to addition. ◎ A common case where the definitions differ is for list-based types where addition may be defined as appending to a list whilst accumulation may be defined as component-based addition. For example, the filter list values blur(2) and blur(3), when added together would produce blur(2) blur(3), but when accumulated would produce blur(5).
これらの演算は、`算出d値$に限り定義される(その結果、例えば `length$t 値[ `15pt^v, `5em^v ]を加算する方法を定義することは,必要とされない — そのような値は、上の手続きに渡される前に`正準的~単位$の値に解決されることになるので)。 ◎ These operations are only defined on computed values. (As a result, it is not necessary to define, for example, how to add a <length> value of 15pt with 5em since such values will be resolved to their canonical unit before being passed to any of the above procedures.)
次に該当する値~型の`加算$における %結果値 は、単純に 値a【値b の誤記?】 で与えられるとする ⇒ `加算$用に特定の手続きを定義していない / `加法的でない@ ものと定義されている ◎ If a value type does not define a specific procedure for addition or is defined as not additive, its addition operation is simply Vresult = Va.
`累積$用に特定の手続きを定義しない値~型の`累積$は、その型の`加算$に一致するとする。 ◎ If a value type does not define a specific procedure for accumulation, its accumulation operation is identical to addition.
4. ~textな~data型
`~textな~data型@ は、[ 様々な~keyword, 識別子, 文字列(`string$t), ~URL( `url$t ) ]を含む。 [ `定義済み~keyword$の大小変換/所与の~prop用に明示的に定義されたもの ]は別として、~Unicode正規化も含め,いかなる正規化も遂行されない — ~propの[ `指定d値$, `算出d値$ ]は、正確に,供された~Unicode値を構文解析した結果になる(他の文字~集合からの変換, ~escape法 を含む)。 `UNICODE$r `CSS-SYNTAX-3$r ◎ The textual data types include various keywords and identifiers as well as strings (<string>) and URLs (<url>). Aside from the casing of pre-defined keywords or as explicitly defined for a given property, no normalization is performed, not even Unicode normalization: the specified and computed value of a property are exactly the provided Unicode values after parsing (which includes character set conversion and escaping). [UNICODE] [CSS-SYNTAX-3]
~CSS `識別子@ は、汎用には `ident@t で表記される, `ident-token$t `CSS-SYNTAX-3$r に適合する文字~並びからなる。 識別子は、引用符で括れない — さもなければ、文字列として解釈されることになる。 ~CSS~propは、2 種の`識別子$ — `定義済み~keyword$, 作者~定義な識別子 — を受容する。 ◎ CSS identifiers, generically denoted by <ident>, consist of a sequence of characters conforming to the <ident-token> grammar. [CSS-SYNTAX-3] Identifiers cannot be quoted; otherwise they would be interpreted as strings. CSS properties accept two classes of identifiers: pre-defined keywords and author-defined identifiers.
注記: `ident$t 生成規則は、~prop値の定義~用に意味されたものではない — 代わりに `custom-ident$t が利用されるベキである。 それは、他の構文上の構成子を簡便に定義するためとして供される。 ◎ Note: The <ident> production is not meant for property value definitions—<custom-ident> should be used instead. It is provided as a convenience for defining other syntactic constructs.
~textな~data型は、すべて`離散的$に`補間-$され,`加法的でない$。 ◎ All textual data types interpolate as discrete and are not additive.
4.1. 定義済み~keyword
値~定義の欄の中では、定義済みな意味を伴う `~keyword@ は,~literalに現れる。 ~keywordは`~CSS識別子$ であり、`~ASCII大小無視$の下で解釈される(すなわち、 a 〜 z と A 〜 Z は等価になる)。 ◎ In the value definition fields, keywords with a pre-defined meaning appear literally. Keywords are CSS identifiers and are interpreted ASCII case-insensitively (i.e., [a-z] and [A-Z] are equivalent).
例えば, `border-collapse$p ~propの値~定義は次で与えられる: ◎ For example, here is the value definition for the border-collapse property:
値 | `collapse^v | `separate^v |
---|
その用例: ◎ And here is an example of its use:
table { border-collapse: separate }
4.1.1. ~CSS全域~keyword: `initial^v, `inherit^v, `unset^v
成分~値の型に定義したように、すべての~propは `~CSS全域~keyword@ を受容する。 これらは、すべての~CSS~propに共通な値の算出法を表現する: ◎ As defined above, all properties accept the CSS-wide keywords, which represent value computations common to all CSS properties.
- ~keyword `initial$v は、~propの`初期~値$として指定されている値を表現する。 ◎ The initial keyword represents the value specified as the property’s initial value.\
- ~keyword `inherit$v は、要素の親~上の~propの`算出d値$を表現する。 ◎ The inherit keyword represents the computed value of the property on the element’s parent.\
- ~keyword `unset$v は、~propが継承するかどうかに応じて, `inherit$v か `initial$v としてふるまう。 ◎ The unset keyword acts as either inherit or initial, depending on whether the property is inherited or not.\
これらの~keywordは、 `CSS3CASCADE$r にて規範的に定義されている。 ◎ All of these keywords are normatively defined in the Cascade module. [CSS3CASCADE]
他の~CSS仕様も追加的な ~CSS全域~keywordを定義し得る。 ◎ Other CSS specifications can define additional CSS-wide keywords.
4.2. 作者~定義な識別子: `custom-ident^t 型
一部の~propは、成分~値として,作者~定義な任意な識別子を受容する。 この汎用~data型は `custom-ident@t で表記され、その~propの値~定義による`定義済み~keyword$に解釈されないような,任意の妥当な`~CSS識別子$を表現する。 その種の識別子の文字~大小は区別される(例えば `example^v と `EXAMPLE^v は、異なる, 無関係な, 作者~定義な識別子である)。 ◎ Some properties accept arbitrary author-defined identifiers as a component value. This generic data type is denoted by <custom-ident>, and represents any valid CSS identifier that would not be misinterpreted as a pre-defined keyword in that property’s value definition. Such identifiers are fully case-sensitive (meaning they’re compared using the "identical to" operation), even in the ASCII range (e.g. example and EXAMPLE are two different, unrelated user-defined identifiers).
`~CSS全域~keyword$は,妥当な `custom-ident$t ではない。 予約-済みの全域~keyword `default^v 【 `revert$v 】 もまた,妥当な `custom-ident$t ではない。 `custom-ident$t を利用する仕様は、どの~keywordが `custom-ident$t から除外されるベキかを明瞭に指定しなければナラナイ — 例えば、 “その~propの値~定義にて`定義済み~keyword$は除外される” と記すなど。 除外される~keywordと `~ASCII大小無視$で等しいものも除外される。 ◎ The CSS-wide keywords are not valid <custom-ident>s. The default keyword is reserved and is also not a valid <custom-ident>. Specifications using <custom-ident> must specify clearly what other keywords are excluded from <custom-ident>, if any—for example by saying that any pre-defined keywords in that property’s value definition are excluded. Excluded keywords are excluded in all ASCII case permutations.
~prop値において,位置により多義的になるような~keywordを構文解析するとき、 `custom-ident$t 生成規則が その~keywordに該当し得るのは,[ その~keywordに該当し得るような,未だ充足されていない生成規則 ]が他に無い場合に限られる。 ◎ When parsing positionally-ambiguous keywords in a property value, a <custom-ident> production can only claim the keyword if no other unfulfilled production can claim it.
例えば、`略式~prop$による宣言 `animation$p: `ease-in ease-out^v; は、`下位prop$による宣言 `animation-timing-function$p: `ease-in$v; `animation-name$p: `ease-out$v; に等価になる。 `ease-in$v は, `animation-timing-function$p に属する `easing-function$t 生成規則に該当する結果、 `ease-out$v は, `animation-name$p に属する `custom-ident$t 生成規則に該当するようになる。 ◎ For example, the shorthand declaration animation: ease-in ease-out is equivalent to the longhand declarations animation-timing-function: ease-in; animation-name: ease-out;. ease-in is claimed by the <easing-function> production belonging to animation-timing-function, leaving ease-out to be claimed by the <custom-ident> production belonging to animation-name.
注記: `custom-ident$t を伴う文法を設計するときは、~prop内のどの~keyword値とも競合し得なくなるよう, `custom-ident$t は 常に “位置により多義的にならない” ようにするベキである。 ◎ Note: When designing grammars with <custom-ident>, the <custom-ident> should always be "positionally unambiguous", so that it’s impossible to conflict with any keyword values in the property.
4.3. `明示的に^em作者~定義な識別子: `dashed-ident^t 型
一部の文脈は、作者~定義な識別子, ~CSS定義な識別子の`両者^emを受容する。 これは、注意深く取扱わないと,~CSS定義な新たな値を追加するときに困難さを伴い得る — ~UAは、[ 利用-中にある作者~定義な識別子のうち,~CSS定義な新たな識別子に合致しているもの ]は,ごく少数に限られるかどうか既存の用法を調査して、新たな値に~CSS定義な特別な意味を与えても,既存の~pageを壊さないことに賭ける必要がある。 ◎ Some contexts accept both author-defined identifiers and CSS-defined identifiers. If not handled carefully, this can result in difficulties adding new CSS-defined values; UAs have to study existing usage and gamble that there are sufficiently few author-defined identifiers in use matching the new CSS-defined one, so giving the new value a special CSS-defined meaning won’t break existing pages.
~CSSには,[ まさにこの~~不安を抱えた仕方で,この 2 つの値~空間が混在する ]ような多くの旧来の事例があり、 `dashed-ident$t 型は,[ 作者~定義な識別子と~CSS定義な識別子とを判別する容易な仕方になる ]ことが意味される。 ◎ While there are many legacy cases in CSS that mix these two values spaces in exactly this fraught way, the <dashed-ident> type is meant to be an easy way to distinguish author-defined identifiers from CSS-defined identifiers.
`dashed-ident@t 生成規則は、[ `custom-ident$t であり,常に文字大小区別になる ]ことに加えて,[ 2 個の~dash( `002D^U `HYPHEN-MINUS^cn )から開始しなければナラナイ ]とする制約も伴う。 ◎ The <dashed-ident> production is a <custom-ident>, with all the case-sensitivity that implies, with the additional restriction that it must start with two dashes (U+002D HYPHEN-MINUS).
`dashed-ident$t は、もっぱら作者~定義な名前~用の利用に予約される。 ~CSSは、 `dashed-ident$t を自前の利用-用に定義することは決してない。 ◎ <dashed-ident>s are reserved solely for use as author-defined names. CSS will never define a <dashed-ident> for its own use.
例えば,`~custom~prop$は、~CSS定義な~propから判別-可能になる必要がある — ~CSSには、新たな~propが定期的に追加されるので。 これを許容するため、`~custom~prop$の名前は `dashed-ident$t になることが要求される — 次の例のように: ◎ For example, custom properties need to be distinguishable from CSS-defined properties, as new properties are added to CSS regularly. To allow this, custom property names are required to be <dashed-ident>s, as in this example:
.foo { --fg-color: blue; }
`dashed-ident$t は, `color-profile$at 規則~内でも利用され、作者~定義な色~profileを `device-cmyk^v の様な定義済みなそれと別々にすることに加え、~CSSが[ 作者~定義な~profileと衝突するおそれなく, 将来にも定義済みな(かつ上書き可能な)~profileを さらに定義する ]ことを許容する: ◎ <dashed-ident>s are also used in the @color-profile rule, to separate author-defined color profiles from pre-defined ones like device-cmyk, and allow CSS to define more pre-defined (but overridable) profiles in the future without fear of clashing with author-defined profiles:
@color-profile --foo { src: url(https://example.com/foo.icc); } .foo { color: color(--foo 1 0 .5 / .2); }
将来には,~CSSは、作者により制御される構文を追加するに伴い, `dashed-ident$t をもっと利用することになる。 ~CSS著作~tool — ~customな構文を標準な~CSSに転換するような前処理器など — も、将来の~CSS設計と衝突するのを避けるよう, `dashed-ident$t を利用する`ベキ^emである。 ◎ CSS will use <dashed-ident> more in the future, as more author-controlled syntax is added. CSS authoring tools, such as preprocessors that turn custom syntax into standard CSS, should use <dashed-ident> as well, to avoid clashing with future CSS design.
例えば,~CSS前処理器が “~customな” 新たな~at-ruleを追加する場合、それを `custom^at と綴る`ベキでない^em — これは、将来に公式的な `custom^at 規則が~CSSに追加されたとき,衝突することになるので。 代わりに, `--custom^at を利用するベキである — そうすれば、~CSSが定義する何物にも決して衝突しないことが保証される。 ◎ For example, if a CSS preprocessor added a new "custom" at-rule, it shouldn’t spell it @custom, as this would clash with a future official @custom rule added by CSS. Instead, it should use @--custom, which is guaranteed to never clash with anything defined by CSS.
さらに良くするには、 `--library1-custom^at を利用するベキである — 別の~libraryが( `--library2-custom^at と綴られる) “~customな” 自前の~at-ruleを追加しても,衝突する可能性がないよう。 理想的には、~tool法にて許容されるなら,この接頭辞も — 作者が自らの手で衝突-を避けれるよう — ~custom化-可能になるベキである。 ◎ Even better, it should use @--library1-custom, so that if Library2 adds their own "custom" at-rule (spelled @--library2-custom), there’s no possibility of clash. Ideally this prefix should be customizable, if allowed by the tooling, so authors can manually avoid clashes on their own.
4.4. 引用符~付き文字列: `string^t 型
`文字列$は `string@t で表記され、一重~引用符または二重~引用符で括られた文字~並びからなる。 これらは、 `string-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。 ◎ Strings are denoted by <string> and consist of a sequence of characters delimited by double quotes or single quotes. They correspond to the <string-token> production in the CSS Syntax Module [CSS-SYNTAX-3].
二重~引用符は、( `"\""^c または `"\22"^c として)`~escape$されない限り,二重~引用符の内側に現れることはできない。 一重~引用符も同様である( `'\''^c または `'\27'^c ): ◎ Double quotes cannot occur inside double quotes, unless escaped (as "\"" or as "\22"). Analogously for single quotes ('\'' or '\27').
content: "これは '文字列'。"; content: "これは \"文字列\"。"; content: 'これは "文字列"。'; content: 'これは \'文字列\'。';
美観その他の理由で,文字列を複数~行lに分割することもアリである。 ただし,そのような場合、改行文字~自身が~backslash( \ )で~escapeされる必要がある。 それらの改行文字は、後で文字列から除去される。 例えば、次の 2 つの選択子は正確に同じになる: ◎ It is possible to break strings over several lines, for aesthetic or other reasons, but in such a case the newline itself has to be escaped with a backslash (\). The newline is subsequently removed from the string. For instance, the following two selectors are exactly the same:
a[title="そんなに長いタイ\ トルではないが"] {/*...*/} a[title="そんなに長いタイトルではないが"] {/*...*/}
文字列は 改行文字を直に表現できないので、改行文字を含ませるためには "`\A^c" ~escapeを利用する。 ( 16 進数 A は~Unicode文字 `000A^U `LINE FEED^cn であるが、~CSSにおいては,一般概念としての “改行文字” を表現する。) ◎ Since a string cannot directly represent a newline, to include a newline in a string, use the escape "\A". (Hexadecimal A is the line feed character in Unicode (U+000A), but represents the generic notion of "newline" in CSS.)
4.5. 資源の所在指定子: `url^t 型
`url$t 型は、ある資源を指す`~URL$を表現する。 ◎ The <url> type represents a URL, which is a pointer to a resource.
`url$t は、概して,[ `url@f / `src@f ]`関数-記法$で記される: ◎ Typically, a <url> is written with the url() or src() functional notations:
`url@t = url( `string$t `url-modifier$t* ) | src( `string$t `url-modifier$t* )
背景~画像として利用される~URLの例: ◎ This example shows a URL being used as a background image:
body { background: url("http://www.example.com/pinkish.gif") }
旧来の理由から、 `url$f は,~URLを括る引用符を省いて記せる(その構文は、 `url-token$t として 特別に構文解析される `CSS-SYNTAX-3$r )。 この特別な構文解析があるため、 `url$f に指定-可能な~URLは~literalに限られる。 一方で `src$f には、この特別な構文解析~規則は無いので, `var$f などの関数により~URLを供せる。 ◎ For legacy reasons, a url() can be written without quotation marks around the URL itself, in which case it is specially-parsed as a <url-token> [CSS-SYNTAX-3]. Because of this special parsing, url() is only able to specify its URL literally; src() lacks this special parsing rule, and so its URL can be provided by functions, such as var().
例えば,次の 2 つの宣言は、同じになる: ◎ For example, the following declarations are identical:
background: url("http://www.example.com/pinkish.gif"); background: url(http://www.example.com/pinkish.gif);
次に挙げるものも同じ意味になる: ◎ And these have the same meaning as well:
background: src("http://www.example.com/pinkish.gif"); --foo: "http://www.example.com/pinkish.gif"; background: src(var(--foo));
が、次は`働かない^em: ◎ But this does not work:
--foo: "http://www.example.com/pinkish.gif"; background: url(var(--foo));
値~内の~escapeされてない `(^l により,構文解析-~errorになり、宣言~全体が無効として棄てられるので。 ◎ ...because the unescaped "(" in the value causes a parse error, so the entire declaration is thrown out as invalid.
注記: 引用符なしの `url$f 構文は、 `url-modifier$t 引数を受容しない。 加えて、~URLの中の[ 括弧, `空白$, 一重~引用符( `'^c ), 二重~引用符( `"^c ) ]は、~backslash( `\^c )で~escapeされなければナラナイ — 例: `url(open\(parens)^v / `url(close\)parens)^v (引用符~付きな `string$t をとる `url$f は、[ 改行文字, 当の文字列を括るために利用した引用符 ]に限り,~escapeする必要がある。 )。 ~URLの種別にもよるが,これらの文字を — `URL$r にしたがって — ~URL~escapeで記すのもアリである(例えば,先の例に対する `url(open%28parens)^v / `url(close%29parens)^v )。 ◎ The unquoted url() syntax cannot accept a <url-modifier> argument and has extra escaping requirements: parentheses, whitespace characters, single quotes (') and double quotes (") appearing in a URL must be escaped with a backslash, e.g. url(open\(parens), url(close\)parens). (In quoted <string> url()s, only newlines and the character used to quote the string need to be escaped.) Depending on the type of URL, it might also be possible to write these characters as URL-escapes (e.g. url(open%28parens) or url(close%29parens)) as described in [URL].
引用符なしの `url$f 構文を構文解析するための精確な要件は、 `CSS-SYNTAX-3$r にて規範的に定義される。 ◎ The precise requirements for parsing the unquoted url() syntax are normatively defined in [CSS-SYNTAX-3].
一部の~CSS文脈( `import$at など)では、 `url$t を関数で包装せずに,裸の `string$t で表現することも許容される。 そのような事例における文字列は、それを包含している `url$f 関数と同じに挙動する。 ◎ Some CSS contexts (such as @import) also allow a <url> to be represented by a bare <string>, without the function wrapper. In such cases the string behaves identically to a url() function containing that string.
例えば,次の 2 つの文は、同じに動作する: ◎ For example, the following statements act identically:
@import url("base-theme.css"); @import "base-theme.css";
4.5.1. 相対~URL
資源の絶対的な所在に依存しない ~module化された~stylesheetを作成するためには、作者は,相対~URLを利用するベキである。 ( `URL$r にて定義される)相対~URLは、基底~URLを利用して全部的な~URLに解決される。 この処理n用の規範的な~algoは、 RFC 3986, § 3 にて定義されている。 ~CSS~stylesheetにおいては、基底~URLは,~source文書のそれではなく,~stylesheet自身のそれである。 文書~内に埋込まれた~stylesheetの基底~URLは、その文書に結付けられている基底~URLになる。 ◎ In order to create modular style sheets that are not dependent on the absolute location of a resource, authors should use relative URLs. Relative URLs (as defined in [URL]) are resolved to full URLs using a base URL. RFC 3986, section 3, defines the normative algorithm for this process. For CSS style sheets, the base URL is that of the style sheet itself, not that of the styled source document. Style sheets embedded within a document have the base URL associated with their container.
注記: ~HTML文書においては、 基底~URLは変異-可能 である。 ◎ Note: For HTML documents, the base URL is mutable.
~propの算出d値に現れる `url$t は、前段落で述べたように,絶対~URLに解決される。 ~UAが~URLを絶対~URLに解決できない場合、指定d値がその算出d値になる。 ◎ When a <url> appears in the computed value of a property, it is resolved to an absolute URL, as described in the preceding paragraph. The computed value of a URL that the UA cannot resolve to an absolute URL is the specified value.
例えば,次の規則が: ◎ For example, suppose the following rule:
body { background: url("tile.png") }
次の~URLで指名される~stylesheetの中に在るとするとき: ◎ is located in a style sheet designated by the URL:
http://www.example.org/style/basic.css
~source文書の `body^e の背景は、次の~URLで指名される資源の画像で,敷詰められることになる: ◎ The background of the source document’s <body> will be tiled with whatever image is described by the resource designated by the URL:
http://www.example.org/style/tile.png
`body^e を包含している~source文書の~URLに関わらず,同じ画像が利用されることになる。 ◎ The same image will be used regardless of the URL of the source document containing the <body>.
4.5.1.1. 素片~URL
~browserによる~URLの取扱いに共通な ある~~極端さに対処するため、~CSSには,素片のみの~url用に特別な挙動がある。 ◎ To work around some common eccentricities in browser URL handling, CSS has special behavior for fragment-only urls.
`url$f の値が文字 `0023^U `NUMBER SIGN^cn ( `#^c )から開始する場合、その `url$f の `局所~url~flag@ 【既定では ~F 】 を ~T にした下で、通常の~URLに対するときのように構文解析する。 ◎ If a url()’s value starts with a U+0023 NUMBER SIGN (#) character, parse it as per normal for URLs, but additionally set the local url flag of the url().
[ `局所~url~flag$が ~T にされた `url$f ]を照合するときは、~URLの素片~以外はすべて無視した上で,その素片を現在の[ 相対~URLの解決-時に用いる文書 ]に対して解決する。 この参照は、常に(他の文書でなく)同じ文書~内として扱うモノトスル。 ◎ When matching a url() with the local url flag set, ignore everything but the URL’s fragment, and resolve that fragment against the current document that relative URLs are resolved against. This reference must always be treated as same-document (rather than cross-document).
[ `局所~url~flag$が ~T にされた `url$f ]を`直列化-$した結果は、素片のみでなければナラナイ。 ◎ When serializing a url() with the local url flag set, it must serialize as just the fragment.
“~browserの~~極端さ” とは? ◎ What “browser eccentricities”?
理論的には,~browserは、文書の基底~URLが変化したとき( `base$e 要素の変異や `pushState()$c の call を通してなど)には、素片のみの~URLも含め,どの相対~URLも解決し直すベキである。 しかしながら,そうするベキでない事例も多い — 素片のみの~URLは、特別に取扱わなければ,いきなり(以前の基底~URLを指す)他の文書への参照になり、それらを利用する箇所の多くを壊すことになるので。 ◎ Theoretically, browsers should re-resolve any relative URLs, including fragment-only URLs, whenever the document’s base URL changes (such as through mutation of the base element, or calling pushState()). In many cases they don’t, however, and so without special handling, fragment-only URLs will suddenly become cross-document references (pointing at the previous base URL) and break in many of the places they’re used.
素片のみの~URLは、[ 現在の文書の~URLが何かに関わらず,現在の文書を基準にする ]ことを,意味論的に明瞭に表出するので、この~hackは,少なくともこれらの事例において期待される挙動を保全する。 ◎ Since fragment-only URLs express a clear semantic of wanting to refer to the current document regardless of what its current URL is, this hack preserves the expected behavior at least in these cases.
4.5.2. 空な~URL
`url$f の値が( `url("")^v や `url()^v の様に)空~文字列である場合、その~urlは,無効な資源に解決するモノトスル( `about:invalid^c のような~urlに対するとき類似に) ◎ If the value of the url() is the empty string (like url("") or url()), the url must resolve to an invalid resource (similar to what the url about:invalid does).
注記: これにより、[ ~web~platformの他所における,埋込d資源に対する空~urlの挙動 ]に合致することに加え、[ 編集時の誤りで `url$f 値が空なままにされたことに因り,~stylesheetや~host文書が再度~要請される ]ような,余計な流通は避けられ、 `url$f がどこに現れようが,資源は ほぼ確実に無効になるであろう。 ~web~platformにおいては,~linkに空~urlをあてがうことも`許容される^emので、~CSSに~hyperlinkを制御する何らかの機能性が加わったときには、この制約は,その種の文脈においては緩められ得る。 ◎ Note: This matches the behavior of empty urls for embedded resources elsewhere in the web platform, and avoids excess traffic re-requesting the stylesheet or host document due to editing mistakes leaving the url() value empty, which are almost certain to be invalid resources for whatever the url() shows up in. Linking on the web platform does allow empty urls, so if/when CSS gains some functionality to control hyperlinks, this restriction can be relaxed in those contexts.
4.5.3. ~URL修飾子
`url$f 関数は、~URLの意味や解釈をいくぶん変える `url-modifier@t を追加的に指定することも~supportする。 `url-modifier$t は、[ `ident$t または `関数-記法$ ]の いずれかである。 ◎ The url() function supports specifying additional <url-modifier>s, which change the meaning or the interpretation of the URL somehow. A <url-modifier> is either an <ident> or a functional notation.
この仕様は、 `url-modifier$t を定義しない — 他の仕様が定義するであろう。 ◎ This specification does not define any <url-modifier>s, but other specs may do so.
注記: 引用符や `url$f で括られていない `url$t には、 `url-modifier$t は受容されない。 ◎ Note: A <url> that is either unquoted or not wrapped in url() notation cannot accept any <url-modifier>s.
5. 数量-~data型
数量-~data型は、[ 数量/~index/位置 ]などの値を表現するために利用される。 構文上は,数量(数的な側面)を表出するような変種がいくつも存在し得るが、[ `指定d値$ / `算出d値$ ]は,所与の数量-値における これらの変種を判別しない — それは、構文上の表現ではなく,値の抽象的な数量を表現する。 ◎ Numeric data types are used to represent quantities, indexes, positions, and other such values. Although many syntactic variations can exist in expressing the quantity (numeric aspect) in a given numeric value, the specified and computed value do not distinguish these variations: they represent the value’s abstract quantity, not its syntactic representation.
`数量-~data型@ は、[ `integer$t, `number$t, `percentage$t ], および次に挙げる様々な`次元$を含む ⇒ `length$t, `angle$t, `time$t, `frequency$t, `resolution$t ◎ The numeric data types include <integer>, <number>, <percentage>, and various dimensions including <length>, <angle>, <time>, <frequency>, and <resolution>.
注記: 一般用の`次元$は,ここに定義されるが、他の一部の~moduleも,追加的な — より局所~化された用法を伴う — ~data型を定義する(例: `css-grid-1$r は `fr$u 単位を導入する)。 ◎ Note: While general-purpose dimensions are defined here, some other modules define additional data types (e.g. [css-grid-1] introduces fr units) whose usage is more localized.
~CSSにおける数量-値の[ 精度, ~supportされる範囲 ]は、`明示的に未定義^emであり,当の値が利用される[ ~prop/他の文脈 ]に基づいて変わり得る。 しかしながら,~CSS仕様の中では、[ 精度, 範囲 ]とも無限と見做される。 実装は、[[ 範囲/精度 ]の制限に因り,明示的に~supportできない値 ]に対しては,[ 自身が~supportする最も近い値に変換する ]モノトスルが、[ 実装が “最も近い” をどう定義するか ]も,明示的に未定義である。 ◎ The precision and supported range of numeric values in CSS is explicitly undefined, and can vary based on the property or other context a value is used in. However, within the CSS specifications, infinite precision and range is assumed. When a value cannot be explicitly supported due to range/precision limitations, it must be converted to the closest value supported by the implementation, but how the implementation defines "closest" is explicitly undefined as well.
5.1. 範囲の制約と範囲~定義の記法
~propには、数量-値を一定~範囲に制約するものもある。 許容d範囲~外の値を伴う宣言は — 他が指定されない限り — 無効であり,`無視する$モノトスル。 数量-型~記法においては、 `角括弧付き範囲~記法@ を利用して,範囲~制約を注釈できる。 それは、山括弧の合間の,型を識別する~keywordの後に `[最小v, 最大v]^g と記され,閉区間を成す範囲 { 最小v 〜 最大v } を指示する。 例えば, `integer [0,10]$t は、範囲 { 0 〜 10 } に入る整数を指示する。 ◎ Properties can restrict numeric values to some range. If the value is outside the allowed range, then unless otherwise specified, the declaration is invalid and must be ignored. Range restrictions can be annotated in the numeric type notation using CSS bracketed range notation—[min,max]—within the angle brackets, after the identifying keyword, indicating a closed range between (and including) min and max. For example, <integer [0,10]> indicates an integer between 0 and 10, inclusive.
注記: ~CSS値は,一般に開区間を成す範囲を許容しないので、角括弧~記法のみが利用される。 ◎ Note: CSS values generally do not allow open ranges; thus only square-bracket notation is used.
~CSSは、理論上は,すべての値~型に対し無限な[ 精度, 範囲 ]を~supportするが、現実の実装においては有限になる。 ~UAは、適度に有用な[ 精度, 範囲 ]を~supportするベキである。 理想上は制限されない範囲は、[ ∞, −∞ ]のうち適切な方を利用して指示される。 例えば, `length [0,∞]$t は、負でない長さを指示する。 ◎ CSS theoretically supports infinite precision and infinite ranges for all value types; however in reality implementations have finite capacity. UAs should support reasonably useful ranges and precisions. Range extremes that are ideally unlimited are indicated using ∞ or −∞ as appropriate. For example, <length [0,∞]> indicates a non-negative length.
`角括弧付き範囲~記法$を利用して, あるいは~propの記述にて,範囲が指示されていない場合、 `[−∞,∞]^g と見做される。 ◎ If no range is indicated, either by using the bracketed range notation or in the property description, then [−∞,∞] is assumed.
注記: これを書いた時点では,`角括弧付き範囲~記法$は まだ日が浅いので、ほとんどの~CSS仕様は,範囲~制限を注釈文でしか述べていない(例えば, “負な値は許容されない” や “負な値は妥当でない(無効)” は、範囲 `[0, ∞]^g を指示する)。 これは、~~制限を~~緩めるものではない。 ◎ Note: At the time of writing, the bracketed range notation is new; thus in most CSS specifications any range limitations are described only in prose. (For example, “Negative values are not allowed” or “Negative values are invalid” indicate a [0,∞] range.) This does not make them any less binding.
5.2. 整数: `integer^t 型
整数~値は `integer@t で表記される。 ◎ Integer values are denoted by <integer>.
`整数@ は、~literalには 1 個以上の 10 進~数字( `0^c 〜 `9^c )の並びで記され, `number-token$t 生成規則 `CSS-SYNTAX-3$r の下位集合に対応する。 整数の先頭には,符号nを指示する[ `-^c / `+^c ]が前置されてもヨイ。 ◎ When written literally, an integer is one or more decimal digits 0 through 9 and corresponds to a subset of the <number-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. The first digit of an integer may be immediately preceded by - or + to indicate the integer’s sign.
5.2.1. `integer^t の結合n
`integer$t の`補間$における %結果値 は次で定義される ⇒ `number$t の`補間-$を用いて得られた結果を最も近い整数に丸める — そのような整数が 2 つある場合は正な無限大に近い方へ丸めるとする — ことにより, `integer^t に変換した結果 ◎ Interpolation of <integer> is defined as Vresult = round((1 - p) × Va + p × Vb); that is, interpolation happens in the real number space as for <number>s, and the result is converted to an <integer> by rounding to the nearest integer, with values halfway between adjacent integers rounded towards positive infinity.
`integer$t の`加算$における %結果値 は次で定義される ⇒ 値a ~PLUS 値b ◎ Addition of <integer> is defined as Vresult = Va + Vb
5.3. 実数: `number^t 型
実数~値は `number@t で表記され、小数部を伴い得る実数( `real number^en )を表現する。 ◎ Number values are denoted by <number>, and represent real numbers, possibly with a fractional component.
`実数@ は、~literalには,`整数$として, または次の並びとして記される:
- `整数$
- ~dot( `.^c )
- 1 個以上の 10 進~数字
-
省略可能な,次の並びによる指数部†:
- 文字[ `e^c または `E^c ]
- `整数$
`実数$は、 `number-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。 整数と同じく、実数の先頭には,符号nを指示する[ `-^c / `+^c ]が前置されてもヨイ††。
【† CSS2 では許容されない指数部は、例えば, CSS Transform にも利用される(元々は)~SVG用の~propに適応するために導入されたと思われる。 】【†† 指数部の整数の先頭にも。 】【 `number^t を意味する `number^en は,より限定的に “~~実数” と訳している(今後,例えば `number^t が虚数にまで拡張されることは まずないであろう)。 】
◎ When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits and optionally an exponent composed of "e" or "E" and an integer. It corresponds to the <number-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. As with integers, the first character of a number may be immediately preceded by - or + to indicate the number’s sign.値 `zero@t は、値 0 をとる,~literalな`実数$を表現する。 単に値 0 の `number$t に評価される式(例えば `calc(0)^v )は、 `zero$t には合致しない — 合致するのは~literalな `number-token$t に限られる。 【 `zero$t を成す~literalは、 `0^v 以外にも無数にある — `-000^v, `0.00^v, `0E+42^v 等々。】 ◎ The value <zero> represents a literal number with the value 0. Expressions that merely evaluate to a <number> with the value 0 (for example, calc(0)) do not match <zero>; only literal <number-token>s do.
5.3.1. `number^t の結合n
`number$t の`補間$における %結果値 は次で定義される ⇒ ( 1 ~MINUS %p ) ~MUL 値a ~PLUS %p ~MUL 値b ◎ Interpolation of <number> is defined as Vresult = (1 - p) × Va + p × Vb
`number$t の`加算$における %結果値 は次で定義される ⇒ 値a ~PLUS 値b ◎ Addition of <number> is defined as Vresult = Va + Vb
5.4. 単位を伴う実数: 次元~付きの値
一般~用語としての `次元@ ( `dimension^en, 計量の次元, ~~寸法)は、単位~付きの実数であり, `dimension@t で表記される。 ◎ The general term dimension refers to a number with a unit attached to it; and is denoted by <dimension>.
`次元$は、~literalには[ `実数$, `識別子$である単位~識別子 ]の並びで記される。 これは、 `dimension-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。 ~keyword同様,単位~識別子も `~ASCII大小無視$である。 ◎ When written literally, a dimension is a number immediately followed by a unit identifier, which is an identifier. It corresponds to the <dimension-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. Like keywords, unit identifiers are ASCII case-insensitive.
~CSSでは、[ 距離( `length$t ), 時間長( `time$t ), 周波数( `frequency$t ), 解像度( `resolution$t ), その他の数量 ]に, `dimension$t を利用する。 ◎ CSS uses <dimension>s to specify distances (<length>), durations (<time>), frequencies (<frequency>), resolutions (<resolution>), and other quantities.
5.4.1. 互換な単位
`算出d値$を`直列化-$する `CSSOM$r とき、その中で`互換$な単位を伴う各 値は,それらの`正準的~単位$による値に(ある静的な乗算的-係数を通して)変換される。 所与の単位どうしが `互換@ であるとは、ある係数( `px$u と `in$u との間の 96:1 の様な係数や, `font-size$p の算出d値による `em$u と `px$u との間の係数など )で互いに~~換算できることを意味する。 `互換$な単位たちが成す各~groupには、その中のある単位が `正準的~単位@ として定義される。 【理論的には、そのような~groupが単独の単位のみからなる(他に互換な単位は無い)こともあり得る — その場合の正準的~単位はその単位~自身になる。】 ◎ When serializing computed values [CSSOM], compatible units (those related by a static multiplicative factor, like the 96:1 factor between px and in, or the computed font-size factor between em and px) are converted into a single canonical unit. Each group of compatible units defines which among them is the canonical unit that will be used for serialization.
[ `解決d値$のうち,`使用~値$を与えるもの ]を直列化する際には、長さを表現する すべての値~型(百分率, 実数, ~keyword, 等々)は,長さに`互換$と見なされる。 同様に,`使用~値$を返すような将来の API は、[ 距離/時間長/周波数/等々 ]を表現するどの値も,関連な`次元$の~groupに`互換$と見なした上で,それに則って正準化しなければナラナイ。 ◎ When serializing resolved values that are used values, all value types (percentages, numbers, keywords, etc.) that represent lengths are considered compatible with lengths. Likewise any future API that returns used values must consider any values that represent distances/durations/frequencies/etc. as compatible with the relevant class of dimensions, and canonicalize accordingly.
5.4.2. 次元の結合n
`互換$な`次元$(例えば, 2 個の `length$t 値)の`補間$における %結果値 は次で定義される ⇒ ( 1 ~MINUS %p ) ~MUL 値a ~PLUS %p ~MUL 値b ◎ Interpolation of compatible dimensions (for example, two <length> values) is defined as Vresult = (1 - p) × Va + p × Vb
`互換$な`次元$の`加算$における %結果値 は次で定義される ⇒ 値a ~PLUS 値b ◎ Addition of compatible dimensions is defined as Vresult = Va + Vb
5.5. 百分率: `percentage^t 型
百分率~値は `percentage@t で表記され、別の基準~値に対する割合を指示する。 ◎ Percentage values are denoted by <percentage>, and indicates a value that is some fraction of another reference value.
`百分率@ は、~literalには[ `実数$, ~percent記号( `%^u ) ]の並びで記される。 `百分率$は、 `percentage-token$t 生成規則 `CSS-SYNTAX-3$r に対応する。 ◎ When written literally, a percentage consists of a number immediately followed by a percent sign %. It corresponds to the <percentage-token> production in the CSS Syntax Module [CSS-SYNTAX-3].
【 “割合” , “パーセンテージ” 等と訳されることも多いが、単位に~percent記号が利用されつつ 百分率でない尺度による割合を表すことは,今後も含めて まず~~考えられないので、より限定的に “百分率” と記すことにする(語源的にも “per-cent” )。 】
百分率~値は常に,例えば長さなど, 別の数量に相対的になる。 百分率を値に許容する 各種~propは、それが基準にする数量も定義する。 この数量は、[ 同じ要素の別の~prop, 先祖~要素の~prop, `整形~文脈$における計量(例えば,`包含塊$の横幅), 他の何か ]になり得る。 ◎ Percentage values are always relative to another quantity, for example a length. Each property that allows percentages also defines the quantity to which the percentage refers. This quantity can be a value of another property for the same element, the value of a property for an ancestor element, a measurement of the formatting context (e.g., the width of a containing block), or something else.
5.5.1. `percentage^t の結合n
`percentage$t の`補間$における %結果値 は次で定義される ⇒ ( 1 ~MINUS %p ) ~MUL 値a ~PLUS %p ~MUL 値b ◎ Interpolation of <percentage> is defined as Vresult = (1 - p) × Va + p × Vb
`percentage$t の`加算$における %結果値 は次で定義される ⇒ 値a ~PLUS 値b ◎ Addition of <percentage> is defined as Vresult = Va + Vb
5.6. 百分率と次元の混合法
`percentage$t が 同じ`成分~値$位置にある`次元$と同じ数量を表現できる所では、 `calc$f 式の中でそれらを組合せることもでき、~prop文法では,次の簡便な記法を利用できる: ◎ In cases where a <percentage> can represent the same quantity as a dimension in the same component value position, and can therefore be combined with them in a calc() expression, the following convenience notations may be used in the property grammar:
- `length-percentage@t
-
[ `length$t | `percentage$t ]
に等価。 この `percentage$t は `length$t に解決される。 ◎ Equivalent to [ <length> | <percentage> ], where the <percentage> will resolve to a <length>. - `frequency-percentage@t
-
[ `frequency$t | `percentage$t ]
に等価。 この `percentage$t は `frequency$t に解決される。 ◎ Equivalent to [ <frequency> | <percentage> ], where the <percentage> will resolve to a <frequency>. - `angle-percentage@t
-
[ `angle$t | `percentage$t ]
に等価。 この `percentage$t は `angle$t に解決される。 ◎ Equivalent to [ <angle> | <percentage> ], where the <percentage> will resolve to an <angle>. - `time-percentage@t
-
[ `time$t | `percentage$t ]
に等価。 この `percentage$t は `time$t に解決される。 ◎ Equivalent to [ <time> | <percentage> ], where the <percentage> will resolve to a <time>.
例えば、 `width$p ~propは `length$t, `percentage$t を受容でき、両者とも距離の計測を表現する。 これは、 width: `calc(500px + 50%);^v は許容されることを意味する — 2 つの値は,絶対~長さに変換された上で加算されることになる。 包含塊が `1000px^v 幅ならば、 `width^p に対する `50%^v は, `500px^v と等価になる。 `width^p に対する `calc(50% + 500px)^v は、 `calc(500px + 500px)^v と等価になる結果, `1000px^v と等価になる。 ◎ For example, the width property can accept a <length> or a <percentage>, both representing a measure of distance. This means that width: calc(500px + 50%); is allowed—both values are converted to absolute lengths and added. If the containing block is 1000px wide, then width: 50%; is equivalent to width: 500px, and width: calc(50% + 500px) thus ends up equivalent to width: calc(500px + 500px) or width: 1000px.
一方, `hsl$f 関数の 2 個目, 3 個目の引数を表出できるのは、 `percentage$t しかない。 `calc$f 生成規則は,その場所にも許容されるが、その引数の中で組合できるのは百分率どうしに限られる — `calc(10% + 20%)^v のように。 ◎ On the other hand, the second and third arguments of the hsl() function can only be expressed as <percentage>s. Although calc() productions are allowed in their place, they can only combine percentages with themselves, as in calc(10% + 20%).
注記: 仕様は、文法における次元の所の `percentage$t を決して交代させるベキでない — それらの単位が`互換$でない限り。 ◎ Note: Specifications should never alternate <percentage> in place of a dimension in a grammar unless they are compatible.
注記: 将来においては、必要に応じて,他のある次元 `TYPE^t 用の `TYPE-percentage^t 生成規則も追加され得る。 `number-percentage^t が追加されることは決してない — `calc$f 内では `number$t と `percentage$t は組合できないので。 ◎ Note: More <type-percentage> productions can be added in the future as needed. A <number-percentage> will never be added, as <number> and <percentage> can’t be combined in calc().
5.6.1. 混在な百分率と次元の結合n
百分率~値と次元~値の組合n(例: `length-percentage$t, `frequency-percentage$t, `angle-percentage$t, `time-percentage$t, その他の等価な記法 )の`補間$は、次に従うものと定義される: ◎ Interpolation of percengage-dimension value combinations (e.g. <length-percentage>, <frequency-percentage>, <angle-percentage>, <time-percentage> or equivalent notations) is defined as
- 値a, 値b とも純粋な `length^t 値の場合 ⇒ `length$t の`補間$と等価。 ◎ equivalent to interpolation of <length> if both Va and Vb are pure <length> values
- 値a, 値b とも純粋な `percentage^t 値の場合 ⇒ `percentage$t の`補間$と等価 ◎ equivalent to interpolation of <percentage> if both Va and Vb are pure <percentage> values
- 他の場合における %結果値 は次で定義される ⇒ 両~値とも,次元~型と百分率(各~場合によっては 0 )の総和を表現している `calc$f 式に変換してから,各~成分を —[ `length$t / `frequency$t / `angle$t / `time$t ]として, および `percentage$t として — 個別に`補間-$した結果 ◎ equivalent to converting both values into a calc() expression representing the sum of the dimension type and a percentage (each possibly zero) and interpolating each component individually (as a <length>/<frequency>/<angle>/<time> and as a <percentage>, respectively)
百分率~値と次元~値の組合nの`加算$は、各~成分を`補間-$する代わりに`加算-$することを除いて`補間$と同じとする。 ◎ Addition of <percentage> is defined the same as interpolation except by adding each component rather than interpolating it.
5.7. 比率: `ratio^t 型
比率~値は、 `ratio@t で表記され, 2 個の数量-値の比率を表現する。 それは、横幅( 1 個目 )と縦幅( 2 個目 )の縦横比を表現することが最も多い。 ◎ Ratio values are denoted by <ratio>, and represent the ratio of two numeric values. It most often represents an aspect ratio, relating a width (first) to a height (second).
~literalに記される `比率@ の構文は: ◎ When written literally, a ratio has the syntax:
`ratio$t = `number [0,∞]$t [ / `number [0,∞]$t ]?
2 個目の `number$t は,省略可能であり、既定は `1^v になるとする。 しかしながら、 `ratio$t は常に,両~成分とも直列化される。 ◎ The second <number> is optional, defaulting to 1. However, <ratio> is always serialized with both components.
`ratio$t の算出d値は、供された 2 個の実数が成す~pairになる。 ◎ The computed value of a <ratio> is the pair of numbers provided.
`ratio$t は、~pairを成す どちらかの実数が[ 0 または無限大【!無限】 ]ならば, `退化な比率@ を表現する(一般に,それに対し何も行えなくなる)。 ◎ If either number in the <ratio> is 0 or infinite, it represents a degenerate ratio (and, generally, won’t do anything).
`ratio$t どうしを比較する必要がある場合、[ 各 `ratio$t に対し,~pairを成す 1 個目の実数を 2 個目の実数で除算した結果 ]を比較する。 例えば, `3/2^v は `2/1^v より小さい — 前者は 1.5 に解決される一方,後者は 2 に解決されるので(言い換えれば、 “縦長” な縦横比は “横長” な縦横比より小さい)。 ◎ If two <ratio>s need to be compared, divide the first number by the second, and compare the results. For example, 3/2 is less than 2/1, because it resolves to 1.5 while the second resolves to 2. (In other words, “tall” aspect ratios are less than “wide” aspect ratios.)
5.7.1. `ratio$t の結合n
`ratio$t の補間は、次により定義される: ◎ The interpolation of a <ratio> is defined by\
- 各 `ratio^t に対し ⇒ 1 個目の値を 2 個目の値で除算して実数に変換してから(比率 `3 / 2^v は 1.5 になる),対数をとる(なので 1.5 は約 0.176 になる) ◎ converting each <ratio> to a number by dividing the first value by the second (so a ratio of 3 / 2 would become 1.5), taking the logarithm of that result (so the 1.5 would become approximately 0.176),\
- 前~段で得られた 2 個の対数を補間してから、その結果を前~段の逆~変換により `ratio^t に戻す。 ◎ then interpolating those values.\ The result during the interpolation is converted back to a <ratio> by inverting the logarithm, then interpreting the result as a <ratio> with the result as the first value and 1 as the second value.
どちらかの `ratio$t が`退化な比率$である場合、それらは補間し得ない。 ◎ If either <ratio> is degenerate, the values cannot be interpolated.
例えば,[ `5/1^v から `3/2^v まで ]の中間点において【!linear】補間した結果の比率は、約 `2.73 / 1^v になる(およそ 11 ~DIV 4 【!slightly taller than a 3 / 1 ratio】)。 ◎ For example, halfway through a linear interpolation from 5 / 1 to 3 / 2, the result is approximately the ratio 2.73 / 1 (roughly 11 / 4, slightly taller than a 3 / 1 ratio):
%start = log(5); // ≈ 0.69897 %end = log(1.5); // ≈ 0.17609 %interp = 0.69897*.5 + 0.17609*.5; // ≈ 0.43753 %final = 10^%interp; // ≈ 2.73
注記: 比率の対数に対し補間することで、結果は縮尺に依存しなくなる([ `5 / 1^v から `300 / 200^v まで ]にしても,上と同じ結果を与える)。 また、比率を成す 2 値の順序に関して対称的になる([ `1 / 5^v から `2 / 3^v まで ]を補間した場合、中間点における比率は約 `1 / 2.73^v になる) — 比率が縦横比を表すなら、[ 横幅が固定的で縦幅がそれに対する比率に基づくか, その逆か ]に関して対称的になる。 これらの特質は、他の多くのアリな補間~策とは異なる。 ◎ Note: Interpolating over the logarithm of the ratio means the results are scale-independent (5 / 1 to 300 / 200 would give the same results as above), that they’re symmetrical over "wide" and "tall" variants (interpolating from 1 / 5 to 2 / 3 would give a ratio approximately equal to 1 / 2.73 at the halfway point), and that they’re symmetrical over whether the width is fixed and the height is based on the ratio or vice versa. These properties are not shared by many other possible interpolation strategies.
注記: 対数の特質に因り、対数の底eには何を利用してもかまわない。 上の例では,底eに 10 を利用しているが、自然~対数(底eは `e$v )でも — 中間-結果は異なるが — 最終-結果は同じになる。 ◎ Note: Due to the properties of logarithms, any log can be used; the example here uses base-10 log, but if, say, the natural log and e was used, the intermediate results would be different but the final result would be the same.
`ratio$t の加算はアリでない。 ◎ Addition of <ratio>s is not possible.
6. 距離の単位: `length^t 型
長さは距離の計量を基準にし,~prop定義においては `length@t で表記される。 長さは 何らかの`次元$による量である。 ◎ Lengths refer to distance measurements and are denoted by <length> in the property definitions. A length is a dimension.
長さが 0 のときは、単位~識別子を省略できる(すなわち,構文上は `number$t の `0^v として表現できる)。 ただし, `0^v は、~propにおいて `number$t, `length$t のどちらにも構文解析できる場合( `line-height$p など)には, `number$t として構文解析するモノトスル。 ◎ For zero lengths the unit identifier is optional (i.e. can be syntactically represented as the <number> 0). However, if a 0 could be parsed as either a <number> or a <length> in a property (such as line-height), it must parse as a <number>.
~propには、長さを一定~範囲に制約するものもある。 許容d範囲~外の値を伴う宣言は無効であり,`無視する$モノトスル。 ◎ Properties may restrict the length value to some range. If the value is outside the allowed range, the declaration is invalid and must be ignored.
【 無効にさせたくない場合、`~math関数$で包装する方法がある。 】
一部の~propには,長さとして負な値も許容されるが、これは整形-法を複雑化する可能性があり,実装に特有な制限sがあり得る。 実装は、負な長さを~supportしないときは,~support可能な最も近い値に変換するモノトスル。 ◎ While some properties allow negative length values, this may complicate the formatting and there may be implementation-specific limits. If a negative length value is allowed but cannot be supported, it must be converted to the nearest value that can be supported.
~UAは、長さを`使用~値$として~supportできない所では,`実際の値$において それを近似するモノトスル。 ◎ In cases where the used length cannot be supported, user agents must approximate it in the actual value.
長さの単位は、相対と絶対の 2 つに分類される。 ◎ There are two types of length units: relative and absolute.
6.1. 相対~単位
`相対~長さ単位@ は、別の長さに相対的な長さを指定する。 相対~単位を利用すれば、~stylesheetをある出力~環境から別の環境に見合った縮尺に転用するのも容易になる。 ◎ Relative length units specify a length relative to another length. Style sheets that use relative units can more easily scale from one output environment to another.
以下のものが相対~単位である: ◎ The relative units are:
単位 | 相対基準 |
---|---|
`em$u | 要素の~font~size ◎ font size of the element |
`ex$u | 要素の~fontの`~x-高さ^i ◎ x-height of the element’s font |
`cap$u | 要素の~fontの~cap-高さ(大字の名目上の高さ) ◎ cap height (the nominal height of capital letters) of the element’s font |
`ch$u | 要素の~fontにおける半角~glyphの代表的な`文字~送幅$ — 文字 “0” ( `0030^U `ZERO^cn )の~glyphで表現される。 ◎ typical character advance of a narrow glyph in the element’s font, as represented by the “0” (ZERO, U+0030) glyph |
`ic$u | 要素の~fontにおける全角~glyphの代表的な`文字~送幅$ — 文字 “水” ( CJK 表語文字, `6C34^U )の~glyphで表現される。 ◎ typical character advance of a fullwidth glyph in the element’s font, as represented by the “水” (CJK water ideograph, U+6C34) glyph |
`rem$u | 根~要素の~font~size ◎ font size of the root element |
`lh$u | 要素の行高 ◎ line height of the element |
`rlh$u | 根~要素の行高 ◎ line height of the root element |
`vw$u | 表示域の横幅の 1% ◎ 1% of viewport’s width |
`vh$u | 表示域の縦幅の 1% ◎ 1% of viewport’s height |
`vi$u | 表示域の~size — 根~要素の`行内-軸$におけるそれ — の 1% ◎ vi 1% of viewport’s size in the root element’s inline axis |
`vb$u | 表示域の~size — 根~要素の`塊-軸$におけるそれ — の 1% ◎ vb 1% of viewport’s size in the root element’s block axis |
`vmin$u | 表示域の小さい方の次元の 1% ◎ 1% of viewport’s smaller dimension |
`vmax$u | 表示域の大きい方の次元の 1% ◎ 1% of viewport’s larger dimension |
~prop値の`継承$において,要素が継承するのは、親に指定された相対~値ではなく,親の`算出d値$である。 ◎ Child elements do not inherit the relative values as specified for their parent; they inherit the computed values.
6.1.1. ~fontに相対的な長さ単位: `em^u, `ex^u, `cap^u, `ch^u, `ic^u, `rem^u, `lh^u, `rlh^u
`~fontに相対的な長さ@ は、それが利用される要素 — あるいは、 `rem$u, `rlh$u に対しては根~要素 — の~font計量法を基準にする。 ◎ The font-relative lengths refer to the font metrics of the element on which they are used—or, in the case of rem and rlh, the metrics of the root element.
共通的な~typographic計量法 — 単語 'Sphinx' には各種~font計量法が注釈されている:
- ~ascender高さ( `ascender height^en ): "h" の~serifの上端
- ~cap-高さ( `cap-height^en ):視覚的に "S" の上端~近く
- ~x-高さ( `x-height^en ):視覚的に "x" の上端~近く
- 基底線( `baseline^en ): "S", "h", "i", "n", "x" の下端を通る
- ~descender高さ( `descender height^en ): "p" の下端
- `em@u 単位
- この単位が利用された要素の `font-size$p ~propの算出d値に等しい。 ◎ Equal to the computed value of the font-size property of the element on which it is used.
- 【 `font-size^p 自身に利用された場合にどうなるかは、下に述べられる。以下に挙げる他の単位も同様。 】
-
次の規則: ◎ The rule:
h1 { line-height: 1.2em }
は、 `h1^e 要素の行高が,要素~自身の~font~sizeより 2 割大きくなることを意味する。 一方で: ◎ means that the line height of h1 elements will be 20% greater than the font size of h1 element. On the other hand:
h1 { font-size: 1.2em }
は、 `h1^e 要素の~font~sizeが, `h1^e 要素に継承された~font~sizeの算出d値より 2 割大きくなることを意味する。 ◎ means that the font size of h1 elements will be 20% greater than the computed font size inherited by h1 elements.
- `ex@u 単位
- `可用な最初の~font$ `CSS3-FONTS$r に利用されている~x-高さに等しい。 ~x-高さという呼称は、多くの場合,それが小文字 “x” の高さに等しいことに由来する。 しかしながら、文字 “x” を包含しない~fontにも, `ex$u は定義される。 ~fontの~x-高さは、別の仕方で見出すこともできる。 ~fontには、~x-高さ用の依拠できる計量法が可用なものもある。 可用でない場合、~UAは小文字~glyphの高さから~x-高さを決定してもヨイ。 アリな経験則として、小文字 "o" の~glyphの下端が基底線の下に突き出ている距離を調べて,その値をその限界~boxの上端から減算して得る方法がある。 ~x-高さを決定するのは不可能, または実用的でない場合、値 0.5em と見做すモノトスル。 ◎ Equal to the used x-height of the first available font [CSS3-FONTS]. The x-height is so called because it is often equal to the height of the lowercase "x". However, an ex is defined even for fonts that do not contain an "x". The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.
- `cap@u 単位
- `可用な最初の~font$ `CSS3-FONTS$r に利用されている~cap-高さに等しい。 ~cap-高さという呼称は、~Latin大字( `capital letters^en )の高さに近似的に等しいことに由来する。 しかしながら、~Latin大字を包含しない~fontにも, `cap$u は定義される。 ~fontの~cap-高さは、別の仕方で見出すこともできる。 ~fontには、~cap-高さ用の依拠できる計量法が可用なものもある。 可用でない場合、~UAは大文字~glyphの高さから~cap-高さを決定してもヨイ。 アリな経験則として、大文字 "O" の~glyphの下端が基底線の下に突き出ている距離を調べて,その値をその限界~boxの上端から減算して得る方法がある。 ~cap-高さを決定するのは不可能, または実用的でない場合、~fontの~ascentが利用するモノトスル。 ◎ Equal to the used cap-height of the first available font [CSS3-FONTS]. The cap-height is so called because it is approximately equal to the height of a capital Latin letter. However, a cap is defined even for fonts that do not contain Latin letters. The cap-height of a font can be found in different ways. Some fonts contain reliable metrics for the cap-height. If reliable font metrics are not available, UAs may determine the cap-height from the height of an uppercase glyph. One possible heuristic is to look at how far the glyph for the uppercase “O” extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the cap-height, the font’s ascent must be used.
- `ch@u 単位
- 描画-時に利用される~fontの文字 "0" ( `0030^U `ZERO^cn )の~glyphに利用される`送幅$に等しい。 ( `送幅@ とは、要素の行内-軸における~glyphの送幅( `advance measure^en )†である。) ◎ Equal to the used advance measure of the “0” (ZERO, U+0030) glyph in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)
- 【† 当の~glyph(この場合は "0" )の始端から次の~glyph(同じ行lに描画されたとする)の始端までの距離。 】
- 注記: この計量は,単独の半角( `narrow^en )~glyphの`送幅$の近似であり(等幅~fontでは,正確な計測になる)、期待される~glyph個数に基づく計量を可能にする。 ◎ This measurement is an approximation (and in monospace fonts, an exact measure) of a single narrow glyph’s advance measure, thus allowing measurements based on an expected glyph count.
- 注記: ~glyphの送幅は、~font設定群のみならず, `writing-mode$p, `text-orientation$p, 他,~glyphの[ 選定/方位 ]に影響する他の~propにも依存する。 ◎ Note: The advance measure of a glyph depends on writing-mode and text-orientation as well as font settings, text-transform, and any other properties that affect glyph selection or orientation.
- “0” ~glyphの計測は不可能, または実用的でない場合、[ ~~高さ `1em^v, 幅 `0.5em^v ]と見做すモノトスル。 したがって `ch$u 単位は、[ 一般~事例では `0.5em^v / 正立に植字されるとき(すなわち、 `writing-mode$p は[ `vertical-rl$v / `vertical-lr$v ], `text-orientation$p は `upright$v のとき)は `1em^v ]に~fall-backする。 ◎ In the cases where it is impossible or impractical to determine the measure of the “0” glyph, it must be assumed to be 0.5em wide by 1em tall. Thus, the ch unit falls back to 0.5em in the general case, and to 1em when it would be typeset upright (i.e. writing-mode is vertical-rl or vertical-lr and text-orientation is upright).
- `ic@u 単位
- 描画-時に利用される~fontの文字 “水” ( CJK 表語文字, `6C34^U )の~glyphに利用される`送幅$に等しい。 ◎ Equal to the used advance measure of the “水” (CJK water ideograph, U+6C34) glyph found in the font used to render it.
- この計量は,概して正確な計測であり(全角~glyphが均衡幅であるような少数の~fontでは,近似になる)、期待される~glyph個数に基づく計量を可能にする。 ◎ This measurement is a typically an exact measure (in the few fonts with proportional fullwidth glyphs, an approximation) of a single fullwidth glyph’s advance measure, thus allowing measurements based on an expected glyph count.
- 表語文字 送幅を決定するのは不可能, または実用的でない場合、 `1em^v と見做すモノトスル。 ◎ In the cases where it is impossible or impractical to determine the ideographic advance measure, it must be assumed to be 1em.
- `rem@u 単位
- 根~要素の `font-size$p の算出d値に等しい。 [ 根~要素/根~要素が無い文書 ]の `font-size$p ~propに指定された `1rem^v は、その~propの`初期~値$に等しいとする。 ◎ Equal to the computed value of font-size on the root element. When specified in the font-size property of the root element, or in a document with no root element, 1rem is equal to the initial value of the font-size property.
- `lh@u 単位
- この単位が利用された要素~上の `line-height$p ~propの算出d値に等しい — ここでは、値 `normal^v も,`可用な最初の~font$の計量法を利用して絶対~長さに変換する。 ◎ Equal to the computed value of the line-height property of the element on which it is used, converting normal to an absolute length by using only the metrics of the first available font.
- `rlh@u 単位
- 根~要素~上の `line-height$p ~propの算出d値に等しい — ここでは、値 `normal^v も, `lh^u のときと同様に絶対~長さに変換する。 ◎ Equal to the computed value of line-height property on the root element, converting normal to an absolute length as above.
- 注記: 要素の `height$p を `lh$u / `rlh$u 単位を利用して設定しても,実際の行l数~制御が可能化されるわけではない。 これらの単位は、理想上は空~行lの理論的~sizeに基づく長さ計算を可能化するものではない — 実際の行l数は、内容の多寡に応じて相違し得る。 作者は、要素~内の実際の行l数を制限したいなら,代わりに `max-lines$p ~propを利用できる。 ◎ Note: Setting the height of an element using either the lh or the rlh units does not enable authors to control the actual number of lines in that element. These units only enable length calculations based on the theoretical size of an ideal empty line; the size of actual lines boxes may differ based on their content. In cases where an author wants to limit the number of actual lines in an element, the max-lines property can be used instead.
もっと~typographic単位を追加することもできる — `cicero^u, `didot^u, 等々。 それらは単に絶対~単位であり,既存の単位に変換できるが、追加するに価するほど十分に欲されているか(印刷用途も含め)? あるいは、単に Houdini Custom Units を待つべきか? ◎ We can potentially add more typographic units, like cicero, didot, etc. They’re just absolute units, and so can be done with the existing units, but is there enough desire for them (potentially for printing use-cases) that it would be worth adding them? Or should we just wait for Houdini Custom Units?
これらの~fontに相対的な単位は(上では,定義されていない/定義が循環する事例では): ◎ ↓
- 要素の文脈の外側(`媒体~query$など)で利用されたときは、[ `font$p, `line-height$p ]~propの初期~値に対応する計量法を基準にする。 ◎ When used outside the context of an element (such as in media queries), these units refer to the metrics corresponding to the initial values of the font and line-height properties.\
- 要素~上の `font-size$p ~propの値に利用されたときは、要素に親が[ 在るならば 親に算出される計量法 / 無いならば[ `font^p, `line-height^p ]~propの初期~値に対応して算出される計量法 ]に基づくように解決される。 ◎ When used in the value of the font-size property on the element they refer to, they resolve against the computed metrics of the parent element—or against the computed metrics corresponding to the initial values of the font and line-height properties, if the element has no parent.\
- [ `lh$u / `rlh$u ]単位が,要素~上の `line-height^p ~propの値に利用されたときは、要素に親が[ 在るならば 親の[ `font^p, `line-height^p ]~propに算出される計量法 / 無いならば[[ `font^p, `line-height^p ]~propの初期~値に対応して算出される計量法 ]]に基づくように解決される(他の単位については、他と同じく,要素の自前の計量法に基づくように解決される)。 ◎ Additionally, when lh or rlh units are used in the value of the line-height property on the element they refer to, they resolve against the computed line-height and font metrics of the parent element—or the computed metrics corresponding to the initial values of the font and line-height properties, if the element has no parent. (The other font-relative units continue to resolve against the element’s own metrics when used in line-height.)
6.1.2. 表示域~百分率による長さ単位: `vw^u, `vh^u, `vi^u, `vb^u, `vmin^u, `vmax^u
`表示域~百分率による長さ@ は `初期~包含塊$の~sizeに相対的になる。 初期~包含塊の縦幅/横幅が変化すれば,それに応じて拡縮される。 ただし,[ 根~要素の `overflow$p の値が `auto^v ]のときは、~scrollbarは存在しないものと見做される。 初期~包含塊の~sizeは、表示域の~scrollbarの有無に影響される。 ◎ The viewport-percentage lengths are relative to the size of the initial containing block. When the height or width of the initial containing block is changed, they are scaled accordingly. However, when the value of overflow on the root element is auto, any scroll bars are assumed not to exist. Note that the initial containing block’s size is affected by the presence of scrollbars on the viewport.
`1766$issue: `overflow$p が `scroll^v のときの表示域~単位は、依然として~scrollbar幅に依存するベキか? ◎ Issue #1766 on GitHub: “[css-values] Should viewport units still depend on scrollbar width for overflow:scroll?”
`~paged媒体$に対する表示域~百分率による長さの正確な定義は `CSS3PAGE$r に委ねられる。 ◎ For paged media, the exact definition of the viewport-percentage lengths is deferred to [CSS3PAGE].
- `vw@u 単位
-
`初期~包含塊$の横幅の 1% に等しい。 ◎ Equal to 1% of the width of the initial containing block.
次の例で,表示域の横幅が 200mm である場合、 `h1^e 要素の~font~sizeは 16mm (すなわち, ( 8 ~MUL 200mm ) ~DIV 100 )になる。 ◎ In the example below, if the width of the viewport is 200mm, the font size of h1 elements will be 16mm (i.e. (8×200mm)/100).
h1 { font-size: 8vw }
- `vh@u 単位
- `初期~包含塊$の縦幅の 1% に等しい。 ◎ Equal to 1% of the height of the initial containing block.
- `vi@u 単位
- `初期~包含塊$の~size — 根~要素の`行内-軸$方向におけるそれ — の 1% に等しい。 ◎ Equal to 1% of the size of the initial containing block in the direction of the root element’s inline axis.
- `vb@u 単位
- `初期~包含塊$の~size — 根~要素の`塊-軸$方向におけるそれ — の 1% に等しい。 ◎ Equal to 1% of the size of the initial containing block in the direction of the root element’s block axis.
- `vmin@u 単位
- `vw$u と `vh$u の小さい方に等しい。 ◎ Equal to the smaller of vw or vh.
- `vmax@u 単位
- `vw$u と `vh$u の大きい方に等しい。 ◎ Equal to the larger of vw or vh.
根~要素が無い, または まだ~styleがあてがわれていない状況(`媒体~query$を評価するときなど)においては、 `vi$u, `vb$u 単位に対応する軸は, `writing-mode$p ~propの初期~値を利用して決定される。 ◎ In situations where there is no root element or it hasn’t yet been styled (such as when evaluating media queries), the vi and vb units use the initial value of the writing-mode property to determine which axis they correspond to.
6.2. 絶対~単位:`cm^u, `mm^u, `Q^u, `in^u, `pt^u, `pc^u, `px^u
`絶対~長さ単位@ は、何らかの物理-計量を`~anchor$にし, 互いが固定的な関係にある単位である。 これは主に、出力~環境が既知である場合に有用になる。 絶対~単位には `物理-単位@ ( `in$u, `cm$u, `mm$u, `pt$u, `pc$u, `Q$u )と `視野角~単位@ ( ~pixel単位 )( `px$u ) — がある: ◎ The absolute length units are fixed in relation to each other and anchored to some physical measurement. They are mainly useful when the output environment is known. The absolute units consist of the physical units (in, cm, mm, pt, pc, Q) and the visual angle unit (pixel unit) (px):
単位 | 名前 | 他の単位との関係 |
---|---|---|
`cm@u | ~centi~meter( `centimeter^en ) | 1 `cm^u = ( 96 ÷ 2.54 ) `px^u |
`mm@u | ~milli~meter( `millimeter^en ) | 1 `mm^u = ( 1 ÷ 10 ) `cm^u |
`Q@u | 四分~milli~meter( `quarter-millimeter^en ) | 1 `Q^u = ( 1 ÷ 40 ) `cm^u |
`in@u | ~inch( `inch^en ) | 1 `in^u = 2.54 `cm^u = 96 `px^u |
`pc@u | ~pica( `pica^en ) | 1 `pc^u = ( 1 ÷ 6 ) `in^u = 12 `pt^u |
`pt@u | ~point( `point^en ) | 1 `pt^u = ( 1 ÷ 72 ) `in^u |
`px@u | ~pixel( `pixel^en, “~~画素” ) | 1 `px^u = ( 1 ÷ 96 ) `in^u |
h1 { margin: 0.5in } /* ~inch */ h2 { line-height: 3cm } /* ~centi~meter */ h3 { word-spacing: 4mm } /* ~milli~meter */ h3 { letter-spacing: 1Q } /* 四分~milli~meter */ h4 { font-size: 12pt } /* ~point */ h4 { font-size: 1pc } /* ~pica */ p { font-size: 12px } /* ~pixel */
すべての絶対~長さ単位どうしは `互換$である — それらの`正準的~単位$は `px$u とする。 ◎ All of the absolute length units are compatible, and px is their canonical unit.
~CSSに基づいて描画する機器においては、これらの次元は、次のいずれかを `~anchor@ にする。 ◎ For a CSS device, these dimensions are anchored either
- (1) `物理-単位$と物理-計量との~~換算法,または ◎ by relating the physical units to their physical measurements, or
- (2) `基準~pixel$と`~pixel単位$との~~換算法 ◎ by relating the pixel unit to the reference pixel.
典型的な視聴距離が想定されている印刷~媒体~用には、`~anchor単位$は,`物理-単位$(~inch, ~centi~meter, 等々)になるベキである。 [ ~screen媒体(高-解像度な機器も含む)/ 低~解像度な機器/ ~~普通でない視聴距離が想定されている機器 ]用には、`~pixel単位$が~anchor単位に推奨される。 そのような機器においては、~pixel単位は,基準~pixelに最良に近似するような 機器~画素の整数倍を基準にすることが推奨される。 ◎ For print media at typical viewing distances, the anchor unit should be one of the physical units (inches, centimeters, etc). For screen media (including high-resolution devices), low-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
注記: `~anchor単位$が`~pixel単位$である場合、`物理-単位$は,物理的な計量に一致するとは限らない。 一方で,~anchor単位が物理-単位である場合、~pixel単位は,機器~画素の整数倍に対応しないことがある。 ◎ Note: If the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
注記: この`~pixel単位$と`物理-単位$の定義は、過去の CSS1, CSS2 による定義と異なる。 特に,以前の~versionでは、~pixel単位と物理-単位は固定d比率で~~換算できなかった — 物理的な単位は,常にその物理的な計量に結付けられていた一方、~pixel単位は,基準~pixelに最も近似するような可変的なものとされていた。 (不幸にも,このように変更された~~理由は、 96dpi を前提にしている既存の内容があまりに多いため、その前提を覆すと,それらの内容も壊してしまうからである。) ◎ Note: This definition of the pixel unit and the physical units differs from the earlier editions of CSS1 and CSS2. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This unfortunate change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)
注記: 単位は`~ASCII大小無視$であり,小文字に直列化される。 例えば `1Q^v は `1q^v に直列化される。 ◎ Note: Units are ASCII case-insensitive and serialize as lower case, for example 1Q serializes as 1q.
`基準~pixel@ とは、~pixel密度 96dpi の機器において 読み手の腕の長さだけ離れたときの, 1 ~pixelが占める視野角である。 名目上の腕の長さ約 71cm の下での視野角は,約 0.0213 度であり、この腕の長さだけ離れた視点からの `1px^v は,およそ 0.26mm ( 1÷96 ~inch)に相当する。 ◎ The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).
下の画像に、視点からの距離が基準~pixelの~~実際の大きさに及ぼす効果を示す: 読み取り距離 71cm ( 28 ~inch)のときの基準~pixelは約 0.26mm になり, 3.5m ( 12 ~feet)のときの基準~pixelは約 1.3mm になる。 ◎ The image below illustrates the effect of viewing distance on the size of a reference pixel: a reading distance of 71 cm (28 inches) results in a reference pixel of 0.26 mm, while a reading distance of 3.5 m (12 feet) results in a reference pixel of 1.3 mm.

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

7. その他の数量
7.1. 角度の単位: `angle^t 型と `deg^u, `grad^u, `rad^u, `turn^u 単位
角度~値は `dimension$t 型であり、 `angle@t で表記される。 角度~単位~識別子には次のものがある: ◎ Angle values are <dimension>s denoted by <angle>. The angle unit identifiers are:
- `deg@u
- 度。 円の全周は 360 度。 ◎ Degrees. There are 360 degrees in a full circle.
- `grad@u
- ~gradian。 “~gon” あるいは “~grade” としても知られる。 円の全周は 400 gradian 。 ◎ Gradians, also known as "gons" or "grades". There are 400 gradians in a full circle.
- `rad@u
- ~radian。 円の全周は 2π ~radian。 ◎ Radians. There are 2π radians in a full circle.
- `turn@u
- 周回数( `turn^en )。 円の全周は 1 周回。 ◎ Turns. There is 1 turn in a full circle.
例えば,直角は[ `90deg^v / `100grad^v / `0.25turn^v / 約 `1.57rad^v ]に等しい。 ◎ For example, a right angle is 90deg or 100grad or 0.25turn or approximately 1.57rad.
すべての `angle$t 単位どうしは `互換$である — それらの`正準的~単位$は `deg$u とする。 ◎ All <angle> units are compatible, and deg is their canonical unit.
方向を表記する角度は、概して `方位角@ として解釈されるのが慣例である — ここで、 `0deg^v は~screen上の “上方” あるいは “北” を指し、角度は時計回りに大きくなる(したがって `90deg^v は “右方” あるいは “東” を指す)。 ◎ By convention, when an angle denotes a direction in CSS, it is typically interpreted as a bearing angle, where 0deg is "up" or "north" on the screen, and larger angles are more clockwise (so 90deg is "right" or "east").
例えば、 `linear-gradient$f 関数において~gradientの方向を決定する `angle$t 値は、方位角に解釈される。 ◎ For example, in the linear-gradient() function, the <angle> that determines the direction of the gradient is interpreted as a bearing angle.
注記: 旧来の理由から、 `angle$t の一部の利用においては、 `0deg^v を意味する裸の `0^v も許容される。 しかしながら、これは一般には成立せず,また、将来における `angle$t 型の利用には生じない。 ◎ Note: For legacy reasons, some uses of <angle> allow a bare 0 to mean 0deg. This is not true in general, however, and will not occur in future uses of the <angle> type.
7.2. 時間長の単位: `time^t 型と `s^u, `ms^u 単位
時間~値は `time@t で表記される`次元$である。 時間の単位~識別子には次のものがある: ◎ Time values are dimensions denoted by <time>. The time unit identifiers are:
- `s@u
- 秒。 ◎ Seconds.
- `ms@u
- ~milli秒。 1 秒は 1000 ~milli秒。 ◎ Milliseconds. There are 1000 milliseconds in a second.
すべての `time$t 単位どうしは `互換$である — それらの`正準的~単位$は `s$u とする。 ◎ All <time> units are compatible, and s is their canonical unit.
~propには、時間~値を一定~範囲に制約するものもある。 許容d範囲~外の値を伴う宣言は無効であり,`無視する$モノトスル。 ◎ Properties may restrict the time value to some range. If the value is outside the allowed range, the declaration is invalid and must be ignored.
7.3. 周波数の単位: `frequency^t 型と `Hz^u, `kHz^u 単位
周波数~値は `frequency@t で表記される`次元$である。 周波数の単位~識別子には次のものがある: ◎ Frequency values are dimensions denoted by <frequency>. The frequency unit identifiers are:
- `Hz@u
- ~Hertz。 1 秒あたりの周波数を表現する。 ◎ Hertz. It represents the number of occurrences per second.
- `kHz@u
- ~KiloHertz。 1 ~KiloHertzは 1000 ~Hertz。 ◎ KiloHertz. A kiloHertz is 1000 Hertz.
例えば 音高を表現する際の, `200Hz^v(または `200hz^v )は 低音域にあり, `6kHz^v(または `6khz^v )は高音域にある。 ◎ For example, when representing sound pitches, 200Hz (or 200hz) is a bass sound, and 6kHz (or 6khz) is a treble sound.
すべての `frequency$t 単位どうしは `互換$である — それらの`正準的~単位$は `Hz$u とする。 ◎ All <frequency> units are compatible, and hz is their canonical unit.
注記: 単位は`~ASCII大小無視$であり,小文字に直列化される。 例えば `1Hz^v は `1hz^v に直列化される。 ◎ Note: Units are ASCII case-insensitive and serialize as lower case, for example 1Hz serializes as 1hz.
7.4. 解像度の単位: `resolution^t 型と `dpi^u, `dpcm^u, `dppx^u 単位
解像度の値は `resolution@t で表記される`次元$である。 解像度の単位~識別子には次のものがある: ◎ Resolution units are dimensions denoted by <resolution>. The resolution unit identifiers are:
- `dpi@u
- ~inchあたりの~dot数 ◎ Dots per inch.
- `dpcm@u
- ~centi~meterあたりの~dot数 ◎ Dots per centimeter.
- `dppx@u
- `x@u
- `px$u 単位あたりの~dot数 ◎ Dots per px unit.
`resolution$t 単位は、 1 ~CSS[ `in$u / `cm$u / `px$u ]の中に収まる~dot数を指示することにより, 1 個の “~dot” の~graphicな表現における~sizeを表現する。 用途については、例えば[ `resolution$d 媒体~query `MEDIAQ$r / `image-resolution$p ~prop `CSS3-IMAGES$r ]を見よ。 ◎ The <resolution> unit represents the size of a single "dot" in a graphical representation by indicating how many of these dots fit in a CSS in, cm, or px. For uses, see e.g. the resolution media query in [MEDIAQ] or the image-resolution property defined in [CSS3-IMAGES].
すべての `resolution$t 単位どうしは `互換$である — それらの`正準的~単位$は `dppx$u とする。 ◎ All <resolution> units are compatible, and dppx is their canonical unit.
注記: ~CSS `in$u から~CSS `px$u への固定d比率 1:96 に因り, `1dppx^v は `96dpi^v に等価になる。 これは、~CSSにて表示される画像の既定の解像度に対応する。 `image-resolution$p ~propを見よ ◎ Note that due to the 1:96 fixed ratio of CSS in to CSS px, 1dppx is equivalent to 96dpi. This corresponds to the default resolution of images displayed in CSS: see image-resolution.
次の `media^at 規則は、 Media Queries `MEDIAQ$r を利用して, 1 ~CSS `px$u 単位に 2 以上の機器~画素を利用する機器に 特別なスタイル規則をアテガう: ◎ The following @media rule uses Media Queries [MEDIAQ] to assign some special style rules to devices that use two or more device pixels per CSS px unit:
@media (min-resolution: 2dppx) { ... }
8. 他所で定義される~data型
他の~moduleにおける一部の~data型は、その~module自身の中で定義されている。 ここでは,多くの仕様に最も共通的に利用されている例を挙げる。 ◎ Some data types are defined in their own modules. This example talks about some of the most common ones used across several specifications.
8.1. 色: `color^t 型
`color$t ~data型は, `CSS3COLOR$r にて定義される。 CSS Color Level 3 またはその後継版を~supportする~UAは、その定義に従って `color$t を解釈するモノトスル。 ◎ The <color> data type is defined in [CSS3COLOR]. UAs that support CSS Color Level 3 or its successor must interpret <color> as defined therein.
8.1.1. `color^t の結合n
`color$t の`補間$は、値を成す[ ~red, ~green, ~blue, ~alpha ]各~成分を `number$t として独立に`補間-$するものとして定義される。 補間は、乗算済み色どうしで行われる(すなわち,指定された[ ~red, ~green, ~blue ]色~成分を~alphaで乗算してから補間する)。 ◎ Interpolation of <color> is defined as the independent interpolation of each component (red, green, blue, alpha) as a <number>. Interpolation is done between premultiplied colors (that is, colors for which the red, green, and blue components specified have been multiplied by the alpha).
同様に `color$t の`加算$は、値を成す各~成分を乗算済み空間 内で `number$t として独立に`加算-$するものとして定義される。 ◎ Addition of <color> is likewise defined as the independent addition of each component as a <number> in premultiplied space.
次のような~styleにおける `text-emphasis-color$p の値を考えるとき、算出d値は[ `currentcolor$v と実際の色との組合n ]を表現-可能になる必要がある。 `445$issue を見よ:
div { text-emphasis: circle; transition: all 2s; } div:hover { text-emphasis-color: lime; } em { color: red; }◎ Computed value needs to be able to represent combinations of currentColor and an actual color. Consider the value of text-emphasis-color in div { text-emphasis: circle; transition: all 2s; } div:hover { text-emphasis-color: lime; } em { color: red; } See Issue 445.
8.2. 画像: `image^t 型
`image$t ~data型は, `CSS3-IMAGES$r にて定義される。 CSS Images Level 3 またはその後継版を~supportする~UAは、その定義に従って `image$t を解釈するモノトスル。 そうでない~UAは、 `image$t を `url$t として解釈するモノトスル。 ◎ The <image> data type is defined in [CSS3-IMAGES]. UAs that support CSS Images Level 3 or its successor must interpret <image> as defined therein. UAs that do not yet support CSS Images Level 3 must interpret <image> as <url>.
8.2.1. `image^t の結合n
注記: `image$t の補間は `CSS3-IMAGES$r による 補間 にて定義される。 【~level 4 による補間】 ◎ Note: Interpolation of <image> is defined in CSS Images 3 §6 Interpolation.
画像は、`加法的でない$とする。 ◎ Images are not additive.
8.3. 二次元の位置: `position^t 型
`position@t 値は、位置決め区画(例:`背景~位置決め区画$)の内側における~obj区画(例:背景~画像)の位置を指定する。 それは、 `background-position$p に指定されるように解釈される。 `CSS3-BACKGROUNDS$r ◎ The <position> value specifies the position of a object area (e.g. background image) inside a positioning area (e.g. background positioning area). It is interpreted as specified for background-position. [CSS3-BACKGROUND]
`position$t = [ [ `left^v | `center^v | `right^v ] || [ `top^v | `center^v | `bottom^v ] | [ `left^v | `center^v | `right^v | `length-percentage$t ] [ `top^v | `center^v | `bottom^v | `length-percentage$t ]? | [ [ `left^v | `right^v ] `length-percentage$t ] && [ [ `top^v | `bottom^v ] `length-percentage$t ] ]
注記: `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.
直列化するときの正準的~順序は、[ 横~成分, 縦~成分 ]の順とする。 ◎ The canonical order when serializing is the horizontal component followed by the vertical component.
文法~内で他の[ ~keyword / `length$t / `percentage$t ]と並べて指定された `position$t は、`貪欲に^em構文解析され,アリな限り多くの成分を消費する。 ◎ When specified in a grammar alongside other keywords, <length>s, or <percentage>s, <position> is greedily parsed; it consumes as many components as possible.
例えば `transform-origin$p は、(実質的に) `position$t `length$t? として,三次元の位置を定義する。 `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) ''<position> <length>?''. A value such as left 50px will be parsed as a 2-value <position>, with an omitted z-component; on the other hand, a value such as top 50px will be parsed as a single-value <position> followed by a <length>.
8.3.1. `position^t の結合n
`position$t の`補間$は、値を成す[ x, y ]各~成分を[ 左上隅からの~offsetに正規化された `length-percentage$t ]として独立に`補間-$するものとして定義される。 ◎ Interpolation of <position> is defined as the independent interpolation of each component (x, y) normalized as an offset from the top left corner as a <length-percentage>.
同様に `position$t の`加算$は、値を成す[ x, y ]各~成分を[ 左上隅からの~offsetに正規化された `length-percentage$t ]として独立に`加算-$するものとして定義される。 ◎ Addition of <position> is likewise defined as the independent addition each component (x, y) normalized as an offset from the top left corner as a <length-percentage>.
9. 関数-記法
`関数-記法@ は、[ より複階的な型を表現する, あるいは特別な処理を呼出せる ]ような,成分~値の型である。 その構文は、[[ 関数の名前, 左~丸括弧 ](すなわち `function-token$t ), 引数の並び, 右~丸括弧 ]の並びである。 [ 左/右の丸括弧 ]と[ 引数の並び ]の合間には`空白$も許容される。 関数は、~CSS~prop値に似た書式で記される引数を,複数個とり得る。 ◎ A functional notation is a type of component value that can represent more complex types or invoke special processing. The syntax starts with the name of the function immediately followed by a left parenthesis (i.e. a <function-token>) followed by the argument(s) to the notation followed by a right parenthesis. White space is allowed, but optional, immediately inside the parentheses. Functions can take multiple arguments, which are formatted similarly to a CSS property value.
`rgba$f などの一部の旧来の関数-記法では,余分に~commaを利用しているが、一般には,~commaが利用されるのは[ ~list内の項を区切る, あるいは文法の一片から多義性を排する ]ときに限られる。 引数の区切りに~commaが利用される場合、その前後には省略可能な`空白$も挿入できる。 ◎ Some legacy functional notations, such as rgba(), use commas unnecessarily, but generally commas are only used to separate items in a list, or pieces of a grammar that would be ambiguous otherwise. If a comma is used to separate arguments, white space is optional before and after the comma.
background: url(http://www.example.org/image); color: rgb(100, 200, 50 ); content: counter(list-item) ". "; width: calc(50% - 2em);
`~math関数$は、 § 数学的な式にて定義される。 ◎ The math functions are defined in § 11 Mathematical Expressions.
9.1. 一連の値の~toggle : `toggle^f
`toggle@f 式は、子孫の一連の要素が,同じ値を継承する代わりに,値の~listから循環的に値を得られるようにする。 ◎ The toggle() expression allows descendant elements to cycle over a list of values instead of inheriting the same value.
次の例は、 `em^e 要素を一般の場所では斜字体にしつつ、斜字体の内側では通常体に戻す: ◎ The following example makes <em> elements italic in general, but makes them normal if they’re inside something that’s italic:
em { font-style: toggle(italic, normal); }
次の例は、入子な~listの~markerを順繰りに循環させる。 ~top-levelの~listの~markerは `disc$v 形状にされ、その中に入子な~listの~markerは,階が深まる度に順に `circle$v, `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.
ul { list-style-type: toggle(disc, circle, square, box); }
`toggle$f 式の構文は次で与えられる: ◎ The syntax of the toggle() expression is:
toggle( `toggle-value$t`#$g )
ここで `toggle-value@t は、式が置かれた場所で妥当である, かつ ~top-levelの~commaは包含しないような,任意の~CSS値である。 内側のいずれかの値が妥当でない場合、 `toggle$f 式~全体が無効になる。 `toggle$f 式は、どの~propの値に利用してもヨイが,その~prop値の唯一の成分でなければナラナイ。 ◎ where <toggle-value> is any CSS value that is valid where the expression is placed, and that doesn’t contain any top-level commas. If any of the values inside are not valid, then the entire toggle() expression is invalid. The toggle() expression may be used as the value of any property, but must be the only component in that property’s value.
`toggle$f 記法は入子にできない。 また `attr$f や `calc$f も包含できない。 そのような構成子を包含している宣言は無効になる。 ◎ The toggle() notation is not allowed to be nested; nor may it contain attr() or calc() notations. Declarations containing such constructs are invalid.
次の `toggle$f 式の例は、どれも無効になる: ◎ The following toggle() examples are all invalid:
background-position: 10px toggle(50px, 100px); /* `toggle$f 式は~propの唯一の成分でなければナラナイ ◎ toggle() must be the sole value of the property */ list-style-type: toggle(disc, 50px); /* `50px^v は `list-style-type$p の妥当な値でない ◎ 50px isn’t a valid value of 'list-style-type' */
`toggle$f 式の算出d値を決定するためには、最初に それぞれの引数を,それが式が置かれた~propの唯一の成分であったかのように評価して,引数ごとに表現される算出d値を得る — n 個目の引数に対し得られた値を Cn とする。 次に、各 Cn を~propの`継承d値$ と比較する。 `toggle$f の算出d値は、[ Cn が`継承d値$に合致するような最~小な n ]に対する Cn+1 になる。 n が最後の引数に対応する場合, あるいは合致する n が無い場合の算出d値は、最初の引数で表現される算出d値 C1 になる。 ◎ 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.
注記: したがって, `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).
注記: `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.
注記: ~propの`算出d値$は抽象的な値の集合であり、特定0の方法による直列化 `CSS21$r で与えられるものではない。 従って、算出d値の比較は常に一義的に定まり, 期待される結果になる筈である。 例えば,Level 2 の `background-position$p の算出d値は、それぞれが絶対~長さまたは百分率として表現される,ちょうど 2 個の~offsetを持つので、宣言 `background-position$p: `top center^v; および `background-position$p: `50% 0%^v; が生産する算出d値は,一致する。 ~prop定義の “算出d値” の欄が多義的, 厳密に過ぎるに思われる場合は、修正に取り掛かれるよう ~feedback を願う。 ◎ 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.
`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.
例えば、次の略式~propによる宣言は: ◎ For example, the following shorthand declaration:
margin: toggle(1px 2px, 4px, 1px 5px 4px);
次の下位propによる宣言に等価になる: ◎ is equivalent to the following longhand declarations:
margin-top: toggle(1px, 4px, 1px); margin-right: toggle(2px, 4px, 5px); margin-bottom: toggle(1px, 4px, 4px); margin-left: toggle(2px, 4px, 5px);
top ~marginには `1px^v が 2 度, bottom ~marginには `4px^v が 2 度 現れているので, 2 個の値のみを行き来する一方、 left / right ~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:
margin-top: toggle(1px, 4px); margin-right: toggle(2px, 4px, 5px); margin-bottom: toggle(1px, 4px); margin-left: toggle(2px, 4px, 5px);
その結果は意図されるものではないであろう。 ◎ which may not be what was intended.
10. 属性~参照: `attr^f 関数
`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.
attr() = attr( `wq-name$t `attr-type$t? , `declaration-value$t?) `attr-type@t = `string$v | `url$v | `ident$v | `color$v | `number$v | `percentage$v | `length$v | `angle$v | `time$v | `frequency$v | `flex$v | `dimension-unit$t
`dimension-unit@t 生成規則は、次のいずれかに合致する: ◎ The <dimension-unit> production matches\
- ~literal `%^l 文字(すなわち,.値に `%^l を伴う `delim-token$t )。 ◎ a literal "%" character (that is, a <delim-token> with a value of "%") or\
- `ident-token$t 【!~ident】のうち,その.値に[ 次に挙げる型~用の~CSS単位( `px$u や `ms$u など) ]を伴うもの ⇒ `length$t / `angle$t / `time$t / `frequency$t / `flex$t ◎ an ident whose value is any of the CSS units for <length>, <angle>, <time>, <frequency>, or <flex> values (such as px or ms).
`attr$f の引数は: ◎ The arguments of attr() are:
- `wq-name$t
- 参照-先の属性の名前を与える。 ◎ Gives the name of the attribute being referenced.
- 名前空間は指定されていない場合( `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.)\
- `wq-name$t における文字大小比較は、`属性~選択子$と同じく,文書~言語に依存する。 ◎ As with attribute selectors, the case-sensitivity of <wq-name> depends on the document language.
- ある要素に適用される~propにおいて `attr$f が利用された場合、その要素~上の所与の名前の属性を参照する。 ~propが`疑似要素$に適用される場合、その`出自の要素$上の属性が検索される。 ◎ 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.
- `attr-type$t
- 当の属性の値を,どの種類の~CSS値( `attr$f の `代用~値@ )として解釈するかを — 値に対し行う特別な構文解析もあれば,それも含めて — 指定する。 ◎ Specifies what kind of CSS value the attribute’s value will be interpreted into (the attr()’s substitution value) and what, if any, special parsing will be done to the value.
- アリな値, および それらの挙動は、 § `attr^f の各~型 にて定義される。 ◎ The possible values and their behavior are defined in § 10.1 attr() Types.
- 省略された場合の既定は、 `string$v になる。 ◎ Defaults to string if omitted.
- `declaration-value$t
- `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.
- 省略された場合の既定は、 `attr-type$t 引数が[ `string$v の場合は空~文字列/ ~ELSE_ `無効が保証される値$ ]になる。 ◎ If the <attr-type> argument is string, defaults to the empty string if omitted; otherwise, defaults to the guaranteed-invalid value if omitted.
~propが 1 個以上の `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.
注記: 既定~値は、所与の型【 `attr-type$t 】にする必要はない。 一例として,作者が要求する属性の型は `px$u であったとしても、 `width$p: `attr(size px, auto)^v; の様に,既定は `auto^v にすることもできる。 ◎ 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 px, the default could still be auto, like in width: attr(size px, auto);.
10.1. `attr^f の各~型
`attr$f 関数の挙動は、 `attr-type$t 引数の値に部分的に依存する — 以下においては:
- 当の要素は、関数が参照している属性を有しているとする。
- %属性~値 は、属性の値をそのまま表すとする。
- %成分~値 は、次の結果を表すとする ⇒ `成分~値を構文解析する$( %属性~値 )
- 結果の`代用~値$に対する値 ε (なし)は、~fallbackを誘発することを意味する。
- `string@v
- `代用~値$は、~CSS文字列であり,その.値には %属性~値 があてがわれる(~CSS構文解析や値の “整理” は遂行されない)。 ◎ The substitution value is a CSS string, whose value is the literal value of the attribute. (No CSS parsing or "cleanup" of the value is performed.)
- %属性~値 が何であれ,~fallbackは誘発されない。 ◎ No value triggers fallback.
- `url@v
- `代用~値$は、 `url$t 値であり,その~urlには %属性~値 があてがわれる(~CSS構文解析や値の “整理” は遂行されない)。 ◎ The substitution value is a CSS <url> value, whose url is the literal value of the attribute. (No CSS parsing or "cleanup" of the value is performed.)
- 注記: `url$f の構文に関数を包含する能力があったならば、 `attr(foo url)^v は, `url(attr(foo string))^v に一致することになる。 ◎ Note: If url() was syntactically capable of containing functions, attr(foo url) would be identical to url(attr(foo string)).
- %属性~値 が何であれ,~fallbackは誘発されない。 ◎ No value triggers fallback.
- `ident@v
-
`代用~値$は、 %属性~値 の`前後の~ASCII空白~列を剥いだ$結果 %結果 に応じて:
- 【文字大小無視で?】[ 空~文字列 / `~CSS全域~keyword$ / `default^v ]の場合は ε 。
- 他の場合、 `custom-ident$t であり,その.値には %結果 があてがわれる(~CSS構文解析は遂行されない)。
- `color@v
- `代用~値$は、[ %成分~値 は[ `hex-color$t / `有名~色$を.値にとる `ident-token$t 【!~ident】 ]であるならば %成分~値 が与える `color$t / ~ELSE_ ε ] ◎ Parse a component value from the attribute’s value. If the result is a <hex-color> or a named color ident, the substitution value is that result as a <color>. ◎ Otherwise there is no substitution value.
- `number@v
- `代用~値$は、[ %成分~値 は `number-token$t であるならば %成分~値 / ~ELSE_ ε ] ◎ Parse a component value from the attribute’s value. If the result is a <number-token>, the result is the substitution value. ◎ Otherwise, there is no substitution value.
- `percentage@v
- `代用~値$は、[ %成分~値 は `percentage-token$t であるならば %成分~値 / ~ELSE_ ε ] ◎ Parse a component value from the attribute’s value. If the result is a <percentage-token>, the result is the substitution value. ◎ Otherwise, there is no substitution value.
- `length@v
- `angle@v
- `time@v
- `frequency@v
- `flex@v
- `代用~値$は、[ %成分~値 は `dimension-token$t であって,その.単位は所与の型に合致するならば %成分~値 / ~ELSE_ ε ] ◎ Parse a component value from the attribute’s value. If the result is a <dimension-token> whose unit matches the given type, the result is the substitution value. ◎ Otherwise, there is no substitution value.
- `dimension-unit$t
- `代用~値$は、[ %成分~値 は `number-token$t であるならば[ %成分~値 の.値, 所与の単位 ]を伴う`次元$ / ~ELSE_ ε ] ◎ Parse a component value from the attribute’s value. If the result is a <number-token>, the substitution value is a dimension with the result’s value, and the given unit. ◎ Otherwise, there is no substitution value.
`attr^f 値として、各種`~math関数$を すべての数量-型~用に許容するよう求まれるか?
同様に, “色” 用にも各種 色~関数を許容するか?
編集者は そう~~考えているが、代用~値が更に参照~関数を包含していないことを確かめるため,内容を検査する必要も生じる
— `foo^a="`rgb(var(--red), 0, 0)^v"
は、 `attr(foo color)^v 用には違法になる必要がある。
◎
Do we want to allow math functions as attr values for all the numeric types? And color functions for "color"? I think we do, but I’d have to check the contents to make sure they don’t contain further reference functions; foo="rgb(var(--red), 0, 0)" needs to be illegal for attr(foo color).
~XML~file内の~dataを可視化するために `attr$f を利用する例: ◎ This example shows the use of attr() to visually illustrate data in an XML file:
<在庫> <木材 length="12"/> <木材 length="5"/> <金属 length="19"/> <木材 length="4"/> </在庫> 在庫::before { display: block; content: "ある縮尺による,在庫の各素材の長さ:"; } 在庫 > * { display: block; width: attr(length em, 0px); height: 1em; border: solid thin; margin: 0.5em; } 木材 { background: orange url(wood.png); } 金属 { background: silver url(metal.png); }
10.2. `attr^f の代用
`attr^f, `var^f は,同時に代用されるので、おそらく, `var^f を代用する を,もっと一般に “参照を代用する” ように書直して、それを両~関数~用に利用するべきである。 ◎ attr() and var() substitute at the same time, so I should probably rewrite substitute a var() to be more generally about "substitute a reference" and just use that for both of these functions.
`attr$f 関数は、算出d値の時点に`代用-$される。 所与の宣言は、[ 宣言を成すすべての `attr^f 関数を代用した結果が、宣言~用に宣言された文法に合致しない ]場合には,`算出d値の時点で無効$になる。 ◎ attr() functions are substituted at computed-value time. If a declaration, once all attr() functions are substituted in, does not match its declared grammar, the declaration is invalid at computed-value time.
所与の~propの値の中で `attr$f 関数 %関数 を `代用-@ するときは: ◎ To substitute an attr():
- ~IF[ %関数 の`代用~値$ ~NEQ ε ] ⇒ %関数 を その代用~値に置換する ◎ If the attr() function has a substitution value, replace the attr() function by the substitution value.
- ~ELIF[ %関数 の`~fallback値$は`無効が保証される値$でない ] ⇒ %関数 を その~fallback値に置換する — ~fallback内に[ `var$f / `attr$f ]参照がある場合は,それらも`代用-$した上で ◎ Otherwise, if the attr() function has a fallback value as its last argument, replace the attr() function by the fallback value. If there are any var() or attr() references in the fallback, substitute them as well.
- ~ELSE ⇒ 当の~propは`算出d値の時点で無効$とする ◎ Otherwise, the property containing the attr() function is invalid at computed-value time.
11. 数学的な式
`~math関数@ ( `calc$f, `clamp$f, `sin$f, その他,この節に定義するもの)は、数量~CSS値を数学的な式として書けるようにする。 ◎ The math functions (calc(), clamp(), sin(), and others defined in this chapter) allow numeric CSS values to be written as mathematical expressions.
`~math関数$は、次に挙げるいずれかの数量-値, または[ `length-percentage$t 等々の複数の型が混在なもの ]を表現し,そのような値が妥当になる所ならどこでも利用できる ⇒# `length$t, `frequency$t, `angle$t, `time$t, `flex$t, `resolution$t, `percentage$t, `number$t, `integer$t ◎ A math function represents a numeric value, one of: • <length>, • <frequency>, • <angle>, • <time>, • <flex>, • <resolution>, • <percentage>, • <number>, • <integer> ◎ ...or the <length-percentage>/etc mixed types, and can be used wherever such a value would be valid.
【 この節では、無限大(−∞/+∞)に加えて,[ 負な 0 を表す ~0N / 正な 0 を表す ~0P ]も利用される。 したがって、 0 は ~0N, ~0P の総称を表すことになる — 特に,[ ~0N は負な数とは見なされない( ~0N ~LT 0 ではない) / ~0P は正な数とは見なされない( ~0P ~GT 0 ではない) ]ことに注意。 】
11.1. 基本的な算術: `calc^f
`calc@f 関数は,`~math関数$であり、[ 加算( `+^css ), 減算( `-^css ), 乗算( `*^css ), 除算( `/^css ), 丸括弧 ]を利用して,数量的な値に対し 基本的な算術を遂行できるようにする。 ◎ The calc() function is a math function that allows basic arithmetic to be performed on numerical values, using addition (+), subtraction (-), multiplication (*), division (/), and parentheses.
`calc$f 関数は、 1 個の`計算式$を包含する。 `計算式@ は、いくつかの演算子が合間に挟まれ,場合によっては丸括弧により~group化された一連の値からなる( `calc-sum$t 文法に合致する)。 それは、標準な演算子 優先順位~規則を利用して,式を評価した結果を表現する(各~演算子は、[ `*^css / `/^css ]が[ `+^css / `-^css ]より~~結合度が高いことを除いて,左から右の順に評価される)。 `calc^f 関数は、それが包含する`計算式$の結果を表現する。 ◎ A calc() function contains a single calculation, which is a sequence of values interspersed with operators, and possibly grouped by parentheses (matching the <calc-sum> grammar), which represents the result of evaluating the expression using standard operator precedence rules (* and / bind tighter than + and -, and operators are otherwise evaluated left-to-right). The calc() function represents the result of its contained calculation.
`計算式$を成す各 成分は、[ ~literal値( `5px^v など), 他の`~math関数$, `attr$f などの他の式 ]のいずれかであって,【式を利用している文脈において】妥当な引数~型( `length$t など)に評価されるものをとれる。 ◎ Components of a calculation can be literal values (such as 5px), other math functions, or other expressions, such as attr(), that evaluate to a valid argument type (like <length>).
`~math関数$は、異なる単位を利用する値を組合せるときに利用できる。 次の例では、作者は各 `section^e の~margin~boxが空間の 1/3 を占めるよう求めているので, `100%/3^v から 要素の~borderと~margin分を減算する。 ( `box-sizing$p は,~borderと~paddingに対しては この効果を自動的に達成できるが、~marginを含めたいと求める場合,~math関数が必要になる。) ◎ Math functions can be used to combine value that use different units. In this example the author wants the margin box of each section to take up 1/3 of the space, so they start with 100%/3, then subtract the element’s borders and margins. (box-sizing can automatically achieve this effect for borders and padding, but a math function is needed if you want to include margins.)
section { float: left; margin: 1em; border: solid 1px; width: calc(100% / 3 - 2 * 1em - 2 * 1px); }
同様に,次の例の~gradientは、要素の最初と最後の `20px^v 内に限り,色の遷移を示すことになる: ◎ Similarly, in this example the gradient will show a color transition only in the first and last 20px of the element:
.fade { background-image: linear-gradient( silver 0%, white 20px, white calc(100% - 20px), silver 100% ); }
`~math関数$は、より自然かつ読易い~~形で値を表出するためだけでも — ただの 10 進数より真意が見える点で — 有用になり得る。 次の例では、 `35em^v がちょうど表示域に収まるように `font-size$p を設定して,[ ~screenの大きさを問わず,常に概ね同じ量の~textが~screenを埋める ]ことを確保している: ◎ Math functions can also be useful just to express values in a more natural, readable fashion, rather than as an obscure decimal. For example, the following sets the font-size so that exactly 35em fits within the viewport, ensuring that roughly the same amount of text always fills the screen no matter the screen size.
:root { font-size: calc(100vw / 35); }
これは,~~機能上は "`font-size: 2.857vw^css" と書くのと同じことになるが、~codeを読んでいる誰かにとっては,その意図( `35em^v が表示域を埋める)はずっと~~不明瞭になる — その誰かは、後で逆算して, 2.857 は 100/35 を近似する~~意図で記されたことを解き明かすはめになる。 ◎ Functionality-wise, this is identical to just writing font-size: 2.857vw, but then the intent (that 35em fills the viewport) is much less clear to someone reading the code; the later reader will have to reverse the math themselves to figure out that 2.857 is meant to approximate 100/35.
標準な演算子 優先順位~規則が適用されるので、 `calc(2 + 3 * 4)^v は, `20^v ではなく `14^v に等しくなる。 ◎ Standard mathematical precedence rules for the operators apply: calc(2 + 3 * 4) is equal to 14, not 20.
丸括弧を利用すれば、優先順位を操作できる: `calc((2 + 3) * 4)^v は, `20^v に等しくなる。 ◎ Parentheses can be used to manipulate precedence: calc((2 + 3) * 4) is instead equal to 20.
丸括弧と, 追加的な `calc$f 関数を入子にするのとは、等価になる。 上の `calc((2 + 3) * 4)^v は、 `calc(calc(2 + 3) * 4)^v と書いても等価になる。 これは、次の例のように,~~細切れな~~成分から `var$f を介して値を築き上げるときに有用になり得る: ◎ Parentheses and nesting additional calc() functions are equivalent; the preceding expression could equivalently have been written as calc(calc(2 + 3) * 4). This can be useful when building up values piecemeal via var(), such as in the following example:
.aspect-ratio-box { --ar: calc(16 / 9); /* 【縦横比】 */ --w: calc(100% / 3); --h: calc(var(--w) / var(--ar)); width: var(--w); height: var(--h); }
`--ar^p の値は単純に `(16 / 9)^v と書く`こともできる^em。 一方, `--w^p は、全部的な `calc^f 関数として書く必要がある — `--ar^p と同じく, `--h^p にて `calc$f 成分に利用されているが、 `width$p にも そのままに利用されているので,。 ◎ Although --ar could have been written as simply --ar: (16 / 9);, --w is used both on its own (in width) and as a calc() component (in --h), so it has to be written as a full calc() function itself.
11.2. 比較~関数: `min^f, `max^f, `clamp^f
比較~関数 — `min$f, `max$f, `clamp$f — は、複数の`計算式$を比較して,それらのうち 1 つの値を表現する。 ◎ The comparison functions of min(), max(), and clamp() compare multiple calculations and represent the value of one of them.
[ `min@f / `max@f ]関数は、~comma区切りの 1 個~以上の`計算式$を包含し,最も[ 小さい (負側の)/大きい(正側の) ]項を表現する。 ◎ The min() or max() functions contain one or more comma-separated calculations, and represent the smallest (most negative) or largest (most positive) of them, respectively.
`clamp@f 関数は、 3 個の`計算式$ — %最小, %中央-, %最大 — を順にとり, %中央- 計算式を { %最小 〜 %最大 } の範囲内に切詰める計算を表現する。 %最大 と %最小 が競合する場合は %最小 が優先される(すなわち, `clamp( 最小v, 値v, 最大v )^v は、 `max( 最小v, min( 値v, 最大v ) ) )^v と正確に同じ値を表現する)。 ◎ The clamp() function takes three calculations—a minimum value, a central value, and a maximum value—and represents its central calculation, clamped according to its min and max calculations, favoring the min calculation if it conflicts with the max. (That is, given clamp(MIN, VAL, MAX), it represents exactly the same value as max(MIN, min(VAL, MAX))).
[ `min$f / `max$f / `clamp$f ]は、[ 値は “安全な” 制限-を超過しない ]ことを~~確保するために利用できる。 例えば, `font-size$p を表示域~単位で設定する “`responsive type^en 【~screen~sizeに合わせた~~植字】” であっても,可読性を確保する最小~sizeが求まれるかもしれない: ◎ min(), max(), and clamp() can be used to make sure a value doesn’t exceed a "safe" limit: For example, "responsive type" that sets font-size with viewport units might still want a minimum size to ensure readability:
.type {
/*
`font-size^p を表示域の縦幅と横幅の平均の 10/100 倍に設定するが、
`12px^v は~~下回らないようにする。
◎
Set font-size to 10x the average of vw and vh, but don’t let it go below 12px.
*/
font-size: max(10 * (1vw + 1vh) / 2, 12px);
}
注記: どの引数にも全部的な~math式が許容されるので、内側に `calc$f を入子にする必要はない。 適用する拘束が複数あるならば、 3 個~以上の引数も供せる。 ◎ Note: Full math expressions are allowed in each of the arguments; there’s no need to nest a calc() inside! You can also provide more than two arguments, if you have multiple constraints to apply.
何かに[ 最小~値を課すときは `max$f / 最大~値を課すときは `min$f ]を利用することになるが(すなわち, `min-width$p の様な~propは、実質的に `max^f を利用する)、これは,反対の関数に混同され易くもある — 最小~sizeを追加するときに不用意に `min^f を利用してしまうなど。 `clamp$f を利用すれば、値は 最小と最大の合間に~~挟まれるので,~codeはより自然に読めるようになる: ◎ An occasional point of confusion when using min()/max() is that you use max() to impose a minimum value on something (that is, properties like min-width effectively use max()), and min() to impose a maximum value on something; it’s easy to accidentally reach for the opposite function and try to use min() to add a minimum size. Using clamp() can make the code read more naturally, as the value is nestled between its minimum and maximum:
.type {
/*
`font-size^p を `12px^v と `100px^v の合間に~~居座るよう強制する
◎
Force the font-size to stay between 12px and 100px
*/
font-size: clamp(12px, 10 * (1vw + 1vh) / 2, 100px);
}
注記: `clamp$f の最小~値は最大~値に — その 2 つの “順序が間違っている” ときでも — “勝つ” ことに注意(他の部分は、~CSS規約に合致しているとする)。 すなわち、 `clamp(100px, ..., 50px)^v は `100px^v に解決されることになる — “最大” として与えられた `50px^v を超過して。 ◎ Note that clamp(), matching CSS conventions elsewhere, has its minimum value "win" over its maximum value if the two are in the "wrong order". That is, clamp(100px, ..., 50px) will resolve to 100px, exceeding its stated "max" value.
別の解決-法が欲される場合、 `clamp$f と `min$f / `max$f を組合せれば達成できる: ◎ If alternate resolution mechanics are desired they can be achieved by combining clamp() with min() or max():
- 最大v が 最小v に勝つようにするためには: ◎ To have MAX win over MIN:
- `clamp( min( 最小v, 最大v ), 値v, 最大v )^v ◎ clamp(min(MIN, MAX), VAL, MAX).\
- 最大v の計算を繰返すのを避けたいなら、単に `clamp$f に定義した関数の入子ngを逆にする~~方法もある ⇒ `min( 最大v, max( 最小v, 値v ) )^v ◎ If you want to avoid repeating the MAX calculation, you can just reverse the nesting of functions that clamp() is defined against—min(MAX, max(MIN, VAL)).
- 順序が間違っているときには、 最大vと最小v を “入替える” ようにするためには: ◎ To have MAX and MIN "swap" when they’re in the wrong order:
- `clamp( min( 最小v, 最大v ), 値v, max( 最小v, 最大v ) )^v ◎ clamp(min(MIN, MAX), VAL, max(MIN, MAX)).\
- あいにく, 最小v, 最大v 項を繰返すことなく これを行う容易な仕方は無い。 ◎ Unfortunately, there’s no easy way to do this without repeating the MIN and MAX terms.
11.3. 丸ng関数と剰余~関数: `round^f, `mod^f, `rem^f
丸ng関数 `round$f と剰余~関数[ `mod$f / `rem$f ]は、どれも,所与の値を別の “段差~値” に則って異なる仕方で変形する。 (これらは、 `stepped-value^en 関数と総称される)。 ◎ The stepped-value functions, round(), mod(), and rem(), all transform a given value according to another "step value", in different ways.
`round(~vC?, ~vA, ~vB)@f 関数は、それが包含する[ 丸ng策を表す省略可能な `rounding-strategy$t 値 ~vC, 丸められる`計算式$ ~vA, 精度を表す`計算式$ ~vB ]に対し, ~vA を[ ~vB の整数~倍 ]のうち — ~vC に則って,~vA 以上または以下の — 最も近い値に丸めた結果を返す。 ◎ The round(<rounding-strategy>?, A, B) function contains an optional rounding strategy, and two calculations A and B, and returns the value of A, rounded according to the rounding strategy, to the nearest integer multiple of B either above or below A.\
~vA, ~vB は,[ `number$t, `dimension$t, `percentage$t ]のどれにも解決し得るが、それらの`型を決定-$した結果は`同じ^emにならなければナラナイ — さもなければ関数は無効になるとする。 結果の`型$は、引数のそれと同じになる。 ◎ The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid; the result will have the same type as the arguments.
~vA が ~vB の整数~倍に正確に等しい場合、 `round$f は正確に ~vA に解決される( ~vA が ~0N, ~0P どちらなのかも保全される)。 他の場合、 ~vB の整数~倍のうち ~vA に “最も近いもの” は[ −∞ に近い方 %低いB, +∞ に近い方 %高いB ]の 2 つがある。 どちらを選ぶかは、 ~vC に与える `rounding-strategy@t が規定する: ◎ If A is exactly equal to an integer multiple of B, round() resolves to A exactly (preserving whether A is 0⁻ or 0⁺, if relevant). Otherwise, there are two integer multiples of B that are potentially "closest" to A, lower B which is closer to −∞ and upper B which is closer to +∞. The following <rounding-strategy>s dictate how to choose between them:
- `nearest@v
- %低いB, %高いB のうち ~vA からの差が(絶対~値として)小さい方を選ぶ。 差が等しい場合は %高いB を選ぶ。 ◎ Choose whichever of lower B and upper B that has the smallest absolute difference from A. If both have an equal difference (A is exactly between the two values), choose upper B.
- `up@v
- %高いB を選ぶ。 ◎ Choose upper B.
- `down@v
- %低いB を選ぶ。 ◎ Choose lower B.
- `to-zero@v
- %低いB, %高いB のうち絶対~値が小さい方を選ぶ。 ◎ Choose whichever of lower B and upper B that has the smallest absolute difference from 0.
[ %低いB / %高いB ]は、 0 になる場合には,特定的に[ ~0P / ~0N ]になるとする。 ◎ If lower B would be zero, it is specifically equal to 0⁺; if upper B would be zero, it is specifically equal to 0⁻.
`rounding-strategy$t が省略された場合の既定は、 `nearest$v とする。 ◎ If <rounding-strategy> is omitted, it defaults to nearest.
`5689$issue: `round^f は~CSSOMにおいて特別か? ◎ w3c/csswg-drafts/5689[cssom] Is `round` special in CSSOM?
~JSの様な,(整数に)丸める自然な “精度” を備える言語と違って、~CSS値には,そのような精度は無い — 値は様々な`互換$な単位で記され得るので。 なので、精度は明示的に与える必要がある。 `round(var(--width), 50px)^v と書いたなら、横幅( `--width^p の値)を最も近い `50px^v の整数倍に丸めることになる。 ◎ Unlike languages like JavaScript which have a natural "precision" to round to (integers), CSS values have no such precision because values can be written in many different compatible units. As such, the precision has to be given explicitly; to round a width to the nearest 50px, one can write round(var(--width), 50px).
注記: ~JSを含む~programming言語には、各種 丸ng策を別々な丸ng関数に分離しているものもある。 ~JSの[ `Math.floor()^c / `Math.ceil()^c / `Math.trunc()^c / `Math.round()^c ]は、~CSSの[ `round(down, …)^v / `round(up, …)^v / `round(to-zero, …)^v / `round(nearest, …)^v (あるいは単に `round(…)^v ) ]に等価になる。 ◎ Note: JavaScript and other programming languages sometimes separate out the rounding strategies into separate rounding functions. JS’s Math.floor() is equivalent to CSS’s round(down, ...); JS’s Math.ceil() is equivalent to CSS’s round(up, ...); JS’s Math.trunc() is equivalent to CSS’s round(to-zero, ...); and JS’s Math.round() is equivalent to CSS’s round(nearest, ...), or just round(...).
注記: `rounding-strategy$t を成す各~keywordは、 `block-step-round$p 【! `block-step-size$p 】用の~keywordと同じであり,同じ挙動を備える( `block-step-round^p は `to-zero$v だけ欠いているが — `塊~size$は負になり得ず, `to-zero^v は `down$v に一致することになるので)。 ◎ Note: The <rounding-strategy> keywords are the same as the keywords in block-step-size and have the same behavior. (block-step-size just lacks to-zero; since block sizes are always non-negative, to-zero and down would be identical.)
剰余~関数 `mod(~vA, ~vB)@f と `rem(~vA, ~vB)@f は、類似する( "mod" は “`modulus^en” の略, "rem" は “`remainder^en” の略 )。 どちらも,それが包含する[ ~~被除数を表す`計算式$ ~vA, 段差を表す`計算式$ ~vB ]に対し, ~vA から ~vA を丸めた結果 — ~vA 以上または以下の, ~vA に最も近い ~vB の整数~倍 — を減算した結果を返す。 ◎ The modulus functions mod(A, B) and rem(A, B) similarly contain two calculations A and B, and return the difference between A and the nearest integer multiple of B either above or below A.\
~vA, ~vB は,[ `number$t, `dimension$t, `percentage$t ]のどれにも解決し得るが、それらの`型を決定-$した結果は`同じ^emにならなければナラナイ — さもなければ関数は無効になるとする。 結果の`型$は、引数のそれと同じになる。 ◎ The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid; the result will have the same type as the arguments.
この 2 つの関数はとても類似する: ◎ The two functions are very similar, and\
-
事実,引数 ~vA, ~vB の符号nが一致する場合、結果は一致する。 関数の値は、その結果が次の範囲に入るように, ~vA の値を ~vB のある整数~倍でずらした結果に等しくなる:
- 引数が負ならば ⇒ ~vB ~LT 結果 ~LTE ~0N ( “負な範囲” ) — 結果が 0 になる場合は ~0N を選ぶ
- 引数が正ならば ⇒ ~0P ~LTE 結果 ~LT ~vB ( “正な範囲” ) — 結果が 0 になる場合は ~0P を選ぶ
例えば, `mod(18px, 5px)^v は、値 `3px^v に解決される — `18px^v から `5px^v の 3 倍 を減算すれば `3px^v が得られ,それが `0px^v と `5px^v 【!3px】の合間に入る唯一の値なので。 ◎ For example, mod(18px, 5px) resolves to the value 3px, because subtracting 5px * 3 from 18px yields 3px, which is the only such value between 0px and 3px.
同様に, `mod(-140deg, -90deg)^v は、値 `-50deg^v に解決される — `-140deg^v に `-90deg^v の 1 倍を加算すれば `-50deg^v が得られ,それが `0deg^v と `-90deg^v の合間に入る唯一の値なので。 ◎ Similarly, mod(-140deg, -90deg) resolves to the value -50deg, because adding -90deg * 1 to -140deg yields -50deg, which is the only such value between 0deg and -90deg.
これら各~例を `rem$f で評価した結果は、正確に同じになる。 ◎ Evaluating either of these examples with rem() yields the exact same results.
-
~vA, ~vB の符号nが一致しない場合、 2 つの関数の挙動は分岐する: ◎ Their behavior diverges if the A value and the B step are on opposite sides of zero:\
- `mod$f は、結果の範囲を ~vB の符号nに基づいて選ぶ。 【 ~vB が 0 の事例は、下の下位節を見よ。】 ◎ mod() (short for “modulus”) continues to choose the integer multiple of B that puts the value between zero and B, as above (guaranteeing that the result will either be zero or share the sign of B, not A), while\
- `rem$f は、結果の範囲を ~vA の符号nに基づいて選ぶ。 【 ~vA が 0 の場合も, ~0N か ~0P かに応じて範囲を選ぶ(結果が同じ ~0N / ~0P になるよう)。】 ◎ rem() (short for "remainder") chooses the integer multiple of B that puts the value between zero and -B, avoiding changing the sign of the value.
【 これらの規則は、引数の符号nが一致する場合も包摂することになる。 】
例えば, `mod(-18px, 5px)^v は、値 `2px^v に解決される — `-18px^v に `5px^v の 4 倍を加算すれば `2px^v が得られ,それが `0px^v と `5px^v の合間に入る。 ◎ For example, mod(-18px, 5px) resolves to the value 2px: adding 5px * 4 to -18px yields 2px, which is between 0px and 5px.
他方, `rem(-18px, 5px)^v は、値 `-3px^v に解決される — `-18px^v に `5px^v の 3 倍を加算すれば, `-18px^v と同じ符号nの `-3px^v が得られ、それが `0px^v と `-5px^v の合間に入る。 ◎ On the other hand, rem(-18px, 5px) resolves to the value -3px: adding 5px * 3 to -18px yields -3px, which has the same sign as -18px but is between 0px and -5px.
同様に, `mod(140deg, -90deg)^v は,値 `-40deg^v に解決されるが( `140deg^v に `-90deg^v の 2 倍を加算すれば, `0deg^v と `-90deg^v の合間に入る)、 `rem(140deg, -90deg)^v は,値 `50deg^v に解決される。 ◎ Similarly, mod(140deg, -90deg) resolves to the value -40deg (adding -90deg * 2 to 140deg, bringing it to between 0deg and -90deg), but rem(140deg, -90deg) resolves to the value 50deg.
`mod$f, `rem$f のどっちを選ぶべきか? ◎ When should I choose mod() vs rem()?
この演算の利用者は、概して,段差~値( ~vB )を制御して,未知な値 ~vA を改変する。 それゆえ,`通例的には^em、 ~vA の符号nに関わらず,結果は 0 と ~vB の合間に入る方が期待される — すなわち, `mod$f が選ばれるべきである。 ◎ Typically, users of this operation are in control of the step value (B), and are modifying an unknown value A. As a result, it’s usually more expected that the result is between 0 and B, regardless of A’s sign, meaning mod() should be chosen.
作者が例えば,ある長さが `px^u ~~単位で偶数/奇数どちらになるか知りたいと求める場合(ここでは、長さは `px^u の整数倍であると見做す)、 `mod(~vA, 2px)^v は ~vA の値が何であれ, `0px^v か `1px^v を返すことになる。 他方,`rem(~vA, 2px)^v は、 ~vA が偶数 `px^u なら `0px^v を返すが,奇数の場合は ~vA に依存して[ 正ならば `1px^v /負ならば `-1px^v ]を返すことになる。 ◎ For example, if an author wants to know whether a length is an even or odd number of pixels, mod(A, 2px) will return either 0px or 1px (assuming the value is a whole number of pixels to begin with), regardless of the value of a. rem(A, 2px), on the other hand, will return 0px if A is an even number of pixels, but will return either 1px or -1px if it’s odd, depending on whether A is positive or negative.
しかしながら,反対の状況もあり【すなわち、 ~vB が未知】、それをまかなうために `rem$f が供されている。 また、 `rem^f は~JSの `%^c 演算子の挙動を備えるので、~CSSと~JS~codeとが正確に合致することが欲される場合には `rem^f が有用になり得る。 ◎ The opposite situation does sometimes occur, however, and so rem() is provided to cater to that. As well, rem() is the behavior of JavaScript’s % operator, so if an exact match between CSS and JS code is desired, rem() can be useful.
注記: `mod$f, `rem$f は、他の関数でも直に定義できる:
-
`mod(~vA, ~vB)^v は、次に等価になる ⇒ `calc(~vA - sign(~vB)*round(down, ~vA*sign(~vB), ~vB))^v
( ~vB が[ 正なら `calc(~vA - round(down, ~vA, ~vB))^v / 負なら `calc(~vA - round(up, ~vA, ~vB))^v ]が得られるようにした式)
- `rem(~vA, ~vB)^v は、次に等価になる ⇒ `calc(~vA - round(to-zero, ~vA, ~vB))^v
(これらの式は、 ~0P, ~0N を常に正しく取扱うわけではないが — ~0N の意味論は加算において可換でないので。)
◎ Note: mod() and rem() can also be defined directly in terms of other functions: mod(A, B) is equivalent to calc(A - sign(B)*round(down, A*sign(B), B)) (a hacky way to say "round(down) when B is positive, round(up) when B is negative), while rem(A, B) is equivalent to calc(A - round(to-zero, A, B)). (These expressions don’t always handle 0⁺ and 0⁻ correctly, though, because 0⁻ semantics aren’t commutative for addition.)11.3.1. 引数の範囲
`round(~vA, ~vB)$f においては: ◎ In round(A, B),\
- ~vB ~IN { ~0N, ~0P } ならば,結果は ~NaN になる。 ◎ if B is 0, the result is NaN.\
- ~vA ~IN { +∞, −∞ } ならば ⇒# ~vB ~IN { +∞, −∞ } ならば,結果は ~NaN になる 他の場合,結果は ~vA になる ◎ If A and B are both infinite, the result is NaN. ◎ If A is infinite but B is finite, the result is the same infinity.
-
他の場合, ~vB ~IN { +∞, −∞ } ならば、 `rounding-strategy$t に応じて: ◎ If A is finite but B is infinite, the result depends on the <rounding-strategy> and the sign of A:
- `nearest$v / `to-zero$v ⇒# ~vA ~EQ ~0P または ~vA ~GT 0 ならば,結果は ~0P になる/ ~vA ~EQ ~0N または ~vA ~LT 0 ならば,結果は ~0N になる ◎ nearest to-zero • If A is positive or 0⁺, return 0⁺. Otherwise, return 0⁻.
- `up$v ⇒# ~vA ~GT 0 ならば,結果は +∞ になる/ ~vA ~EQ ~0P ならば,結果は ~0P になる/ ~vA ~EQ ~0N または ~vA ~LT 0 ならば,結果は ~0N になる ◎ up • If A is positive (not zero), return +∞. If A is 0⁺, return 0⁺. Otherwise, return 0⁻.
- `down$v ⇒# ~vA ~EQ ~0P または ~vA ~GT 0 ならば,結果は ~0P になる/ ~vA ~EQ ~0N ならば,結果は ~0N になる/ ~vA ~LT 0 ならば,結果は −∞ になる ◎ down • If A is negative (not zero), return −∞. If A is 0⁻, return 0⁻. Otherwise, return 0⁺.
[ `mod(~vA, ~vB)$f / `rem(~vA, ~vB)$f ]においては、次のいずれかに該当する場合,結果は ~NaN になる:
- ~vB ~IN { ~0N, ~0P } ◎ In mod(A, B) or rem(A, B), if B is 0, the result is NaN.\
- ~vA ~IN { +∞, −∞ } ◎ If A is infinite, the result is NaN.
-
`mod(~vA, ~vB)$f の場合に限り:
- [ ~vB ~EQ +∞ ]~AND[ ~vA ~LT 0 ]
- [ ~vB ~EQ −∞ ]~AND[ ~vA ~GT 0 ]
注記: 他のすべての “無限な ~vB ” の事例は妥当であり、単に ~vA を返す。 ◎ Note: All other "infinite B" cases are valid, and just return A immediately.
11.4. 三角-関数: `sin^f, `cos^f, `tan^f, `asin^f, `acos^f, `atan^f, `atan2^f
三角-関数 — `sin$f, `cos$f, `tan$f, `asin$f, `acos$f, `atan$f, `atan2$f — は、様々な基本的な三角-関係性を算出する。 ◎ The trigonometric functions—sin(), cos(), tan(), asin(), acos(), atan(), and atan2()—compute the various basic trigonometric relationships.
[ `sin(~vA)@f / `cos(~vA)@f / `tan(~vA)@f ]関数は、 1 個の`計算式$ ~vA を包含する — ~vA は、[ `number$t または `angle$t ]に解決されなければナラナイ。 これらの関数は、 ~vA を~radianとして解釈する下で,それぞれに対応している関数を算出した結果を返すモノトスル(すなわち,[ `sin(45deg)^v, `sin(.125turn)^v, `sin(3.14159 / 4)^v ]は、どれも同じ値(約 `.707^v )を表現する)。 それらはすべて `number^t を表現する。 [ `sin$f / `cos$f ]は,常に −1 以上 1 以下の実数を返す一方で、 `tan$f は ±∞ も含むどの実数も返し得る。 (`~math関数$が ∞ をどう取扱うかについての詳細は`§ 型の検査-法$を見よ。) ◎ The sin(A), cos(A), and tan(A) functions all contain a single calculation which must resolve to either a <number> or an <angle>, and compute their corresponding function by interpreting the result of their argument as radians. (That is, sin(45deg), sin(.125turn), and sin(3.14159 / 4) all represent the same value, approximately .707.) They all represent a <number>; sin() and cos() will always return a number between −1 and 1, while tan() can return any number between −∞ and +∞. (See § 11.9 Type Checking for details on how math functions handle ∞.)
[ `asin(~vA)@f / `acos(~vA)@f / `atan(~vA)@f ]関数は、 “逆” 三角-関数であり、[ それぞれに対応する “通常の” 三角-関数 ]に対する逆-関数を表現する。 いずれも, 1 個の`計算式$ ~vA を包含する。 ~vA は、 `number$t に解決されなければナラナイ。 これらの関数は、それぞれに対応している関数を算出した結果を `angle$t を表現している~radian数として解釈してから,次の範囲に正規化した角度として返すモノトスル ⇒# `asin$f 用には `-90deg^v 以上, `90deg^v 以下 / `acos$f 用には `0deg^v 以上, `180deg^v 以下 / `atan$f 用には `-90deg^v 以上, `90deg^v 以下 ◎ The asin(A), acos(A), and atan(A) functions are the "arc" or "inverse" trigonometric functions, representing the inverse function to their corresponding "normal" trig functions. All of them contain a single calculation which must resolve to a <number>, and compute their corresponding function, interpreting their result as a number of radians, representing an <angle>. The angle returned by asin() must be normalized to the range [-90deg, 90deg]; the angle returned by acos() to the range [0deg, 180deg]; and the angle returned by atan() to the range [-90deg, 90deg].
`atan2(~vA, ~vB)@f 関数は、~comma区切りの 2 個の`計算式$ ~vA, ~vB を包含する。 ~vA, ~vB は[ `number$t, `dimension$t, `percentage$t ]のどれにも解決し得るが、`型を決定-$した結果は,`同じ^emにならなければナラナイ — さもなければ、関数は無効になるとする。 この関数は、正な X 軸から点 ( ~vB, ~vA ) までの `angle$t を `-180deg^v 以上, `180deg^v 未満の角度に正規化して返すモノトスル。 ◎ The atan2(A, B) function contains two comma-separated calculations, A and B. A and B can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid. The function returns the <angle> between the positive X-axis and the point (B,A). The returned angle must be normalized to the interval (-180deg, 180deg] (that is, greater than -180deg, and less than or equal to 180deg).
注記: `atan2(~vA, ~vB)$f は,`一般に^em `atan(~vA / ~vB)$f と等価になるが、対応する点 ( ~vB, ~vA ) が負な成分を含み得るときには,より良い答えを与える。 点 ( −1, 1 ) に対応する `atan2(1, -1)^v は `135deg^v を返す一方で、点 ( 1, −1 ) に対応する `atan2(-1, 1)^v は `-45deg^v を返す。 対照的に `atan(1 / -1)^v, `atan(-1 / 1)^v は、両者とも `-45deg^v を返す — 両者とも内部的な計算は `-1^v に解決されるので。 ◎ Note: atan2(Y, X) is generally equivalent to atan(Y / X), but it gives a better answer when the point in question may include negative components. atan2(1, -1), corresponding to the point (-1, 1), returns 135deg, distinct from atan2(-1, 1), corresponding to the point (1, -1), which returns -45deg. In contrast, atan(1 / -1) and atan(-1 / 1) both return-45deg, because the internal calculation resolves to -1 for both.
11.4.1. 引数の範囲
[ `sin(~vA)^v / `cos(~vA)^v / `tan(~vA)^v ]においては、 ~vA が ±∞ ならば,結果は ~NaN になる。 (`~math関数$が ~NaN をどう取扱うかの詳細は、`§ 型の検査-法$を見よ。) ◎ In sin(A), cos(A), or tan(A), if A is infinite, the result is NaN. (See § 11.9 Type Checking for details on how math functions handle NaN.)
[ `sin(~vA)^v / `tan(~vA)^v ]においては、 ~vA ~EQ ~0N ならば,結果は ~0N になる。 ◎ In sin(A) or tan(A), if A is 0⁻, the result is 0⁻.
`tan(~vA)^v において, ~vA が漸近~値( `90deg^v, `270deg^v, 等)である場合の結果は、[ `90deg^v との差が `360deg^v の整数倍である値( `-270deg^v, `90deg^v, `450deg^v など) ]に対しては +∞ になり,[ `-90deg^v との差が `360deg^v の整数倍である値( `-450deg^v, `-90deg^v, `270deg^v など) ]に対しては −∞ になるモノトスル。 ◎ In tan(A), if A is one of the asymptote values (such as 90deg, 270deg, etc), the result must be +∞ for 90deg and all values a multiple of 360deg from that (such as -270deg or 450deg), and −∞ for -90deg and all values a multiple of 360deg from that (such as -450deg or 270deg).
注記: これが関連するのは、 `deg$u や `grad$u など,漸近的な値を正確に表現できる単位に限られる。 `rad$u では表現できないので、結果が巨大な[ 負な/正な ]値になるかどうかは,[ 丸ng, 実数が内部的にどう格納されるか ]の精確な詳細~に依存し得る。 そのような単位を利用している作者は、この挙動に依存しないことが推奨される。 ◎ Note: This is only relevant for units that can exactly represent the asymptotic values, such as deg or grad. rad cannot, and so whether the result is a very large negative or positive value can depend on rounding and precise details of how numbers are internally stored. It’s recommended you don’t depend on this behavior if using such units.
[ `asin(~vA)^v / `acos(~vA)^v ]においては、[ −1 ~LTE ~vA ~LTE 1 ]でないならば,結果は ~NaN になる。 ◎ In asin(A) or acos(A), if A is less than -1 or greater than 1, the result is NaN.
`acos(~vA)^v においては、 ~vA ~EQ 1 ならば,結果は 0 になる。 ◎ In acos(A), if A is exactly 1, the result is 0.
[ `asin(~vA)^v / `atan(~vA)^v ]においては、 ~vA ~EQ ~0N ならば,結果は ~0N になる。 ◎ In asin(A) or atan(A), if A is 0⁻, the result is 0⁻.
`atan(~vA)^v においては ⇒# ~vA ~EQ +∞ ならば,結果は `90deg^v になる / ~vA ~EQ −∞ ならば,結果は `-90deg^v になる ◎ In atan(A), if A is +∞, the result is 90deg; if A is −∞, the result is -90deg.
atan(%Y, %X)
においては、すべての通例でない引数の組合nの結果は,次の表で与えられる:
◎
In atan2(Y, X), the following table gives the results for all unusual argument combinations:
−∞ | 有限(負) | ~0N | ~0P | 有限(正) | +∞ | |
---|---|---|---|---|---|---|
−∞ | −135 | −90 | −90 | −90 | −90 | −45 |
有限(負) | −180 | (通常) | −90 | −90 | (通常) | ~0N |
~0N | −180 | −180 | −180 | ~0N | ~0N | ~0N |
~0P | 180 | 180 | 180 | ~0P | ~0P | ~0P |
有限(正) | 180 | (通常) | 90 | 90 | (通常) | ~0P |
+∞ | 135 | 90 | 90 | 90 | 90 | 45 |
注記: これらの関数の挙動はすべて、ほとんどの~programming言語 — 特に~JS — に実装されている “標準な” 定義に合致することが意図されている。 ◎ Note: All of these behaviors are intended to match the "standard" definitions of these functions as implemented by most programming languages, in particular as implemented in JS.
注記: `tan(90deg)^v の挙動は、~JSの挙動からは拘束されないが(~JS関数の入力は~radianであり、~JS実数では値 π ~DIV 2 を完璧には表出し得ないので),値の往来が働くように定義される — 次が得られるように ⇒# `tan(atan(infinity))^v からは +∞ / `tan(atan(-infinity))^v からは −∞ / `atan(tan(90deg))^v からは `90deg^v / `atan(tan(-90deg))^v からは `-90deg^v ◎ Note: The behavior of tan(90deg), while not constrained by JS behavior (because the JS function’s input is in radians, and one cannot perfectly express a value of π/2 in JS numbers), is defined so that roundtripping of values works; tan(atan(infinity)) yields +∞, tan(atan(-infinity)) yields −∞, atan(tan(90deg)) yields 90deg, and atan(tan(-90deg)) yields -90deg.
11.5. 指数-関数: `pow^f, `sqrt^f, `hypot^f, `log^f, `exp^f
指数-関数 — `pow$f, `sqrt$f, `hypot$f, `log$f, `exp$f — は、引数から様々な指数-関数を算出する。 ◎ The exponential functions—pow(), sqrt(), hypot(), log(), and exp()—compute various exponential functions with their arguments.
`pow(~vA, ~vB)@f 関数は、~comma区切りの 2 個の`計算式$ ~vA, ~vB を包含する。 両者とも `number$t に解決されなければナラナイ。 この関数は、 ~vA を ~vB 乗した結果の値を `number^t として返すモノトスル。 ◎ The pow(A, B) function contains two comma-separated calculations A and B, both of which must resolve to <number>s, and returns the result of raising A to the power of B, returning the value as a <number>.
`sqrt(~vA)@f 関数は、 1 個の`計算式$ ~vA を包含する。 ~vA は `number$t に解決されなければナラナイ。 この関数は、 ~vA の平方根を `number^t として返すモノトスル。 ( `sqrt(~vA)^v は、 `pow(~vA, .5)^v と基本的には等価だが,一部の~errorの取扱いは相違する。 `sqrt$f は、簡便さを供するに価するほど十分~共通的な関数である。) ◎ The sqrt(A) function contains a single calculation which must resolve to a <number>, and returns the square root of the value as a <number>. (sqrt(X) and pow(X, .5) are basically equivalent, differing only in some error-handling; sqrt() is a common enough function that it is provided as a convenience.)
`hypot(…)@f 関数は、~comma区切りの 1 個以上の`計算式$を包含する — それは、各`計算式$に等しい成分を伴う多次元~vectorの長さを返す(すなわち、各~引数の二乗の総和の平方根)。 各~引数の`計算式$は[ `number$t, `dimension$t, `percentage$t ]のどれにも解決し得るが、`型を決定-$した結果は,すべて`同じ^emにならなければナラナイ — さもなければ関数は無効になるとする。 結果の`型$は、引数と同じになる。 ◎ The hypot(A, …) function contains one or more comma-separated calculations, and returns the length of an N-dimensional vector with components equal to each of the calculations. (That is, the square root of the sum of the squares of its arguments.) The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid; the result will have the same type as the arguments.
`hypot$f は次元(単位を伴う値)を許容するのに、なぜ, `pow$f, `sqrt$f は実数に限り働くのか? ◎ Why does hypot() allow dimensions (values with units), but pow() and sqrt() only work on numbers?
作者には、 `hypot(30px, 40px)^v の様な式を書くことは許容され, `50px^v に解決されるが、 `sqrt(pow(30px, 2) + pow(40px, 2))^v の様な式を書くのは許容されない — ほとんどの数学体系においては、この 2 つは等価であるにもかかわらず。 ◎ You are allowed to write expressions like hypot(30px, 40px), which resolves to 50px, but you aren’t allowed to write the expression sqrt(pow(30px, 2) + pow(40px, 2)), despite the two being equivalent in most mathematical systems.
これには 2 つの理由 — 指数における数量-精度, 作者の期待に沿わないこと — がある。 ◎ There are two reasons for this: numeric precision in the exponents, and clashing expectations from authors.
まず、数量的な精度について。 `length$t の様な~CSS生成規則に`合致する$ためには、`型$は,その指数が正確に 1 に設定された単独の単位からなる必要がある。 `pow(pow(30px, 3), 1/3)^v の様な式の結果は、理論上は,正確に次のように得られるべきである: まず、~~内側の `pow(30px, 3)^v を[ `型$ «[ `length^l → 3 ]» ( `length^t の 3 乗) ]を伴う値 27000 に解決する。 次に、 `pow(~vA, 1/3)^v により,値の三乗根をとって 30 に戻すとともに指数に 1/3 を乗算する。 結果は、 «[ `length^l → 1 ]» を型に伴い, `length^t に`合致する$。 ◎ First, numerical precision. For a type to match a CSS production like <length>, it needs to have a single unit with its exponent set to exactly 1. Theoretically, expressions like pow(pow(30px, 3), 1/3) should result in exactly that: the inner pow(30px, 3) would resolve to a value of 27000 with a type of «[ "length" → 3 ]» (aka <length>³), and then the pow(X, 1/3) would cube-root the value back down to 30 and multiply the exponent by 1/3, giving «[ "length" → 1 ]», which matches <length>.
上述は,純粋~数学においては仕事を成すことは保証されるが、二進-浮動小数点~算術を利用している~computerの現実世界においては,冪乗が正確に~~相殺されずに無効な`~math関数$になる事例もある — それは、作者を惑わすことに加え,理由も追跡し難くなる。 (~JSの例で言えば、 `Math.pow(Math.pow(30, 10/3), .1+.1+.1)^c を評価した結果は,正確には 30 にならない — `.1+.1+.1^c が正確には 3 ~DIV 10 にならず、 `(10/3) * (.1+.1+.1)^c は 1 より`わずかに大きく^emなるので。) ◎ In the realm of pure mathematics, that’s guaranteed to work out; in the real-world of computers using binary floating-point arithmetic, in some cases the powers might not exactly cancel out, leaving you with an invalid math function for confusing, hard-to-track-down reasons. (For a JS example, evaluate Math.pow(Math.pow(30, 10/3), .1+.1+.1); the result is not exactly 30, because .1+.1+.1 is not exactly 3/10. Instead, (10/3) * (.1 + .1 + .1) is slightly greater than 1.)
[ 値から単位を外した生の実数~上ですべての~mathを行ってから,最後に欲される単位に戻す ]よう作者に要求することは、不便にはなるが,数的な精度は誰にとっても~~支障ないことを確保する: `calc(pow(pow(30px / 1px, 3), 1/3) * 1px)^v は `length$t に解決され、 30 にごく近くなることは保証される — 実際には、数量的な精度により冪乗を正確に~~相殺できず,正確には 30 ではなくとも。 ◎ Requiring authors to cast their value down into a number, do all the math on the raw number, then finally send it back to the desired unit, while inconvenient, ensures that numerical precision won’t bite anyone: calc(pow(pow(30px / 1px, 3), 1/3) * 1px) is guaranteed to resolve to a <length>, with a value that, if not exactly 30, is at least very close to 30, even if numerical precision actually prevents the powers from exactly canceling.
次に,期待に沿わないことについて。 作者が[ `pow(30px, 2)^v の結果は — 単位はそのままに数量的な値だけ二乗して — `900px^v になる ]ものと期待することは,少なからずある( この Sass issue など)。 しかしながらこれは、[ 結果が,引数をどの単位で表出しているかに依存する ]ことを意味する。 例えば `1em^v が `16px^v に等しい場合、 `pow(1em, 2)^v は `1em^v を与える一方で, `pow(16px, 2)^v は `256px^v ( `16em^v )を与える — 入力~引数が一致するときに、このような かけ離れた値が得られるべきではない。 ~CSSにおいては、一般に,値を`正準的~単位$に自由に~~換算することが許容されるので、この類の入力への依存性は,~CSSにとって厄介の元になる。 それは、 `pow(2em + 10px, 2)^v の様な,より複階的な式の解釈を困難にしてしまう。 ◎ Second, clashing expectations. It’s not uncommon for authors to expect pow(30px, 2) to result in 900px (such as in this Sass issue); that is, just squaring the numerical value and leaving the unit alone. This, however, means the result is dependent on what unit you’re expressing the argument in; if 1em is 16px, then pow(1em, 2) would give 1em, while pow(16px, 2) would give 256px, or 16em, which are very different values for what should otherwise be identical input arguments! This sort of input dependency is troublesome for CSS, which generally allows values to be canonicalized freely; it also makes more complex expressions like pow(2em + 10px, 2) difficult to interpret.
戻って、値から単位を外してから,再び欲される単位に戻すよう作者に要求すれば、これらの課題から免れることになる。 `pow(30, 2)^v は `900^v になり、作者は自身が望む何にでも解釈できる。 ◎ Again, requiring authors to cast their value down into a number and then back up again into the desired unit sidesteps these issues; pow(30, 2) is indeed 900, and the author can interpret that however they wish.
他方, `hypot$f は、これらの問題には悩まされない — 入力も出力もすべて同じ型であり,その演算の資質に因り,結果はいずれにせよ単位に依存しないので、単位における数量的な精度は懸念にならない。 `hypot(3em, 4em)^v, `hypot(48px, 64px)^v の両者とも、 `1em^v が `16px^v に等しいときの結果は,同じ長さ `5em^v ~EQ `80px^v になる。 したがって、作者が `hypot()^v 内に直に次元を利用できるようにしてもかまわない。 ◎ On the other hand, hypot() doesn’t suffer from these problems. Numerical precision in units isn’t a concern, as the inputs and output all have the same type. The result isn’t unit-dependent, either, due to the nature of the operation; hypot(3em, 4em) and hypot(48px, 64px) both result in the same length when 1em equals 16px: 5em or 80px. Thus it’s fine to let author use dimensions directly in hypot().
`log(~vA, ~vB?)@f 関数は、[ 対数~化される値を表現する`計算式$ ~vA, 対数の底eを表現する省略可能な`計算式$ ~vB (省略時の既定は `e$v とする) ]を包含する。 ~vA, ~vB は `number$t に解決されなければナラナイ。 この関数は、 ~vB を底eとする ~vA の対数を `number$t として返すモノトスル。 ◎ The log(A, B?) function contains one or two calculations (representing the value to be logarithmed, and the base of the logarithm, defaulting to e), which must resolve to <number>s, and returns the logarithm base B of the value A, as a <number>.
`exp(~vA)@f 関数は、 1 個の`計算式$ ~vA を包含する。 ~vA は `number$t に解決されなければナラナイ。 この関数は、 `pow(e, ~vA)$f と同じ値を `number$t として返すモノトスル。 ◎ The exp(A) function contains one calculation which must resolve to a <number>, and returns the same value as pow(e, A) as a <number>.
`pow$f 関数は、 CSS Modular Scale の様な,~page上のすべての~font~sizeを互いに固定d比率で関係付ける方策に有用になり得る。 ◎ The pow() function can be useful for strategies like CSS Modular Scale, which relates all the font-sizes on a page to each other by a fixed ratio.
これらの~sizeは、次の様に~custom~propの中にも容易に書ける: ◎ These sizes can be easily written into custom properties like:
:root { --h6: calc(1rem * pow(1.5, -1)); --h5: calc(1rem * pow(1.5, 0)); --h4: calc(1rem * pow(1.5, 1)); --h3: calc(1rem * pow(1.5, 2)); --h2: calc(1rem * pow(1.5, 3)); --h1: calc(1rem * pow(1.5, 4)); }
値を `5.0625rem^v ( `calc(1rem * pow(1.5, 4))^v を解決した結果)の様な — 何に基づくのか~~不明瞭な — 予め計算-済みの実数に書き出すことなく。 ◎ ...rather than writing out the values in pre-calculated numbers like 5.0625rem (what calc(1rem * pow(1.5, 4)) resolves to) which have less clear provenance when encountered in a stylesheet.
1 個の引数を伴う `hypot$f は、入力の絶対~値を与える。 `hypot(2em)^v, `hypot(-2em)^v は両者とも `2em^v に解決される。 ◎ With a single argument, hypot() gives the absolute value of its input; hypot(2em) and hypot(-2em) both resolve to 2em.
複数個の引数を伴う場合、[ 各辺の長さが各~引数により与えられた多次元~box ]の対頂線の~sizeを与える。 これは、変形-に関係するものに有用になり得る — それは、特定0の (X, Y, Z ) 量だけ並進されたとき,要素が実際に~~移動する距離を与える。 ◎ With more arguments, it gives the size of the main diagonal of a box whose side lengths are given by the arguments. This can be useful for transform-related things, giving the distance that an element will actually travel when it’s translated by a particular X, Y, and Z amount.
例えば, `hypot(30px, 40px)^v は、 `50px^v に解決され,[ `translate(30px, 40px)^v により要素が並進されたとき,要素が~~実際に~~移動する距離 ]を与える。 作者は、元位置から離れるほど要素を小さくしたいと求めるなら(例えば,何らかの類の `word cloud^en 【単語の “重み”(出現頻度など)を可視化する図】を描くとき),この距離を拡縮ng係数の計算に利用することもできる。 ◎ For example, hypot(30px, 40px) resolves to 50px, which is indeed the distance between an element’s starting and ending positions when it’s translated by a translate(30px, 40px) transform. If an author wanted elements to get smaller as they moved further away from their starting point (drawing some sort of word cloud, for example), they could then use this distance in their scaling factor calculations.
引数を 1 個だけ伴う `log$f は、その引数の “自然~対数” を供する — 対数の底eは ~JSと同じ `e^i になる。 ◎ With a single argument, log() provides the “natural log” of its argument, or the log base e, same as JavaScript.
代わりに,[ 10 を底eとする対数(例:値の 10 進表記における桁数) / 2 を底eとする対数(例:値を成す~bit数) ]を求めるなら、[ `log(~vA, 10)^v / `log(~vA, 2)^v ]が,それを供する。 ◎ If one instead wants log base 10 (to, for example, count the number of digits in a value) or log base 2 (counting the number of bits in a value), log(X, 10) or log(X, 2) provide those values.
11.5.1. 引数の範囲
`pow(~vA, ~vB)$f においては、[ ~vA, ~vB とも有限 ]~AND[ ~vA ~LT 0 ]~AND[ ~vB は整数でない ]ならば,結果は ~NaN になる。 ◎ In pow(A, B), if A is negative and finite, and B is finite, B must be an integer, or else the result is NaN.
他の場合、 ~vA, ~vB どちらかは[ ±∞/ 0 ]ならば,結果は次の 2 つの表で与えられる: ◎ If A or B are infinite or 0, the following tables give the results:
−∞ | ~0N | ~0P | +∞ | |
---|---|---|---|---|
奇数(負) | ~0N | −∞ | +∞ | ~0P |
偶数(負) | ~0P | +∞ | +∞ | ~0P |
0 | 常に 1 | |||
奇数(正) | −∞ | ~0N | ~0P | +∞ |
偶数(正) | +∞ | ~0P | ~0P | +∞ |
~vA ~LT −1 | −1 | −1 ~LT ~vA ~LT 1 | 1 | 1 ~LT ~vA | |
---|---|---|---|---|---|
+∞ | +∞ | NaN | ~0P | NaN | +∞ |
−∞ | ~0P | NaN | +∞ | NaN | ~0P |
`sqrt(~vA)$f においては ⇒# ~vA ~EQ +∞ ならば,結果は +∞ になる/ ~vA ~EQ ~0N ならば,結果は ~0N になる/ ~vA ~LT 0 ならば,結果は ~NaN になる ◎ In sqrt(A), if A is +∞, the result is +∞. If A is 0⁻, the result is 0⁻. If A is less than 0, the result is NaN.
`hypot(…)$f においては ⇒ 入力のいずれかがが ±∞ ならば,結果は +∞ になる ◎ In hypot(A, …), if any of the inputs are infinite, the result is +∞.
`log(~vA, ~vB)$f においては: ◎ In log(A, B),\
-
[ ~vB ~EQ 1 / ~vB ~LT 0 ]ならば,結果は ~NaN になる。
注記: [ 0 ~LT ~vB ~LT 1 / ~vB ~GT 1 ]であっても妥当である。 【当然? / ~vB ~EQ +∞ の場合の結果は?】
◎ if B is 1 or negative, <B values between 0 and 1, or greater than 1, are valid.> the result is NaN.\ - 他の場合 ⇒# ~vA ~LT 0 ならば,結果は ~NaN になる/ ~vA ~IN { ~0P, ~0N } ならば,結果は −∞ になる/ ~vA ~EQ 1 ならば,結果は ~0P になる/ ~vA ~EQ +∞ ならば,結果は +∞ になる ◎ If A is negative, the result is NaN. If A is 0⁺ or 0⁻, the result is −∞. If A is 1, the result is 0⁺. If A is +∞, the result is +∞.
`exp(~vA)$f においては ⇒# ~vA ~EQ +∞ ならば,結果は +∞ になる/ ~vA ~EQ −∞ ならば,結果は ~0P になる ◎ In exp(A), if A is +∞, the result is +∞. If A is −∞, the result is 0⁺.
(`~math関数$が ~NaN, ±∞ 【, ~0N, ~0P】をどう取扱うかの詳細は、`§ 型の検査-法$を見よ。) ◎ (See § 11.9 Type Checking for details on how math functions handle NaN and infinities.)
注記: これらの関数の挙動はすべて、ほとんどの~programming言語 — 特に~JS — に実装されている “標準な” 定義に合致することが意図されている。 ◎ All of these behaviors are intended to match the "standard" definitions of these functions as implemented by most programming languages, in particular as implemented in JS.
等価な~JS関数の挙動からの唯一の乖離は、 ~NaN は `どの関数^emにおいても “伝染的” である — すなわち,ある引数~計算の結果が ~NaN になる場合、関数は ~NaN を返すよう強制する — ことにある。 ◎ The only divergences from the behavior of the equivalent JS functions are that NaN is "infectious" in every function, forcing the function to return NaN if any argument calculation is NaN.
~JSの挙動の詳細 ◎ Details of the JS Behavior
~math関数に対応する~JS関数において、 ~NaN が “伝染的” にならない事例は 2 つある ⇒# `Math.hypot(Infinity, NaN)^c は `Infinity^jv を返す/ `Math.pow(NaN, 0)^c は `1^jv を返す ◎ There are two cases in JS where a NaN is not "infectious" to the math function it finds itself in: • Math.hypot(Infinity, NaN) will return Infinity. • Math.pow(NaN, 0) will return 1.
ここでの~logicは、 `NaN^jv を `どの数に置換しようが^em,返り値は同じになる点にあると見受けられる。 しかしながら,この~logicは、各種 `Math^c 関数に一貫して適用されてもいない: `Math.max(Infinity, NaN)^c は, `Infinity^jv ではなく `NaN^jv を返すし、 `Math.min(-Infinity, NaN)^c も,同様になる。 ◎ The logic appears to be that, if you replace the NaN with any Number, the return value will be the same. However, this logic is not applied consistently to the Math functions: Math.max(Infinity, NaN) returns NaN, not Infinity; the same is true of Math.min(-Infinity, NaN).
[ これは、~~常用されない~error事例であること/ ~JSは、この点について一貫でないこと/ `計算式$における ~NaN の認識や取扱いは、内部~math関数~内ではなく,どのみち より高~levelな~CSSにて行われると見込まれる ]ことから、~CSSにおける一貫性が,より重要であると選ばれた。 なので、すべての関数において, ~NaN は “伝染的” になるよう定義されている。 ◎ Because this is an error corner case, JS isn’t consistent on the matter, and NaN recognition/handling of calculations is likely done at a higher CSS level rather than in the internal math functions anyway, consistency in CSS was chosen to be more important, so all functions were defined to have "infectious" NaN.
11.6. 符号nに関係する関数: `abs^f, `sign^f
符号nに関係する関数 — `abs$f, `sign$f — は、引数の符号nに関係する関数を算出する。 ◎ The sign-related functions—abs() and sign()—compute various functions related to the sign of their argument.
`abs(~vA)@f 関数は、 1 個の`計算式$ ~vA を包含し, ~vA の絶対~値を ~vA と同じ`型$の値として返す — 結果の数量-値は、 ~vA の数量-値に応じて ⇒# ~0P または正ならば そのまま ~vA になる/ ~0N または負ならば −1 ~MUL ~vA になる ◎ The abs(A) function contains one calculation A, and returns the absolute value of A, as the same type as the input: if A’s numeric value is positive or 0⁺, just A again; otherwise -1 * A.
`sign(~vA)@f 関数は、 1 個の`計算式$ ~vA を包含し, ~vA の数量-値に応じて次を返す ⇒# 負ならば −1 / 正ならば +1 / ~0P ならば ~0P / ~0N ならば ~0N ◎ The sign(A) function contains one calculation A, and returns -1 if A’s numeric value is negative, +1 if A’s numeric value is positive, 0⁺ if A’s numeric value is 0⁺, and 0⁻ if A’s numeric value is 0⁻.
注記: 両~関数とも、引数を全部的に単純~化して解決した結果に対し演算する。 それは、一目では直感的でない結果も与え得る。 特に, `10%^v の様な式を解決した結果は、式がどの値を~~基準に解決されるかに依存して,`正にも負にも^emなり得る。 例えば, `background-position$p においては、背景~画像が背景~区画より大きい場合には,正な百分率は負な長さに(逆に,負な百分率は正な長さに)解決される。 したがって `sign(10%)$f は、百分率がどう解決されるかに依存して, `1^v, `-1^v `どちらも返し得る^em(長さ 0 を~~基準に解決される場合には, `0^v にもなる)。 ◎ Note: Both of these functions operate on the fully simplified/resolved form of their arguments, which may give unintuitive results at first glance. In particular, an expression like 10% might be positive or negative once it’s resolved, depending on what value it’s resolved against. For example, in background-position positive percentages resolve to a negative length, and vice versa, if the background image is larger than the background area. Thus sign(10%) might return 1 or -1, depending on how the percentage is resolved! (Or even 0, if it’s resolved against a zero length.)
11.7. 数量-定数: `e^v, `pi^v
[ 三角-関数/指数-関数 ]は,多くの複階的な数量-演算を取扱うが、計算式を適度にまとめる手間を要することに加え, `e^i や `π^i などの周知な定数を含むことも多い。 ◎ While the trigonometric and exponential functions handle many complex numeric operations, some reasonable calculations must be put together more manually, and many times these include well-known constants, such as e and π.
作者が これらの定数を成す一連の数字を手で打ち込まずに済むよう、少数の定数は直に供される: ◎ Rather than require authors to manually type out several digits of these constants, a few of them are provided directly:
- `e@v
- 自然~対数の底eを表す。 約 2.7182818284590452354 。 ◎ e is the base of the natural logarithm, approximately equal to 2.7182818284590452354.
- `pi@v
- 円周率を表す。 約 3.1415926535897932 。 ◎ pi is the ratio of a circle’s circumference to its diameter, approximately equal to 3.1415926535897932.
注記: これらの~keywordが利用-可能になるのは、 `calc(pow(e, pi) - pi)^v や `min(pi, 5, e)^v など,`計算式$の中に限られる。 計算式の外側で利用された場合、他の~keywordと同様に扱われる: `animation-name$p: `pi^v は、名前 `pi^l の~animationを指す。 `line-height$p: `e^v は、無効になる( `line-height^p: `2.7^v に類似な何かにはならない【!?, but line-height: calc(e); is】)。 ◎ Note: These keywords are only usable within a calculation, such as calc(pow(e, pi) - pi), or min(pi, 5, e). If used outside of a calculation, they’re treated like any other keyword: animation-name: pi; refers to an animation named "pi"; line-height: e; is invalid (not similar to line-height: 2.7, but line-height: calc(e); is).
11.7.1. 退化な値を表す数量-定数: `infinity^v, `-infinity^v, `NaN^v
`計算式$や その下位treeが[ 無限/~NaN ]になるとき,もはや数量-値で表現することはアリでなくなる。 これらの退化な値の直列化を援助するため、追加的な~math定数として,次が定義される ⇒# `infinity@v ( +∞ を表す), `-infinity@v ( −∞ を表す), `NaN@v ( ~NaN を表す) ◎ When a calculation or a subtree of a calculation becomes infinite or NaN, representing it with a numeric value is no longer possible. To aid in serialization of these degenerate values, the additional math constants infinity (with the value +∞), -infinity (with the value −∞), and NaN (with the value NaN) are defined.
これらは、通例の~CSS~keywordと同じく,`~ASCII大小無視$である。 したがって, `calc(InFiNiTy)^v も まったく妥当である。 しかしながら, `NaN$v は、この正準的な大小法で直列化するモノトスル。 ◎ As usual for CSS keywords, these are ASCII case-insensitive. Thus, calc(InFiNiTy) is perfectly valid. However, NaN must be serialized with this canonical casing.
注記: これらの~keywordは、`形上では^em実数ではないが, `e$v や `pi$v と類似に数量-値として動作する。 したがって,無限な長さを取得するためには、 `calc(infinity * 1px)^v の様な式が要求される。 ◎ Note: While not technically numbers, these keywords act as numeric values, similar to e and pi. Thus to get an infinite length, for example, requires an expression like calc(infinity * 1px).
注記: これらの定数は、`主として^em[ 無限/~NaN ]値の直列化をもっと単純かつ明らかにするために定義されているが、 “アリな最も大きい値” を指示するためにも`利用できる^em — 無限~値は、許容される範囲に切詰められることになるので。 これが~~適するのは希であるが、 `infinity$v を利用すれば,~stylesheetに何桁もの数をただ記すより意図は明瞭になる。 ◎ Note: These constants are defined mostly to make serialization of infinite/NaN values simpler and more obvious, but can be used to indicate a "largest possible value", since an infinite value gets clamped to the allowed range. It’s rare for this to be reasonable, but when it is, using infinity is clearer in its intent than just putting an enormous number in one’s stylesheet.
11.8. 構文
`~math関数$の構文は、次で与えられる: ◎ The syntax of a math function is:
`calc()$t = calc( `calc-sum$t ) `min()$t = min( `calc-sum$t# ) `max()$t = max( `calc-sum$t# ) `clamp()$t = clamp( `calc-sum$t#{3} ) `round()$t = round( `rounding-strategy$t?, `calc-sum$t, `calc-sum$t ) `mod()$t = mod( `calc-sum$t, `calc-sum$t ) `rem()$t = rem( `calc-sum$t, `calc-sum$t ) `sin()$t = sin( `calc-sum$t ) `cos()$t = cos( `calc-sum$t ) `tan()$t = tan( `calc-sum$t ) `asin()$t = asin( `calc-sum$t ) `acos()$t = acos( `calc-sum$t ) `atan()$t = atan( `calc-sum$t ) `atan2()$t = atan2( `calc-sum$t, `calc-sum$t ) `pow()$t = pow( `calc-sum$t, `calc-sum$t ) `sqrt()$t = sqrt( `calc-sum$t ) `hypot()$t = hypot( `calc-sum$t# ) `log()$t = log( `calc-sum$t, `calc-sum$t? ) `exp()$t = exp( `calc-sum$t ) `abs()$t = abs( `calc-sum$t ) `sign()$t = sign( `calc-sum$t ) `calc-sum@t = `calc-product$t [ [ '+' | '-' ] `calc-product$t ]* `calc-product@t = `calc-value$t [ [ '*' | '/' ] `calc-value$t ]* `calc-value@t = `number$t | `dimension$t | `percentage$t | `calc-constant$t | ( `calc-sum$t ) `calc-constant@t = `e$v | `pi$v | `infinity$v | `-infinity$v | `NaN$v
加えて、演算子[ `+^css / `-^css ]の両側には`空白$が要求される(演算子[ `*^css / `/^css ]の両側には要求されない)。 ◎ In addition, whitespace is required on both sides of the + and - operators. (The * and / operators can be used without white space around them.)
【 例えば `5 -5^v は、 2 個の実数~token並びとして構文解析され,引数として妥当でなくなる。 一方で `5*5^v は、 `*^css も含む 3 個の~token並びとして構文解析され,引数として妥当になる。 】
上に挙げた~math関数のうちいくつかには、 `calc-sum$t 引数が包含し得るものに追加的な拘束がある。 詳細は、個々の関数の定義を見よ。 ◎ Several of the math functions above have additional constraints on what their <calc-sum> arguments can contain. Check the definitions of the individual functions for details.
~UAは、`計算式$を成す `calc-value$t の項~数として,少なくとも 20 個~以上は~supportするモノトスル。 包含する項~数が~supportする数を超える計算式は、無効であったかのように扱うモノトスル。 ◎ UAs must support calculations of at least 20 <calc-value> terms. If a calculation contains more than the supported number of terms, it must be treated as if it were invalid.
11.9. 型の検査-法
`~math関数$にアリな型 — `length$t, `number$t, 等々 — には、それが包含する`計算式$に依存して,下に定義されるように いくつもある。 ~math関数は、その型の値が許容される どこでも利用できる。 ◎ A math function can be many possible types, such as <length>, <number>, etc., depending on the calculations it contains, as defined below. It can be used anywhere a value of that type is allowed.
例えば, `width$p ~propは `length$t 値を受容するので、 `length$t に解決される`~math関数$ — `calc(5px + 1em)^v など — は, `width^p に利用できる。 ◎ For example, the width property accepts <length> values, so a math function that resolves to a <length>, such as calc(5px + 1em), can be used in width.
加えて, `number$t に解決される`~math関数$は、 `integer$t のみを受容する どこでも利用できる(それは、最も近い整数に丸められる)。 ◎ Additionally, math functions that resolve to <number> can be used in any place that only accepts <integer>. (It gets rounded to the nearest integer, as specified in § 11.12 Range Checking.)
演算子をとる下位式からは、その引数に基づいて型が得られる。 ◎ Operators form sub-expressions, which gain types based on their arguments.
注記: この仕様の以前までの~versionでは、[ 乗算/除算 ]がとれる引数は制限されていた — 複階的な中間-結果( `1px * 1em^v の次元は `length$t の 2 乗になるなど)が生産されるのを避けるため / 0 による除算を構文解析-時に検出-可能にするため。 この~versionでは、その制約は緩められる。 ◎ Note: In previous versions of this specification, multiplication and division were limited in what arguments they could take, to avoid producing more complex intermediate results (such as 1px * 1em, which is <length>²) and to make division-by-zero detectable at parse time. This version now relaxes those restrictions.
`計算式$の `型を決定する@ ときは、以下に従う — 以下において,`型$を得る演算の結果が `失敗^i になった場合、`計算式$の型は `失敗^i になるとする: ◎ To determine the type of a calculation:
- [ `+^css / `-^css ]が成す下位式の`型$は、次の結果で与えられる ⇒ `型を加算する$( 左側の引数の`型$, 右側の引数の`型$ ) ◎ At a + or - sub-expression, attempt to add the types of the left and right arguments. If this returns failure, the entire calculation’s type is failure. Otherwise, the sub-expression’s type is the returned type.
- `*^css が成す下位式の`型$は、次の結果で与えられる ⇒ `型を乗算する$( 左側の引数の`型$, 右側の引数の`型$ ) ◎ At a * sub-expression, multiply the types of the left and right arguments. The sub-expression’s type is the returned result.
- `/^css が成す下位式の`型$は、次の結果で与えられる ⇒ `型を乗算する$( 左側の引数の`型$, `型を逆数にする$( 右側の引数の`型$ ) ) ◎ At a / sub-expression, let left type be the result of finding the types of its left argument, and right type be the result of finding the types of its right argument and then inverting it. ◎ The sub-expression’s type is the result of multiplying the left type and right type.
-
他のものは末端~値であり,その`型$は、次の手続きにより決定される:
- %単位 ~LET %値 に応じて ⇒# `percentage$t ならば `percent^l / `number$t ならば `number^l / `calc-constant$t ならば `number^l / ~ELSE_( `dimension$t ならば) %値 の単位
- ~IF[ %単位 ~EQ `percent^l ]~AND[ %値 は[ この`計算式$を包含している`~math関数$が置かれた文脈において,[ `number$t 以外の別の型の値 ]に相対的に解決される(例えば `width$p における `percentage$t は、ある `length$t に対し解決される) ] ⇒ %単位 ~SET その型の単位
- ~RET `型を作成する$( %単位 )
`~math関数$自身も、関数に応じて,それが包含する`計算式$に則って決定される`型$を持つ: ◎ Math functions themselves have types, according to their contained calculations:
- `calc$f
- `abs$f
- 包含する`計算式$の`型を決定-$した結果 ◎ The type of a calc() or abs() expression is the type of its contained calculation.
- `min$f
- `max$f
- `clamp$f
- `型を加算する$( 包含している~comma区切りの各`計算式$からなる~list ) ◎ The type of a min(), max(), or clamp() expression is the result of adding the types of its comma-separated calculations.
- `sign$f
- `型を作成する$( `number^l ) ◎ The type of a sign() expression is «[ "number" → 1 ]».
- `sin$f
- `cos$f
- `tan$f
- `型を作成する$( `number^l ) ◎ The type of a sin(), cos(), or tan() expression is «[ "number" → 1 ]».
- `asin$f
- `acos$f
- `atan$f
- `atan2$f
- `型を作成する$( `angle^l ) ◎ The type of an asin(), acos(), atan(), or atan2() expression is «[ "angle" → 1 ]».
- `pow$f
- `sqrt$f
- `log$f
- `exp$f
- `型を作成する$( `number^l ) ◎ The type of a pow(), sqrt(), log(), or exp() expression is «[ "number" → 1 ]».
- `hypot$f
- `round$f
- `mod$f
- `rem$f
- `型を加算する$( 包含している~comma区切りの各`計算式$からなる~list ) ◎ The type of a hypot(), round(), mod(), or rem() expression is the result of adding the types of its comma-separated calculations.
上の各~項において、結果の`型$が失敗になる場合,`~math関数$は無効になるとする。 ◎ For each of the above, if the type is failure, the math function is invalid.
`~math関数$は、その`型$が[ `number$t / `length$t / `angle$t / `time$t / `frequency$t / `resolution$t / `flex$t / `percentage$t ]のうち,どの生成規則に`合致する$かに則って,合致したものが表す型に解決される(この分類は相互排他的である)。 どれにも合致しない場合、`~math関数$は無効になる。 ◎ A math function resolves to <number>, <length>, <angle>, <time>, <frequency>, <resolution>, <flex>, or <percentage> according to which of those productions its type matches. (These categories are mutually exclusive.) If it can’t match any of these, the math function is invalid.
0 による除算もアリであり、ある種の複雑さを導入する。 `~math関数$は、そのような演算に対しては,~IEEE-754意味論に従う: ◎ Division by zero is possible, which introduces certain complications. Math functions follow IEEE-754 semantics for these operations:
- [ 正な値 / 負な値 ]を 0 で除算するときは、[ +∞ / −∞ ]を生産する。 【この 0 が “負な 0” ( ~0N )の場合は逆になる(下を見よ)。】 ◎ Dividing a positive value by zero produces +∞. ◎ Dividing a negative value by zero produces −∞.
- 次に挙げる演算は、後続する規則にて ~NaN を生産するものと定義されない限り,引数に与える ±∞ と同じ符号の ±∞ を生産する ⇒# 何かと ±∞ を乗算するとき / 何かと ±∞ を加算するとき / ±∞ から何かを減算するとき / 何かから −( ±∞ ) を減算するとき ◎ Adding or subtracting ±∞ to anything produces the appropriate infinity, unless a following rule would define it as producing NaN. ◎ Multiplying any value by ±∞ produces the appropriate infinity, unless a following rule would define it as producing NaN.
- 何かを ±∞ で除算するときは、後続する規則にて ~NaN を生産するものと定義されない限り, 0 を生産する。 ◎ Dividing any value by ±∞ produces zero, unless a following rule would define it as producing NaN.
- 次に挙げる演算は、 ~NaN を生産する ⇒# 0 を 0 で除算するとき / ±∞ を ±∞ で除算するとき / 0 と ±∞ を乗算するとき / +∞ と −∞ を加算するとき / ±∞ から同じ符号の ±∞ を減算するとき ◎ Dividing zero by zero, dividing ±∞ by ±∞, multiplying 0 by ±∞, adding +∞ to −∞ (or the equivalent subtractions) produces NaN.
- どの演算も、ある引数が ~NaN ならば ~NaN を生産する。 ◎ Any operation with at least one NaN argument produces NaN.
加えて,~IEEE-754は、 “負な 0” の概念を導入する — それも、[ 計算の中/入子な計算の間 ]で追跡するモノトスル(以下、[ 負な 0 は ~0N / 他の 0( “正な 0” )は ~0P ]と記され, 0 はこれらの総称を表す): ◎ Additionally, IEEE-754 introduces the concept of "negative zero", which must be tracked within a calculation and between nested calculations:
-
0 を生産する[ 乗算/除算 ]のうち,片方の引数だけ負であるもの(例: `-5 * 0^v や `1 / (-infinity)^v )は、 ~0N を生産する。 加えて、他の`~math関数$における,ある種の引数の組合nも ~0N を生産する。 ◎ Negative zero (0⁻) can be produced by a multiplication or division that produces zero with exactly one negative argument (such as -5 * 0 or 1 / (-infinity)), or by certain argument combinations in the other math functions.
注記: 負な 0 は`~math関数$から外へは~~漏れないことに注意。 下に詳細を与えるように、負な 0 は “無符号” 0 に “~~同化される” ことになる。 ◎ Note: Note that negative zeros don’t escape a math function; as detailed below, they’re "censored" away into an "unsigned" zero.
-
次に挙げる演算は、 ~0N を生産する ⇒# ~0N と ~0N を加算するとき / ~0N から ~0P を減算するとき
0 を生産するような他のすべての加算/減算は、 ~0P を生産する。
◎ 0⁻ + 0⁻ or 0⁻ - 0 produces 0⁻. All other additions or subtractions that would produce a zero produce 0⁺. -
次に挙げる演算は、 ~0N を生産する ⇒# ~0N と ~0P を乗算するとき / ~0N と正な値を乗算するとき / ~0N を正な値で除算するとき
次に挙げる演算は、 ~0P を生産する ⇒# ~0N と ~0N を乗算するとき / ~0N と負な値を乗算するとき / ~0N を負な値で除算するとき
[ 正な値 / 負な値 ]を ~0N で除算するときは、[ −∞ / +∞ ]を生産する。
(言い換えれば、 ~0N を引数にとる[ 乗算/除算 ]は,標準な符号n規則に従う。)
◎ Multiplying or dividing 0⁻ with a positive number (including 0⁺) produces a negative result (either 0⁻ or −∞), while multiplying or dividing 0⁻ with a negative number produces a positive result. (In other words, multiplying or dividing with 0⁻ follows standard sign rules.) - ~0P と ~0N を比較するときは、 ~0N ~LT ~0P になるとする。 例えば,[ `min(0, -0)^v / `max(0, -0)^v / `clamp(0, -0, 1)^v 【!`min(~0P, ~0N)^v / `max(~0P, ~0N)^v / `clamp(~0P, ~0N, 1)^v】 ]は、[ ~0N / ~0P / ~0P ]を生産するモノトスル。 ◎ When comparing 0⁺ and 0⁻, 0⁻ is less than 0⁺. For example, min(0⁺, 0⁻) must produce 0⁻, max(0⁺, 0⁻) must produce 0⁺, and clamp(0⁺, 0⁻, 1) must produce 0⁺.
別の`~math関数$の内側に入子にされてない`~math関数$は、 `~top-levelの計算式@ と総称される。 `~top-levelの計算式$が生産する値の数量-部が[ ~NaN/ ~0N ]になる場合、数量-部は[ +∞ / “無符号” 0 ]になったかのように動作するとする。 ◎ If a top-level calculation (a math function not nested inside of another math function) would produce a value whose numeric part is NaN, it instead act as though the numeric part is +∞. If a top-level calculation would produce a value whose numeric part is 0⁻, it instead acts as though the numeric part is the standard "unsigned" zero.
例えば, `calc(-5 * 0)^v は ~0N に解決されるが、`~top-levelの計算式$としては 無符号 0 に~~同化される。 ◎ For example, calc(-5 * 0) produces an unsigned zero—the calculation resolves to 0⁻, but as it’s a top-level calculation, it’s then censored to an unsigned zero.
他方, `calc(1 / calc(-5 * 0))^v は、 `calc(1 / (-5 * 0))^v と同じく, −∞ を生産する。 ~~内側の `calc^f は、`~top-levelの計算式$ではないので, ~0N に解決される。 その結果は,そのまま~top-levelの `calc^f に渡され、 −∞ を生産することになる — ~~仮に,そのままではなく無符号 0 に~~同化された場合、 +∞ を生産することになる。 ◎ On the other hand, calc(1 / calc(-5 * 0)) produces −∞, same as calc(1 / (-5 * 0))—the inner calc resolves to 0⁻, and as it’s not a top-level calculation, it passes it up unchanged to the outer calc to produce −∞. If it was censored into an unsigned zero, it would instead produce +∞.
注記: `~math関数$やそれが解決される型の妥当性は、代数的な単純~化により影響されることはない。 例えば, `calc(5px - 5px + 10s)^v や `calc(0 * 5px + 10s)^v は、いずれも長さと時間を加算しようと試みるので,無効になる。 ◎ Note: Algebraic simplifications do not affect the validity of a math function or its resolved type. For example, calc(5px - 5px + 10s) and calc(0 * 5px + 10s) are both invalid due to the attempt to add a length and a time.
注記: `number$t に相対的な `percentage$t — `opacity$p におけるそれなど — は、 `number$t と組合できないことに注意。 これを許容すると,( `dimension$t の乗算や除算を許容するための) “単位~代数” に有意な問題をもたらすので。 どの事例においても,それが新たな機能性を供することはない(例えば `opacity^p: `25%^v は, `opacity^p: `.25^v に一致する — それは自明な構文~変形-に過ぎない)。 それでも、他の演算は遂行できる — 例えば `opacity^p: `calc(100% / 3)^v; は妥当になる。 ◎ Note: Note that <percentage>s relative to <number>s, such as in opacity, are not combinable with those numbers—opacity: calc(.25 + 25%) is invalid. Allowing this causes significant problems with "unit algebra" (allowing multiplication/division of <dimension>s), and in every case so far, doesn’t provide any new functionality. (For example, opacity: 25% is identical to opacity: .25; it’s just a trivial syntax transform.) You can still perform other operations with them, such as opacity: calc(100% / 3);, which is valid.
注記: `number-token$t は,常に `number$t, `integer$t のいずれかに解釈されるので、 `~math関数$内では `length$t を意図する単位なしの `0^v は~supportされない。 すなわち、 width: `0^v; や width: `5px^v; は妥当であっても, width: `calc(0 + 5px)^v; は妥当でない — `number$t と `length$t を~~加算しようと~~試みるので。 ◎ Note: Because <number-token>s are always interpreted as <number>s or <integer>s, "unitless 0" <length>s aren’t supported in math functions. That is, width: calc(0 + 5px); is invalid, because it’s trying to add a <number> to a <length>, even though both width: 0; and width: 5px; are valid.
注記: 裸の `number$t が使用~値の時点で `length$t になるような~propも少数あるが(特定的には, `line-height$p, `tab-size$p )、 `number$t は, `calc$f 内では決して “長さの様なもの” にはならず、常に `number$t であり続ける。 ◎ Note: Altho there are a few properties in which a bare <number> becomes a <length> at used-value time (specifically, line-height and tab-size), <number>s never become "length-like" in calc(). They always stay as <number>s.
注記: 過去互換~mode `quirks$r においては、通常は `length$t しか受容しない一部の~propは, `number$t も受容して それらを `px$u 長さとして解釈するものと定義される。 単位なしの `0^v の様に、これには`~math関数$の[ 構文解析/挙動 ]に対する効果は無い — `number^t 値に解決される`~math関数$は、過去互換~modeにおいては妥当になる(その結果は `px^u 長さとして解釈される)かもしれないが。 ◎ Note: In Quirks Mode [quirks], some properties that would normally only accept <length>s are defined to also accept <number>s, interpreting them as px lengths. Like unitless zeroes, this has no effect on the parsing or behavior of math functions, tho a math function that resolves to a <number> value might become valid in Quirks Mode (and have its result interpreted as a px length).
11.10. 内部~表現
`~math関数$の`内部~表現$は、 `計算式~tree@ になる — この~treeを成す各~nodeのうち: ◎ The internal representation of a math function is a calculation tree: a tree where\
-
枝分かれ~node(子を持つ~node)には、 `演算子~node@ と総称される,次のいずれかが対応する ⇒# `~math関数$( `Min^i, `Cos^i, `Sqrt^i, 等々)/ `計算式$内の演算子( `Sum^i, `Product^i, `Negate^i, `Invert^i †)
後者は `~calc演算子~node@ と総称される。 【† これらの各 名前は、 `CSSMathValue$I の各種 下位classの名前に対応する。】
◎ the branch nodes are operator nodes corresponding either to math functions (such as Min, Cos, Sqrt, etc) or to operators in a calculation (Sum, Product, Negate, and Invert, the calc-operator nodes), and\ - 葉~node(子を持たない~node)には、次のいずれかが対応する ⇒# 数量-値(実数, 次元, 百分率)/ `~math関数$でない ある数量-型に解決されるもの ◎ the leaf nodes are either numeric values (such as numbers, dimensions, and percentages) or non-math functions that resolve to a numeric type.
`~math関数$は、次に与える`計算式~tree$に転換される: ◎ Math functions are turned into calculation trees depending on the function:
- `calc$f 関数の`内部~表現$は、次の結果になる ⇒ `計算式を構文解析する$( その引数 ) ◎ calc() • The internal representation of a calc() function is the result of parsing a calculation from its argument.
- その他の`~math関数$の`内部~表現$は、当の関数と同じ名前の`演算子~node$になる ⇒ その各~子は、関数の各~引数が現れる順序で,[ 各~引数に対する次の結果 ]で与えられる ⇒ `計算式を構文解析する$( 引数 ) ◎ any other math function • The internal representation is an operator node with the same name as the function, whose children are the result of parsing a calculation from each of the function’s arguments, in the order they appear.
`計算式を構文解析する@ ときは、所与の ( `計算式$を表現している`成分~値$の~list %値~list ) に対し,`計算式~tree$を返す: ◎ To parse a calculation, given a calculation values represented as a list of component values, and returning a calculation tree:
- %値~list から `whitespace-token$t をすべて除去する ◎ Discard any <whitespace-token>s from values.
-
この段の目的においては、 %値~list を成す各 %~item には、次に与える `演算子^i が結付けられる ⇒# %~item は `delim-token$t であって,その.値 ~IN { `+^l, `-^l, `*^l, `/^l } ならば それ / ~ELSE_ ε
【 この段では、各[[ `*^l / `/^l ]で区切って連結された成分たちが成す連なり ]を `Product^i ~nodeの中に収集する。 それに伴い、[ `-^l / `/^l ]が前置された各~成分は[ `Negate^i / `Invert^i ]~nodeの中に包装する。 】【 この段は、原文の記述にかなり手を加えている(より~algo的に~~厳密化/~~整理集約など) 】
- ~Assert: %値~list は[ `演算子^i ~NEQ ε のものと, それ以外のもの ]が交互に並んでいて、最初, 最後の~itemの `演算子^i ~EQ ε
- %子~list ~LET 新たな~list
- %積~list ~LET 新たな~list
- %現在の演算子 ~LET ε
-
%値~list を成す ~EACH( %~item ) に対し:
-
~IF[ %~item の `演算子^i ~NEQ ε ]:
- %現在の演算子 ~SET %~item の `演算子^i
- ~IF[ %現在の演算子 ~IN { `*^l / `/^l } ]~OR[ %積~list の~size ~EQ 0 ] ⇒ ~CONTINUE
-
~ELSE:
- ~IF[ %現在の演算子 ~EQ `-^l ] ⇒ %~item ~SET %~item を子として包含している `Negate^i ~node
- ~ELIF[ %現在の演算子 ~EQ `/^l ] ⇒ %~item ~SET %~item を子として包含している `Invert^i ~node
- %積~list に %~item を付加する
- ~IF[ %~item は %値~list の最後の~itemでない ] ⇒ ~CONTINUE
- ~IF[ %積~list の~size ~EQ 1 ] ⇒ %子~list に %積~list[0] を付加する
- ~ELSE ⇒ %子~list に[ %子~list を成す各~itemを子として持つ `Product^i ~node ]を付加する
- %積~list を空にする
-
- %根 ~LET %子~list を成す各~itemを子として持つ `Sum^i ~node ◎ ↓
- ~IF[ %子~list は唯一の~itemからなる ]~AND[ その~itemは[ `Product^i ~node/`丸括弧~block$ ]である ] ⇒ %根 ~SET その~item ◎ If values has only one item, and it is a Product node or a parenthesized simple block, replace values with that item. ◎ Otherwise, replace values with a Sum node containing the value items of values as its children.
- ~Assert: %根 を根とする~treeを成す~nodeのうち,子を持つ~nodeは[ `Sum^i / `Product^i/ `Negate^i/ `Invert^i ]~nodeであって,他の~node(葉~node)は そうでない。 ◎ At this point values is a tree of Sum, Product, Negate, and Invert nodes, with other types of values at the leaf nodes. Process the leaf nodes.
-
%根 を成す ~EACH( 子を持たない~node %葉 ) に対し: ◎ For every leaf node leaf in values:
- ~IF[ %葉 は`丸括弧~block$である ] ⇒ %葉 を次の結果に置換する ⇒ `計算式を構文解析する$( %葉 の内容 ) ◎ If leaf is a parenthesized simple block, replace leaf with the result of parsing a calculation from leaf’s contents.
- ~IF[ %葉 は`~math関数$である ] ⇒ %葉 をその~math関数の`内部~表現$に置換する ◎ If leaf is a math function, replace leaf with the internal representation of that math function.
- ~RET `計算式~treeを単純~化する$( %根 ) ◎ Return the result of simplifying a calculation tree from values.
11.10.1. 単純~化
`~math関数$の`内部~表現$は、標準な代数的な単純~化を利用して,~~隅々までアリな限り単純~化される(乗算を総和に分配する, 単位が`互換$な値どうしを結合する, 等々)。 ◎ Internal representations of math functions are eagerly simplified to the extent possible, using standard algebraic simplifications (distributing multiplication over sums, combining similar units, etc.).
`計算式~treeを単純~化する@ ときは、所与の ( %根 ) に対し: ◎ To simplify a calculation tree root:
-
~IF[ %根 は数量-値である ]: ◎ If root is a numeric value:
- ~IF[ %根 は ある次元の %別の値 を~~基準に解決される百分率であって,それを解決するに十分な情報は可用である ] ⇒ ~RET %根 を その次元の`正準的~単位$において解決した結果の数量-値 ◎ If root is a percentage that will be resolved against another value, and there is enough information available to resolve it, do so, and express the resulting numeric value in the appropriate canonical unit. Return the value.
- ~IF[ %根 は ある次元の値であって,その単位は`正準的~単位$でない ]~AND[ %根 を正準的~単位の値に換算するに十分な情報は可用である ] ⇒ ~RET %根 を正準的~単位に換算した結果 ◎ If root is a dimension that is not expressed in its canonical unit, and there is enough information available to convert it to the canonical unit, do so, and return the value.
- ~IF[ %根 は `calc-constant$t である ] ⇒ ~RET %根 の数量-値 ◎ If root is a <calc-constant>, return its numeric value.
- ~RET %根 ◎ Otherwise, return root.
-
~IF[ %根 は他の葉~nodeである(演算子~nodeでない) ]: ◎ If root is any other leaf node (not an operator node):
- ~IF[ %根 の数量-値を決定するに十分な情報は可用である ] ⇒ ~RET 値を`正準的~単位$で表出した結果 ◎ If there is enough information available to determine its numeric value, return its value, expressed in the value’s canonical unit.
- ~RET %根 ◎ Otherwise, return root.
- ~Assert: この時点で, %根 は`演算子~node$である。 ◎ At this point, root is an operator node.\
- %根 を成す ~EACH( %子 ) を次の結果に置換する ⇒ `計算式~treeを単純~化する$( %子 ) ◎ Simplify all the children of root.
- ~IF[ %根 は`~calc演算子~node$でない ]~AND[ %根 の子は どれも数量-値であって, %根 が表現する演算を算出するに十分な情報を伴う ] ⇒ ~RET [ %根 の子たちを利用して %根 の演算を走らせた結果 ]を値にとり,結果の`正準的~単位$で表出される数量-値 ◎ If root is an operator node that’s not one of the calc-operator nodes, and all of its children are numeric values with enough information to computed the operation root represents, return the result of running root’s operation using its children, expressed in the result’s canonical unit.
-
%根 に応じて:
- `Negate^i ~node ◎ If root is a Negate node:
-
- ~IF[ %根 の子は数量-値である ] ⇒ ~RET 0 ~MINUS その値 (反数にした結果) ◎ If root’s child is a numeric value, return an equivalent numeric value, but with the value negated (0 - value).
- ~IF[ %根 の子は `Negate^i ~nodeである ] ⇒ ~RET %根 の子の子 ◎ If root’s child is a Negate node, return the child’s child.
- ~RET %根 ◎ Return root.
- `Invert^i ~node ◎ If root is an Invert node:
-
- ~IF[ %根 の子は実数である(百分率でも次元でもない) ] ⇒ ~RET 1 ~DIV その値(すなわち逆数) ◎ If root’s child is a number (not a percentage or dimension) return the reciprocal of the child’s value.
- ~IF[ %根 の子は `Invert^i ~nodeである ] ⇒ ~RET %根 の子の子 ◎ If root’s child is an Invert node, return the child’s child.
- ~RET %根 ◎ Return root.
- `Sum^i ~node ◎ If root is a Sum node:
-
- %根 の子のうち `Sum^i ~nodeである ~EACH( %子 ) を %子 の子たちに置換する ◎ For each of root’s children that are Sum nodes, replace them with their children.
-
~EACH( %根 の数量-値である子のうち,互いの単位が一致するものたちが成す集合 ) に対し ⇒ その集合を成す子たちを[ それらの総和が成す単独の数量-値 ]に置換する ◎ For each set of root’s children that are numeric values with identical units, remove those children and replace them with a single numeric value containing the sum of the removed nodes, and with the same unit.
(例:[ 実数どうし/百分率どうし/`px^u 値どうし ]を結合する) ◎ (E.g. combine numbers, combine percentages, combine px values, etc.)
- ~RET [ %根 の子は 1 個だけならば %根 の子 / ~ELSE_ %根 ] ◎ If root has only a single child at this point, return the child. Otherwise, return root.
- `Product^i ~node ◎ If root is a Product node:
-
- %根 の子のうち `Product^i ~nodeである ~EACH( %子 ) を %子 の子たちに置換する ◎ For each of root’s children that are Product nodes, replace them with their children.
- ~IF[ %根 には実数である(百分率でも次元でもない)子~nodeが複数個ある ] ⇒ それらの~nodeを[ それらの積が成す単独の実数 ]に置換する ◎ If root has multiple children that are numbers (not percentages or dimensions), remove them and replace them with a single number containing the product of the removed nodes.
- ~IF[ %根 には子が 2 つだけある ]~AND[ 一方の子は 実数 %N である(百分率でも次元でもない) ]~AND[ もう一方の子は `Sum^i ~node %S であって,その子たちは すべて数量-値である ] ⇒# %S の ~EACH( 子 ) に対し,その値に %N を乗算する; ~RET %S ◎ If root contains only two children, one of which is a number (not a percentage or dimension) and the other of which is a Sum whose children are all numeric values, multiply all of the Sum’s children by the number, then return the Sum.
- ~IF[ %根 の子は どれも[ 数量-値/数量-値を子とする `Invert^i ~node ]である ] ⇒ ~IF[ `型を乗算する$( %根 のすべての子 ) の結果は 当の`~math関数$を解決できる型に`合致する$ ( `Invert^i ~nodeの型は `型を逆数にする$( その子の型 ) の結果になることに注意) ] ⇒ ~RET [ %根 のすべての子の値を乗算した結果 ( `Invert^i ~nodeの値は、その子の値の逆数であることに注意) ]を値にとり,結果の`正準的~単位$で表出される数量-値 ◎ If root contains only numeric values and/or Invert nodes containing numeric values, and multiplying the types of all the children (noting that the type of an Invert node is the inverse of its child’s type) results in a type that matches any of the types that a math function can resolve to, return the result of multiplying all the values of the children (noting that the value of an Invert node is the reciprocal of its child’s value), expressed in the result’s canonical unit.
- ~RET %根 ◎ Return root.
- `Min^i ~node ◎ ↓
- `Max^i ~node ◎ If root is a Min or Max node:
-
- ~EACH( %根 の数量-値である子のうち,[ 互いの単位が一致する, かつ `percent^l でない†もの ]たちが成す集合 ) に対し ⇒ その集合を成す子たちを[ %根 に応じて適切な演算子 【 `Min^i ~nodeならば `min$f (最小~値をとる)等】 で結合した結果の数量-値 ]に置換する ◎ For each node child of root’s children: ◎ If child is a numeric value with a unit other than "percent", and there are other children of root that are numeric values with the same unit, combine all such children with the appropriate operator per root, and replace child with the result, removing all other child nodes involved.
- ~RET [ %根 の子は 1 個だけならば %根 の子 / ~ELSE_ %根 ] ◎ If root now has only a single child, return that child. Otherwise, return root.
- 【† `percent^l が除外されている理由は、それらが,負な量を基準にすることもあるため。 】
- その他の~node
- ~Assert: この事例は生じ得ない
- 【 この段は、この訳による補完(未策定な事例があるかもしれない)。 】
11.11. 算出d値
`~math関数$の`算出d値$は、算出d値の時点で可用なすべての情報( `em$u と `px$u の比率, 何らかの~propにおいて百分率を解決する方法, 等々)を利用する下で,その`計算式~treeを単純~化$した結果になる。 ◎ The computed value of a math function is its calculation tree simplified, using all the information available at computed value time. (Such as the em to px ratio, how to resolve percentages in some properties, etc.)
算出d値の時点で解決されない百分率は、`~math関数$の中でも解決されない。 例えば,式 `calc(100% - 100% + 1px)^v は、 `1px^v ではなく, `calc(0% + 1px)^v に解決される。 百分率から算出d値を得るための特別な規則がある場合(例えば `height$p ~prop)、その規則が`~math関数$に含まれるどの百分率にも適用される。 ◎ Where percentages are not resolved at computed-value time, they are not resolved in math functions, e.g. calc(100% - 100% + 1px) resolves to calc(0% + 1px), not to 1px. If there are special rules for computing percentages in a value (e.g. the height property), they apply whenever a math function contains percentages.
`計算式~tree$は、`使用~値$の時点でも,その時点の情報で再び単純~化される — `~math関数$は常に,単独の数量-値に さらに単純~化される。 ◎ The calculation tree is again simplified at used value time; with used value time information, a math function always simplifies down to a single numeric value.
例えば, `font-size$p における百分率~値は、`~fontに相対的な長さ$ 単位を算出できるよう,`算出d値$の時点で解決される。 一方で, `background-position$p における百分率~値は、その挙動が~layoutに依存するため,使用~値の時点まで解決されない。 ◎ For example, whereas font-size computes percentage values at computed value time so that font-relative length units can be computed, background-position has layout-dependent behavior for percentage values, and thus does not resolve percentages until used-value time.
このことに因り、 `background-position$p における算出では, `calc$f 内の百分率は保全される一方で、 `font-size$p では,そのような式は直に長さに算出される。 ◎ Due to this, background-position computation preserves the percentage in a calc() whereas font-size will compute such expressions directly into a length.
~tableを成す[ ~cellその他の要素 ]の~size計算は複階的なので、~tableの[ ~col, ~col~group, ~row, ~row~group, ~cell ]の~sizeに対する[ 長さと百分率が混在な式 ]については、~table~layoutが自動( `auto^v )か固定的( `fixed^v )かに関わらず, `~autoS$v が指定されていたかのように扱う`モノトスル^em。 ◎ Given the complexities of width and height calculations on table cells and table elements, math expressions mixing both percentages and lengths for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MUST be treated as if auto had been specified.
11.12. 範囲の検査-法
構文解析-時には、`~math関数$の中の値に対しては,範囲は検査されないので、値が範囲~外であっても宣言は無効にならない。 しかしながら、式による結果の値は,当の文脈に許容される範囲に切詰めるモノトスル。 この切詰ngは、`算出d値$に対しては,アリな所すべてで遂行され、算出において範囲を検査するに足るまで式を単純~化できなかった場合には,`使用~値$に対し遂行される。 (`指定d値$に対しては、切詰ngは遂行されない。) ◎ Parse-time range-checking of values is not performed within math functions, and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from an expression must be clamped to the range allowed in the target context. Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking. (Clamping is not performed on specified values.)
注記: したがって、【!*calc】`~math関数$を受容するすべての文脈において,許容される値の範囲は(開区間ではなく)閉区間として定義することが要求される。 ◎ Note: This requires all contexts accepting calc() to define their allowable values as a closed (not open) interval.
注記: ±∞ は、[ どの~propに対しても、定義により,許容される範囲の外側にある ]ので,許容される[ 最小/最大 ]値に切詰められることになる。 `animation-iteration-count$p など,~keyword値として明示的に `infinity$v 【実際には `infinte^v だが】 を許容する~propであっても、`~math関数$は,~prop構文の`数量-部分^emの[ 最小/最大 ]値に切詰められ,~keyword値には解決され得ない。 ◎ Note: By definition, ±∞ are outside the allowed range for any property, and will clamp to the minimum/maximum value allowed. Even for properties that explicitly allow infinity as a keyword value, such as animation-iteration-count, will end up clamping ±∞, as math functions can’t resolve to keyword values; the numeric part of the property’s syntax still has a minimum/maximum value.
加えて, `number$t に解決される`~math関数$が `integer$t のみを受容する所に利用された場合、その[ `算出d値$/ `使用~値$ ]は,上の切詰ngと同じ方式で最も近い整数に丸められる。 丸める手法は、整数~値の~animationと同じそれを利用するモノトスル。 ◎ Additionally, if a math function that resolves to <number> is used somewhere that only accepts <integer>, the computed value and used value are rounded to the nearest integer, in the same manner as clamping, above. The rounding method must be the same as is used for animations of integer values.
`0px^v より小さい横幅は許容されないので、次の 3 つは `width$p: `0px^v; に等価になる: ◎ Since widths smaller than 0px are not allowed, these three declarations are equivalent:
width: calc(5px - 10px); width: calc(-5px); width: 0px;
しかしながら、 `width$p: `-5px^v; と `width$p: `calc(-5px)^v; は等価ではないことに注意。 `calc$f の`外側^emにある範囲~外の値は,構文上は無効であり、宣言はまるごと落とされることになる。 ◎ Note however that width: -5px is not equivalent to width: calc(-5px)! Out-of-range values outside calc() are syntactically invalid, and cause the entire declaration to be dropped.
11.13. 直列化
この節は、依然として討議中にある。 【!https://lists.w3.org/Archives/Member/w3c-css-wg/2016AprJun/0239.html】 ◎ This section is still under discussion.
`~math関数を直列化する@ ときは、所与の ( %fn ) に対し: ◎ To serialize a math function fn:
- %根 ~LET %fn が表現する`計算式~tree$の根~node
- ~IF[ %根 は数量-値(実数/百分率/次元)である ]~AND[ これが生産している直列化は`算出d値$かそれより後のものである ] ⇒ ~RET 必要とされるなら,値を その文脈に許容される範囲に切詰めた上で、値を通常通り直列化した結果 【すなわち、この~algoを適用し直す】 ◎ If the root of the calculation tree fn represents is a numeric value (number, percentage, or dimension), and the serialization being produced is of a computed value or later, then clamp the value to the range allowed for its context (if necessary), then serialize the value as normal and return the result.
-
~IF[ %fn は[ 無限/~NaN ]値を表現する ]: ◎ If fn represents an infinite or NaN value:
- %s ~LET 値を表現する適切な[ `infinity$v / `-infinity$v / `NaN$v ]~keywordを直列化した結果 ◎ ↓↓Let s be the string "calc(". ◎ Serialize the keyword infinity, -infinity, or NaN, as appropriate to represent the value, and append it to s.
- ~IF[ %fn の`型$は `number$t を表現するもの( «[ ]» に等価/無次元)でない ] ⇒ %s に次を順に付加する【!`型$が多重次元の場合は?】 ⇒# ` * 1^l, %fn の`型$用の`正準的~単位$( `length$t 用には `px$u など) ◎ If fn’s type is anything other than «[ ]» (empty, representing a <number>), append " * " to s. Create a numeric value in the canonical unit for fn’s type (such as px for <length>), with a value of 1. Serialize this numeric value and append it to s.
- ~RET 次を順に連結した結果 ⇒# `calc(^l, %s, `)^l【!原文抜け】 ◎ Return s.
- %名前 ~LET %根 に応じて ⇒# 数量-値であるならば `calc^l / `~calc演算子~node$であるならば `calc^l / ~ELSE_ 小文字~化された %根 の名前( `sin^l, `max^l など) ◎ If the calculation tree’s root node is a numeric value, or a calc-operator node, let s be a string initially containing "calc(". ◎ Otherwise, let s be a string initially containing the name of the root node, lowercased (such as "sin" or "max"), followed by a "(" (open parenthesis).
- %~list ~LET 新たな~list ◎ ↓↓
-
%根 の ~EACH( 子 %子 ) に対し:
- %直列化 ~LET `計算式~treeを直列化する$( %子 )
- ~IF[ %直列化 の先頭の文字 ~EQ `(^l (左~丸括弧) ]~AND[ %直列化 の末尾の文字 ~EQ `)^l (右~丸括弧) ] ⇒ %直列化 から先頭, 末尾の文字を除去する
- %~list に %直列化 を付加する
- %引数~列 ~LET %~list を `, ^l (~comma, ~spaceの並び)で`連結-$した結果 ◎ Concatenate all of the results using ", " (comma followed by space), then append the result to s.
- ~RET 次を順に連結した結果 ⇒# %名前, `(^l (左~丸括弧), %引数~列, `)^l (右~丸括弧) ◎ Append ")" (close parenthesis) to s. ◎ Return s.
`計算式~treeを直列化する@ ときは、所与の ( `計算式~tree$の根を与える~node %根 ) に対し: ◎ To serialize a calculation tree: • Let root be the root node of the calculation tree.
- ~IF[ %根 は数量-値である ]~OR[ %根 は`~math関数$でない ] ⇒ ~RET %根 用の通常の規則により %根 を直列化した結果 ◎ If root is a numeric value, or a non-math function, serialize root per the normal rules for it and return the result.
- ~IF[ %根 は[ `Sum^i, `Negate^i, `Product^i, `Invert^i ]以外の~nodeである ] ⇒ ~RET `~math関数を直列化する$( %根 ) 【!treating the ... 不要?】 ◎ If root is anything but a Sum, Negate, Product, or Invert node, serialize a math function for the function corresponding to the node type, treating the node’s children as the function’s comma-separated calculation arguments, and return the result.
- ~IF[ %根 は `Negate^i ~nodeである ] ⇒ ~RET 次を順に連結した結果 ⇒# `(-1 * ^l, `計算式~treeを直列化する$( %根 の子 ), `)^l ◎ If root is a Negate node, let s be a string initially containing "(-1 * ". ◎ Serialize root’s child, and append it to s. ◎ Append ")" to s, then return it.
- ~IF[ %根 は `Invert^i ~nodeである ] ⇒ ~RET 次を順に連結した結果 ⇒# `(1 / ^l, `計算式~treeを直列化する$( %根 の子 ), `)^l ◎ If root is an Invert node, let s be a string initially containing "(1 / ". ◎ Serialize root’s child, and append it to s. ◎ Append ")" to s, then return it.
-
~IF[ %根 は `Sum^i ~nodeである ]: ◎ If root is a Sum node,\
- %s ~LET `(^l ◎ let s be a string initially containing "(".
- %子~list ~LET `根の子たちを~sortする$( %根 ) ◎ Sort root’s children.
- %s に次の結果を付加する ⇒ `計算式~treeを直列化する$( %子~list の最初の~item ) ◎ Serialize root’s first child, and append it to s.
-
%子~list を成す最初の~itemを除く ~EACH( %子 ) に対し: ◎ For each child of root beyond the first:
- ~IF[ %子 は `Negate^i ~nodeである ] ⇒ %s に次を順に付加する ⇒# ` - ^l, `計算式~treeを直列化する$( %子 の子 ) ◎ If child is a Negate node, append " - " to s, then serialize the Negate’s child and append the result to s.
- ~ELIF[ %子 は 負な数量-値である ] ⇒ %s に次を順に付加する ⇒# ` - ^l, %子 の反数化を通常通り直列化した結果 ◎ If child is a negative numeric value, append " - " to s, then serialize the negation of child as normal and append the result to s.
- ~ELSE ⇒ %s に次を順に付加する ⇒# ` + ^l, `計算式~treeを直列化する$( %子 ) ◎ Otherwise, append " + " to s, then serialize child and append the result to s.
- %s に `)^l を付加する ◎ Finally, append ")" to s\
- ~RET %s ◎ and return it.
-
~IF[ %根 は `Product^i ~nodeである ]: ◎ If root is a Product node,\
- %s ~LET `(^l ◎ let s be a string initially containing "(".
- %子~list ~LET `根の子たちを~sortする$( %根 ) ◎ Sort root’s children.
- %s に次の結果を付加する ⇒ `計算式~treeを直列化する$( %子~list の最初の~item ) ◎ Serialize root’s first child, and append it to s.
-
%子~list を成す最初の~itemを除く ~EACH( %子 ) に対し: ◎ For each child of root beyond the first:
- ~IF[ %子 は `Invert^i ~nodeである ] ⇒ %s に次を順に付加する ⇒# ` / ^l を付加する, `計算式~treeを直列化する$( %子 の子 ) ◎ If child is an Invert node, append " / " to s, then serialize the Invert’s child and append the result to s.
- ~ELSE ⇒ %s に次を順に付加する ⇒# ` * ^l, `計算式~treeを直列化する$( %子 ) ◎ Otherwise, append " * " to s, then serialize child and append the result to s.
- %s に `)^l を付加する; ◎ Finally, append ")" to s\
- ~RET %s ◎ and return it.
`根の子たちを~sortする@ ときは、所与の ( %根 ) に対し,[ %根 の子たちを,次に従って~sortした結果 ]を新たな~listとして返す: ◎ To sort a calculation’s children nodes:
- 次の順に~sortする ⇒# `実数$を包含する~node(高々 1 個), `百分率$を包含する~node(高々 1 個), `次元$を包含する~node, その他の~node ◎ Let ret be an empty list. ◎ If nodes contains a number, remove it from nodes and append it to ret. ◎ If nodes contains a percentage, remove it from nodes and append it to ret.
- 次元を包含する~nodeどうしは、`~ASCII大小無視$の下で,それらの単位の~alphabet順に~sortする ◎ If nodes contains any dimensions, remove them from nodes, sort them by their units, ordered ASCII case-insensitively, and append them to ret.
- その他の~nodeどうしは、元と同じ順序に従う ◎ If nodes still contains any items, append them to ret in the same order. ◎ Return ret.
例えば, `calc(20px + 30px)^v は、指定d値としては `calc(50px)^v に,算出d値としては `50px^v に直列化する。 ◎ For example, calc(20px + 30px) would serialize as calc(50px) as a specified value, or as 50px as a computed value.
`calc(20px + 0%)^v の様な値は、 `calc(0% + 20px)^v として直列化し,いずれの項も 直列化された値の中に保守する。 ( 0 値の項を保守することは重要である — いずれかの値が一時的に 0 値になっても,遷移の最中に突然 `calc$f の “~~形が変わる” ことがないように。 また、すべての項が 0 であるときに “単位を選ぶ” 必要もなくなる。) ◎ A value like calc(20px + 0%) would serialize as calc(0% + 20px), maintaining both terms in the serialized value. (It’s important to maintain zero-valued terms, so the calc() doesn’t suddenly "change shape" in the middle of a transition when one of the values happens to have a zero value temporarily. This also removes the need to "pick a unit" when all the terms are zero.)
`calc(20px + 2em)^v の様な値は、指定d値としては `calc(2em + 20px)^v に直列化する(両 単位とも、指定d値の時点では互換でないので,~alphabet順に~sortした上で保守する)。 また、算出d値としては `52px^v の様な値に直列化する( `em$u 値は,算出d値の時点で絶対~長さに換算されるので、 `1em^v = `16px^v であったなら、それらは `52px^v に結合した上で,包装している `calc$f を外す)。 ◎ A value like calc(20px + 2em) would serialize as calc(2em + 20px) as a specified value (maintaining both units as they’re incompatible at specified-value time, but sorting them alphabetically), or as something like 52px as a computed value (em values are converted to absolute lengths at computed-value time, so assuming 1em = 16px, they combine into 52px, which then drops the calc() wrapper.)
直列化についての更なる情報は、 `CSSOM$r を見よ。 ◎ See [CSSOM] for further information on serialization.
11.14. ~math関数の結合n
[ `~math関数$どうし/ 数量-値と数量-値をとる関数 ]の:
-
`補間$における %結果値 は次で定義される
⇒
calc((1 - %p) * %値a + %p * %値b)
-
`加算$における %結果値 は次で定義される
⇒
calc(%値a + %値b)
(いずれの場合も、 %結果値 の`計算式~treeを単純~化$した結果は、式をより小さく単純な形に簡約し得る。)
◎ Interpolation of math functions, with each other or with numeric values and other numeric-valued functions, is defined as Vresult = calc((1 - p) * Va + p * Vb). (Simplification of the value might then reduce the expression to a smaller, simpler form.) ◎ Addition of math functions, with each other or with numeric values and other numeric-valued functions, is defined as Vresult = calc(Va + Vb). (Simplification of the value might then reduce the expression to a smaller, simpler form.)付録 A. IANA 考慮点
A.1. `about:invalid^c ~URL~schemeの登録
この節では、 `RFC6694$r にて定義される登録~手続きに則って, `about:invalid^c ~URLを定義して登録する。 ◎ This sections defines and registers the about:invalid URL, in accordance with the registration procedure defined in [RFC6694].
この登録の公式的な記録は http://www.iana.org/assignments/about-uri-tokens/about-uri-tokens.xhtml に見出せる。 ◎ The official record of this registration can be found at http://www.iana.org/assignments/about-uri-tokens/about-uri-tokens.xhtml.
登録された~token | `invalid^c |
---|---|
意図されている用途 | `about:invalid^c ~URLは、汎用~error条件を伴う,存在しない文書を参照する。 ~URLが必要な所で,既定~値がいかなる型の文書にも解決-可能になるべきでないときに、利用できる。 ◎ The about:invalid URL references a non-existent document with a generic error condition. It can be used when a URL is necessary, but the default value shouldn’t be resolvable as any type of document. |
連絡先/変更管理者 | CSS WG <www-style@w3.org> (on behalf of W3C) |
仕様 | CSS Values and Units Module Level 3 |
謝辞
はじめに、この~moduleの 以前の~level に貢献されたすべての方々に感謝する。 ◎ Firstly, the editors would like to thank all of the contributors to the previous level of this module.
次に、~commentと示唆を寄せられ,この Level 4 を向上させた `Koji Ishii^en, `Xidorn Quan^en 両氏に。 ◎ Secondly, we would like to acknowledge Koji Ishii and Xidorn Quan for their comments and suggestions, which have improved Level 4.
変更点
- 2019年 1月 13日 作業草案 からの変更点(これは、 ~level 3 に対する追加の一部を成す) ◎ Changes Since the Jan 13 2019 Working Draft ◎ Changes since Jan 13 2019 WD (this is a subset of Additions Since Level 3):
- `dashed-ident$t 型を定義した。 ◎ Defined the <dashed-ident> type.
- `url$t 型に `src$f を追加した。 ◎ Added src() to the <url> type.
- `ratio$t 型を定義した。 ◎ Defined the <ratio> type.
- `attr$f 関数を定義する仕方を有意に変更した。 ◎ Significantly changed the way the attr() function is defined.
- 次に挙げる~math関数を追加した ⇒# `round$f, `mod$f, `rem$f, `sin$f, `cos$f, `tan$f, `asin$f, `acos$f, `atan$f, `atan2$f, `pow$f, `sqrt$f, `hypot$f, `log$f, `exp$f, `abs$f, `sign$f ◎ Added round(), mod(), rem(), sin(), cos(), tan(), asin(), acos(), atan(), atan2(), pow(), sqrt(), hypot(), log(), exp(), abs(), sign() math functions.
- `calc$f における利用-用に,次に挙げる定数を追加した ⇒# `e$v, `pi$v, `infinity$v, `-infinity$v, `NaN$v ◎ Added e, pi, infinity, -infinity, NaN constants for use in calc().
- `~math関数$の 直列化 を定義した。 ◎ Defined serialization of math functions.
- CSS Values and Units Level 3 [ に対する追加/ からの変更点 ] ◎ Additions Since Level 3 ◎ Changes since CSS Values and Units Level 3:
- 数量-[ 精度/範囲 ]を明示的に未定義にした。 ◎ Explicitly undefined numeric precision/range.
- 各~値~型ごとに補間~用の規則を追加して,それらの算出d値を明確化した。 ◎ Added rules for interpolation per value type, and their clarified computed values.
- `dashed-ident$t 型を定義した。 ◎ Defined the <dashed-ident> type.
- `url$t 型に `src$f を追加した。 ◎ Added src() to the <url> type.
- 長さ単位として次を追加した ⇒# `vi$u, `vb$u, `ic$u, `cap$u, `lh$u, `rlh$u ◎ Added the vi, vb, ic, cap, lh and rlh length units.
- `dppx$u の別名として, `x$u を追加した。
- `ratio$t 型を定義した。 ◎ Defined the <ratio> type.
- 比較~関数として次を追加した ⇒# `min$f, `max$f, `clamp$f ◎ Added min(), max(), and clamp() comparison functions.
- 次に挙げる~math関数を追加した ⇒# `round$f, `mod$f, `rem$f, `sin$f, `cos$f, `tan$f, `asin$f, `acos$f, `atan$f, `atan2$f, `pow$f, `sqrt$f, `hypot$f, `log$f, `exp$f, `abs$f, `sign$f ◎ Added round(), mod(), rem(), sin(), cos(), tan(), asin(), acos(), atan(), atan2(), pow(), sqrt(), hypot(), log(), exp(), abs(), sign() math functions.
- `calc$f における利用-用に,次に挙げる定数を追加した ⇒# `e$v, `pi$v, `infinity$v, `-infinity$v, `NaN$v ◎ Added e, pi, infinity, -infinity, NaN constants for use in calc().
- `calc$f に 単位~代数を追加して,`次元$の乗算と除算を許容した。 ◎ Added unit algebra to calc(), allowing multiplication and division of dimensions.
- `toggle$f を追加し戻した(元々は、~level 3 から~puntされていた)。 ◎ Added back toggle() (punted from level 3 originally).
- [ `integer$t が要求される所で利用された `calc^f ]を解決した結果が整数でないときは、自動的に最も近い整数に丸められる。 ◎ A non-integer in a calc() automatically rounds to the nearest integer when used where an <integer> is required.
- `~math関数$の直列化を定義した。 ◎ Defined serialization of math functions.
~securityと~privacyの考慮点
この仕様は,ほぼ各種~CSS仕様に共通な単位を定義するだけであり、~securityの懸念になるものはない。 ◎ This specification mostly just defines units that are common to CSS specifications, and which present no security concerns.
注記: ~URLの取扱いは~securityの懸念になるか? おそらく。 ◎ Note: Does URL handling have a security concern? Probably.
この仕様は、利用者の~screen~size, および 既定の~font~sizeを公開する単位を定義するが、両者とも~JSから自明に観測-可能なので、新たな~privacy~riskを成すことはない。 ◎ 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.