CSS値と単位モジュール レベル4

W3C作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2024/WD-css-values-4-20240312/
最新公開バージョン:
https://www.w3.org/TR/css-values-4/
編集者ドラフト:
https://drafts.csswg.org/css-values-4/
履歴:
https://www.w3.org/standards/history/css-values-4/
フィードバック:
CSSWG イシューレポジトリ
仕様内インライン
編集者:
Tab Atkins (Google)
Elika J. Etemad / fantasai (Apple)
この仕様への編集提案:
GitHub エディター
テストスイート:
https://wpt.fyi/results/css/css-values/

要約

このCSSモジュールは、CSSプロパティが受け入れる共通の値や単位、およびCSSプロパティ定義でそれらを記述するために使用される構文について説明します。

CSSは、構造化文書(HTMLやXMLなど)の画面や紙などへの描画を記述するための言語です。

この文書の位置付け

このセクションは、本書が公開された時点での位置付けについて説明します。 現在のW3Cの出版物一覧や、この技術報告書の最新版は https://www.w3.org/TR/ のW3C技術報告書インデックスで確認できます。

この文書は、CSS作業グループによって 作業草案として、 勧告トラックに従い公開されました。 作業草案としての公開は、W3Cおよびそのメンバーによる承認を意味するものではありません。

この文書はドラフトであり、今後いつでも更新・差し替え・廃止される可能性があります。 この文書を進行中の作業以外のものとして引用することは適切ではありません。

ご意見は、GitHubでイシューを登録(推奨)し、 タイトルに仕様コード“css-values”を含めてください。例: “[css-values] …コメント概要…”。 すべてのイシューおよびコメントはアーカイブされています。 あるいは、(アーカイブあり)のパブリックメーリングリストwww-style@w3.orgに送信することもできます。

この文書は、2023年11月3日W3Cプロセス文書に準拠しています。

この文書は、W3C特許ポリシーの下で活動するグループによって作成されました。 W3Cは、当該グループの成果物に関連してなされた特許開示の公開リストを管理しています。 このページには特許開示に関する手続きも記載されています。 特許に関する実際の知識を有し、その特許が必須クレームを含むと考える個人は、W3C特許ポリシー第6節に従い情報を開示しなければなりません。

1. 序論

各CSSプロパティの値定義欄には、キーワード、データ型(<>で囲まれて表示される)、およびそれらの組み合わせ方法に関する情報が含まれることがあります。 多くのプロパティで利用できる汎用的なデータ型(<length>が最も広く利用されています)は本仕様で説明されており、より特定のデータ型(例:<spacing-limit>)は、それぞれ対応するモジュールで説明されています。

1.1. モジュール間の相互作用

本モジュールは、[CSS2]1.4.2.14.3、 およびA.2節のデータ型定義を置き換え、拡張します。

2. 値定義の構文

ここで説明する値定義の構文は、CSSプロパティ(およびCSSの他の多くの部分の有効な構文)における有効値の集合を定義するために用いられます。 このように記述された値は1つ以上の構成要素を持つことができます。

2.1. 構成値タイプ

構成値タイプは、いくつかの方法で指定されます:

  1. キーワード値(例:autodiscなど)、 これはクォートなしでリテラルとして現れます(例:auto)。

  2. 基本データ型は、<>で囲まれて現れます(例:<length><percentage>など)。 数値データ型の場合、 この型記法は下記の角括弧による範囲指定記法を用いて範囲制限を注釈することができます。

  3. プロパティ値の範囲は、同名のプロパティが持つ値と同じパターンを表します。 これらはプロパティ名をシングルクォートで囲み、<>で挟んで記述します。 例:<'border-width'><'background-attachment'>など。

    これらの型にはCSS全体で使えるキーワード(例:inherit)は含みません。 さらに、プロパティ値の文法がカンマ区切り反復の場合、 対応する型にはトップレベルのカンマ区切りリスト乗数は含まれません。 (例:pairingというプロパティが[ <custom-ident> <integer>? ]#と定義されている場合、 <'pairing'>[ <custom-ident> <integer>? ]と等価であり、 [ <custom-ident> <integer>? ]#にはなりません。)

    なぜ乗数を除外するのか?

    これらの値型からトップレベルの乗数が除外される理由は、 トップレベルのカンマ区切り反復が主にリスト連携プロパティで使われており、 ショートハンドが複数のそのようなプロパティをまとめる場合、 独自のカンマ区切り反復を構築できるように、乗数なしの文法が必要になるためです。

    この特別な扱いがなければ、 それぞれのロングハンドごとに内部値専用の独自の生成規則を定義しなければならず、 文法全体の理解が難しくなってしまいます。

  4. 関数記法とその引数。 これらは関数名と空の括弧を、<>で囲んで記述します。 例:<calc()>。 これは対応する関数記法を参照します。

  5. その他の非終端記号。 これらは非終端の名前を<>で囲んで記述します。 例:<spacing-limit><border-width><'border-width'>の違いに注意してください。 後者はborder-widthプロパティの文法を表し、 前者は別の場所で明示的に展開される必要があります。 非終端の定義は通常、仕様書内で最初に現れる付近に記載されています。

一部のプロパティ値定義にはスラッシュ(/)、カンマ(,)、括弧もリテラルとして含まれます。 これらは対応するトークンを表します。 構成値に現れるその他のキーワード以外のリテラル文字(「+」など)は、シングルクォートで囲んで記述する必要があります。

カンマ は文法上、特定の条件下で省略可能です。 これは文法でオプション項目を区切る際に使われた場合に当てはまります。 プロパティや他のCSS値のトップレベルリスト、または関数の引数リストの中で、 文法上指定されたカンマは以下の場合に省略しなければなりません:

例:ある関数が順番に3つの引数を受け取ることができ、すべてがオプションの場合、 文法は次のように記述できます:
example( first? , second? , third? )

この文法に基づき、 example(first, second, third)のような記述は有効ですし、 example(first, second)example(first, third)example(second)も有効です。 ただし、example(first, , third)は無効です。なぜなら、これらのカンマのうち1つが2つの選択肢を区切らなくなるためです。 同様に、example(,second)example(first,)も無効です。 また、example(first second)も選択肢を区切るためにカンマが必要なため無効です。

もしカンマが暗黙的に省略できなかった場合、 引数の省略方法を適切に表現するために文法がより複雑になり、 機能のシンプルさが大きく損なわれます。

すべてのCSSプロパティは、CSS全体で使えるキーワード値もプロパティ値の唯一の構成要素として受け入れます。 可読性の観点からこれらはプロパティ値構文定義に明示的に記載されていません。 たとえば、border-colorの完全な値定義はCSS Cascading and Inheritance Level 3において<color>{1,4} | inherit | initial | unsetですが、 (実際には<color>{1,4}とだけ記載されています)。

注: これは一般的に、これらのキーワードを他の構成値と同じ宣言で組み合わせると 無効な宣言になることを意味します。 例えば、background: url(corner.png) no-repeat, inherit;は無効です。

2.2. 構成値コンビネータ

構成値は次のようにプロパティ値へ配置できます:

並置(juxtaposition)は二重アンパサンドより強く、二重アンパサンドはダブルバーより、ダブルバーはバーより強くなります。 したがって、次の2行は等価です:

  a b   |   c ||   d &&   e f
[ a b ] | [ c || [ d && [ e f ]]]

順不同コンビネータ(||, &&)においては、文法内の順序は問われません。 同じグループ内の構成要素はどの順序でも混在して現れて良いです。 したがって、次の行はすべて等価です:

a || b || c
b || a || c

注: コンビネータは結合的(associative)ではないので、グループ分けが重要です。 例えば、a || b || ca || [ b || c ]は異なる文法です: 前者はb a cのような値を許しますが、後者は許しません。

2.3. 構成値乗数

すべての型、キーワード、または括弧で囲まれたグループには、次のいずれかの修飾子を後置できます:

+#の乗数は+#のように積み重ねることができ、 同様に#?の乗数も#?のように積み重ねることができます。 これらの積み重ねは、それぞれ後ろの乗数を前の乗数適用後に適用したものを表します。 (これらの積み重ねはグループ化でも表現できますが、複雑な文法だと括弧の数が多くなり可読性が損なわれます。)

繰り返し構成値(*+、または#で示される)については、UAは最低でも20回の繰り返しをサポートしなければなりません。 プロパティ値がサポート回数を超える場合、その宣言は無効として無視されます。

2.4. コンビネータと乗数のパターン

特定の数や順序で複数の独立した構成値を組み合わせるには、いくつかの一般的な方法があります。 特に、構成値の集合から0個以上、1個以上、またはすべてを選択し、文法で指定された順番または任意の順番で並べることがよく求められます。

これらはすべて、コンビネータ乗数のシンプルなパターンで表現できます:

順番に 任意の順番
0個以上 A? B? C? A? || B? || C?
1個以上 [ A? B? C? ]! A || B || C
すべて A B C A && B && C

「任意の順番」の可能性はすべてコンビネータで、「順番に」はすべて並置のバリエーションとして表現されることに注意してください。

2.5. 構成値と空白

特に指定がない限り、空白やコメントは、上記のコンビネータ乗数で組み合わされた構成要素の前後および間に現れても構いません。

注: 多くの場合、構成要素同士を区別するために 空白が必須となることがあります。 例えば、値1em2emは、数値1と識別子em2emからなる<dimension-token>として解析され、これは無効な単位になります。 この場合、2の前に空白が必要で、1em2emという2つの長さとして解析できます。

2.6. 関数記法の定義

関数記法の構文は、次のシーケンスとして定義されます:

  1. 関数名を識別子として書き、続けて開き括弧を書く (例:example()。 または、<function-token>生成規則で 任意の関数名を示すこともできます。

  2. 関数の引数(あれば)は、値定義の構文で表現されます。

  3. リテラルの閉じ括弧。

関数の引数は暗黙的にグループ化されており、角括弧([ ... ])で囲まれているかのように扱われます。

例:次のような文法の場合:
example( <length> , <length> )

この場合、関数名が "example" であり、引数が「<length> , <length>」に一致する関数を受け付けます。

例:セレクター文法では疑似クラスを汎用的に定義し、 コロンの後に任意の関数名を許可しています:
<pseudo-class-selector> = ':' <ident-token> | ':' <function-token> <any-value> ')'

これは任意の関数名と、<any-value>を引数として取る関数を表します。

関数記法暗黙的にグループ化されるため、 その中にあるコンビネータの効果は関数の引数にスコープされます。 例:関数記法構文定義example( foo | bar )example( [ foo | bar ] )と等価です。

2.7. プロパティ値の例

以下は、いくつかのプロパティとそれに対応する値定義欄の例です。

プロパティ 値定義欄 例となる値
orphans <integer> 3
text-align left | right | center | justify center
padding-top <length> | <percentage> 5%
outline-color <color> | invert #fefefe
text-decoration none | underline || overline || line-through || blink overline underline
font-family [ <family-name> | <generic-family> ]# "Gill Sans", Futura, sans-serif
border-width [ <length> | thick | medium | thin ]{1,4} 2px medium 4px
box-shadow [ inset? && <length>{2,4} && <color>? ]# | none 3px 3px rgba(50%, 50%, 50%, 50%), lemonchiffon 0 0 4px inset

2.8. 非終端定義と文法生成ブロック

<position><calc()>のような非終端記号の正確な文法は、しばしばCSS文法生成ブロックで指定されます。 これらは次のような定義が並ぶ整形済みブロックで表現されるのが通例です:

<foo>構文は以下のように定義されます:
<foo> = keyword | <bar> |
        some-really-long-pattern-of-stuff
<bar> = <length>

各定義はそれぞれ独立した行で始まり、 定義される非終端、=、それが展開される値定義の構文の断片からなります。 定義は複数行にまたがることができ、 次の生成規則の開始行またはブロック終端まで続きます(どちらか早い方)。

上記例では、<foo>の定義が2行に及んでいます。 3行目は<bar>の新しい定義を開始します。 (=が値定義の構文で単独で現れることは決してないので、新しい定義開始は明確です。)

3. 値の組み合わせ:補間、加算、累積

例えばトランジションアニメーションなど、いくつかの手続きでは、2つのCSSプロパティ値を組み合わせます。 以下の組み合わせ操作は、2つの算出値VAVBから算出値Vresultを生成します。 可換でない操作(例えば行列の乗算や、異なるtransformリストの累積)では、VAが最初の項、VBが2番目の項となります。

補間(interpolation)
2つのプロパティ値VAVBが与えられたとき、VAVBの間の区間上のpの距離にある中間値Vresultを生成します。p=0の場合はVAp=1の場合はVBとなります。

pの範囲はタイミング関数の影響により(−∞, ∞)です。 このため、この手続きはpが[0, 1]の外側の場合の外挿動作も定義しなければなりません。

加算(addition)
2つのプロパティ値VAVBが与えられたとき、2つのプロパティの合計Vresultを返します。

注: 加算は、多くの場合補間の定義に使われる加重和関数で表現できますが、必ずしもそうとは限りません。 例えば、transform行列の補間は行列要素の分解と補間に基づきますが、加算は行列の乗算に依存します。

値型が加算のための特定の手続きを定義していない場合、あるいは加算不可(not additive)と定義されている場合、 その加算操作は単にVresult=VBとなります。

累積(accumulation)
2つのプロパティ値VAVBが与えられたとき、2つのオペランドを組み合わせ、VBVAからの差分(delta)として扱った結果Vresultを返します。
注: 数値や長さなど多くのアニメーション型では、累積加算と同一に定義されています。

定義が異なる一般的なケースはリスト型で、加算はリストへの追加、累積は要素ごとの加算とされる場合です。 例えば、フィルターリスト値blur(2)blur(3)加算するとblur(2) blur(3)となり、累積するとblur(5)となります。

値型が累積のための特定の手続きを定義していない場合、その累積操作は加算と同一です。

これらの操作は算出値に対してのみ定義されます。 (そのため、例えば<length>15pt5emをどのように加算するかを定義する必要はありません。これらの値は上記手続きに渡される前に正準単位へ解決されるためです。)

3.1. 範囲チェック

補間の結果、すべての入力値が有効であっても、プロパティの有効範囲外の値になることがあります。 これは特にpが[0, 1]の範囲外のときに発生しますが、一部のイージング関数ではこの範囲内でも発生することがあります。 補間・加算・累積の最終結果が、値が使われるターゲット文脈で範囲外になった場合でも、その宣言が無効になることはありません。 その代わり、値はターゲット文脈で許可される範囲にクランプ(制限)されます。これは数式関数§ 10.12 範囲チェック参照)と同様です。

注: 補間の結果が範囲外でも、加算や累積で結果が「修正」されて範囲内に戻る場合があります。 したがって、クランプはすべての補間関連操作の最終結果にのみ適用されます。

4. テキストデータ型

テキストデータ型には、 さまざまなキーワードや識別子、また文字列(<string>)、URL(<url>)などが含まれます。 定義済みキーワードの大文字・小文字や、プロパティごとに明示的に定められていない限り、 正規化処理は行われません(Unicode正規化もされません)。 プロパティの指定値算出値は パース後のUnicode値そのまま(文字セット変換やエスケープを含む)となります。[UNICODE] [CSS-SYNTAX-3]

CSSの識別子(identifier)は、 一般的に<ident>で示され、 <ident-token>文法に準拠した文字の並びです。[CSS-SYNTAX-3] 識別子はクォートできません。 クォートすると文字列として解釈されてしまいます。 CSSプロパティは2種類の識別子を受け入れます:定義済みキーワード著者定義識別子です。

注: <ident>生成規則はプロパティ値定義用ではありません。<custom-ident>を使うべきです。 これは他の構文要素の定義の便宜用です。

すべてのテキストデータ型は補間時に離散的に扱われ、加算不可です。

4.1. 定義済みキーワード

値定義欄では、あらかじめ意味が定義されたキーワードがリテラルで現れます。 キーワードは識別子であり、ASCII大文字小文字無視で解釈されます(すなわち[a-z]と[A-Z]は等価)。

例えば、border-collapseプロパティの値定義は以下の通りです:
Value: collapse | separate

また、使用例は以下の通りです:

table { border-collapse: separate }

4.1.1. CSS全体で使えるキーワード:initialinheritunset

上記の通り、 すべてのプロパティはCSS全体で使えるキーワードを受け入れます。 これらはすべてのCSSプロパティに共通する値計算を表します。 これらのキーワードは CSS カスケードと継承モジュールで規範的に定義されています。

他のCSS仕様でも追加のCSS全体キーワードを定義できます。

4.2. 接頭辞なし著者定義識別子:<custom-ident>

いくつかのプロパティは任意の著者定義識別子を値の一要素として受け入れます。 この汎用データ型は<custom-ident>で表され、 そのプロパティの値定義で定義済みキーワードと誤認されない有効なCSS識別子を表します。 これらの識別子は完全に大文字小文字を区別します("同一性比較"で比較されます)。 すなわち、ASCII範囲でもexampleEXAMPLEは異なる無関係な識別子です。

CSS全体キーワード<custom-ident>としては無効です。 defaultキーワードも予約されており、<custom-ident>として無効です。 <custom-ident>を使う仕様は、 どのキーワードが<custom-ident>として除外されるかを明記する必要があります(例えば、そのプロパティの値定義に現れる定義済みキーワードは全て除外されるなど)。 除外キーワードはすべてASCII大文字・小文字の全パターンで除外されます。

プロパティ値で位置的に曖昧なキーワードをパースする際は、 <custom-ident>生成規則は、 他の未充足の生成規則がそのキーワードを主張できない場合のみ、そのキーワードを主張できます。

例えば、animation: ease-in ease-outというショートハンド宣言は、ロングハンド宣言 animation-timing-function: ease-in; animation-name: ease-out;と等価です。 ease-inanimation-timing-function<easing-function>生成規則が取得し、 ease-outanimation-name<custom-ident>生成規則が取得します。

注: <custom-ident>を使った文法設計では、<custom-ident>が 「位置的に曖昧でない」ようにし、プロパティのキーワード値と衝突しないようにするべきです。 このような衝突は代わりに<dashed-ident>を使うことで回避できます。

4.3. 接頭辞付き著者定義識別子:<dashed-ident>

一部の文脈では、著者定義識別子CSS定義識別子の両方が受け入れられます。 慎重に処理しないと、新しいCSS定義値の追加が困難になり、UAは既存の使用例を調査し、新しい値が十分に使われていないと判断して 新たな意味を与えるかどうか賭けをすることになります。これにより既存ページが壊れるリスクがあります。

CSSにはこの2つの値空間を危うい形で混在させているレガシーケースが多々ありますが、 <dashed-ident>型は、著者定義識別子とCSS定義識別子を簡単に区別できるように設計されています。

<dashed-ident>生成規則は、 <custom-ident>であり、 その大文字小文字区別性も持ちながら、さらに先頭が2つのハイフン(U+002D HYPHEN-MINUS)で始まるという制限があります。

<dashed-ident>は著者定義名のみに予約されており、 CSS自体が<dashed-ident>を独自用途で定義することはありません。

例えば、カスタムプロパティは、CSS定義プロパティと区別できる必要があります。 これを実現するため、カスタムプロパティ名は<dashed-ident>でなければなりません。例:
.foo {
  --fg-color: blue;
}
<dashed-ident>@color-profile規則でも使われ、 著者定義カラープロファイルとdevice-cmykのような定義済みプロファイルを区別し、 将来CSSがさらに多くの定義済み(だが上書き可能な)プロファイルを定義できるようにします。 これにより著者定義プロファイルとの衝突を心配する必要がなくなります:
@color-profile --foo { src: url(https://example.com/foo.icc); }
.foo {
  color: color(--foo 1 0 .5 / .2);
}
CSSは今後より多く<dashed-ident>を活用していく予定です。 より多くの著者制御構文が追加されるからです。 CSSオーサリングツール(カスタム構文を標準CSSに変換するプリプロセッサなど)も、将来のCSS設計との衝突を避けるために必ず<dashed-ident>を使うべきです。

例:CSSプリプロセッサが新しい「カスタム」atルールを追加する場合、 @customと書くべきではありません。これは将来CSSが公式に@custom規則を追加した際に衝突します。 その代わり@--customを使うべきです。これはCSSで定義されるものと絶対に衝突しません。

さらに良いのは@--library1-customのようにすることで、 Library2が自分の「custom」atルール(@--library2-customと記述)を追加しても衝突しません。 理想的には、このプレフィックスはツールで許可されているならカスタマイズ可能にし、 著者が自分で衝突を避けられるようにするべきです。

4.4. クォートされた文字列:<string>

文字列<string>で表されます。 リテラルとして記述する場合は、ダブルクォートまたはシングルクォートで囲まれた文字の並びであり、 これは<string-token>生成規則 (CSS構文モジュール [CSS-SYNTAX-3])に対応します。

ダブルクォート内にダブルクォートを直接書くことはできません。 エスケープが必要です("\""または"\22"のように)。 シングルクォートの場合も同様です('\''または'\27')。
content: "this is a 'string'.";
content: "this is a \"string\".";
content: 'this is a "string".';
content: 'this is a \'string\'.'

文字列は見た目や他の理由で複数行に分割することが可能ですが、その場合は改行自体をバックスラッシュ(\)でエスケープする必要があります。 改行はその後、文字列から削除されます。例えば、以下の2つのセレクターは全く同じ意味になります:

例:

a[title="a not s\
o very long title"] {/*...*/}
a[title="a not so very long title"] {/*...*/}

文字列は直接改行を表現できないため、文字列内で改行を含めたい場合はエスケープ「\A」を使ってください。(16進数AはUnicodeの改行文字(U+000A)ですが、CSSでは「改行」の一般的な意味を表します。)

4.5. リソースロケータ:<url>

<url>型は、 url()src()関数で記述され、 URL(リソースへの参照)を表します。

<url>の構文は次の通りです:

<url> = <url()> | <src()>

<url()> = url( <string> <url-modifier>* ) | <url-token>
<src()> = src( <string> <url-modifier>* )
この例は、URLを背景画像として使う方法を示しています:
body { background: url("http://www.example.com/pinkish.gif") }

レガシーの理由から、url()はURL自体をクォートせずに書くこともでき、その場合は特別なパース<url-token>)が行われます。[CSS-SYNTAX-3] この特別なパース規則のため、url()はリテラルURLしか指定できません。src()はこの規則がないため、var()などの関数によるURL指定も可能です。

例えば、次の宣言は同じ意味です:
background: url("http://www.example.com/pinkish.gif");
background: url(http://www.example.com/pinkish.gif);

また、次の宣言も同じ意味になります:

background: src("http://www.example.com/pinkish.gif");
--foo: "http://www.example.com/pinkish.gif";
background: src(var(--foo));

しかし、これは動作しません

--foo: "http://www.example.com/pinkish.gif";
background: url(var(--foo));

...なぜなら値内のエスケープされていない「(」がパースエラーとなり、宣言全体が無効として破棄されるためです。

クォートなしのurl()構文では <url-modifier>引数は指定できず、追加のエスケープ要件があります。 カッコ、空白、シングルクォート(')、ダブルクォート(")がURL内に現れる場合は バックスラッシュでエスケープする必要があります(例:url(open\(parens)url(close\)parens))。 (クォートされた<string>url()では、 改行およびクォートに使った文字だけエスケープが必要です。) URLの種類によっては、これらの文字をURLエスケープ(例:url(open%28parens)url(close%29parens))として書くこともできます。

クォートなしurl()構文の厳密なパース要件は [CSS-SYNTAX-3]で規範的に定義されています。

一部のCSSコンテキスト(@importなど)では、<url>を関数ラッパーなしの素の<string>で表すこともできます。 その場合、その文字列はurl()関数の中にその文字列が入っているのと全く同じように動作します。

例えば、次の記述は全く同じに動作します:
@import url("base-theme.css");
@import "base-theme.css";

4.5.1. 相対URL

リソースの絶対位置に依存しないモジュール化スタイルシートを作成するには、著者は相対URLを使用すべきです。 相対URL([URL]で定義)は ベースURLを使って完全なURLへと解決されます。RFC 3986の第3節でこのアルゴリズムが規範的に定義されています。 CSSスタイルシートの場合、ベースURLはスタイルシート自体のURLであり、スタイル対象ドキュメントのURLではありません。 ドキュメント内に埋め込まれたスタイルシートは、そのコンテナのベースURLを持ちます。

注: HTMLドキュメントにおいては、 ベースURLは変更可能です。

<url>がプロパティの算出値に現れる場合、 それは前述の通り絶対URLに解決されます。 UAが絶対URLに解決できないURLの算出値は、指定値そのままとなります。

例えば、次のルールがあるとします:
body { background: url("tile.png") }

これが次のURLのスタイルシート内にある場合:

http://www.example.org/style/basic.css

ソースドキュメントの<body>の背景は、次のURLが指し示すリソースの画像でタイルされます:

http://www.example.org/style/tile.png

この画像は、<body>を含むソースドキュメントのURLに関係なく常に同じものが使われます。

4.5.1.1. フラグメントURL

要素ID参照がベースURLの変化やシャドウDOMの有無にかかわらず機能するようにするため、 <url>は、フラグメントのみを含む場合特別な挙動を持ちます。

<url>の値がU+0023 NUMBER SIGN(#)で始まっている場合、 そのURLには追加でローカルURLフラグがセットされ、 URLのフラグメントに対するツリースコープ参照となります。

<url>ローカルURLフラグ付きでマッチさせる場合:

該当要素の検索への参照が必要かもしれませんが、 これはDocument専用であり、 ShadowRootには定義されていません。

注: このようなフラグメントは、現在のドキュメント (またはシャドウDOMの場合はスタイルシートが属するノードツリー)の内容に対して常に解決されます。 これは、base要素によるベースURLの変更や、 リンクされたスタイルシート内の相対URLがスタイルシートのURLを基準に解決されるといった他の解決方法を無視します。

次の例では、#anchorhttp://example.com/に対して解決され、 #imageはHTMLドキュメント自体の要素に対して解決されます:
<!DOCTYPE html>
<base href="http://example.com/">
...
<a href="#anchor" style="background-image: url(#image)">link</a>

シリアライズ時、ローカルURLフラグ付きurl()は フラグメントのみでシリアライズされなければなりません。

4.5.2. 空のURL

<url>の値が空文字列の場合 (url("")url()など)、 そのurlは無効なリソース(about:invalidのようなもの)として解決されなければなりません。

算出値は指定されたurl("")またはsrc("")となり、 シリアライズもその通りになります。

注: これはWebプラットフォーム上の他の埋め込みリソースでの空のurlの挙動と一致します。 また、編集ミスなどでurl()値が空になった場合、不要な再リクエストによるトラフィック増加を防ぎます。 ほぼ確実に無効なリソースとなるためです。 Webプラットフォームのリンク機能では空のurlも許可されていますが、 将来CSSにハイパーリンク制御機能が追加されれば、その場合はこの制約が緩和される可能性があります。

4.5.3. URL修飾子

<url>は 追加の<url-modifier>を指定でき、 これによってURLの意味や解釈が変更されます。 <url-modifier><ident>または関数記法です。

本仕様は<url-modifier>を定義しませんが、他の仕様で定義されることがあります。

注: クォートされていない、またはurl()記法でラップされていない<url>は、<url-modifier>を指定できません。

4.5.4. URL処理モデル

スタイルリソースの取得 urlまたは<url>urlValueから CSSStyleSheet sheetRequestDestinationに一致する文字列destination、 "no-cors"または"cors"のcorsModeresponseとnull・失敗・バイトストリームを受け取るアルゴリズムprocessResponseが与えられたとき:
  1. environmentSettingssheet関連設定オブジェクトとする。

  2. basesheetスタイルシートベースURL(nullでなければ)とし、 そうでなければenvironmentSettingsAPIベースURLとする。[CSSOM]

  3. parsedUrlurlValueurlbaseを使って URLパーサー手順を実行した結果とする。 エラーなら中断。

  4. reqを新しいrequestとする。その urlparsedUrldestinationdestinationmodecorsModeoriginenvironmentSettingsorigincredentials modeは"same-origin"、 use-url-credentials flagはセット、 clientenvironmentSettingsreferrerenvironmentSettingsAPIベースURL

  5. このリクエストに適用されるURLリクエスト修飾ステップを適用する。

    注: 本仕様はURLリクエスト修飾ステップを定義しませんが、他の仕様で定義されることがあります。

  6. reqmodeが"cors"なら、 reqreferrersheetlocationにする。[CSSOM]

  7. sheetorigin-clean flagがセットされていれば、 reqinitiator typeを"css"に設定。[CSSOM]

  8. Fetch reqprocessresponseconsumebodyprocessResponseをセットして実行。

CSSで表現されたURLを解釈する際は、 URLパーサーencoding引数は省略(デフォルトのUTF-8を使用)しなければなりません。 これはスタイルシートのエンコーディングに関係ありません。

注: つまり、CSSで記述されたURLは、スタイルシート自身のエンコーディングに関係なく、常にパーセントエンコードで非ASCIIコードポイントをUTF-8でURLオブジェクトに変換します(したがって、URL値がネットワークリクエストなどに使われる場合は常に同様です)。 この処理はスタイルシートをデコードしてUnicode コードポイントに変換した後で行われることに注意してください。

5. 数値データ型

数値データ型は、量、インデックス、位置、その他の値を表現するために使用されます。 ある数値値の数量(数値的側面)を表現する際には多くの構文上のバリエーションが存在し得ますが、 指定値および算出値はこれらの違いを区別しません。 それらは値の抽象的な数量を表し、構文上の表現方法には依存しません。

数値データ型には、<integer><number><percentage>、 および次元<length><angle><time><frequency><resolution>など)が含まれます。

注: ここでは汎用的な次元を定義していますが、 他のモジュールではより局所的な用途の追加データ型(例:[css-grid-1]で導入されるfr単位)を定義している場合があります。

CSSでの数値値の精度およびサポートされる範囲は実装依存であり、 値が使用されるプロパティやその他の文脈によって異なる場合があります。 しかし、CSS仕様内では無限の精度と範囲を前提としています。 範囲や精度の制限により明示的にサポートできない値の場合、 実装がサポートする最も近い値に変換されなければなりませんが、「最も近い値」の定義もまた実装依存です。

<angle>が実装依存のサポート範囲を超えて変換される必要がある場合は、 サポートされている360degの最も近い倍数にクランプされなければなりません。

5.1. 範囲制限と範囲定義記法

プロパティは数値値の範囲を制限できます。 許可された範囲外の値である場合、特に指定がない限り、 その宣言は無効となり無視されなければなりません。 範囲制限は、数値型記法でCSS角括弧範囲記法[min,max])を使って 角括弧内、識別キーワードの直後に注釈できます。これはminmaxを含む閉区間を示します。 例えば、<integer [0,10]>0から10まで(両端を含む)の整数を示し、 <angle [0,180deg]>0degから180degまで(どの単位でもよい)を示します。

注: CSS値は基本的に開区間(open range)を許可しません。 したがって角括弧記法のみ使用します。

CSSは理論的にはすべての値型で無限の精度と無限の範囲をサポートしていますが、 実際の実装には有限の容量があります。UAは合理的に有用な範囲と精度をサポートすべきです。 理想的には制限しない範囲の端点は、適宜 ∞ や −∞ で示されます。 例:<length [0,∞]>は非負の長さを示します。

角括弧記法やプロパティ記述で範囲が示されていない場合、 [−∞,]が仮定されます。

−∞や∞の値は、単位付きの値型であっても単位なしで記述しなければなりません。 0の値は、単位なしで書いてもよく、 たとえその値型が「単位なしゼロ」を許さない場合(<time>など)でも許可されます。

注: 執筆時点では、 角括弧範囲記法は新しいものです。 そのため多くのCSS仕様では範囲制限は記述的に(文章でのみ)記載されています。 (例えば「負の値は許可されない」や「負の値は無効」といった表現は [0,]範囲を示します。) ただし、これらの記述も同様に拘束力を持ちます。

5.2. 整数:<integer>

整数値は<integer>で表されます。

リテラルで記述する場合、 整数は1つ以上の10進数字0から9で構成され、CSS構文モジュールの<number-token>生成規則の部分集合に対応します。[CSS-SYNTAX-3] 整数の最初の数字の直前には符号を示す-+を付けることができます。

特に指定がない限り、 CSS仕様書上で最も近い整数に丸めるとは、 小数部分がちょうど0.5のときは+∞方向に丸めることを意味します。 (例:1.52に、-1.5-1に丸められます。)

5.2.1. <integer>の計算と組み合わせ

特に指定がない限り、 指定された算出値は指定された抽象整数値となります。

補間は、<integer>について Vresult = round((1 - p) × VA + p × VB)と定義されます。 つまり、補間は実数空間で行われ、結果は最も近い整数に丸められることで <integer>となります。

加算<integer>に対し Vresult = VA + VB

5.3. 実数:<number>

数値値は<number>で表され、 小数部分を持つ実数を表します。

リテラルで記述する場合、 数値整数または 0個以上の10進数字・ピリオド(.)・1個以上の10進数字の並びです。 オプションで「e」または「E」の後に整数を続けて10進指数を示す科学的記法も可能です。 これはCSS構文モジュールの<number-token>生成規則に対応します。[CSS-SYNTAX-3] 整数と同様、数値の最初の文字の直前には-+を付けて符号を示すことができます。

<zero> は値が0のリテラル数値を表します。 <number>で値が0になる式(例:calc(0))は <zero>には一致しません。リテラルな<number-token>のみ一致します。

5.3.1. <number>の計算と組み合わせ

特に指定がない限り、 指定された算出値は指定された抽象的な数値となります。

補間<number>について Vresult = (1 - p) × VA + p × VB

加算<number>に対し Vresult = VA + VB

5.4. 単位付き数値:次元

一般的な用語としての次元は、 単位が付随する数値を指します。 これは<dimension>で表されます。

リテラルで記述する場合、 次元数値の直後に単位識別子(識別子)が続きます。 これはCSS構文モジュールの<dimension-token>生成規則に対応します。[CSS-SYNTAX-3] キーワードと同様、単位識別子もASCII大文字小文字無視です。

CSSは<dimension>を使って 距離(<length>)、 時間(<time>)、 周波数(<frequency>)、 解像度(<resolution>)、 その他の量を指定します。

5.4.1. 互換単位

CSS値のシリアライズ時には、 算出値互換単位(静的な乗算係数で関係付けられる単位。例:pxinの96:1、font-sizeで計算されるempxなど)は すべて単一の正準単位に変換されます。 互換単位の各グループは、どの単位を正準単位としてシリアライズするか決めています。

使用値としてシリアライズされる場合、 長さを表すすべての値型(パーセント、数値、キーワードなど)は長さと互換と見なします。 将来のAPIでも、距離・時間・周波数などを表す値は 関連する次元のクラスと互換とみなして正準化する必要があります。

5.4.2. 次元の組み合わせ

補間互換次元(例:2つの<length>値)で Vresult = (1 - p) × VA + p × VBと定義されます。

加算互換次元に対して Vresult = VA + VB

5.5. パーセンテージ:<percentage>

パーセンテージ値は<percentage>で表され、 何らかの基準値に対する割合を示します。

リテラルで記述する場合、 パーセンテージ数値の直後にパーセント記号%が続きます。 これはCSS構文モジュールの<percentage-token>生成規則に対応します。[CSS-SYNTAX-3]

パーセンテージ値は常に他の量(例えば長さ)に対して相対的です。 パーセンテージを許可する各プロパティは、パーセンテージが参照する量を定義します。 この量は同じ要素の他のプロパティ値や、祖先要素のプロパティ値、 フォーマット文脈の測定値(例:包含ブロックの幅)などであり得ます。

5.5.1. <percentage>の計算と組み合わせ

font-sizeなど、<percentage>値を<length>に算出する場合など) 特に指定がない限り、 パーセンテージの算出値は指定されたパーセンテージです。

補間<percentage>について Vresult = (1 - p) × VA + p × VB

加算<percentage>に対し Vresult = VA + VB

5.6. パーセンテージと次元の混在

<percentage>が同じ次元と 同じ構成値位置で同じ量を表し、 calc()式でそれらを組み合わせられる場合、 プロパティ文法では次の便宜的な記法を使えます:

<length-percentage>

[ <length> | <percentage> ]と等価であり、 <percentage><length>に解決されます。

<frequency-percentage>

[ <frequency> | <percentage> ]と等価であり、 <percentage><frequency>に解決されます。

<angle-percentage>

[ <angle> | <percentage> ]と等価であり、 <percentage><angle>に解決されます。

<time-percentage>

[ <time> | <percentage> ]と等価であり、 <percentage><time>に解決されます。

例えば、widthプロパティは<length>または<percentage>を受け取ることができ、 どちらも距離を表します。 つまり、width: calc(500px + 50%);という記述も 許可されており、両者は絶対長さに変換され加算されます。 含むブロックが1000px幅なら、 width: 50%;width: 500pxと等価、 width: calc(50% + 500px)width: calc(500px + 500px)width: 1000pxと等価になります。

一方、hsl()関数の2番目・3番目の引数は <percentage>のみが許されます。 これらの場所でもcalc()生成規則は許可されますが、 パーセンテージ同士のみを加算でき、 calc(10% + 20%)のようにしか使えません。

注: 仕様は、<percentage>を 互換性のない次元の代わりに文法で交互利用してはなりません。

注: type-percentage型の生成規則は必要に応じて将来追加できます。 <number><percentage>calc()で組み合わせられないため、<number-percentage>は追加されません。

5.6.1. パーセンテージと次元の混合の計算と組み合わせ

パーセンテージ-次元混合の算出値は次のように定義されます:

補間は パーセンテージ-次元値の組み合わせ(例:<length-percentage><frequency-percentage><angle-percentage><time-percentage>など)は

加算<percentage>について 補間と同じですが 各成分を加算します(補間するのではなく)。

5.7. 比率:<ratio>

比率値は<ratio>で表され、 2つの数値の比を表します。 一般的にはアスペクト比(幅と高さの関係)に使われます。

リテラルで記述する場合、 比率の構文は次の通りです:

<ratio> = <number [0,]> [ / <number [0,]> ]?

2つ目の<number>は省略可能で、 省略時は1が既定値となります。 ただし、<ratio>は常に2つの成分でシリアライズされます。

<ratio>の算出値は、与えられた2つの数値のペアです。

<ratio>内のいずれかの数値が0または無限大の場合、 それは異常比率(通常は何も起こらない)を表します。

2つの<ratio>を比較する必要がある場合は、 1つ目の数値を2つ目の数値で割り、その結果を比較します。 例:3/22/1より小さいです(1.5と2の比較)。 (つまり「縦長」アスペクト比は「横長」アスペクト比より小さいと見なされます。)

5.7.1. <ratio>の組み合わせ

<ratio>の補間は、 各<ratio>を1つ目の値÷2つ目の値で数値化し (例:3 / 21.5)、 その結果の対数をとり(例:1.5なら約0.176)、 それらの値を補間します。 補間中の結果は対数を逆算して<ratio>に戻し、 その値を1つ目の値、2つ目を1とみなして新しい<ratio>とします。

いずれかの<ratio>異常比率である場合、補間はできません。

例えば、 5 / 1から3 / 2への線形補間の途中は、 およそ2.73 / 1(約11 / 43 / 1よりやや縦長)の比率です:
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から300 / 200でも同じ)、 「横長」と「縦長」のバリエーションに対して対称性が保たれ (1 / 5から2 / 3でも途中は1 / 2.73程度になる)、 幅固定・高さ固定のどちらでも対称的です。 これらは他の多くの補間法が持たない性質です。

注: 対数の性質により、どの対数でも同じですが (例では常用対数ですが、自然対数でも最終結果は同じ)、 補間途中の値は異なります。

<ratio>の加算はできません。

6. 距離単位: <length>

長さは距離の測定を指し、 プロパティ定義では<length>で表されます。 長さは次元です。

0の長さの場合、単位識別子は省略可能です (すなわち、<number> 0として構文的に表現できます)。 ただし、0<number>または<length>のいずれとしても解釈できる場合 (例えばline-heightなど)、 それは<number>として解釈されなければなりません。

プロパティによっては長さの値をある範囲に制限することがあります。 値が許容範囲外の場合、 その宣言は無効とみなされ、無視されます。

一部のプロパティは負の長さ値を許可していますが、 これにより書式設定が複雑になったり、実装依存の制限がある場合があります。 負の長さ値が許可されているがサポートできない場合、 サポートできる最も近い値に変換されなければなりません。

使用値の長さがサポートできない場合には、 ユーザーエージェントは実際の値で近似しなければなりません。

長さ単位は相対絶対の2種類があります。 長さの指定値指定長さ)は その量と単位で表されます。 長さの算出値算出長さ)は 指定された長さを絶対長さに解決したものであり、 その単位は区別されません: どの絶対長さ単位でも表現できます(ただし正準単位pxでシリアライズされます)。

数値値のサポートされる精度と その精度に合わせてどのように丸められるかは 通常は実装依存ですが、<length>border-widthなど一部のプロパティで 視覚的な表示を合理的にするために特定の方法で丸められます。 (このアルゴリズムは個々のプロパティから明示的に呼び出されます。)

ボーダー幅として長さをスナップするには、<length> lenを与える:
  1. アサート: len は負でない。

  2. lenデバイスピクセルの整数値の場合は、 何もしない。

  3. lenが0より大きく、1 デバイスピクセル未満の場合は、 lenを1 デバイスピクセルに切り上げる。

  4. lenが1 デバイスピクセルより大きい場合は、 最も近い整数のデバイスピクセルに切り下げる。

6.1. 相対長さ

相対長さ単位は他の長さに対する相対的な長さを指定します。 相対単位を使ったスタイルシートは様々な出力環境に容易にスケールできます。

相対単位は以下の通りです:

相対単位の参考サマリー
単位 基準
em 要素のフォントサイズ
ex 要素のフォントのxハイト
cap 要素のフォントのキャップハイト(大文字の名目高さ)
ch 要素のフォントにおける狭いグリフの代表的な進み幅、 “0”(ゼロ、U+0030)グリフで表される
ic 要素のフォントにおける全角グリフの代表的な進み幅、 “水”(CJK水漢字、U+6C34)グリフで表される
rem ルート要素のフォントサイズ
lh 要素の行の高さ
rlh ルート要素の行の高さ
vw ビューポート幅の1%
vh ビューポート高さの1%
vi ルート要素のインライン軸におけるビューポートサイズの1%
vb ルート要素のブロック軸におけるビューポートサイズの1%
vmin ビューポートの小さい方の寸法の1%
vmax ビューポートの大きい方の寸法の1%

子要素は親の指定された相対値を継承せず、 算出値を継承します。

6.1.1. フォント相対長さ:em, rem, ex, rex, cap, rcap, ch, rch, ic, ric, lh, rlh 単位

フォント相対長さは 使用する要素のフォントメトリクス (ローカルフォント相対長さの場合) またはルート要素のフォントメトリクス (ルートフォント相対長さの場合)を参照します。

「Sphinx」という単語にフォント各種メトリクス:アセンダーの高さ(hのセリフ上端)、キャップハイト(Sの上端)、xハイト(xの上端)、ベースライン(S, h, i, n, xの下端)、ディセンダーの高さ(pの下端)を注記した図。
代表的なタイポグラフィのメトリクス
em
使用される要素のfont-sizeプロパティの算出値に等しい。
このルール:
h1 { line-height: 1.2em }

は、h1要素の行の高さが そのh1要素のフォントサイズより20%大きくなることを意味します。 一方:

h1 { font-size: 1.2em }

は、h1要素のフォントサイズが h1要素が継承する算出フォントサイズより20%大きくなることを意味します。

rem
ルート要素のem単位の算出値に等しい。
ex
最初に利用可能なフォントの使用済みxハイトに等しい。xハイトは通常、小文字「x」の高さに等しいためこの名がある。 ただし、exは「x」を含まないフォントにも定義される。 xハイトはフォントごとに異なる方法で取得できる。 一部のフォントには信頼できるxハイトの指標が含まれている。 信頼できるフォントメトリクスが利用できない場合、UAは小文字グリフの高さからxハイトを決定してもよい。 1つの手法は、小文字「o」グリフがベースラインよりどれだけ下に伸びているかを見て、その値を外枠の上端から引くこと。 xハイトを決定できない場合は0.5emとみなす。
rex
ルート要素におけるex単位の値に等しい。
cap
最初に利用可能なフォントの使用済みキャップハイトに等しい。キャップハイトはおおよそ大文字ラテン文字の高さに等しいためこの名がある。 ただし、capはラテン文字を含まないフォントにも定義される。 キャップハイトはフォントごとに異なる方法で取得できる。 一部のフォントには信頼できるキャップハイトの指標が含まれている。 信頼できるフォントメトリクスが利用できない場合、UAは大文字グリフの高さからキャップハイトを決定してもよい。 1つの手法は、大文字「O」グリフがベースラインよりどれだけ下に伸びているかを見て、その値を外枠の上端から引くこと。 キャップハイトを決定できない場合は、そのフォントのアセント値を使用する。
rcap
ルート要素におけるcap単位の値に等しい。
ch
欧文英数字の代表的な進み幅を表す。 使用フォントで“0”(ゼロ、U+0030)グリフの使用済み進み幅で測定される。 (進み幅は、要素のインライン軸におけるグリフの進み幅または高さのいずれか。)

注: この測定値は近似値であり(等幅フォントでは正確)、 1つの狭いグリフの進み幅の目安となる。 これにより想定グリフ数に基づく測定が可能。

注: グリフの進み幅はwriting-modeやtext-orientation、 フォント設定やtext-transform、その他グリフ選択や向きに影響するプロパティにも依存する。

“0”グリフの幅が取得できない場合は0.5em幅・1em高さとみなす。 よってch単位は一般的に0.5em、 立て組みの場合は1emになる (すなわちwriting-modevertical-rlまたはvertical-lrかつtext-orientationupright)。

rch
ルート要素におけるch単位の値に等しい。
ic
CJK文字の代表的な進み幅を表す。 使用フォントで“水”(CJK水漢字、U+6C34)グリフの使用済み進み幅で測定される。

注: この測定値は通常は正確 (プロポーショナル全角グリフを持つフォントでは近似値) であり、単一の全角グリフの進み幅の目安となる。

イデオグラフ進み幅が取得できない場合は1emとみなす。

ric
ルート要素におけるic単位の値に等しい。
lh
使用する要素のline-heightプロパティの算出値に等しい。 normal最初に利用可能なフォントだけのメトリクスを用いて絶対長さに変換される。
rlh
ルート要素におけるlh単位の値に等しい。

注: 要素のheightlhrlh単位で指定しても、 実際の行数を制御できるわけではありません。 これらの単位は理想的な空行の理論サイズに基づく長さ計算だけが可能です。 実際の行ボックスのサイズは内容によって異なります。 実際の行数を制限したい場合はmax-linesプロパティを使うことができます。

font-*プロパティ値で使用される場合、 参照先要素のフォント相対長さは親要素の算出メトリクスを基準に解決されます。 (親がない場合はfontおよびline-heightプロパティの初期値に対応する算出メトリクスを基準にします。) 同様に、 lhrlh単位が line-heightプロパティや font-*プロパティ値で使用される場合も、 親要素の算出line-heightおよびフォントメトリクスを基準に解決されます(親がない場合はfontline-heightプロパティの初期値の算出メトリクスを基準)。 (他のフォント相対長さはline-heightで使用される場合、要素自身のメトリクスを基準に解決され続けます。)

要素以外の文脈 (メディアクエリなど)で使用される場合、 フォント相対長さ単位は fontline-heightプロパティの初期値に対応するメトリクスを基準にします。 また、ルート要素が存在しない文書で指定された場合も、 ルートフォント相対長さfontおよびline-heightプロパティの初期値のメトリクスを想定して解決されます。

注: chicなどのフォント相対単位は、 必要なフォントがまだ読み込まれていない場合フォントのダウンロードを引き起こすことがあります。

フォント相対長さはシェーピングなしで計算されます。

一部のユーザーエージェントは、可読性を高めるために文書内のフォントサイズに追加の制限(最小フォントサイズの設定など)を適用できる場合があります。 こういった制限は影響を受けるプロパティの使用値にのみ適用されなければならず、 フォント相対長さの解決には影響してはなりません。 ただし、他の文脈 (メディアクエリなど)で 使用フォントメトリクスに影響する場合は その解決に影響します。

注: 一般的に、ユーザーの好み(最小フォントサイズなど)を尊重することは望ましいです。 例えば(min-width: 40em)のようなメディアクエリでは 実際に表示されるフォントサイズを使うのが有用です。 しかし、こうした好みが 要素上のプロパティ値内のフォント相対長さに影響するのは Web互換性がありませんでした。 多くのページが、これらの単位が指定font-sizeの正確な倍数になることを想定しているためです。 実際のユーザー設定後の実際のフォントサイズではありません。

一部のユーザーエージェントはフォームコントロールのline-height値に制限を加えることがあります。 これらはlhrlh単位には影響すべきではありません。 ただし子孫への影響は実装依存です。

6.1.2. ビューポート割合長さ:*vw, *vh, *vi, *vb, *vmin, *vmax 単位

ビューポート割合長さは、初期包含ブロックの大きさに対して相対的です。 これは ビューポート(連続メディアの場合) またはページ領域ページメディアの場合)に基づきます。 初期包含ブロックの高さや幅が変わると、それに合わせてスケールされます。

6.1.2.1. ラージ・スモール・ダイナミック ビューポートサイズ

ビューポート割合長さ単位には4つのバリエーションがあり、 3つの(同一の場合もある)ビューポートサイズの概念に対応します。

ラージビューポート
ラージビューポート割合単位lv*) およびデフォルトビューポート割合単位v*) は、ラージビューポートサイズに基づいて定義されます: 動的に展開・格納されるUAインターフェイスがすべて格納された状態のビューポートサイズ。 これにより、著者はUI要素が格納されている状態で確実にページ全体を埋めるコンテンツを配置できますが、 UI要素が展開された場合にはコンテンツが隠れる場合があります。

ラージビューポート割合単位のサイズは ビューポート自体がリサイズされない限り固定(安定)です。

例:スマートフォンでは 画面スペースが限られているため、 ブラウザはページスクロール開始時にタイトルバーやアドレスバーの一部または全部を隠すことがあります。 ラージビューポート割合単位は これらがすべて格納された広い状態のスペースを基準にサイズ決定されるため、 それらUI要素が隠れた時にページ全体を埋めます。 ただし、UI要素が表示されている場合は それら単位でサイズや位置決めされたコンテンツが隠れる場合があります。
スモールビューポート
スモールビューポート割合単位sv*) は、スモールビューポートサイズに基づいて定義されます: 動的に展開・格納されるUAインターフェイスがすべて展開された状態のビューポートサイズ。 これにより、著者はUI要素が表示されている場合でも ビューポート内に収まるコンテンツを配置できますが、 UI要素が格納された場合はページ全体を埋めない場合があります。

スモールビューポート割合単位のサイズは ビューポート自体がリサイズされない限り固定(安定)です。

例えば、height: 100svhとした要素は すべての動的UA UI要素が表示されているときに 画面にぴったり収まります。

これらのUI要素が隠れると、 要素の周りに余白が生じます。 スモールビューポート割合単位は 一般的には「安全」ですが、 ユーザーがページを操作し始めると最適なレイアウトにならない場合もあります。

ダイナミックビューポート
ダイナミックビューポート割合単位dv*) は、ダイナミックビューポートサイズに基づいて定義されます: 動的に展開・格納されるUAインターフェイスの状態を動的に考慮したビューポートサイズ。 これにより、著者はUI要素の有無にかかわらず ちょうどビューポートに収まるコンテンツを配置できます。

ダイナミックビューポート割合単位のサイズは ビューポートが変わらなくても安定しません。 この単位を使うと、ユーザーがページをスクロールするなどした際に コンテンツがリサイズされる場合があります。 用途によってはユーザーの体験を妨げたり、パフォーマンスコストが発生することがあります。

UAはUI要素の展開・格納のアニメーション中、 ダイナミックビューポート割合単位の値を アニメーションせず、完全に展開または格納された状態とみなして単位値を計算してもよい。 (アニメーション中は格納状態を前提とすることが推奨されます。)

特定のUI要素の展開・格納が (A) すべてのビューポート割合長さ(および初期包含ブロック)のサイズを同時に変えるのか、 それとも(B) ラージビューポートサイズスモールビューポートサイズの差分に寄与するのかは 主にUA依存です。 ただし:

すべての場合において、 overflowscrollbar-gutterプロパティが ルート要素のいずれかの軸で 常にスクロールバーが表示される(またはスペースが常時確保される) (例:overflow: scroll、ただしoverflow: autoは除く)場合は、 その軸の算出値におけるビューポート割合長さ初期包含ブロックに応じて減少します。 それ以外の場合、 そして常にメディアクエリの場合は、 ビューポート割合長さは スクロールバーが存在しないものとして (たとえそれが初期包含ブロックと異なっても)サイズ決定されます。

注: overflowプロパティの値がbody要素で設定されている場合、 ルート要素のスクロールバー表示に影響を与えることがあります。 ただし、このことはビューポート単位のサイズには影響しません

6.1.2.2. 様々なビューポート相対単位

ビューポート割合長さ単位は以下の通りです:

vw
svw
lvw
dvw
それぞれラージビューポートサイズスモールビューポートサイズラージビューポートサイズ、 およびダイナミックビューポートサイズ の幅の1%に等しい。
下記の例では、ビューポート幅が200mmの場合、 h1要素のフォントサイズは16mm(すなわち (8×200mm)/100)となります。
h1 { font-size: 8vw }
vh
svh
lvh
dvh
それぞれラージビューポートサイズスモールビューポートサイズラージビューポートサイズ、 およびダイナミックビューポートサイズ の高さの1%に等しい。
vi
svi
lvi
dvi
ボックスのインライン軸において、 それぞれラージビューポートサイズスモールビューポートサイズラージビューポートサイズ、 およびダイナミックビューポートサイズ のサイズの1%に等しい。
vb
svb
lvb
dvb
ボックスのブロック軸において、 初期包含ブロックのそれぞれラージビューポートサイズスモールビューポートサイズラージビューポートサイズ、 およびダイナミックビューポートサイズ のサイズの1%に等しい。
vmin
svmin
lvmin
dvmin
*vw*vh の小さい方に等しい。
vmax
svmax
lvmax
dvmax
*vw*vh の大きい方に等しい。

注: 元々の(プリフィックスなしの)ビューポート単位は 初期包含ブロックに対して定義されていました。 連続メディアの場合、これは常に単一のビューポートサイズと一致します。 ブラウザクロームがスクロール時に動的に出し入れされる仕組みは後から導入され、 Safariに倣って多くのUAがこれらの単位をより大きいサイズにマッピングしました。 この方法は多くの場合見た目が良くなりますが、 重要なコンテンツ(ツールバーやヘッダー、フッターなど)を隠してしまう場合もあります。 そのため、このマッピングが最適だったかは完全には明らかではなく、 以前の仕様書ではUAがこれらデフォルト単位のマッピングを選択できるようにしていました。 しかし現時点ではラージビューポート割合単位へのマッピングが Web互換性のために必須とみなされています。

要素が存在しない場合やまだスタイルが適用されていない場合 (メディアクエリの評価時など)には、 *vi および *vb 単位は writing-modeプロパティの初期値を使って どの軸に対応するかを決定します。

6.2. 絶対長さ:cmmmQinptpcpx 単位

絶対長さ単位は互いに固定の比率で結びついており、 いずれかの物理的な測定値にアンカーされています。 出力環境が既知の場合に主に有用です。 絶対単位は 物理単位incmmmptpcQ) および視角単位(ピクセル単位)px)からなります:

単位 名称 等価
cm センチメートル 1cm = 96px/2.54
mm ミリメートル 1mm = 1cmの1/10
Q 四分の一ミリメートル 1Q = 1cmの1/40
in インチ 1in = 2.54cm = 96px
pc パイカ 1pc = 1inの1/6
pt ポイント 1pt = 1inの1/72
px ピクセル 1px = 1inの1/96
h1 { margin: 0.5in }      /* インチ */
h2 { line-height: 3cm }   /* センチメートル */
h3 { word-spacing: 4mm }  /* ミリメートル */
h3 { letter-spacing: 1Q } /* 四分の一ミリメートル */
h4 { font-size: 12pt }    /* ポイント */
h4 { font-size: 1pc }     /* パイカ */
p  { font-size: 12px }    /* px */

注: 出版分野では 2p3のように 2パイカ3ポイントの長さを表記することがあります。 これはCSSでは calc(2pc + 3pt) と書けます(§ 10.1 基本的な算術: calc()参照)。

すべての絶対長さ単位は互換があり、 px正準単位です。

CSSデバイスでは、これらの寸法はアンカーされます:

  1. 物理単位を物理的な測定値に結びつける、もしくは
  2. ピクセル単位基準ピクセルに結びつける。

印刷メディアで標準的な閲覧距離の場合、 アンカー単位物理単位 (インチ、センチメートル等)であるべきです。 スクリーンメディア(高解像度デバイスを含む)、 低解像度デバイス、 または異常な閲覧距離のデバイスの場合は、 アンカー単位ピクセル単位とすることが推奨されます。 その場合、ピクセル単位デバイスピクセルの整数値に最も近い値になるよう 基準ピクセルに対応させることが推奨されます。

注: アンカー単位ピクセル単位の場合、 物理単位は物理的な測定値と一致しないことがあります。 逆にアンカー単位物理単位の場合、 ピクセル単位デバイスピクセルの整数値に一致しないことがあります。

注: ピクセル単位および物理単位のこの定義は CSS1やCSS2の初期版とは異なります。 特に以前のCSSではピクセル単位物理単位は固定比率ではありませんでした: 物理単位は常に物理測定値に結びつけられ、 ピクセル単位は基準ピクセルに最も近くなるよう可変でした。 (この変更は、96dpiを前提にした既存コンテンツが多く、 それを崩すとコンテンツが壊れるためやむなく導入されたものです。)

注: 単位はASCII大文字小文字を区別しません。 シリアライズ時は小文字になります(例:1Q → 1q)。

基準ピクセルは、 96dpiのデバイスピクセル密度および 腕の長さ(約28インチ)離れた位置での1ピクセルの視角です。 腕の長さが28インチの場合、視角は約0.0213度となります。 腕の長さで読む場合、1pxは約0.26mm(1/96インチ)に相当します。

下の図は、閲覧距離が基準ピクセルのサイズに与える影響を示しています。 読書距離が71cm(28インチ)の場合、基準ピクセルは0.26mm、 3.5m(12フィート)の場合は1.3mmとなります。

この図は、ピクセルの定義が
			ユーザーと表示面(紙やスクリーン)との距離に依存することを示しています。
			画像ではユーザーが2つの平面を見ており、1つはユーザーから28インチ(71cm)、もう1つは140インチ(3.5m)離れています。ユーザーの目から各平面に拡大する円錐が投影されており、最初の平面での投影ピクセルは高さ0.26mm、2番目の平面での投影ピクセルは高さ1.4mm です。
閲覧距離が大きくなるとピクセルも大きくなる必要があることを示す図

2番目の図は、デバイスの解像度がピクセル単位に与える影響を示しています。 1px×1pxの領域は低解像度デバイス(例:一般的なコンピュータディスプレイ)では1つのドットで覆われますが、 同じ領域が高解像度デバイス(例:プリンター)では16個のドットで覆われます。

この図は、基準ピクセルとデバイスピクセル(以下「ドット」と呼ぶ)との関係を示しています。
			画像では左に高解像度(ドット密度が高い)レーザープリンタ出力、右に低解像度モニタ画面を示しています。レーザープリンタでは正方形の基準ピクセルが16個のドットで実現されています。モニタ画面では正方形の基準ピクセルが1つのドットで実現されています。
高解像度デバイスでは同じ1px×1px領域を覆うのにより多くのデバイスピクセル(ドット)が必要になることを示す図 (同じ程度の閲覧距離の場合)

デバイスピクセルは デバイスの出力上でその全色域を表示できる最小単位の面積です。 一般的なカラースクリーンでは、赤・緑・青のサブピクセルを含む正方形またはやや長方形の領域です。 一部の非伝統的な出力デバイスでは、色ごとに高解像度で表示できるなど、この定義が曖昧になる場合がありますが、 それでも「デバイスピクセル」に相当する概念が存在します。

7. その他の量

7.1. 角度単位: <angle> 型と deggradradturn 単位

角度値は<dimension>であり、<angle>で表されます。 角度単位識別子は次の通りです:

deg
度(degree)。1周は360度です。
grad
グラジアン(gradian)、別名「gon」または「grade」。 1周は400グラジアンです。
rad
ラジアン(radian)。1周は2πラジアンです。
turn
ターン(turn)。1周は1turnです。

例えば直角は 90deg100grad0.25turn、または 約1.57rad です。

すべての<angle>単位は互換があり、 deg正準単位です。

慣例として、 CSSで角度が方向を示す場合、 通常はベアリング角として解釈されます。 0degは画面の「上」または「北」を指し、 角度が大きくなるほど時計回りとなります (つまり90degは「右」または「東」)。

例えば、linear-gradient()関数では、 グラデーションの方向を決める<angle>はベアリング角として解釈されます。

注: 互換性のため、 <angle>の一部の用途では、単独の00degを意味することがあります。 しかしこれは一般的には当てはまらず、 今後<angle>型の新たな用途でこのようなことが起こることはありません。

7.2. 継続時間単位: <time> 型と sms 単位

時間値は次元であり、 <time>で表されます。 時間単位識別子は次の通りです:

s
秒(Second)。
ms
ミリ秒(Millisecond)。1秒は1000ミリ秒です。

すべての<time> 単位は互換があり、 s正準単位です。

プロパティによっては時間値をある範囲に制限する場合があります。 値が許容範囲外の場合、 その宣言は無効となり無視されます。

7.3. 周波数単位: <frequency> 型と HzkHz 単位

周波数値は次元であり、 <frequency>で表されます。 周波数単位識別子は次の通りです:

Hz
ヘルツ(Hertz)。1秒あたりの回数を表します。
kHz
キロヘルツ(KiloHertz)。1キロヘルツは1000ヘルツです。

例えば音の高さを表す場合、200Hz(または 200hz)は低音、6kHz(または 6khz)は高音にあたります。

すべての<frequency>単位は互換があり、 hz正準単位です。

注: 単位はASCII大文字小文字を区別しません。 シリアライズ時は小文字になります(例:1Hz → 1hz)。

7.4. 解像度単位: <resolution> 型と dpidpcmdppx 単位

解像度単位は次元であり、 <resolution>で表されます。 解像度単位識別子は次の通りです:

dpi
1インチあたりのドット数(dots per inch)。
dpcm
1センチメートルあたりのドット数(dots per centimeter)。
dppx
x
px単位あたりのドット数。

<resolution>単位は、 CSSのincm、またはpxに どれだけのドットが収まるかを示すことで、 グラフィカル表現における1つの「ドット」の大きさを表現します。 主な用途としては、[MEDIAQ]resolutionメディアクエリや、 image-resolutionプロパティ([CSS3-IMAGES] 定義)があります。

すべての<resolution>単位は互換があり、 dppx正準単位です。

<resolution>値の許容範囲は、 明示的な範囲指定がある場合を除き、常に負の値を除外します。

CSSのinpxの1:96固定比により、1dppx96dpiと等価であることに注意してください。 これはCSSで画像を表示する際のデフォルト解像度に対応します。 詳細はimage-resolutionを参照。

次の@mediaルールはMedia Queries [MEDIAQ]を利用し、 CSSのpx単位あたり2つ以上のデバイスピクセルを使うデバイスに 特別なスタイルを割り当てています:
@media (min-resolution: 2dppx) { ... }

8. 他で定義されているデータ型

一部のデータ型は、それぞれ専用のモジュールで定義されています。 ここでは、複数の仕様でよく使われる代表的なものを紹介します。

8.1. 色: <color>

<color>データ型は [CSS-COLOR-4] で定義されています。 UAは<color>を そこで定められている通りに解釈しなければなりません。

8.1.1. <color>の合成

補間<color>に対して CSS Color 4 § 12. Color Interpolationで定義されています。 補間はプリマルチプライドされた色同士で行われます(CSS Color 4 § 12.3 アルファ付き補間参照)。

<color>型は加法ではありません

注: CSS WGではユースケースを募集しており、 将来的に<color>型を加法可能にすることも検討しています。

8.2. 画像: <image>

<image>データ型は[CSS3-IMAGES]で定義されています。 UAがCSS Images Level 3またはその後継仕様をサポートする場合は <image>をその仕様通りに解釈しなければなりません。 まだCSS Images Level 3をサポートしていないUAは <image><url>として解釈しなければなりません。

8.2.1. <image>の合成

注: <image>の補間は CSS Images 3 § 6 Interpolationで定義されています。

画像は加法ではありません

8.3. 2次元位置指定: <position>

<position>値は、 配置領域(例:背景画像)を 配置対象領域(例:背景配置領域)内でどこに置くかを指定します。 これはbackground-positionと同じ方法で算出・解釈されます。[CSS3-BACKGROUND]

<position> = [
  [ left | center | right | top | bottom | <length-percentage> ]
|
  [ left | center | right ] && [ top | center | bottom ]
|
  [ left | center | right | <length-percentage> ]
  [ top | center | bottom | <length-percentage> ]
|
  [ [ left | right ] <length-percentage> ] &&
  [ [ top | bottom ] <length-percentage> ]
]

注: background-positionプロパティは3値構文も受け入れます。 これは他の長さやパーセンテージ成分と組み合わさった場合に構文上の曖昧さを生じるため、 一般的には禁止されています。

8.3.1. <position>の構文解析

他のキーワード、<length><percentage>などと 文法内で並んで指定された場合、<position>グリーディーに構文解析されます。 可能な限り多くの構成要素を消費します。

例えば、transform-originは事実上 <position> <length>?として 3D座標を定義しています。 left 50pxのような値は、z成分が省略された2値の<position>として構文解析されます。 一方、top 50pxのような値は 1値の<position>の後ろに<length>が続く形で解析されます。

8.3.2. <position>のシリアライズ

指定値<position>をシリアライズする際:

1つだけ指定されている場合:
  • 暗黙のcenterキーワードが追加され、 2要素値としてシリアライズされます。

2つ指定されている場合:
  • キーワードはキーワードとしてシリアライズされます。

  • <length-percentage><length-percentage>としてシリアライズされます。

  • 要素は水平方向→垂直方向の順でシリアライズされます。

4つ指定されている場合:
  • キーワードとオフセットの両方がシリアライズされます。

  • 要素は水平方向→垂直方向の順でシリアライズされます。

注: <position>値は 決して1つだけの値としてシリアライズされません。 単一値で同じ挙動になる場合でも、 <position>の隣に<length>が来るなど、 一部の文法で構文上の曖昧さを避けるためです (例:transform-origin)。

注: 算出値は 常に2つのオフセット(キーワードなし)としてシリアライズされます。 算出値では構文上の区別が保存されないためです。

8.3.3. <position>の合成

補間<position>に対して 各要素(x, y)ごとに独立して、 左上隅からのオフセットとして正規化された <length-percentage>で補間されます。

加算も同様に、 <position>の 各要素(x, y)ごとに独立して、 左上隅からのオフセットとして正規化された <length-percentage>で加算されます。

9. 関数記法

関数記法とは、 より複雑な型を表現したり、特別な処理を呼び出したりできる コンポーネント値の一種です。 構文は、関数名の直後に左丸括弧 (すなわち<function-token>) を書き、その後に関数の引数を書き、最後に右丸括弧で閉じます。 キーワード同様、関数名はASCII大小区別しません空白は丸括弧内部の直後にあっても良いですが、省略可能です。 関数は複数の引数を取ることができ、引数はCSSプロパティ値と同様の書式で記述します。 詳細は§ 2.6 関数記法の定義を参照してください。

注: 関数記法の中には、rgba()のように、不要なカンマを使っているレガシーなものもありますが、 通常カンマはリスト内の項目や、そうでなければ曖昧になる文法部分の区切りにだけ使われます。 引数を区切るためにカンマを使う場合、カンマの前後の空白はあってもなくても構いません。

background: url(http://www.example.org/image);
color: rgb(100, 200, 50 );
content: counter(list-item) ". ";
width: calc(50% - 2em);

数式関数はこの下で定義されています。 その他の関数記法は それぞれのモジュールで定義されています。 例えば<color>関数は [CSS-COLOR-4][CSS-COLOR-5]で定義されています。

10. 数式表現

数式関数calc()clamp()sin()など、この章で定義されているもの)は CSS数値値を数式として記述できるようにします。

数式関数は数値値を表し、 次のいずれかです:

...または<length-percentage>などの混合型であり、 そのような値が有効となる箇所で使うことができます。

10.1. 基本算術:calc()

calc()関数は、 加算(+)、減算(-)、乗算(*)、除算(/)、および丸括弧を使って 数値値に対して基本的な算術演算を行う数式関数です。

calc()関数は1つの計算式を含みます。 これは値と演算子が並んだ並びであり、必要に応じて丸括弧でグループ化され (<calc-sum>文法に一致)、 通常の演算子の優先順位ルール (*/+-より優先し、 それ以外は左から右に評価)で式を評価した結果を表します。 calc()関数は 内部の計算式の結果を表します。

計算式の構成要素は (例:5pxのような)リテラル値、 他の数式関数、 あるいはvar()など、 有効な引数型(<length>など)に評価される他の式も使えます。

数式関数は 異なる単位を組み合わせて値を計算するのに使えます。 この例では、各section要素のマージンボックスが スペースの1/3を占めるようにしたいので 100%/3を基準にし、 そこから要素のボーダーやマージン分を差し引いています。 (ボーダーやパディングはbox-sizingで自動化できますが、 マージン込みで計算したい場合は数式関数が必要です。)

section {
  float: left;
  margin: 1em; border: solid 1px;
  width: calc(100% / 3 - 2 * 1em - 2 * 1px);
}

同様に、この例ではグラデーションは要素の最初と最後20pxだけで色が変化します:

.fade {
  background-image: linear-gradient(silver 0%, white 20px,
                                    white calc(100% - 20px), silver 100%);
}

数式関数は 値をより自然で読みやすい形で表現したい時にも便利です。 例えば次の例では、font-sizeを ちょうど35emがビューポートに収まるように設定し、 画面サイズが変わってもテキスト量が常にほぼ一定になるようにしています。

:root {
  font-size: calc(100vw / 35);
}

機能的にはfont-size: 2.857vwと同じですが、 35emでビューポートを埋めるという意図が コードを読む人にとって格段に分かりやすくなります。 後から読む人は2.857が100/35を近似していることを自分で逆算しなければなりません。

演算子の優先順位は標準的な数学のルールと同じです:calc(2 + 3 * 4)14 であり、20ではありません。

優先順位を操作したい場合は丸括弧を使います:calc((2 + 3) * 4)20です。

丸括弧と追加のcalc()のネストは等価です。 先程の式はcalc(calc(2 + 3) * 4)とも書けます。 これはvar()で値を段階的に組み立てる場合などに便利です:

.aspect-ratio-box {
  --ar: calc(16 / 9);
  --w: calc(100% / 3);
  --h: calc(var(--w) / var(--ar));
  width: var(--w);
  height: var(--h);
}

--arは単に--ar: (16 / 9);と書くこともできますが、 --wは単独(widthに使用)でも --h用のcalc()成分としても使うので、 フルのcalc()関数として書く必要があります。

10.2. 比較関数:min()max()clamp()

min()max()clamp()の比較関数は 複数の計算式を比較し、 そのうち1つの値を表します。

min()またはmax()関数は 1つ以上のカンマ区切りの計算式を持ち、 それぞれ最も小さい値(最も負)または最も大きい値(最も正)を表します。

clamp()関数は 3つの計算式(最小値・中央値・最大値)を取り、 中央値に最小値・最大値によるclampを適用したものを表します。 最小値・最大値が矛盾した場合は最小値を優先します。 (すなわちclamp(MIN, VAL, MAX)max(MIN, min(VAL, MAX))と同じ意味です。)

最小値・最大値のいずれか(または両方)に キーワードnoneを指定することもでき、 その側からのclampをしないことを示します。 (clamp(MIN, VAL, none)max(MIN, VAL)clamp(none, VAL, MAX)min(VAL, MAX)clamp(none, VAL, none)は単にcalc(VAL)と同じ意味です。)

これら3関数のすべてで、 引数の計算式<number><dimension><percentage>のいずれにもなれますが、 型の一貫性がとれていないと無効になります。 結果値の型はその一貫した型となります。

min()max()clamp() を使うことで、値が「安全な」範囲を超えないようにできます。 例えばビューポート単位でfont-sizeを設定する「レスポンシブタイプ」でも 可読性を保つための最小サイズを設けたい場合:

.type {
  /* font-sizeをvwとvhの平均の10倍にするが、12px未満にはしない */
  font-size: max(10 * (1vw + 1vh) / 2, 12px);
}

注: それぞれの引数には完全な数式が書けます。 calc()をネストする必要はありません! また、複数の制約を同時に適用したい場合は2つ以上の引数を与えることもできます。

min()/max()使用時の混乱点として、 max()は最小値の制約に使い (つまりmin-widthなどは実質的にmax()を利用)、 min()は最大値の制約に用いる、という点があります。 逆にmin()で最小値を設定しようとしてしまいがちです。 clamp() を使うと、値が最小・最大の間に収まることが直感的に書けます:
.type {
  /* font-sizeを12px~100pxの範囲に制限 */
  font-size: clamp(12px, 10 * (1vw + 1vh) / 2, 100px);
}

最小値だけ制約し、あとは自由に大きくしたい場合:

.type {
  /* font-sizeを最低12pxに制限 */
  font-size: clamp(12px, 10 * (1vw + 1vh) / 2, none);
}
clamp()は CSSの他の慣習と同様、 最小値と最大値が逆になる場合は最小値が「勝つ」ことに注意してください。 つまりclamp(100px, ..., 50px)100pxになり、 指定された「最大値」を超えることになります。

異なる解決方法を使いたい場合は clamp()min()max()を組み合わせて書けます:

MAXがMINより優先されるようにするには:

clamp(min(MIN, MAX), VAL, MAX)。 MAXの計算を繰り返したくない場合は、 clamp()のネスト順を逆にして min(MAX, max(MIN, VAL))と書くこともできます。

MINとMAXの順序がおかしい場合に「入れ替える」には:

clamp(min(MIN, MAX), VAL, max(MIN, MAX))。 残念ながら、MINとMAXを繰り返さずにこれを実現する簡単な方法はありません。

10.3. ステップ値関数: round()mod()rem()

ステップ値関数であるround()mod()rem()は、 いずれも与えられた値を 別の「ステップ値」に従って 異なる方法で変換します。

round(<rounding-strategy>?, A, B?)関数は 丸め戦略を省略可能で指定し、 2つの計算式 A, B を受け取り、 Aの値を、丸め戦略に従って、 Aの上または下のBの整数倍のいずれか最も近い値に丸めて返します。 引数の計算式<number><dimension><percentage>のいずれにもなれますが、 型の一貫性がとれていない場合は無効となります。 結果の型は一貫した型となります。

AがBの整数倍とちょうど等しい場合、round()はAそのものを返します (Aが0⁻か0⁺かも保持します)。 そうでない場合、Aに最も近いBの整数倍であるlower B(−∞側に近い)と upper B(+∞側に近い)の2つがあります。 次の<rounding-strategy>が そのどちらを選ぶかを決定します:

nearest

lower Bupper Bのいずれか、Aとの絶対差が小さい方を選びます。 両者の差が等しい場合 (Aが2つの値のちょうど中間の場合)、 upper Bを選びます。

up

upper Bを選びます。

down

lower Bを選びます。

to-zero

lower Bupper Bのうち、0との絶対差が小さい方を選びます。

lower Bがゼロの場合は0⁺、 upper Bがゼロの場合は0⁻とします。

<rounding-strategy>を省略した場合、 デフォルトはnearestです。 (いわゆる四捨五入。) Aの<number>と一致する場合は Bを省略でき、その場合はデフォルトで1となります。 それ以外でBを省略するのは無効です。

CSSOMはどのように丸めるか明記する必要があり、 CSS関数もデフォルトで同じ丸めを行うべきでしょう。 どの挙動がよいでしょうか? [Issue #5689]

JavaScriptのような言語は 自然な「精度」(整数)で丸めますが、 CSS値にはそのような精度がありません (多様な互換単位で書けるため)。 そのため、精度は明示的に与える必要があります。 例えば幅を50px単位で丸めたい場合は round(var(--width), 50px)と書きます。

注: JavaScript等のプログラミング言語では 丸め戦略ごとに丸め関数を分けている場合があります。 JSのMath.floor()はCSSのround(down, ...)と同等です。 JSのMath.ceil()はCSSのround(up, ...)と同等です。 JSのMath.trunc()はCSSのround(to-zero, ...)と同等です。 JSのMath.round()はCSSのround(nearest, ...)または単にround(...)と同等です。

注: <rounding-strategy>のキーワードは block-step-sizeのキーワードと同じで、挙動も同じです。 (block-step-sizeにはto-zeroはありません; blockサイズは常に非負なので、to-zerodownは同じ意味になります。)

剰余関数であるmod(A, B)およびrem(A, B)も同様に2つの計算式 A, B を受け取り、 AからAの上下どちらかに最も近いBの整数倍を引いた差を返します。 引数の計算式<number><dimension><percentage>のいずれにもなれますが、 同じでなければ無効です。 結果も引数と同じになります。

この2つの関数は非常に似ていますが、 両方の引数が正または負の場合は同じ結果になります: 関数の値はAからBの整数倍だけずらした値で ゼロ以上B未満の範囲内に収まります。 (具体的には、範囲はゼロを含みBを含みません。 さらに、Bが正なら0⁺から、Bが負なら0⁻から始まります。)

例えばmod(18px, 5px)3pxになります。 18pxから5px*3を引くと3pxとなり、 これは0px3pxの間に収まる唯一の値です。

同様にmod(-140deg, -90deg)-50degになり、 -140deg-90deg*1を加えると-50degになり、 これは0deg-90degの間に収まる唯一の値です。

これらの例をrem()で計算してもまったく同じ結果になります。

AとBが異符号の場合は挙動が異なります。 mod()(modulusの略)は 上記と同様に「ゼロ以上B未満」の範囲に結果を持ってきます (結果は必ずゼロかBと同じ符号でAと同じ符号にはなりません)。 一方rem()(remainderの略)は 「ゼロ以上−B未満」の範囲に結果を持ってきて値の符号を変えません。

例えばmod(-18px, 5px)2pxになります。 -18px5px*4を加えると2pxとなり、 これは0px5pxの間です。

一方、rem(-18px, 5px)-3pxになります。 -18px5px*3を加えると-3pxとなり、 これは-18pxと同じ符号かつ0px-5pxの間です。

同様にmod(140deg, -90deg)-40degになります(140deg-90deg*2を加えて0deg-90degの間)、 しかしrem(140deg, -90deg)50degになります。

どちらを使うべきか、mod()rem()

通常この操作を使うユーザーは ステップ値(B)をコントロールし、 不明な値Aを修正する場合が多いです。 そのため、通常はAの符号に関係なく 結果が0からBの間になることが期待されるので、 mod()を選ぶべきです。

例えば長さが偶数ピクセルか奇数ピクセルか知りたい場合、 mod(A, 2px)はAが整数ピクセルなら0pxまたは1px を返します(Aの値が正負どちらでも)。 一方rem(A, 2px)はAが偶数ピクセルなら0px、 奇数ならAの符号に応じて1pxまたは-1pxを返します。

逆の状況もまれにありますので、 rem()も用意されています。 また、rem()はJavaScriptの%演算子と同じ挙動なので、 CSSとJSで完全に一致させたい場合はrem()が便利です。

注: mod()rem()は他の関数による定義も可能です: mod(A, B)calc(A - sign(B)*round(down, A*sign(B), B))と等価です (Bが正ならround(down)、負ならround(up)とするためのトリック)、 rem(A, B)calc(A - round(to-zero, A, B))と等価です。 (ただしこれらの式は0⁺と0⁻の扱いが常に正しいとは限りません—0⁻の意味は加算に対して可換ではないためです。)

10.3.1. 引数の範囲

round(A, B)で Bが0の場合、結果はNaNです。 AとBがともに無限大の場合も、結果はNaNです。

Aが無限大、Bが有限の場合は 結果は同じ無限大になります。

Aが有限、Bが無限大の場合、 結果は<rounding-strategy>およびAの符号によって異なります:

nearest
to-zero

Aが正または0⁺なら0⁺を返します。 それ以外は0⁻を返します。

up

Aが正(ゼロでない)なら+∞を返します。 Aが0⁺なら0⁺を返します。 それ以外は0⁻を返します。

down

Aが負(ゼロでない)なら−∞を返します。 Aが0⁻なら0⁻を返します。 それ以外は0⁺を返します。

mod(A, B)rem(A, B)で Bが0の場合、結果はNaNです。 Aが無限大の場合もNaNです。

mod(A, B)のみの場合、 Bが無限大かつAとBが逆符号 (ゼロの符号も含む)の場合はNaNです。

注: その他の「無限大B」の場合は有効で、 単にAをそのまま返します。

10.4. 三角関数:sin()cos()tan()asin()acos()atan()atan2()

三角関数—sin()cos()tan()asin()acos()atan()atan2()は 各種基本的な三角関係を計算します。

sin(A)cos(A)tan(A)関数は いずれも1つの計算式を受け取り、 それは<number> もしくは<angle>でなければなりません。 引数をラジアンとみなして対応する三角関数を計算します。 (sin(45deg)sin(.125turn)sin(3.14159 / 4)はいずれも約.707で同じ値になります。) 戻り値は<number>で、 戻り値の型は入力計算式の型と一貫性を持たせますsin()cos()は常に−1〜1の範囲の数を返し、 tan()は−∞〜+∞のいずれの数も返します。 (§ 10.9 型チェック数式関数の∞処理詳細あり。)

asin(A)acos(A)atan(A)関数は 「arc」または「逆」三角関数であり、 対応する通常の三角関数の逆関数を表します。 どれも1つの計算式を受け取り、 それは<number>でなければなりません。 計算結果をラジアン数とみなし <angle>を表します。戻り値の型は入力計算式の型と一貫性を持たせますasin()の角度は[-90deg, 90deg]に、 acos()の角度は[0deg, 180deg]に、 atan()の角度は[-90deg, 90deg]に正規化されます。

atan2(A, B)関数は 2つのカンマ区切り計算式 A, B を受け取ります。 A, Bは<number><dimension><percentage>のいずれにもなれますが、 型の一貫性がとれていない場合は無効です。 この関数は正のX軸と点(B,A)のなす<angle>を返します。 戻り値の型は入力計算式の型と一貫性を持たせます。 返される角度は(-180deg, 180deg]の範囲(-180degより大きく180deg以下)に正規化されます。

注: atan2(Y, X)一般的にはatan(Y / X)と同じですが、 対象点が負成分を含む場合はより正確な値を返します。 atan2(1, -1)(点(-1, 1))は135degを返し、 atan2(-1, 1)(点(1, -1))は-45degを返します。 一方、atan(1 / -1)atan(-1 / 1)はいずれも -45degとなります(内部計算がどちらも-1になるため)。

10.4.1. 引数の範囲

sin(A)cos(A)tan(A)で Aが無限大の場合、結果はNaNです。 (§ 10.9 型チェック数式関数のNaN処理詳細あり。)

sin(A)tan(A)で Aが0⁻の場合、結果は0⁻です。

tan(A)でAが漸近値(90deg270degなど)の場合、 数値結果は実装依存です。 実装がこれらの入力を正確に表現できる場合は できるだけ 90deg + N*360degで+∞を、 -90deg + N*360degで−∞を返すべきですが、 実装が正確に表現できない場合は 実装可能な最も近い近似値として最も適切な数値結果を返します。 著者はtan()がこれら入力で特定の値を返すことに依存してはなりません

なぜこれらが実装依存なのか?

タンジェント関数は漸近値で不連続だからです。 一方からは無限大に、他方からは負の無限大に発散し、 ちょうど漸近値の点では定義されません。

また、漸近値が実装で正確に表現できるかは 内部でどのように角度を格納・扱うかに依存します。 度数法なら単純(90deg等)ですが、 ラジアンでは超越数(pi / 2等)となり厳密には表現できません。 したがって特定の挙動を定義するのも難しいです。 内部的にラジアンを使う実装は 入力が漸近値に十分近い場合に定義値を返すための曖昧マッチが必要です。

Webの他の主要言語であるJavaScriptも これら関数はラジアンのみ受け付けるので 漸近値を正確には扱えません (他の多くの言語も同様)。 JSで書いたコードでも特定の挙動は期待できませんし、 CSSでも同様のはずです。

漸近値を正確に表現できる実装向けの推奨挙動は atan()との往復変換を維持するためです。 tan(atan(X))atan(tan(X))はいずれも あらゆるXに対して(近似的に)Xを返します。 これによりatan()の出力範囲内で関数が連続になります。

asin(A)acos(A)で Aが-1未満または1より大きい場合、結果はNaNです。

acos(A)で Aがちょうど1の場合、結果は0です。

asin(A)atan(A)で Aが0⁻の場合、結果は0⁻です。

atan(A)で Aが+∞なら結果は90deg、 −∞なら-90degです。

atan2(Y, X)では、 すべての特殊な引数の組み合わせに対して下表の通りです:

X
−∞ -有限 0⁻ 0⁺ +有限 +∞
Y −∞ -135deg -90deg -90deg -90deg -90deg -45deg
-有限 -180deg (通常) -90deg -90deg (通常) 0⁻deg
0⁻ -180deg -180deg -180deg 0⁻deg 0⁻deg 0⁻deg
0⁺ 180deg 180deg 180deg 0⁺deg 0⁺deg 0⁺deg
+有限 180deg (通常) 90deg 90deg (通常) 0⁺deg
+∞ 135deg 90deg 90deg 90deg 90deg 45deg

注: これらの挙動は ほとんどのプログラミング言語の「標準的」定義に合わせており、 とくにJSの実装と一致することを意図しています。

10.5. 指数関数: pow()sqrt()hypot()log()exp()

指数関数—pow()sqrt()hypot()log()exp()—は、それぞれの引数で様々な指数演算を行います。

pow(A, B)関数は 2つのカンマ区切りの計算式 A, B を受け取り、 両方とも<number>でなければならず、 AをB乗した結果を返します。 戻り値は<number>です。 入力の計算式型の一貫性が取れていなければ無効になり、 結果の型は一貫した型となります。

sqrt(A)関数は 1つの計算式を受け取り、 それは<number>でなければなりません。 値の平方根を返します。 戻り値は<number>であり、型は入力計算式の型と一貫性を持たせます。 (sqrt(X)pow(X, .5)はほぼ同じですが、 エラー処理が一部異なります。sqrt()はよく使われるため便宜上用意されています。)

hypot(A, …)関数は 1つ以上のカンマ区切り計算式を受け取り、 各計算式を成分とするN次元ベクトルの長さを返します。 (つまり、引数の2乗和の平方根です。) 引数計算式<number><dimension><percentage>のいずれにもなれますが、 型の一貫性が取れていなければ無効です。 結果の型は一貫した型となります。

なぜhypot()は次元(単位付き値)を許容するのに、pow()sqrt()は数値だけなのか?

hypot(30px, 40px)のような表現は許され、 50pxとなりますが、 sqrt(pow(30px, 2) + pow(40px, 2))のような表現はできません。 両者は数学的には等価ですが。

理由は2つあります: 指数の数値精度と、著者の期待値の不一致です。

まず数値精度について。 CSS生成物<length>など)に 合致するには、単一単位で指数が正確に1でなければなりません。 理論上はpow(pow(30px, 3), 1/3)のような式は それを実現するはずです。 内側のpow(30px, 3)は値27000および«[ "length" → 3 ]» (すなわち<length>³) となり、pow(X, 1/3)で値を立方根にし指数も1/3倍し、 «[ "length" → 1 ]»となるので<length>合致します。

純粋数学の世界ではこれで必ず一致しますが、 実際のコンピュータのバイナリ浮動小数点演算では べき乗がぴったり相殺されず 理由不明な無効関数になる場合もあります。 (JSの例では Math.pow(Math.pow(30, 10/3), .1+.1+.1) はちょうど30にならず、 .1+.1+.1が厳密に3/10ではないためです。 (10/3) * (.1 + .1 + .1)わずかに1より大きい。)

著者が値をいったん数値に変換し、すべての計算を生の数値で行い、最後に希望する単位に戻すことを求めるのは不便に思えるかもしれませんが、これにより数値精度の問題で誰も困らないことが保証されます。例えば、calc(pow(pow(30px / 1px, 3), 1/3) * 1px) は必ず<length>型として解決されますし、値が厳密に30でなくても、少なくとも非常に30に近くなります。これは、たとえ数値精度のせいで累乗計算が完全に打ち消し合わない場合でも同様です。

次に期待値の不一致について。 pow(30px, 2)900pxになる(このSassのissueのように)と期待する著者もいますが、 これは単に数値を2乗して単位をそのまま残すという意味です。 しかしそうすると、入力の単位によって値が変わるので 例えば1em16pxなら pow(1em, 2)1empow(16px, 2)256px16emと 入力は同じでも結果は大きく異なります! CSSでは値を正準化するのが一般的なので こうした単位依存は問題ですし、 pow(2em + 10px, 2)のような複雑な式の解釈も困難です。

したがって値を一旦数値に落として演算し、単位に戻すようにすれば こうした問題を回避できます。 pow(30, 2)は確かに900であり、 著者が望むように解釈できます。


一方でhypot()にはこの問題がありません。 単位内で数値精度が問題にならず、 入出力の型が全て同じです。 またこの演算の性質上、単位依存にもなりません。 hypot(3em, 4em)hypot(48px, 64px)1em=16pxなら 5emまたは80pxとなります。 したがってhypot()では単位付き値を直接使っても問題ありません。

log(A, B?)関数は 1つまたは2つの計算式(対数化する値とその底。省略時はe)を受け取り、 どちらも<number>でなければなりません。 戻り値はAのB底対数であり、 <number>型で戻され、型は入力計算式の型と一貫性を持たせます。

exp(A)関数は 1つの計算式<number>でなければならない)を受け取り、 pow(e, A)と同じ値を返します。 戻り値は<number>型で、型は入力計算式の型と一貫性を持たせます。

pow()関数は、CSS Modular Scaleのように ページ内の全てのフォントサイズを一定比率で関連付ける設計に役立ちます。

こうしたサイズはカスタムプロパティで簡単に記述できます:

: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.0625remcalc(1rem * pow(1.5, 4))の結果)を直接書くよりも スタイルシート上で由来が明確になります。

引数が1つの場合、hypot()は絶対値を返します。 hypot(2em)hypot(-2em)2emとなります。

複数引数の場合は 各辺の長さが引数の値である直方体の対角線の長さを返します。 これはtransform系で便利で、 要素を特定のX,Y,Zだけ移動したとき実際に移動する距離を計算できます。

例えばhypot(30px, 40px)50pxとなり、 translate(30px, 40px)で移動したときの始点と終点の距離になります。 離れるほど小さくなるようにしたい場合 (例:ワードクラウド描画など)この距離をスケーリング計算に使えます。

引数1つのlog()は 「自然対数」(底eの対数)を返します(JSと同じ)。

底10の対数(桁数カウント等)や底2の対数(ビット数カウント等)が欲しい場合は log(X, 10)log(X, 2)を使います。

10.5.1. 引数の範囲

pow(A, B)で、 Aが負かつ有限、Bも有限なら Bは整数でなければならず、そうでない場合は結果はNaNです。

AまたはBが無限大または0の場合は 以下の表の通りです:

Aが−∞ Aが0⁻ Aが0⁺ Aが+∞
Bが−有限 Bが奇数整数: 0⁻、それ以外: 0⁺ Bが奇数整数: −∞、それ以外: +∞ +∞ 0⁺
Bが0 常に1
Bが+有限 Bが奇数整数: −∞、それ以外: +∞ Bが奇数整数: 0⁻、それ以外: 0⁺ 0⁺ +∞
A < -1 A = -1 -1 < A < 1 A = 1 A > 1
Bが+∞ 結果は+∞ 結果はNaN 結果は0⁺ 結果はNaN 結果は+∞
Bが−∞ 結果は0⁺ 結果はNaN 結果は+∞ 結果はNaN 結果は0⁺

sqrt(A)で Aが+∞なら結果は+∞。 Aが0⁻なら結果は0⁻。 Aが0未満なら結果はNaN。

hypot(A, …)で 入力のいずれかが無限大なら結果は+∞。

log(A, B)で Bが1または負なら結果はNaN。 Bが0より大きく1未満、または1より大きい場合は有効。 Aが負なら結果はNaN。 Aが0⁺または0⁻なら結果は−∞。 Aが1なら結果は0⁺。 Aが+∞なら結果は+∞。

exp(A)で Aが+∞なら結果は+∞。 Aが−∞なら結果は0⁺。

§ 10.9 型チェック数式関数のNaNや無限大の扱い詳細あり。)

これらの挙動は ほとんどのプログラミング言語の「標準的」定義に合わせており、 特にJS実装と一致することを意図しています。

JSの同等関数との唯一の違いは あらゆる関数でNaNが「伝染性」になる点です。 すなわち、いずれかの引数計算がNaNなら必ずNaNを返します。

JSの挙動の詳細

JSではNaNが関数内で「伝染性」でない場合が2つあります:

  • Math.hypot(Infinity, NaN)Infinityを返します。

  • Math.pow(NaN, 0)1を返します。

どんなNumberでNaNを置換しても戻り値は同じ、というロジックですが、 この論理はMath関数に一貫して適用されていません: Math.max(Infinity, NaN)NaN(Infinityではない)を返します。 Math.min(-Infinity, NaN) も同様です。

これはエラー隅のケースであり、 JSが一貫していないため CSSでは一貫性を重視して すべての関数でNaNを「伝染性」と定義しました。

10.6. 符号関連関数: abs()sign()

符号関連関数—abs()sign()—は、引数の符号に関する各種関数を計算します。

abs(A)関数は 1つの計算式 A を受け取り、 Aの絶対値を返します。 戻り値は入力と同じです。 Aの数値が正または0⁺ならAそのもの、 それ以外は-1 * Aです。

sign(A)関数は 1つの計算式 A を受け取り、 Aの数値が負なら−1、正なら+1、0⁺なら0⁺、0⁻なら0⁻を返します。 戻り値の型は<number>で、入力計算式の型と一貫性を持たせます。

注: これらの関数はいずれも 引数の完全に単純化/解決済みの値で動作します。 そのため一見直感に反する結果になる場合があります。 例えば10%は 解決先によって正にも負にもなり得ます。 例:background-positionでは 背景画像がエリアより大きい場合 正のパーセンテージは負の長さに、 逆も同様です。 したがってsign(10%)は 解決方法によって1にも-1にもなります! (またはゼロ長さに対して解決されれば0にもなります。)

10.7. 数値キーワード

計算式内のキーワードは リテラルで表現しにくい値へのアクセスを提供します。 各キーワードは値・・解決タイミングを定めます。

10.7.1. 数値定数: epi

三角関数・指数関数で多くの複雑な数値演算はできますが、 いくつかの計算は手作業で組み立てる必要があり、 その際よく使われる定数(eπなど)があります。

著者がこれらの定数の桁を手入力しなくてもいいように、 いくつかは直接キーワードとして提供されています:

e

自然対数の底。約2.7182818284590452354。

pi

円周率。約3.1415926535897932。

これらのキーワードはどちらも<number>であり、 パース時に解決されます。

注: これらのキーワードは計算式内でのみ使用可能です。 例:calc(pow(e, pi) - pi)min(pi, 5, e)など。 計算式外では他のキーワード同様扱われます: animation-name: pi;は"pi"というアニメーションを指し、 line-height: e;は無効です (line-height: 2.7のようにはならず、 line-height: calc(e);は有効)。

10.7.2. 特殊数値定数: infinity-infinityNaN

計算式またはその部分木が無限大NaNになった場合、 数値で表現できなくなります。 こうした特殊値のシリアライズを容易にするため、 以下の追加定数が定義されています:

infinity

正の無限大(+∞)

-infinity

負の無限大(−∞)

NaN

NaN(非数)

これらはすべて<number>であり、 パース時に解決されます。

CSSキーワードの通常のルール通り、 これらはASCII大文字小文字を区別しませんつまりcalc(InFiNiTy)も有効です。ただしNaNはこの正準表記でシリアライズされる必要があります。

注: これらのキーワードも<number>なので、 例えば無限大の長さが必要な場合は calc(infinity * 1px)のような式が必要です。

注: これらの定数は主に 無限大やNaN値のシリアライズを簡単・明示的にするために定義されていますが、 最大値の意味で使うこともできます。 これはまれですが、必要な場合は infinityの方が 非常に大きな数字を書くより意図が明確です。

10.7.3. 数値変数

他の仕様で、特定の文脈で計算式内で使える追加キーワードを定義できます。 例:相対色構文では 各カラーチャンネルの値を<number>として表すカラーチャンネルキーワードが定義されています。

このようなキーワードを定義する仕様は 各キーワードごとに次を定義しなければなりません:

10.8. 構文

数式関数の構文は以下の通りです:

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

いくつかの文脈では、追加の<calc-keyword>値が有効として定義されることがあります。 (例えば相対色構文では、適切なチャンネルキーワードが許可されます。)

さらに、空白+および -演算子の両側に必要です。 (*および/演算子はその前後に空白なしで使うことができます。)

上記のいくつかの数式関数には、<calc-sum>引数に含められる内容に追加の制約があります。 詳細は各関数の定義を参照してください。

UAは少なくとも32個の計算式<calc-value>項、 および少なくとも32階層の入れ子(括弧や関数)をサポートしなければなりません。 任意個数の引数を受け付ける関数(例:min())についても、少なくとも32個の引数をサポートしなければなりません。 計算式がサポート数を超える項・引数・入れ子を持つ場合は無効として扱わなければなりません。

10.9. 型チェック

数式関数は様々な型を持ち得ます。 例えば<length><number>など、 含まれる計算式によって決まります(下記参照)。 その型が許される任意の場所で使用できます。

例えば widthプロパティは<length>型を受け付けるため、 数式関数<length>に解決されるもの (例:calc(5px + 1em))はwidthで使用できます。

また、数式関数<number>に解決される場合、 <integer>しか受け付けない箇所でも使えます。 このとき値は解決時に最も近い整数に丸められます。

演算子は引数に基づき部分式を形成し、それぞれ型を持ちます。

注: 以前の仕様では 乗算・除算がとれる引数を制限していました。 これは(1px * 1emのような<length>²などの)複雑な中間型の生成や 0除算の構文時検出を避けるためでしたが、 本仕様ではこれらの制約を緩和しています。

計算式calculationの型を決定するには:
値がパーセンテージを含むのは、そのが«[ "percent" → 1 ]»の場合、 または型のpercent hintがnullでない場合。
2つ以上の計算式が一貫した型を持つとは、型を加算したとき失敗にならないときです。 一貫した型はその加算結果です。
baseを別の型input一貫させるには:
  1. 両方のbaseinputが異なる非nullpercent hintを持つ場合、 一貫化できません。 失敗を返します。

  2. basepercent hintがnullであれば、basepercent hintinputpercent hintで上書きします。

  3. baseを返します。

数式関数自身も 内部の計算式に従ってを持ちます:

calc()
abs()

内部計算式の型。

min()
max()
clamp()
hypot()
round()
mod()
rem()

カンマ区切りの計算式の型を加算した結果。

asin()
acos()
atan()
atan2()

«[ "angle" → 1 ]»。

sign()
sin()
cos()
tan()
pow()
sqrt()
log()
exp()

«[ ]»(空マップ)。

上記のいずれかでが失敗の場合、 数式関数は無効です。

数式関数は、 そのがどの生成物に一致するかに応じて、 <number><length><angle><time><frequency><resolution><flex><percentage>のいずれかに解決されます。 (これらのカテゴリは相互に排他的です。) いずれにも一致しない場合、 数式関数は無効です。

注: 代数的な単純化は数式関数の有効性や型には影響しません。 例えばcalc(5px - 5px + 10s)calc(0 * 5px + 10s)は 長さと時間の加算となるため無効です。

注: <percentage><number>に対して相対的な場合 (例:opacityなど)は これらの数値と合成不可です。opacity: calc(.25 + 25%)は無効です。 これを許すと「単位の代数」処理に深刻な問題が生じ (<dimension>の乗除を許すなど)、 これまでの事例でも新規機能を提供しないためです。 (例:opacity: 25%opacity: .25は同じ意味であり、単なる構文変換です。) ただし、opacity: calc(100% / 3);のような他の演算は有効です。

注: <number-token>は常に<number>または<integer>と解釈されるため、 「単位なし0」の<length>数式関数内でサポートされません。 つまり、width: calc(0 + 5px);<number><length>の加算となるため無効です。 (ただしwidth: 0;width: 5px;は有効です。)

注: <number>が使用値時に<length>になるプロパティが少数存在します (特にline-heighttab-size)。 しかし<number>calc()内で「長さ的」になることはありません。 常に<number>のままです。

注: Quirks Mode [QUIRKS]では、 通常は<length>しか受け付けないプロパティが <number>も受け付けるようになり、これをpx長さとして解釈します。 単位なしゼロと同様、 これは数式関数の構文解析や挙動には影響しませんが、 数式関数<number>に解決される場合、 Quirks Modeでは有効となり、その結果がpx長さとして解釈されることがあります。

10.9.1. 無限大・NaN・符号付きゼロ

数式関数はIEEE-754セマンティクスに従い、 正・負ゼロ、正・負無限大、NaN(非数)を認識します。

ただし、これらの概念は計算式ツリー内でのみ保持されます。 トップレベル計算式 (他の数式関数に直接ネストされていない数式関数) がこれらの特殊値になる場合、下記の通り「検閲」され標準的な表現値に変換されます。

符号付きゼロ(ここでは0⁺または0⁻で示す)は CSSで直接記述できません。0+0-0はいずれも通常の「符号なし」ゼロとなり、 これらのルールでは正(0⁺)とみなされます。

符号付きゼロは次のように生成されます:

符号付きゼロトップレベル計算式からは抜け出せません。最終的に「符号なし」ゼロに変換されます。

無限大 (ここでは+∞または−∞で示す)は 数式定数infinity-infinityで直接書くこともできますし、 計算結果としても発生します:

注: 以下のNaN生成規則は 無限大生成規則より優先されます。

無限大トップレベル計算式からは抜け出せません。 文脈で許される最小または最大値にクランプされます(§ 10.12 範囲チェック参照)。

NaN(非数, "not a number"の略)は 値の定義ができない特定の演算結果です。 数式定数NaNで直接記述したり、 計算結果としても発生します:

NaNトップレベル計算式からは抜け出せません。 ゼロ値に変換されます。

例えばcalc(-5 * 0)は符号なしゼロになります。 計算式としては0⁻に解決されますが、トップレベル計算式なので 最終的に符号なしゼロに検閲されます。

一方、calc(1 / calc(-5 * 0))は−∞、 calc(1 / (-5 * 0))も−∞を返します。 内側のcalcは0⁻になり、トップレベルでないのでそのまま外側calcに渡され、−∞になります。 もし検閲されて符号なしゼロになっていたら、代わりに+∞になったでしょう。

10.10. 内部表現

内部表現としての数式関数は、計算ツリーです。 このツリーでは、分岐ノードは 演算子ノード であり、 数式関数(Min、Cos、Sqrtなど)や、 計算式の演算子(Sum、Product、Negate、Invert、これを calc-operatorノードと呼ぶ)に対応します。 葉ノードは、数値(数、寸法、パーセンテージなど)または数値型に解決される非数式関数です。

数式関数は関数ごとに 計算ツリーに変換されます:

calc()

内部表現は、引数をcalc()関数の 計算式の構文解析結果です。

その他の数式関数

その関数名と一致するoperatorノードとなります。 子ノードは各引数を計算式として構文解析したものとなり、順番は引数の順です。

計算式の構文解析を行うには、 計算式 valuescomponent valueのリスト)を受け取り、 計算ツリーを返す:
  1. valuesから<whitespace-token>をすべて除去する。

  2. values内の項目が「operator」かどうかを判定する。 それが<delim-token>かつ値が"+", "-", "*", "/"のいずれかならoperator。 それ以外は「値」とする。

  3. Productノード・Invertノードを子としてまとめる。

    values内の値項目を、"*"または"/"で区切られた連続部分ごとに:

    1. その部分内の各"/"演算子について、 右側の値rhsをInvertノードで包む。

    2. その部分全体をProductノードに置き換え、 その子として値項目を並べる。

  4. Sumノード・Negateノードを子としてまとめる。

    1. values内の各"-"演算子について、 右側の値rhsをNegateノードで包む。

    2. valuesが1つだけになり、それがProductノードまたは括弧付きsimple blockなら、その項目に置き換える。

      そうでなければ、values全体をSumノードに置き換え、その子に値項目を並べる。

  5. ここでvaluesはSum, Product, Negate, Invertノードからなるツリー。 葉ノードを処理する。

    全ての葉ノードleafについて:

    1. leafが括弧付きsimple blockなら、 その中身を再帰的に計算式として構文解析する。

    2. leaf数式関数なら、 その内部表現に置き換える。

  6. values計算ツリーの単純化に渡して返す。

10.10.1. 単純化

内部表現としての数式関数は、可能な限り積極的に単純化されます。 標準的な代数的単純化(乗算の分配、同単位の合成など)を用います。

@font-face記述子など)プロパティ以外の文脈では、 数式関数指定値として単純化されます。

計算ツリーの単純化 rootを行うには:
  1. rootが数値の場合:

    1. rootが他の値に対して解決されるパーセンテージで、十分な情報があるなら解決して 適切な正準単位で表現し、値を返す。

    2. rootが正準単位でない寸法で、十分な情報があれば正準単位に変換して返す。

    3. rootが解決可能な<calc-keyword>なら、解決して単純化して返す。

    4. それ以外はrootをそのまま返す。

  2. 他の葉ノード(演算子ノード以外)の場合:

    1. 十分な情報があれば数値値で返し、値は正準単位で表現する。

    2. それ以外はrootを返す。

  3. ここでrootoperatorノードである。 計算式の子全てを単純化する。

  4. rootoperatorノードで、calc-operatorノードでない場合で、 全ての子が十分な情報を持つ数値であり、演算が実行できるなら、 子の値で演算を行い、結果を正準単位で返す。

    この時点でパーセンテージが残っている場合、通常そのノードの単純化はブロックされます。 これは他の値への解決に追加情報が必要なためです。 (それ以外なら前の段階で他の値へ変換されているはずです。) これには"min"のような演算も含みます。 パーセンテージが負の基準値で解決される場合、結果が直感と逆になることがあるためです。

    ただし、opacityのように、他の値に解決されない「生の」パーセンテージは 単純化を妨げない場合もあります。

  5. rootがMinまたはMaxノードの場合、部分的な単純化を試みる:

    1. 全ての子ノードchildについて: childが他の同一単位の子と比較できる数値であれば、それら全てをまとめて演算し childを結果に置き換え、他の該当子を削除する。

    2. もしrootが1つだけ子を持つなら、それを返す。 そうでなければrootを返す。

  6. rootがNegateノードの場合:

    1. 子が数値なら、その値を反転(0 - value)した値で返す。

    2. 子がNegateノードなら、その子の子を返す。

    3. rootを返す。

  7. rootがInvertノードの場合:

    1. 子が数値(パーセンテージや寸法でない)なら、その値の逆数を返す。

    2. 子がInvertノードなら、その子の子を返す。

    3. rootを返す。

  8. rootがSumノードの場合:

    1. Sumノードの子のうちSumノードは、その子に展開する。

    2. 同じ単位の数値の子が複数あれば合計して1つの値にまとめ、他の該当子を消す。

      (例:数値、パーセンテージ、px値などを合算)

    3. この時点で子が1つだけならそれを返す。そうでなければrootを返す。

    注: ゼロ値はSumから単純に除去できず、同単位同士でのみ合算できます。 (単位があるゼロ値が振る舞い変化を伴う場合があるため。)

  9. rootがProductノードの場合:

    1. Productノードの子のうちProductノードは、その子に展開する。

    2. 複数の数値の子(パーセンテージや寸法でない)があれば、積をとって1つの数値にまとめる。

    3. 2つの子で、1つが数値でもう1つがSumノード(全子が数値)なら、Sumの全子に数値を掛けてSumとして返す。

    4. 全ての子が数値やInvertノード(中身は数値)で、 子の型を乗算して いずれかの有効型に合致するなら、 子の値の積を計算(Invertノードは逆数)し、 結果を正準単位で返す。

    5. rootを返す。

10.11. 算出値

算出値としての数式関数は、その計算ツリー単純化したものです。 ここでは算出値時点で得られるすべての情報を使います。 (例:emからpxへの変換比、プロパティによるパーセンテージの解決方法など。)

パーセンテージが算出値時点で解決されない場合、 数式関数でも解決されません。 例:calc(100% - 100% + 1px)calc(0% + 1px)となり、 1pxにはなりません。 値内でパーセンテージの算出特別規則がある場合 (例:heightプロパティ)は、 数式関数内のパーセンテージにも適用されます。

計算ツリー使用値時にも再度単純化され、 使用値時の情報により 数式関数は必ず単一の数値にまで簡約されます。

例えば font-sizeはパーセンテージを算出値時に解決して フォント相対長単位を計算しますが、 background-positionは レイアウト依存のパーセンテージ動作となり、使用値時まで解決されません。

このため、background-positionの計算では calc()内のパーセンテージが保持されるのに対し、 font-sizeでは直接長さとして計算されます。

テーブルのセルやテーブル要素の幅・高さ計算の複雑さにより、 パーセンテージとゼロでない長さを混ぜた数式(幅・高さ)を テーブルカラム、カラムグループ、行、行グループ、セルにauto・fixedレイアウト両方で使う場合、 auto指定とみなさなければなりません。

10.12. 範囲チェック

数式関数内では構文解析時の範囲チェックは行われないため、 範囲外値も宣言を無効にはしません。 ただし、トップレベル計算式の計算結果は 対象文脈で許される範囲にクランプされなければなりません。 クランプは算出値で可能な限り行い、 それでも不十分な場合は使用値でクランプします。 (指定値にはクランプしません。)

注: calc()を受け付けるすべての文脈で、許容値は必ず閉区間で定義されていなければなりません。

注: 定義上、±∞はどのプロパティの許容範囲外であり、最小/最大値にクランプされます。 無限大をキーワード値として明示的に指定できるプロパティ (例:animation-iteration-count)でも ±∞は最終的にクランプされます。 数式関数はキーワード値には解決されないため、 プロパティの数値部分はやはり最小/最大値を持ちます。

さらに、数式関数<number>に解決されるものを<integer>しか受け付けない場所で使った場合、 算出値使用値は 上記クランプと同様に最も近い整数に丸められます。

widthが0px未満は不可なので、次の3つの宣言は等価です:
width: calc(5px - 10px);
width: calc(-5px);
width: 0px;

ただしwidth: -5pxwidth: calc(-5px)とは等価になりません! calc()の外側で範囲外値になると構文的に無効となり、 宣言全体が破棄されます。

10.13. シリアライズ

このセクションはまだ議論中です。

数式関数のシリアライズ fn を行うには:
  1. もし計算ツリー fn のルートが 数値(数値・パーセンテージ・寸法)の場合で、 かつ算出値以上のシリアライズであれば 文脈の許容範囲にクランプし(必要なら)、 通常通りシリアライズして返す。

  2. もしfnが無限大またはNaN値の場合:

    1. s文字列 "calc(" で初期化。

    2. キーワードinfinity-infinityNaN のうち適切なものをシリアライズし、 sに追加。

    3. fnが «[ ]» 以外(空、<number>を表す)なら、 s に " * " を追加。 fnの型の正準単位(例:pxなど)で値1の数値を作成し、 シリアライズしてsに追加。

    4. sを返す。

  3. もし計算ツリーのルートノードが数値またはcalc-operatorノードの場合、 sを "calc(" で初期化する。

    それ以外の場合は ルートノード名の小文字("sin"や"max"など)+ "(" でsを初期化する。

  4. ルートノードの各子について計算ツリーのシリアライズを行う。 結果が "(" で始まり ")" で終わる場合はその括弧を外す。 全ての結果を", "(カンマとスペース)で連結し、sに追加。

  5. sに")"を追加。

  6. sを返す。

計算ツリーのシリアライズを行うには:
  1. root計算ツリーのルートノードとする。

  2. もしrootが数値または非数式関数なら、 通常の規則でシリアライズして返す。

  3. もしrootがSum, Negate, Product, Invertノード以外なら、 対応する関数名で数式関数のシリアライズを行い、 子ノードはコンマ区切り計算式引数として扱い、結果を返す。

  4. もしrootがNegateノードなら、 sを "(-1 * " で初期化。

    子をシリアライズし、sに追加。

    ")"をsに追加し、返す。

  5. もしrootがInvertノードなら sを "(1 / " で初期化。

    子をシリアライズし、sに追加。

    ")"をsに追加し、返す。

  6. もしrootがSumノードなら、 sを"("で初期化。

    子をソート

    最初の子をシリアライズし、sに追加。

    2番目以降の子について:

    1. Negateノードなら " - " をsに追加し、その子をシリアライズして追加。

    2. 負の数値なら " - " を追加し、符号反転した値を通常通りシリアライズして追加。

    3. それ以外は " + " を追加し、子をシリアライズして追加。

    最後に")"をsに追加して返す。

  7. もしrootがProductノードなら、 sを"("で初期化。

    子をソート

    最初の子をシリアライズし、sに追加。

    2番目以降の子について:

    1. Invertノードなら " / " をsに追加し、その子をシリアライズして追加。

    2. それ以外は " * " を追加し、子をシリアライズして追加。

    最後に")"をsに追加して返す。

計算式の子ソート nodes を行うには:
  1. ret を空リストで初期化。

  2. nodesに数値があれば、nodesから除去しretに追加。

  3. nodesにパーセンテージがあれば、除去してretに追加。

  4. nodesに寸法値があれば、除去し単位でASCII大文字・小文字区別せずにソートしてretに追加。

  5. nodesに他に項目があれば、元の順でretに追加。

  6. retを返す。

例:calc(20px + 30px)は 指定値としてはcalc(50px)、算出値としては50pxとシリアライズされます。

calc(20px + 0%)のような値はcalc(0% + 20px)とシリアライズされ、 両方の項が保持されます。 (ゼロ値の項を維持することで、calc() がトランジション中に突然「形が変わる」ことを防ぎます。 またゼロのときどの単位を選ぶか悩まなくても済みます。)

calc(20px + 2em)のような値は、指定値ではcalc(2em + 20px)とシリアライズされ (単位が互換でないため両方保持し、アルファベット順でソート)、 算出値では52pxなどになります (em値は算出値時に絶対長に換算されるため、 例えば1em=16pxなら合算して52pxとなり、その場合calc()ラッパーは消えます)。

プロパティ以外の文脈 (例:@font-face記述子など)で使われる場合、数式関数指定値として単純化されます。

シリアライズの詳細は[CSSOM]を参照。

10.14. 数式関数の合成

補間としての数式関数の合成は、 他の数値や数値関数との場合も含めて Vresult = calc((1 - p) * VA + p * VB) で定義されます。 (単純化によってより短く・簡単な式になることがあります。)

加算としての数式関数の合成も、 他の数値や数値関数との場合も含めて Vresult = calc(VA + VB) で定義されます。 (単純化によってより短く・簡単な式になることがあります。)

付録A: リスト値プロパティの連携

リスト値プロパティの中には、連動する効果を持つものがあります。 それぞれの値リストの項目が個々の効果に適用され、 各プロパティの同順位の項目は同じ効果を指します。 しばしば、連動する値はリスト値のショートハンドプロパティで まとめて指定することもできます。

代表的な例がリスト値background-*プロパティで、 複数の背景画像レイヤーを指定できます。 各プロパティで画像のサイズ・タイル・配置等を制御する場合、 そのリストのN番目の項がN番目の背景画像に適用されます。

連携リストプロパティグループ連結値リストを生成します。 各項目ごとにグループ中の全プロパティから値を集め、 それらをまとめて1つの効果(例:背景画像レイヤーやアニメーション)として使います。 連結値リストは次のように組み立てられます:

付録B: IANA考慮事項

about:invalid URLスキームの登録

このセクションはabout:invalid URLを定義・登録します。 [RFC6694]で定義された登録手続きに従っています。

この登録の公式記録は http://www.iana.org/assignments/about-uri-tokens/about-uri-tokens.xhtml で確認できます。

登録トークン invalid
用途 about:invalid URLは 汎用的なエラー状態を示す存在しないドキュメントを指します。 URLが必要だが、既存のドキュメントに解決されてはいけない場合に使います。
連絡先/管理者 CSS WG <www-style@w3.org> (W3Cを代表して)
仕様 CSS Values and Units Module Level 3

付録C: クワーキーレングス

CSSがクワークスモードでパースされているとき、<quirky-length>は、特定のプロパティでのみ有効な<length>型の一種です:

これは、これらのプロパティを含む、または参照するプロパティ(例:backgroundのショートハンドや 関数記法(例:calc())の内部など)では有効ではありません。 ただし、rect()関数がclipプロパティ内で使われる場合は例外です。

また、<quirky-length><length>として @supportsルール内で該当プロパティをパースする際は有効でなければなりませんが、 CSS.supports() メソッドで使う場合はそのプロパティに対して有効ではありません

<quirky-length>は、構文的には<number-token>と同一であり、 同じ値のpx長さとして解釈されます。

(つまり、Quirks Modeでは該当プロパティのすべてのpx長さを単位なしで記述でき、単位なしゼロ長さと同様の扱いになります。)

謝辞

まず最初に、編集者は前レベルのモジュールへのすべての貢献者に感謝します。

次に、Level 4の改善に寄与したコメントや提案をくださった Anthony Frehner, Emilio Cobos Álvarez, Koji Ishii, Noam Rosenthal, Xidorn Quan 各氏にも謝意を表します。

変更点

最近の変更

(これはLevel 3以降の追加点のサブセットです。)

2023年12月18日WD以降の主な変更:

2023年10月27日WD以降の主な変更:

2023年4月6日WD以降の主な変更:

2022年10月19日WD以降の主な変更:

2021年12月16日WD以降の主な変更:

2021年10月16日WD以降の主な変更:

2021年7月15日WD以降の主な変更:

2020年11月11日WD以降の主な変更:

Level 3以降の追加点

CSS Values and Units Level 3以降の変更:

CSS Values and Units Level 3以降の追加:

セキュリティに関する考慮事項

本仕様は新たなセキュリティ上の考慮事項を提示しません。

本仕様はurl()およびsrc()関数(<url>)を定義しており、 CSSからネットワークリクエストを可能にします。 どの機能で使われるかによって、 ユーザーがネットワーク上のリソースにアクセスできるかどうかが露呈したり、 その内容(スタイルシート内のルール、画像サイズ、フォントのメトリクスなど)が露呈する可能性があります。 また、URL経由でデータを持ち出すことも可能です。

プライバシーに関する考慮事項

本仕様はユーザーの画面サイズ(ビューポートパーセンテージ長さ)、デフォルトフォントサイズ、 そしてユーザーのシステムにどのフォントがあるかなど一部の情報(フォント相対長さ)を 露呈する単位を定義します。

本仕様はurl()およびsrc()関数(<url>)を定義しており、 CSSからネットワークリクエストを可能にします。 どの機能で使われるかによって、 ユーザーがネットワーク上のリソースにアクセスできるかどうかが露呈したり、 その内容(スタイルシート内のルール、画像サイズ、フォントのメトリクスなど)が露呈する可能性があります。 また、URL経由でデータを持ち出すことも可能です。

適合性

文書の規約

適合性要件は、記述的な断定とRFC 2119用語の組み合わせで表現されます。規範的部分で使われる “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”、“OPTIONAL” などのキーワードはRFC 2119に従って解釈されます。ただし、読みやすさのため、本仕様ではこれらの単語をすべて大文字で表記しません。

本仕様のすべての文章は、明示的に非規範的・例・注として記載されたセクションを除き、規範的です。[RFC2119]

本仕様の例は「for example」で始まるか、class="example" のクラスで規範文から区分されます。例えば:

これは説明用の例です。

説明用の注は “Note” で始まり、class="note" で規範文から区分されます。例えば:

Note, これは説明用の注です。

アドバイスメントは特別な注意を促す規範的なセクションであり、<strong class="advisement"> で他の規範文と区別されます。例えば: UAはアクセシブルな代替手段を提供しなければなりません。

適合クラス

本仕様への適合性は、以下の3つの適合クラスについて定義されます:

style sheet
CSSスタイルシート
renderer
UA(ユーザーエージェント)。スタイルシートの意味を解釈し、それを利用する文書をレンダリングします。
authoring tool
UA(ユーザーエージェント)。スタイルシートを生成します。

スタイルシートは、当該モジュールで定義された構文を使うすべての文が、汎用CSS文法および各機能ごとの個別文法に従って有効であれば、この仕様に適合します。

レンダラーは、対応する仕様で定義されたスタイルシートの解釈に加え、本仕様で定義されたすべての機能を正しくパースし文書を適切にレンダリングすることで、本仕様に適合します。ただし、デバイスの制約によりUAが文書を正しくレンダリングできない場合でも、UAが非適合とはなりません(例えば、UAはモノクロモニターで色を表示する必要はありません)。

オーサリングツールは、汎用CSS文法および本モジュール内の各機能ごとの個別文法に従い構文的に正しいスタイルシートを書き、かつ本モジュールで記述されたスタイルシートのすべての他の適合要件を満たす場合、本仕様に適合します。

部分的な実装

著者が前方互換のパース規則を活用してフォールバック値を割り当てられるように、CSSレンダラーは、利用可能なサポートレベルがないat-ルール、プロパティ、プロパティ値、キーワード、その他の構文要素を無効として扱い(そして適切に無視)なければなりません。特に、ユーザーエージェントは、サポートされていない値を無視し、サポートされている値だけを単一の複数値プロパティ宣言で尊重してはなりません。いずれかの値が無効(サポート外値でなければならない)とみなされた場合、CSSは宣言全体を無視することを要求します。

不安定機能・独自拡張の実装

将来の安定したCSS機能との競合を避けるため、CSSWGはベストプラクティスの遵守を推奨します。不安定な機能やunstable機能、独自拡張の実装について。

非実験的な実装

仕様がCandidate Recommendation段階に達した場合、非実験的な実装が可能になり、実装者は仕様に従い正しく実装されていることを示せるCRレベルの機能については、接頭辞なしでリリースすべきです。

CSSの実装間での相互運用性を確立・維持するため、CSSワーキンググループは、非実験的なCSSレンダラーが、未接頭辞の実装リリース前に実装報告書(必要に応じてそのテストケースも)をW3Cに提出することを求めます。W3Cに提出されたテストケースはCSSワーキンググループによるレビュー・修正の対象となります。

テストケースや実装レポートの提出方法については、CSSワーキンググループのウェブサイト https://www.w3.org/Style/CSS/Test/ をご覧ください。質問は public-css-testsuite@w3.org メーリングリストまで。

索引

本仕様で定義されている用語

参照によって定義される用語

参考文献

規範的参考文献

[CSS-2023]
Chris Lilley 他. CSS Snapshot 2023.2023年12月7日.NOTE.URL: https://www.w3.org/TR/css-2023/
[CSS-BOX-4]
Elika Etemad.CSS Box Model Module Level 4.2022年11月3日.WD.URL: https://www.w3.org/TR/css-box-4/
[CSS-CASCADE-5]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr..CSS Cascading and Inheritance Level 5.2022年1月13日.CR.URL: https://www.w3.org/TR/css-cascade-5/
[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley; Lea Verou.CSS Color Module Level 4.2022年11月1日.CR.URL: https://www.w3.org/TR/css-color-4/
[CSS-COLOR-5]
Chris Lilley 他.CSS Color Module Level 5.2022年6月28日.WD.URL: https://www.w3.org/TR/css-color-5/
[CSS-CONDITIONAL-3]
David Baron; Elika Etemad; Chris Lilley.CSS Conditional Rules Module Level 3.2022年1月13日.CR.URL: https://www.w3.org/TR/css-conditional-3/
[CSS-COUNTER-STYLES-3]
Tab Atkins Jr..CSS Counter Styles Level 3.2021年7月27日.CR.URL: https://www.w3.org/TR/css-counter-styles-3/
[CSS-DISPLAY-3]
Elika Etemad; Tab Atkins Jr..CSS Display Module Level 3.2023年3月30日.CR.URL: https://www.w3.org/TR/css-display-3/
[CSS-EASING-1]
Brian Birtles; Dean Jackson; Matt Rakow.CSS Easing Functions Level 1.2023年2月13日.CR.URL: https://www.w3.org/TR/css-easing-1/
[CSS-FONTS-4]
Chris Lilley.CSS Fonts Module Level 4.2024年2月1日.WD.URL: https://www.w3.org/TR/css-fonts-4/
[CSS-FONTS-5]
Chris Lilley.CSS Fonts Module Level 5.2024年2月6日.WD.URL: https://www.w3.org/TR/css-fonts-5/
[CSS-GRID-2]
Tab Atkins Jr.; Elika Etemad; Rossen Atanassov.CSS Grid Layout Module Level 2.2020年12月18日.CR.URL: https://www.w3.org/TR/css-grid-2/
[CSS-IMAGES-4]
Tab Atkins Jr.; Elika Etemad; Lea Verou.CSS Images Module Level 4.2023年2月17日.WD.URL: https://www.w3.org/TR/css-images-4/
[CSS-INLINE-3]
Dave Cramer; Elika Etemad.CSS Inline Layout Module Level 3.2023年4月1日.WD.URL: https://www.w3.org/TR/css-inline-3/
[CSS-MASKING-1]
Dirk Schulze; Brian Birtles; Tab Atkins Jr..CSS Masking Module Level 1.2021年8月5日.CR.URL: https://www.w3.org/TR/css-masking-1/
[CSS-OVERFLOW-3]
Elika Etemad; Florian Rivoal.CSS Overflow Module Level 3.2023年3月29日.WD.URL: https://www.w3.org/TR/css-overflow-3/
[CSS-PAGE-3]
Elika Etemad.CSS Paged Media Module Level 3.2023年9月14日.WD.URL: https://www.w3.org/TR/css-page-3/
[CSS-POSITION-3]
Elika Etemad; Tab Atkins Jr..CSS Positioned Layout Module Level 3.2023年4月3日.WD.URL: https://www.w3.org/TR/css-position-3/
[CSS-SCOPING-1]
Tab Atkins Jr.; Elika Etemad.CSS Scoping Module Level 1.2014年4月3日.WD.URL: https://www.w3.org/TR/css-scoping-1/
[CSS-SHAPES-1]
Rossen Atanassov; Alan Stearns.CSS Shapes Module Level 1.2022年11月15日.CR.URL: https://www.w3.org/TR/css-shapes-1/
[CSS-SIZING-3]
Tab Atkins Jr.; Elika Etemad.CSS Box Sizing Module Level 3.2021年12月17日.WD.URL: https://www.w3.org/TR/css-sizing-3/
[CSS-SYNTAX-3]
Tab Atkins Jr.; Simon Sapin.CSS Syntax Module Level 3.2021年12月24日.CR.URL: https://www.w3.org/TR/css-syntax-3/
[CSS-TEXT-4]
Elika Etemad 他.CSS Text Module Level 4.2023年10月20日.WD.URL: https://www.w3.org/TR/css-text-4/
[CSS-TYPED-OM-1]
Shane Stephens; Tab Atkins Jr.; Naina Raisinghani.CSS Typed OM Level 1.2018年4月10日.WD.URL: https://www.w3.org/TR/css-typed-om-1/
[CSS-VALUES-5]
CSS Values and Units Module Level 5.Editor's Draft.URL: https://drafts.csswg.org/css-values-5/
[CSS-VARIABLES-1]
Tab Atkins Jr..CSS Custom Properties for Cascading Variables Module Level 1.2022年6月16日.CR.URL: https://www.w3.org/TR/css-variables-1/
[CSS-WRITING-MODES-4]
Elika Etemad; Koji Ishii.CSS Writing Modes Level 4.2019年7月30日.CR.URL: https://www.w3.org/TR/css-writing-modes-4/
[CSS2]
Bert Bos 他.Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification.2011年6月7日.REC.URL: https://www.w3.org/TR/CSS21/
[CSS22]
Bert Bos.Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification.2016年4月12日.WD.URL: https://www.w3.org/TR/CSS22/
[CSS3-BACKGROUND]
Elika Etemad; Brad Kemper.CSS Backgrounds and Borders Module Level 3.2023年12月19日.CR.URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS3-FONTS]
John Daggett; Myles Maxfield; Chris Lilley.CSS Fonts Module Level 3.2018年9月20日.REC.URL: https://www.w3.org/TR/css-fonts-3/
[CSS3-IMAGES]
Tab Atkins Jr.; Elika Etemad; Lea Verou.CSS Images Module Level 3.2023年12月18日.CR.URL: https://www.w3.org/TR/css-images-3/
[CSSOM]
Daniel Glazman; Emilio Cobos Álvarez.CSS Object Model (CSSOM).2021年8月26日.WD.URL: https://www.w3.org/TR/cssom-1/
[DOM]
Anne van Kesteren.DOM Standard.Living Standard.URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren.Fetch Standard.Living Standard.URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren 他.HTML Standard.Living Standard.URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola.Infra Standard.Living Standard.URL: https://infra.spec.whatwg.org/
[MEDIAQUERIES-5]
Dean Jackson 他.Media Queries Level 5.2021年12月18日.WD.URL: https://www.w3.org/TR/mediaqueries-5/
[RFC2119]
S. Bradner.Key words for use in RFCs to Indicate Requirement Levels.1997年3月.Best Current Practice.URL: https://datatracker.ietf.org/doc/html/rfc2119
[UNICODE]
The Unicode Standard.URL: https://www.unicode.org/versions/latest/
[URL]
Anne van Kesteren.URL Standard.Living Standard.URL: https://url.spec.whatwg.org/
[WEB-ANIMATIONS-1]
Brian Birtles 他.Web Animations.2023年6月5日.WD.URL: https://www.w3.org/TR/web-animations-1/

参考情報

[CSS-ANIMATIONS-1]
David Baron 他.CSS Animations Level 1.2023年3月2日.WD.URL: https://www.w3.org/TR/css-animations-1/
[CSS-BREAK-3]
Rossen Atanassov; Elika Etemad.CSS Fragmentation Module Level 3.2018年12月4日.CR.URL: https://www.w3.org/TR/css-break-3/
[CSS-CASCADE-3]
Elika Etemad; Tab Atkins Jr..CSS Cascading and Inheritance Level 3.2021年2月11日.REC.URL: https://www.w3.org/TR/css-cascade-3/
[CSS-COLOR-3]
Tantek Çelik; Chris Lilley; David Baron.CSS Color Module Level 3.2022年1月18日.REC.URL: https://www.w3.org/TR/css-color-3/
[CSS-GRID-1]
Tab Atkins Jr. 他.CSS Grid Layout Module Level 1.2020年12月18日.CR.URL: https://www.w3.org/TR/css-grid-1/
[CSS-OVERFLOW-4]
David Baron; Florian Rivoal; Elika Etemad.CSS Overflow Module Level 4.2023年3月21日.WD.URL: https://www.w3.org/TR/css-overflow-4/
[CSS-RHYTHM-1]
Koji Ishii; Elika Etemad.CSS Rhythmic Sizing.2017年3月2日.WD.URL: https://www.w3.org/TR/css-rhythm-1/
[CSS-TEXT-3]
Elika Etemad; Koji Ishii; Florian Rivoal.CSS Text Module Level 3.2023年9月3日.CR.URL: https://www.w3.org/TR/css-text-3/
[CSS-TEXT-DECOR-4]
Elika Etemad; Koji Ishii.CSS Text Decoration Module Level 4.2022年5月4日.WD.URL: https://www.w3.org/TR/css-text-decor-4/
[CSS-TRANSFORMS-1]
Simon Fraser 他.CSS Transforms Module Level 1.2019年2月14日.CR.URL: https://www.w3.org/TR/css-transforms-1/
[CSS-UI-4]
Florian Rivoal.CSS Basic User Interface Module Level 4.2021年3月16日.WD.URL: https://www.w3.org/TR/css-ui-4/
[MEDIAQ]
Florian Rivoal; Tab Atkins Jr..Media Queries Level 4.2021年12月25日.CR.URL: https://www.w3.org/TR/mediaqueries-4/
[QUIRKS]
Simon Pieters.Quirks Mode Standard.Living Standard.URL: https://quirks.spec.whatwg.org/
[RFC6694]
S. Moonesamy, Ed..The "about" URI Scheme.2012年8月.Informational.URL: https://www.rfc-editor.org/rfc/rfc6694

課題一覧

参照としてfind a potential indicated elementを使う可能性があるが、これはDocument専用であり、 ShadowRootには定義されていない。
CSSOMは丸め方法を明記する必要があり、CSSの関数もデフォルトで同じ丸め方法を使う方がよいかもしれない。 どの挙動を使うべきか?[Issue #5689]
このセクションはまだ議論中です。
CanIUse

Support:Android Browser2.1+Baidu Browser13.18+Blackberry Browser7+Chrome4+Chrome for Android122+Edge12+Firefox3.6+Firefox for Android123+IE11+IE Mobile10+KaiOS Browser2.5+Opera11.6+Opera MiniAllOpera Mobile12+QQ Browser13.1+Safari5+Safari on iOS6.0+Samsung Internet4+UC Browser for Android15.5+

Source: caniuse.com as of 2024-03-07

CanIUse

Support:Android Browser4.4+Baidu Browser13.18+Blackberry Browser10+Chrome27+Chrome for Android122+Edge12+Firefox2+Firefox for Android123+IE (limited)9+IE Mobile10+KaiOS Browser2.5+Opera15+Opera MiniNoneOpera Mobile73+QQ Browser13.1+Safari7+Safari on iOS7.0+Samsung Internet4+UC Browser for Android15.5+

Source: caniuse.com as of 2024-03-07

CanIUse

Support:Android Browser4.4+Baidu Browser13.18+Blackberry Browser10+Chrome26+Chrome for Android122+Edge16+Firefox19+Firefox for Android123+IE (limited)9+IE Mobile (limited)10+KaiOS Browser2.5+Opera15+Opera MiniNoneOpera Mobile73+QQ Browser13.1+Safari6.1+Safari on iOS8+Samsung Internet4+UC Browser for Android15.5+

Source: caniuse.com as of 2024-03-07

CanIUse

Support:Android Browser122+Baidu Browser13.18+Blackberry Browser10+Chrome26+Chrome for Android122+Edge12+Firefox16+Firefox for Android123+IE (limited)9+IE Mobile10+KaiOS Browser2.5+Opera15+Opera MiniNoneOpera Mobile73+QQ Browser13.1+Safari6.1+Safari on iOS7.0+Samsung Internet4+UC Browser for Android15.5+

Source: caniuse.com as of 2024-03-07