CSS Values and Units Module Level 3 日本語訳

W3C Candidate Recommendation Draft,

More details about this document
This version:
https://www.w3.org/TR/2024/CRD-css-values-3-20240322/
Latest published version:
https://www.w3.org/TR/css-values-3/
Editor's Draft:
https://drafts.csswg.org/css-values-3/
History:
https://www.w3.org/standards/history/css-values-3/
Implementation Report:
https://drafts.csswg.org/css-values-3/implementation-report.html
Feedback:
CSSWG Issues Repository
Editors:
Tab Atkins (Google)
Elika J. Etemad / fantasai (Apple)
Former Editor:
(Opera Software)
Suggest an Edit for this Spec:
GitHub Editor
Test Suite:
https://wpt.fyi/results/css/css-values/

概要

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

CSSは、画面で、紙でなど(HTMLやXMLなどの)構造化文書のレンダリングを記述するための言語である。

この文書の位置付け

この節は、公開時点におけるこの文書のステータスについて説明する。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index at https://www.w3.org/TR/で見つけることができる。

この文書は、CSS Working Groupによって、勧告トラックを使用してCandidate Recommendation Draftとして公表された。Candidate Recommendationでの公表は、W3Cとそのメンバーの支持を意味するものではない。Candidate Recommendation Draftは、Working Groupが後続のCandidate Recommendation Snapshotに含める予定の以前のCandidate Recommendationからの変更を統合する。

これは草案文書であり、いつでも更新、他の文書による置き換えや廃止扱いにされうる。進行中の作業以外のものとしてこの文書を引用することは不適切である。

“[css-values] …summary of comment…”のように、タイトルに仕様コード“css-values”を含めて、GitHub(推奨)にissuesを提出することにより、フィードバックを送信されたい。すべてのissuesとコメントはアーカイブされる。そうでなければ、(アーカイブされた)公開メーリングリストwww-style@w3.orgにフィードバックを送信することもできる。

この文書は、2023年11月3日のW3C Process Documentによって管理される。

この文書はW3C特許ポリシーの下で活動するグループによって作成された。W3Cは、グループの成果物に関するあらゆる開示特許の公開リストを管理する。ここには、特許開示にあたっての指示も含まれている。特許について十分に知識のある人物が、仕様にEssential Claim(s)が認められると判断した場合は、W3C特許ポリシーの第6章に従い情報を開示する必要がある。

1. 概論

各CSSプロパティの値の定義フィールドは、キーワード、データ型(これは<>の間に出現する)、およびこれらをどのように組み合わせることができるかの情報を含めることができる。より具体的なデータ型(たとえば、<spacing-limit>など)は対応するモジュールで記述される一方で、多くのプロパティで使用することができる汎用的なデータ型(最も広く使用されている<length>)は、この仕様で記述される。

1.1. モジュール間の相互関係

このモジュールは、[CSS2]1.4.2.1節4.3節A.2節におけるデータ型定義を置換し、拡張する。

2. 値の定義構文

ここで説明される値の定義構文は、CSSプロパティの妥当な値(およびCSSの他の多くの部分の妥当な構文)の集合を定義するために使用される。そのように説明された値は、1つ以上のコンポーネントを持つことができる。

2.1. コンポーネント値型

コンポーネント値の型は、複数の方法で指定される:

  1. (たとえば、autoなど)引用符なしで、リテラルに出現するキーワード値(autodiscなど)。

  2. <>の間に出現する基本データ型(たとえば、<length><percentage>など)。数値データ型の場合、この型表記は、後述の角括弧で囲まれた範囲表記を用いて任意の範囲の制限に注釈付けすることができる。

  3. プロパティ値の範囲。これは同じ名前を持つプロパティと同じ値のパターンを表す。これらは、 <>との間に一重引用符で囲まれたプロパティ名として記述される。たとえば、<'border-width'><'background-attachment'>など。

    これらの型には、inheritのようなCSS全域キーワードは含まれない。それに加えて、プロパティの値の文法がカンマ区切りの繰り返しである場合、対応する型にはトップレベルのカンマ区切りのリスト乗数は含まれない。(たとえば、 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全域キーワード値を受け入れる。読みやすさためにプロパティ値の構文定義で明示的に記載されない。たとえば、CSS Cascading and Inheritance Level 3のもとでのborder-colorの完全な値の定義は、(<color>{1,4}と記載されるが)<color>{1,4} | inherit | initial | unsetである。

注:一般に、同一宣言中の他のコンポーネント値を持つこれらのキーワードを組み合わせは、無効な宣言を意味する。たとえば、background: url(corner.png) no-repeat, inherit;は無効である。

2.2. コンポーネント値の結合子

コンポーネント値は、次のようにプロパティ値に配置することができる:

並置は二重アンパサンドよりも強く、二重アンパサンドは二重縦線よりも強く、二重縦線は縦線よりも強い。したがって、次の2行は等価である:

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

再並び替え可能な結合子(||, &&)に対して、文法の順序付けは重要でない。同じグループにおける成分は、任意の順序で配置されてもよい。したがって、次の2行は等価である:

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

注: 結合子は結合性がないため、グループ化は重要である。たとえば、a || b || ca || [ b || c ]は別個の文法である。最初の文法はb a cのような値を許可するが、2番目の文法は許可しない。

2.3. コンポーネント値の量指定子

すべての型、キーワード、角括弧グループは、次の量指定子を付けてもよい:

+および#乗数は、+#として積み重ねてもよく、同様に、#および? 乗数は、#?として積み重ねてもよい。これらのスタックはそれぞれ、前の乗数の結果に適用された後の乗数を表す。(これらの同じスタックはグループ化を用いて表現できるが、複雑な文法では、これにより括弧の数が読みにくくなる可能性がある。)

繰り返しのコンポーネントの値(*+、または#で示される)の場合、ユーザーエージェントは、少なくとも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. プロパティ値の例

以下の対応する値の定義のフィールドを持つプロパティの例をいくつか示す。

プロパティ 値の定義フィールド 値の例
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

3. テキストデータ型

テキストデータ型には、文字列(<string>)およびURL(<url>)だけでなく、さまざまなキーワードおよび識別子も含まれる。

一般的に<ident>で示されるCSS識別子は、<ident-token>文法に準拠する文字シーケンスで構成される。[CSS-SYNTAX-3]識別子を引用符で囲むことはできない。そうでなければ、文字列として解釈される。CSSプロパティは、識別子の2つのクラスを受け入れる:事前定義されたキーワードおよび著者定義の識別子

注:<ident>の生成は、プロパティ値の定義を目的としたものではない—代わりに<custom-ident>を使用すべきである。これは、他の構文構造を定義するための利便性のために提供される。

3.1. 定義済みキーワード

値の定義フィールドにおいて、事前に定義された意味を持つキーワードはリテラルに出現する。キーワードは、識別子であり、かつASCII大文字・小文字不区別で解釈される(すなわち、[a-z][A-Z]と等価である)。

たとえば、border-collapseプロパティ値の定義は次のとおり:
Value: collapse | separate

その使用例:

table { border-collapse: separate }

3.1.1. CSS全域キーワード:initialinheritおよびunset

上記で定義されるような、すべてのプロパティはすべてのCSSプロパティに共通の計算値を表すCSS全域キーワードを受け入れる。これらのキーワードは、CSS Cascading and Inheritance Moduleで規範的に定義される。

他の仕様は、追加でCSS全域キーワードを定義することができる。

3.2. 著者定義識別子:<custom-ident>

一部のプロパティはコンポーネント値として著者定義識別子を受け入れる。この汎用データ型は、<custom-ident>で示され、そのプロパティの値定義において事前定義されたキーワードとして表示されない、任意の妥当なCSS識別子を表す。そのような識別子もASCIIの範囲で、完全に大文字・小文字区別である(たとえば、exampleEXAMPLEは2つの異なる無関係なユーザー定義の識別子である)。

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-outanimation-nameに属する<custom-ident>生成規則で主張されるままにしておき、ease-inanimation-timing-functionに属する<easing-function>生成規則によって要求される。

注:<custom-ident>をもつ文法を設計する場合、プロパティにおける任意のキーワード値と競合することが不可能なように、<custom-ident>は常に、位置的に"曖昧でない"ようにすべきである。

3.3. 引用符付き文字列:<string>

文字列<string>で表される。リテラルに記述される場合、これらは二重引用符または一重引用符で区切られた一連の文字で構成され、CSS Syntax Module [CSS-SYNTAX-3]<string-token>生成に対応する。

二重引用符は、("\""または"\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では"改行"の一般的な概念を表す。)

3.4. 資源位置表示:<url>

<url>で示されるurl()関数表記は、URLを表す。これは資源へのポインターである。<url>の典型的な構文は次のとおり:

<url> = url( <string> <url-modifier>* )
次の例は、背景画像として使用されるURLを示している:
body { background: url("http://www.example.com/pinkish.gif") }

<url>は、URL自身を引用符で囲まずに記述してもよい。この場合、<url-token>として特別に解析されるCSS Syntax 3 § 4.3.6 Consume a url tokenを参照。[CSS-SYNTAX-3]

たとえば、以下の宣言は同一である:
background: url("http://www.example.com/pinkish.gif");
background: url(http://www.example.com/pinkish.gif);

注:引用符なしurl()構文は、<url-modifier>引数を受け入れることができず、追加のエスケープ要件を持つ:URLで出現する丸括弧、空白文字、単一引用符(')、二重引用符(")がバックスラッシュでエスケープされなければならない。たとえば、url(open\(parens)url(close\)parens)。(引用符付きの<string> url()において、改行とその文字列を引用符付けするために使用される文字のみがエスケープされる必要がある。)URLの種類によって、[URL]で説明されるようにURLエスケープ(たとえば、url(open%28parens)またはurl(close%29parens))としてこれらの文字を書くことも可能であるかもしれない。

@importのような)一部のCSSコンテキストは、関数ラッパーなしで、 <url>にむき出しの<string>で表現することを可能にする。この場合、文字列はその文字列を含むurl()関数に同様に振る舞う。

たとえば、次の宣言は同じように機能する:
@import url("base-theme.css");
@import "base-theme.css";

3.4.1. 相対URL

リソースの絶対位置に依存しないモジュラー・スタイルシートを作成するために、著者は、相対URLを使用すべきである。([URL]で定義されるように)相対URLは、基底URLを用いて完全なURLに解決される。RFC 3986の3章は、この処理に用いる標準的なアルゴリズムを定義する。CSSスタイルシートに対して、基底URLはスタイル付けされたソース文書のURIではなく、スタイルシート自身のURLである。文書中で埋め込まれるスタイルシートは、スタイルシートコンテナに関連付けられた基底URLを持つ。

注:HTML文書の場合、ベースURLは変更可能である。

前段落で説明したように、<url>がプロパティの算出値に出現する場合、絶対URLに解決される。ユーザーエージェントが絶対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にかかわらず使用される。

3.4.1.1. フラグメントURL

ブラウザーのURL処理におけるいくつか共通の奇癖を回避するために、CSSはフラグメント専用URLのための特別な挙動を持つ。

url()の値は、U+0023 NUMBER SIGN(#)文字で開始する場合、URLに通常通り値を解析するが、url()ローカルURLフラグを追加で設定する。

設定されるローカルURLフラグurl()をマッチする場合、URLのフラグメント以外のすべてを無視し、相対URLが解決される現在の文書に対してその断片を解決する。この参照は、(横断文書よりむしろ)同一文書として常に扱われなければならない。

設定されるローカルURLフラグとともにurl()シリアル化する場合、その断片のみとしてシリアル化しなければならない。

“ブラウザーの奇癖”とは何か?

理論的にブラウザーは、フラグメント専用のURLを含む、文書のベースURLが変更するたびに(たとえば、base要素の変異を通じてまたはpushState()の呼び出しなど)、任意の相対URLを再解決すべきである。しかし、多くの場合にURLが解決せず、かつ特別な処理なし解決し、断片のみのURLは(以前のベースURLを指す)突如として横断文書参照となり、参照が使用される多くの場所で破る。

断片のみのURLは、その現在のURLが何であるかに関係なく、現在の文書を参照したいものの明確なセマンティックを表現するので、このハックは、少なくともこれらの場合に期待される動作を維持する。

3.4.2 空URL

<url>の値が(url("")またはurl()のような)空文字列である場合、urlは(url about:invalidが解決するものと同類な)無効なリソースに解決しなければならない。

算出値はurl("")であり、そのようにシリアル化しなければならない。

注:これは、ウェブプラットフォームの他の場所で埋め込まれたリソースに対する空URLの動作と一致し、かつ、url()が現れるものは何でも無効なリソースであることがほぼ確実である、url()値を空のままにする製作中のミスによるスタイルシートまたはホスト文書を再要求する過剰なトラフィックを回避する。ウェブプラットフォーム上でのリンクは空のURLを許可、よってCSSはハイパーリンクを制御するためのいくつかの機能を獲得する場合、この制限はこれらのコンテキストで緩和することができる。

3.4.3. URL修飾子

url()関数は、URLの意味または解釈を変更する、追加の<url-modifier>指定をサポートする。<url-modifier>は、<ident>または関数のいずれかである。

この仕様は、<url-modifier>を定義しないが、他の仕様が定義してもよい。

注:<url>は、引用符で囲まれていないかurl()表記で包まれないいずれかが任意の<url-modifier>を受け入れることはできないものである。

4. 数値データ型

数値データ型は、数量、指標、位置、およびその他のそのような値を表すために使用される。与えられた数値で量(数値的側面)を表現する際に多くの構文上のバリエーションが存在する可能性があるが、指定および算出値はこれらのバリエーションを区別しない。これらは、構文表現ではなく、値の抽象的な量を表す。

数値データ型には、<integer><number><percentage>、および<length><angle><time><frequency><resolution>などのさまざまな次元がある。

注:ここでは汎用の次元が定義されているが、他のモジュールの中には用法がよりローカライズされた追加のデータ型を定義するものもある(たとえば、[css-grid-1]fr単位を導入する)。

4.1. 範囲制限および範囲定義の表記

プロパティは数値をある範囲に制限することができる。値が許容範囲外にある場合、特に指定のない限り、宣言は無効であり、無視しなければならない。範囲制限は、CSSの角括弧で囲まれた範囲表記—​[min,max]—を用いて、数値型表記で注釈を付けることができる。これは、山括弧内で、識別キーワードの後に、minmaxの間の閉区間を示す。たとえば、<integer [0,10]>0から10までの最初と最後を含めた整数を示す一方で、<angle [0,180deg]>0degから180deg度までの角度(任意の単位で表される)を示す。

注:CSS値では一般に開区間は許可されない。したがって、角括弧表記のみが使用される。

理論的には、CSSはすべての値型の無限精度および無限大範囲をサポートしているが、現実の実装では有限のキャパシティを持つ。ユーザーエージェントは、合理的で有用な範囲および精度をサポートすべきである。理想的には無制限である範囲の極値は、必要に応じて∞または−∞を用いて示される。たとえば、<length [0,∞]>は負でない長さを示す。

角括弧で囲まれた範囲表記を用いるか、プロパティの説明でのいずれかで範囲が指定されない場合、[−∞,]が仮定される。

−∞または∞の値は、たとえ値の型で単位が使用されているとしても、単位なしで記述しなければならない。たとえ値の型が「単位のないゼロ」(<time>など)を許可しないとしても、0の値を単位なしで書き込むことができる

注:これを書いている時点では、角括弧で囲まれた範囲表記は新しいものである。よって、ほとんどのCSS仕様において、任意の範囲制限は本文でのみ説明されている(たとえば、「負の値は許可されない」または「負の値は無効である」は、[0,]の範囲を示す)。これは、拘束力を低下させるものではない。

4.2. 整数:<integer>

整数値は<integer>で示される。

リテラルに記述される場合、整数は、1つ以上の10進数0から9であり、かつCSS Syntax Moduleにおける<number-token>生成物のサブセットに対応する[CSS-SYNTAX-3]。整数の最初の桁は、符号を示す-または+を先行させてもよい。

4.3. 実数:<number>

数値は、<number>によって表記され、場合により分数成分をもつ実数を表す。

リテラルに記述する場合、 実数は、 整数、または0個以上の10進数の後にドット(.)が続き、その後に1個以上の10進数が続くものである。オプションで、文字"e"または"E"の後に指数表記の10を底とする指数を示す整数が続くことで終了できる。これは、CSS Syntax Module [CSS-SYNTAX-3]における <number-token>生成物に対応する。整数と同様に、最初の桁は、符号を示す-または+を先行させてもよい。

4.4. 単位をもつ数字:次元

一般的な用語次元は、数に付随する単位とその数を指し、<dimension>で表記される。

リテラルに記述される場合、次元は、識別子である、実数の直後に単位識別子が続くものである。これは、CSS Syntax Module [CSS-SYNTAX-3]における<dimension-token>生成物に対応する。キーワードと同様に、単位識別子はASCII大文字・小文字不区別である。

CSSは、長さ(<length>)、継続時間(<time>)、周波数(<frequency>)、解像度(<resolution>)、および他の量を指定するために<dimension>を使用する。

4.4.1. 互換性のある単位

算出値シリアル化する場合[CSSOM]互換性のある単位pxin間の96:1の係数、またはempx間の計算されたfont-size係数のような、静的な倍数因子によって関連するもの)は、単一の規準的な単位に変換される。互換性のある単位の各グループは、単位間がシリアル化のために使用される規準的な単位であるものを定義する。

使用値である解決値をシリアル化する場合、長さを表すすべての値型(パーセンテージ、数、キーワードなど)は、長さとの互換性が考慮される。同様に、使用値を返す任意の将来のAPIは、距離/所要時間/周波数などを表す任意の値を関連する次元のクラスと互換性があるものと見なさなければならず、適切な方法で正規化しなければならない。

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

パーセント値は、<percentage>で示され、別の基準値のある割合である値を示す。

リテラルに記述される場合、パーセントは、実数の直後のパーセント記号%から構成される。これは、CSS Syntax Module [CSS-SYNTAX-3]における<percentage-token>生成物に対応する。

パーセント値は、たとえば長さなど、常に他の量に対する相対値となる。パーセント値を許可する各プロパティはまた、パーセンテージが参照する量を定義する。この量は、同じ要素の別のプロパティ、祖先要素に対するプロパティの値、整形文脈の測定物(たとえば、包含ブロックの幅)、または何か他のものとすることができる。

4.6. パーセンテージと次元の混合

<percentage>が同じコンポーネント値次元と同じ数量を表すことができ、したがって、calc()式でそれらと組み合わせることが可能な場合に、次の便利な記法は、プロパティの文法で使用することができる:

<length-percentage>

<percentage><length>に解決される場合に、[ <length> | <percentage> ]と同等である。

<frequency-percentage>

<percentage><frequency>に解決される場合に、[ <frequency> | <percentage> ]と同等である。

<angle-percentage>

<percentage><angle>に解決される場合に、[ <angle> | <percentage> ]と同等である。

<time-percentage>

<percentage><time>に解決される場合に、[ <time> | <percentage> ]と同等である。

たとえば、widthプロパティは、距離の寸法を表す、<length>または<percentage>を受け入れることができる。これは、width: calc(500px + 50%);が許可されることを意味する―両方の値は絶対長さに変換されて、加えられる。包含ブロックが1000pxの幅である場合、width: 50%;width: 500pxに等しく、よってwidth: calc(50% + 500px)は、最終的にwidth: calc(500px + 500px)すなわちwidth: 1000pxと等しくなる。

一方、hsl()関数の第二および第三引数は、<percentage>としてのみ表すことができる。calc()生成物がその場所で許可されるが、生成物は、calc(10% + 20%)において見られるような、自分自身とパーセンテージのみを組み合わせることができる。

注:仕様は互換性がある限り、仕様は文法で次元の代わりに<percentage>を交互にすべきでない。

注:将来、必要に応じて<type-percentage>生成物を追加できる。<number>および<percentage>calc()で組み合わせることができないため、<number-percentage>が追加されることはない。

5. 長さの単位:<length>

長さは距離の大きさを参照し、プロパティ定義で<length>と示される。長さは次元である。

0長さに対する単位識別子は任意である(すなわち、構文的に<number> 0として表現できる)。しかし、0を(line-heightなど)プロパティで<number>または<length>のいずれかとして解析できる場合、<number>として解析しなければならない。

プロパティは、ある範囲に長さを制限してもよい。値が許容範囲外にある場合、宣言は無効であり、無視しなければならない。

一部のプロパティは負の長さの値を許可する一方で、整形を複雑にしてもよく、実装特有の限界があってもよい。負の長さの値をサポートできない場合、値をサポート可能な最も近い値に変換しなければならない。

使用される長さがサポートできない場合、ユーザーエージェントは実効値で近似しなければならない。

長さの単位には相対絶対の2種類がある。

5.1. 相対長さ

相対長さの単位は別の長さに対して相対的な長さを指定する。相対単位を使用するスタイルシートは、より簡単に1つの出力環境から別のものに拡張できる。

相対単位は以下のものがある:

相対単位の参考情報の概要
単位 何と相対か
em 要素のフォントサイズ
ex 要素のフォントのx-height
ch 要素のフォントにおける“0”(0、U+0030)グリフの事前測定
rem ルート要素のフォントサイズ
vw ビューポートの幅の1%
vh ビューポートの高さの1%
vmin ビューポートの小さい方の幅の1%
vmax ビューポートの大きい方の幅の1%

子要素は特定の親の相対値を継承しない。算出値を継承するのである。

5.1.1. フォント相対長さ:emexchrem単位

フォント相対長さは、それらが使用されている要素のフォントメトリック、またはremの場合はルート要素のメトリックを参照する。

em
この単位が使用される要素のfont-sizeプロパティの算出値に等しい。
規則:
h1 { line-height: 1.2em }

これはh1要素の行の高さがh1要素のフォントサイズの20%増しであることを意味する。一方:

h1 { font-size: 1.2em }

これはh1要素によって継承される算出されるフォントサイズがh1要素のフォントサイズの20%増しであることを意味する。

rem
ルート要素のemの算出値に等しい。
ex単位
最初に使用可能なフォントの使用されるx-heightに等しい。[CSS3-FONTS]x-heightは、小文字の"x"の高さに等しくなることが多いことからこう呼ばれる。しかし、exは"x"を含まないフォントに対しても定義される。フォントのx-heightは、別の方法で見つけることができる。一部のフォントは、x-heightの信頼できる測定基準を含む。信頼できるフォントメトリックが利用できない場合、ユーザーエージェントは小文字グリフの高さからx-heightを決定してもよい。実行可能なヒューリスティックの1つは、小文字の"o"のグリフを下ベースラインまで広げ、境界ボックスの上ベースラインから値を減算し、その長さを調べることである。x-heightを測定することが不可能または非現実的な場合、0.5emの値を仮定しなければならない。
ch単位
ヨーロッパの英数字の典型的な事前測定を表し、それをレンダリングするために使用される「0」(ZERO, U+0030)グリフの使用される事前測定として測定される。(グリフの事前測定は、要素のインライン軸であるいずれか、その事前の幅または高さである。)

注:この測定は、単一の狭いグリフの事前測定の概算(および等幅フォントで、正確な測定値)であり、よって予想されるグリフも合計数に基づいて測定できる。

注:グリフの事前測定は表記方向およびテキストの向きだけでなく、フォント設定、テキスト変換、およびグリフの選択や向きに影響を与える他の特性に依存する。

“0”グリフを測定することが不可能または非現実的な場合、この単位は1em高さで0.5emであると仮定しなければならない。したがって、ch単位は、一般的な場合において0.5emに後退し、直立に活字を組む(すなわち、writing-modevertical-rlまたはvertical-lrおよびtext-orientationuprightである)場合に1emに後退する。

要素のコンテキスト外で(たとえばメディアクエリーなどで)使用される場合、これらの単位は、fontプロパティの初期値に対応する計算されたフォントメトリックを参照する。これらが参照する要素のfont-sizeプロパティの値で使用される場合、これらの単位は、親要素の計算されたフォントメトリック(または、親なしの場合にfontプロパティの初期値に対応する計算されたフォントメトリック)を参照する。

フォント相対長さは、シェーピングがない場合に計算される。

5.1.2. ビューポート割合長さ:vwvhvminvmax単位

ビューポートのパーセンテージ長さは、 初期包含ブロックの大きさに対する相対的なものである。ブロック自身は、ビューポート(連続メディアの場合)またはページ領域ページメディアの場合)のいずれかの大きさに基づく。初期包含ブロックの高さまたは幅が変更されたとき、これらはビューポートに応じてスケーリングされる。しかし、スクロールバーは存在しないものとみなされる。

ページメディアについて、ビューポート割合長さの厳密な定義は、[CSS3PAGE]を優先する。

vw単位
初期包含ブロックの幅の1%に等しい。
ビューポートの幅が200mmである場合、以下の例で、h1要素のフォントサイズは16mm(すなわち、(8×200mm)/100)になる。
h1 { font-size: 8vw }
vh単位
初期包含ブロックの高さの1%に等しい。
vmin単位
vwまたはvhの小さい方に等しい。
vmax単位
vwまたはvhの大きい方に等しい。

5.2. 絶対長さ:cmmmqinptpcpx単位

絶対長さの単位は、互いに関連して固定されており、物理的な測定に固定されている。これは、主に出力環境が既知の場合に有用である。絶対単位は物理単位incmmmptpcq)および視覚角度単位px)で構成される:

単位 名前 等値
cm センチメートル 1cm = 96px/2.54
mm ミリメートル 1mm = 1/10cm
Q 4分の1ミリメートル 1Q = 1/40th of 1cm
in インチ 1in = 2.54cm = 96px
pc パイカ 1pc = 1/6 in
pt ポイント 1pt = 1/72nd of 1in
px ピクセル 1px = 1/96 in
h1 { margin: 0.5in }      /* inches  */
h2 { line-height: 3cm }   /* centimeters */
h3 { word-spacing: 4mm }  /* millimeters */
h3 { letter-spacing: 1Q } /* quarter-millimeters */
h4 { font-size: 12pt }    /* points */
h4 { font-size: 1pc }     /* picas */
p  { font-size: 12px }    /* px */

Note: 出版の文脈での長さは、 2p3のように書かれることがあり、2パイカと3ポイントの長さを示す。これらは、 calc(2pc + 3pt)としてCSSで記述できる(§ 8.1 数学表現:calc())を参照)。

絶対長さ単位のすべては互換性があり、かつpx規準的な単位である。

CSSデバイスの場合、これらの大きさは次のいずれかに固定される

  1. 物理的寸法に物理単位を関連付けること、または
  2. 参照ピクセルピクセル単位を関連付けること。

典型的な表示距離の印刷媒体の場合、固定単位物理単位のいずれか(インチ、センチメートルなど)となるべきである。スクリーンメディア(高解像度デバイスを含む)、低解像度のデバイスおよび独自の視聴距離を伴うデバイスの場合、固定単位は代わりにピクセル単位が推奨される。そのようなデバイスの場合、ピクセル単位は、参照ピクセルに最も近いデバイスピクセルの整数を参照することが推奨される。

注:固定単位ピクセル単位である場合、物理単位は物理的な測定結果と一致するとは限らない。あるいは固定単位物理単位の場合、ピクセル単位は、デバイスピクセルの整数に変換されないことがある。

注:このピクセル単位物理単位の定義は、CSS1およびCSS2の初期のバージョンとは異なる。特に、ピクセル単位物理単位が固定比で関連しないとされた以前のCSSバージョンにおいて、ピクセル単位が最も近い基準画素と一致するように変化する一方で、物理単位は常に物理的な測定に結びつけられる。(この不運な変更は、あまりにも多くの既存のコンテンツが96dpiの仮定に依存するために行われた。この前提を壊すことはコンテンツを壊すことになる。)

注:単位は大文字・小文字不区別であり、小文字としてシリアライズする。たとえば、1Qは1qとしてシリアライズする。

参照ピクセルとは、腕の長さのデバイスからの距離と96dpiのデバイスピクセル密度におけるデバイス上の1ピクセルとの視角である。名目の腕の長さが28インチの場合、視角は約0.0213度である。距離をおいて読むために、1pxは約0.26mm(1/96インチ)に対応する。

下の画像は、参照ピクセルの大きさで距離を見ることの効果を示している:71cm(28インチ)の読み取り距離では基準画素が0.26mmで、3.5m(12フィート)では1.3mmの参照画素となる。

This diagram illustrates how the definition of a pixel
		          depends on the users distance from the viewing surface
		          (paper or screen).
		          The image depicts the user looking at two planes,
		          one 28 inches (71 cm) from the user,
		          the second 140 inches (3.5 m) from the user.
		          An expanding cone is projected from the user's eye onto each plane.
		          Where the cone strikes the first plane,
		          the projected pixel is 0.26 mm high.
		          Where the cone strikes the second plane,
		          the projected pixel is 1.4 mm high.
閲覧距離の増大に伴ってピクセルが大きくなる

次の図は、ピクセル単位でのデバイスの解像度の効果を示している:低解像度のデバイス(たとえば、典型的なコンピュータ画面)では1px平方の領域が単独の画素で覆われてしまうのに対し、高解像度のデバイス(レーザープリンタなど)では1pxの領域に16個もの画素が入ることがわかる。

This diagram illustrates the relationship between
		          the reference pixel and device pixels (called “dots” below).
		          The image depicts
		          a high resolution (large dot density) laser printer output on the left
		          and a low resolution monitor screen on the right.
		          For the laser printer, one square reference pixel is implemented by 16 dots.
		          For the monitor screen, one square reference pixel is implemented by a single dot.
より多くのデバイスピクセル(ドット)が(ほぼ同じ視距離の)低解像度のデバイス上よりも高解像度のデバイス上の1px平方の面積をカバーするために必要とされることを示す

デバイスピクセルは、全範囲の色を表示する能力があるデバイス出力の領域の最小単位である。典型的なカラー画面では、赤、緑、および青のサブピクセルを含む正方形または少し長方形の領域である。一部の色をより高い解像度で表示することによってなど、この定義を曖昧にする可能性のある従来とは異なる出力が多数存在する。しかし、そのようなデバイスでも、"デバイスピクセル"と同等の概念がいくつか公開される。

6. その他の単位

6.1. 角度:<angle>型およびdeggradradturn単位

角度の値はで示される<dimension>である。角度の単位識別子は次のとおり:

deg
度。円の1周は360度である。
grad
グラディアン。ゴンまたはグラードとしても知られる。円の1周は400グラディアンである。
rad
ラジアン。円の1周は2πラジアンである。
turn
回転円の1周は1回転である。

たとえば、直角は90degまたは100gradまたは0.25turnまたは約1.570796326794897radである。

すべての<angle>単位は、互換性があり、かつdeg規準的な単位である。

慣例により、CSSで角度が方向を示す場合、角度は方位角として通常解釈される。ここで、0degは画面上で「上」または「北」であり、そしてより大きな角度は時計回りに大きくなる(よって、90degは「右」または「東」となる)。

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

注:レガシーな理由から、<angle>の使用は、裸の00degを意味することがある。しかし、これは一般に真ではなく、<angle>型の将来の使用では起こらない。

6.2. 時間:<time>型およびsms単位

時間の値は<time>で示される次元である。時間の単位識別子は次のとおり:

s
秒。
ms
ミリ秒。1秒は1000ミリ秒ある。

すべての<time>単位は、互換性があり、かつs規準的な単位である。

プロパティは、ある範囲に時間値を制限してもよい。値が許容範囲外にある場合、宣言は無効であり、無視しなければならない。

6.3. 周波数:<frequency>型およびHzkHz単位

周波数は<frequency>で示される次元である。周波数の単位識別子は次のとおり:

Hz
ヘルツ。これは1秒あたりの出現回数を表す。
kHz
キロヘルツ。1キロヘルツは1000ヘルツである。

たとえば、音の高低を表すときに、200Hzは低音域であり、6kHzは高音域である。

すべての<frequency>単位は、互換性があり、かつhz規準的な単位である。

注:単位は大文字・小文字不区別であり、小文字としてシリアライズする。たとえば、1Hzは1hzとしてシリアライズする。

6.4 解像度単位:<resolution>型およびdpidpcmdppx単位

解像度の値は<resolution>で表される次元である。解像度の単位識別子は次のとおり:

dpi
インチあたりのドット。
dpcm
センチメートルあたりのドット。
dppx
px単位あたりのドット。

<resolution>単位は、多数のこれらの点がCSS incmまたはpxに収まる方法を示すことにより、グラフィカルな表現の単一の"ドット"の大きさを表す。用途については、たとえば[MEDIAQ]におけるresolutionメディアクエリーまたは[CSS3-IMAGES]で定義されるimage-resolutionプロパティを参照のこと。

すべての<resolution>単位は、互換性があり、かつdppx2>は規準的な単位である。

<resolution>値の許容範囲は常に、明示的に指定された範囲に加えて、負の値を除外する。

CSSでのpxinは、CSSでは1:96の固定比率のため、1dppx96dpiに等しいことに注意する。これはCSSで表示される画像のデフォルト解像度に対応する。image-resolution参照。

次の@media規則は、一部の特別なスタイル規則を2 CSS px単位あたりデバイスピクセル以上を使用するデバイスに割り当てるためにメディアクエリー[MEDIAQ]を使用する。
@media (min-resolution: 2dppx) { ... }

7. 他の場所で定義されるデータ型

一部のデータ型は、独自のモジュールで定義されている。以下の例は、複数の仕様に渡って使用される最も一般的なデータ型の部について議論する。

7.1. 色:<color>

<color>データ型は[CSS3COLOR]で定義される。CSS Color Level 3またはその後継をサポートするユーザーエージェントは、その中で定義されているように<color>を解釈しなければならない。

7.2. 画像:<image>

<image>データ型は[CSS3-IMAGES]で定義される。CSS Image Level 3またはその後継をサポートするユーザーエージェントは、その中で定義されるように<image>を解釈しなければならない。まだCSS Images Level 3をサポートしていないUAは、<image><url>として解釈しなければならない。

7.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値構文も受け入れる。これは、プロパティ値で他の長さまたはパーセントのコンポーネントと組み合わされる場合に構文解析のあいまいさを引き起こすため、一般的には許可されていない。

シリアライズ時の基準的な順序は、水平方向のコンポーネントに続いて垂直方向のコンポーネントである。

他のキーワード、<length>、または<percentage>と同時に文法の中で指定される場合、<position>貪欲に解析される。可能な限り多くのコンポーネントを消費する。

たとえば、transform-originは3D位置を(実質的に)<position> <length>?と定義する。left 50pxのような値は、省略されたz成分をもつ2値の<position>として解析される。一方、top 50pxのような値は、単一値の<position>とそれに続く<length>として解析される。

8. 関数表記

関数表記は、より複雑な型を表す、または特別な処理を呼び出すことができる、コンポーネント値の型である。構文は、関数名に始まり、直後に左丸括弧が続き(すなわち<function-token>)、続いて引数、直後に右丸括弧が続く。キーワードと同様に、関数名はASCII大文字・小文字不区別である。空白は丸括弧のすぐ内側に許可されるが、任意である。関数は、CSSプロパティ値と同様に整形される、複数の引数を取ることができる。

注:rgba()のような一部のレガシー関数表記は、コンマを余計に使用するが、一般にコンマはリストで項目を区切るため、または別の方法で明確にする文法の場所でのみ使用される。コンマが引数を区切るために使用される場合、空白文字はコンマの前後でオプションである。

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

8.1. 数学表現:calc()

calc()関数は、数的なCSSコンポーネント値に、加算(+)、減算(-)、乗算(*)、および/または除算(/)を用いて数式として記述するのを可能にする。

calc()式は、その式に含まれる数学計算の結果を表す。これは、標準の演算子の優先順位規則を使用して評価される(*および/は、+および-よりも厳しくバインドされ、それ以外の場合、演算子は左から右に評価される)。

これは<length><frequency><angle><time><percentage><number>または<integer>の値が許可される場所ならどこにでも使用することができる。calc()式のコンポーネントは、リテラル値またはcalc()式を持つことができる。

section {
  float: left;
  margin: 1em; border: solid 1px;
  width: calc(100%/3 - 2*1em - 2*1px);
}
p {
  margin: calc(1rem - 2px) calc(1rem - 1px);
}
ビューポート内で正確に40emが一致し、テキストのほぼ同じ量が常に画面に関係なく画面サイズいっぱいになることを確認できるように、次のfont-sizeを設定する。
:root {
  font-size: calc(100vw / 40);
}

デザインの残りの部分がrem単位を使用して指定される場合、全体のレイアウトはビューポートの幅に合わせて調整される。

次の例は、完全に中央に配置された最初の画像と、最初の画像の左および下部に20pxのオフセットを設定する2つ目の画像の、2つの背景画像を積み重ねる。
.foo {
  background: url(top.png), url(bottom.png);
  background-repeat: no-repeat;
  background-position: 50% 50%, calc(50% + 20px) calc(50% + 20px);
}
この例では、グラデーションにどちらかの端から等しい距離にカラーストップを配置する方法を示す。
.foo {
  background-image: linear-gradient(to right, silver,
                                              white 50px,
                                              white calc(100% - 50px),
                                              silver);
}

8.1.1. 構文

calc()関数の構文は次のとおり:

<calc()> = calc( <calc-sum> )
<calc-sum> = <calc-product> [ [ '+' | '-' ] <calc-product> ]*
<calc-product> = <calc-value> [ '*' <calc-value> | '/' <calc-number-value> ]*
<calc-value> = <number> | <dimension> | <percentage> | ( <calc-sum> )
<calc-number-sum> = <calc-number-product> [ [ '+' | '-' ] <calc-number-product> ]*
<calc-number-product> = <calc-number-value> [ '*' <calc-number-value> | '/' <calc-number-value> ]*
<calc-number-value> = <number> | ( <calc-number-sum> )

さらに、空白文字+-演算子の両側に要求される。(*および/演算子は周りの空白なしで使用することができる。)

NUMBERDIMENSIONPERCENTAGEが項である場合、ユーザーエージェントは、少なくとも20項のcalc()式をサポートしなければならない。calc()式がサポートされる項の数よりも多く含まれる場合、式が無効であったかのように扱わなければならない。

8.1.2. 型のチェック

演算式は、<length><frequency><angle><time><percentage><number>または<integer>のいずれか1つの解決型を持つ。解決型は式が置かれている場所で妥当でなければならない。そうでなければ、式は無効である。式の解決型は、式に含まれる値の型によって決定される。<number-token>は、<number>または<integer>型である。<dimension-token>の型はその単位によって与えられる(cm<length>deg<angle>など)。

注:<number-token>は常に<number>または<integer>として解釈されるため、"単位なし0"<length>calc()でサポートされない。つまり、width: 0;width: 5px;の両方は有効であるが、width: calc(0 + 5px);は無効である。

式が置かれているコンテキストでパーセンテージが受け入れられ、かつパーセンテージが<number>以外の他の型との相対的な値として定義される場合、 <percentage-token>はその型として扱われる。たとえば、widthプロパティでは、パーセンテージは<length>型を持つ。パーセンテージは、<percentage>値が他の型と使用値の互換性がない場合に、<percentage>型のみを持つ。パーセンテージが通常calc()の代わりに許可されない場合、パーセンテージを含むcalc()式は、そのコンテキストで無効となる。

注:<percentage><number>に対して相対的であることに注意する。たとえばopacityにおいて、calc()で許可されない。これを許すことは、(<dimension>の乗算/除算を可能にする)"単位代数"に重大な問題を引き起こし、これまでのすべての場合に、新しい機能を提供しない。(たとえば、opacity: 25%opacity: .25と同じであるが、これは単なる構文変換である)。

注:使用値のときに(特にline-heightおよびtab-size)、<number>だけが<length>になるプロパティがいくつかあるが、<number>calc()で決して"長さのよう"にはならない。常に<number>のままとなる。

演算子は、利得の型がその引数に基づいて、部分式を形成する。式を簡単にするため、演算子は、受け入れる型に制限がある。各演算子で、左右の引数の型は制限が検査される。互換性のある場合、型は以下で説明するように解決される(以下は、簡単にするために演算子の優先順位規則を無視する):

演算子は上記の検査に合格しない場合、式は無効である。また、0による除算は無効である。これは、リテラルに実数0で割るだけでなく、0に評価される任意の数値式(純粋に数値式は、解析時に追加情報なしで評価することができるものとして)の両方を含む。

注:代数による単純化は、calc()式またはその解決型の妥当性に影響を与えない。たとえば、calc(5px - 5px + 10s)およびcalc(0 * 5px + 10s)は、長さに時間を加えようとするためにどちらも無効である。

8.1.3. 算出値

calc()表現の算出値は、算出されたすべてのコンポーネントをもつ表現である。

パーセンテージが算出値に解決されない場合、パーセンテージはcalc()式の中で解決されない。たとえば、calc(100% - 100% + 1em)は、1emでなくcalc(1em)に解決される。値におけるパーセンテージを算出するための特別な規則(たとえばheightプロパティ)が存在する場合、calc()式がパーセンテージを含むならばいつでも、特別な規則が適用される。

たとえば、font-sizeフォント相対長さの単位を計算できるように計算値時でパーセント値を計算する一方で、background-positionはパーセント値に対してレイアウト依存の動作を持ち、結果として使用値時までパーセントを解決しない。

このため、background-position計算ではcalc()内のパーセンテージが保持され、一方font-sizeではそのような式を直接長さに計算する。

テーブルセルとテーブル要素において、幅と高さの計算の複雑さを与えることは、自動および固定レイアウトテーブルの両方で、テーブル列、テーブル列グループ、テーブル行、テーブル行グループ、およびテーブルセルに幅と高さのパーセンテージを含む数式はあたかもautoが指定されたかのように扱われてもよい。

8.1.4. 範囲のチェック

値の解析時間範囲チェックはcalc()内で実行されず、したがって範囲外の値は宣言に無効にさせない。しかし、式から得られた値は、対象コンテキストで許可された範囲にとどめなければならない。計算が範囲照合を可能にするために式を十分に単純化できない場合、クランプは、可能な限りの算出値に対して実行され、また使用値についても同様である。(クランプは指定値で実行されない。)

注:これは、許容される値を(開区間でなく)閉区間と定義するために、calc()を受け入れるすべてのコンテキストを必要とする。

0pxより小さい幅は許可されないので、これら3つの宣言は等価である:
width: calc(5px - 10px);
width: calc(-5px);
width: 0px;

しかし幅に注目すると、width: -5pxwidth: calc(-5px)と等価ではない!calc()外の範囲外の値は、構文的に無効であり、宣言全体をドロップさせる。

8.1.5. シリアライゼーション

calc()値のシリアライゼーションは、このレベルにおいて未定義である。

付録 A:IANA 考慮事項

about:invalid URL スキームの登録

この節は、[RFC6694]で定義された登録手順に従って、about:invalidのURLを定義し、登録する。

この登録の公式記録は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 日本語訳

謝辞

Comments and suggestions from Giovanni Campagna, Christoph Päper, Keith Rarick, Alex Mogilevsky, Ian Hickson, David Baron, Edward Welbourne, Boris Zbarsky, Björn Höhrmann and Michael Day improved this module.

変更点

Changes since the 1 December 2022 Candidate Recommenation Snapshot are:

Changes since the 6 June 2019 Candidate Recommendation are:

Changes since the 31 January 2019 Candidate Recommendation are:

Changes since the 14 August 2018 Candidate Recommendation are:

A Disposition of Comments is available.

Changes since the 29 September 2016 Candidate Recommendation are:

A Disposition of Comments is available.

Changes since the 11 June 2015 Candidate Recommendation are:

Changes since the 30 July 2013 Candidate Recommendation are:

A Disposition of Comments is available.

Changes since the 28 August 2012 Candidate Recommendation are:

Changes since the 4 April 2013 Candidate Recommendation are:

セキュリティの考慮事項

この仕様は、新しいセキュリティの考慮事項を示すことはない。

この仕様では、url()関数(<url>)を定義する。これは、CSSがネットワークリクエストを作成できるようにする。それらのネットワークリクエストが使用される機能に応じて、これらは、ユーザーがネットワーク上のリソースにアクセスできるかどうかを暴露する可能性があり、コンテンツに関する情報(スタイル シート内のルール、画像のサイズ、フォントのメトリックなど)を暴露する可能性がある。また、URL経由でデータを盗み出す可能性もある。

プライバシーの考慮事項

この仕様では、ユーザーの画面サイズ(ビューポートのパーセンテージ長さ)、デフォルトのフォントサイズ、およびユーザーのシステムで使用できるフォントに関する情報(フォント相対的な長さ)を暴露する単位が導入されている。

この仕様では、url()関数(<url>)を定義する。これは、CSSがネットワークリクエストを作成できるようにする。それらのネットワークリクエストが使用される機能に応じて、これらは、ユーザーがネットワーク上のリソースにアクセスできるかどうかを暴露する可能性があり、コンテンツに関する情報(スタイル シート内のルール、画像のサイズ、フォントのメトリックなど)を暴露する可能性がある。また、URL経由でデータを盗み出す可能性もある。

適合性

文書規約

適合性要件は、説明的な表現とRFC 2119用語の組み合わせで表現される。本文章での標準部分においてキーワード“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”、“OPTIONAL”はRFC 2119で示されたとおりに解釈される。しかし、読みやすさのために、これらの単語はこの仕様で大文字のみで出現しない。

この仕様のすべての本文は、明示的に非規範的、例、および注としてマークされた部分を除き、規範的である。[RFC2119]

この仕様の例は、 "たとえば"という言葉で導入されるか、規範的な本文からclass="example"を設定し離される。このように:

これは参考情報の一例である。

参考情報の注は“注”で始まり、class="note"を設定し離される。このように:

注、これは参考情報の注である。

助言は、特別な注意を喚起するようにスタイル付けされる規範的なセクションであり、<strong class="advisement">とともに他の規範的なテキストとは別に設定される。このように:ユーザーエージェントは、アクセシブルな代替手段を提供しなければならない。

適合クラス

この仕様の適合クラスには次の3つが定義される:

スタイルシート
CSSスタイルシート
レンダラ
スタイルシートの意味を解釈し、かつスタイルシートを使って文書を表現するユーザーエージェント
オーサリングツール
スタイルシートを記述するユーザーエージェント

スタイルシートは、このモジュールで定義される構文プロパティを使用するスタイルシートの宣言のすべてが、このモジュールで定義される総称的なCSS文法および個々の文法に従って妥当である場合、この仕様に準拠する。

レンダラは、適切な仕様によって定義されるスタイルシートの解釈に加え、機能を正確にパースしかつ文書を適切な方法でレンダリングすることでこの仕様によって定義されるすべての機能をサポートする場合、この仕様に準拠する。しかし、デバイスの制限によってユーザーエージェントが文書を正確にレンダリングできないことは、ユーザーエージェントを非準拠にしない。(たとえば、ユーザーエージェントはモノクロのモニタで色のレンダリングを要求されない。)

オーサリングツールは、このモジュールにおける機能の総称的なCSS文法および個々の文法に従って構文的に正しいスタイルシートを既述し、かつこのモジュールで説明されるようにスタイルシートの他のすべての適合性要件を満たす場合、この仕様に準拠する。

部分的実装

著者がフォールバックの値を割り当てるための上位互換の解析規則を利用することができるようにするために、CSSレンダラは任意の@規則、プロパティー、プロパティーの値、キーワード、その他レンダラが使用可能なサポートのレベルがない構文要素を、無効(そして必要に応じて無視)として扱わなければならない。特に、ユーザーエージェントはある1つの複数値プロパティー宣言において非サポートのコンポーネントの値を無視し、かつサポートされる値を選択的に履行してはならない。任意の値が無効と見なされる(サポートされない値はそうでなければならない)場合、CSSは宣言全体が無視される必要がある。

不安定な実装およびプロパティ機能

将来の安定したCSS機能との衝突を避けるために、CSSワーキンググループは、不安定な機能とCSSへの独自拡張の実装に対する次のベストプラクティスを推奨する。

非実験的実装

一旦仕様がCandidate Recommendationの段階に達すると、非実験的な実装が可能になり、実装者は、仕様に従って正確に実装されるように明示することができる任意のCR段階の機能の接頭辞なしの実装を公開すべきである。

実装を問わずCSSの相互運用性を確立し維持するために、CSSワーキンググループは、非実験的なCSSレンダラが、任意のCSS機能の接頭辞なしの実装を公開する前に、実装レポート(そして、もし必要なら、実装レポートで使用したテストケース)をW3Cへ提出することを要請する。W3Cへ提出されたテストケースは、CSSワーキンググループによるレビューと修正の対象となる。

テストケースと実装レポートの提出に関する詳細情報は、CSSワーキンググループのウェブサイト(https://www.w3.org/Style/CSS/Test/)にある。質問は直接public-css-testsuite@w3.orgメーリングリストまで。

CRの終了基準

この仕様をProposed Recommendationにするためには、各機能で少なくとも2つの独立した、相互運用可能な実装がなくてはならない。各機能は、プロダクトの別のセットによって実装されてよく、すべての機能が1つの製品で実装される必要はない。この基準のために、以下の用語を定義する:

independent
各実装は異なる団体によって開発されている必要があり、共有、再利用、また別の条件を満たす実装で使用されているコードからの派生はできない。コードの、この仕様の実装に何の関係もない部分は、この要件から免除される。
interoperable
公式のCSSテストスイート(実装がWebブラウザでない場合は、同等のテスト)において、個々のテストケースをパスすること。該当するユーザーエージェントが相互運用性を主張するために使用される場合、テストスイート内の関連する全てのテストには、同等のテストが作られていなければならない。加えて、そのようなユーザーエージェント相互運用性を主張するために使用される場合、相互運用性のために、同じ方法で同等のテストをパスするユーザーエージェントが1つ以上追加で必要となる。同等のテストは、ペアレビューできるように公開して利用できるようにしなければならない。
implementation
ユーザーエージェントは
  1. 仕様を実装している。
  2. 一般に公開されている。実装は出荷する製品、もしくは公開され利用可能なバージョンである(たとえば、ベータバージョンやプレビュー版、"ナイトリービルド"など)。非出荷製品のリリースは、安定性を実証するため少なくとの1ヶ月の期間が機能実装に必要となる。
  3. 実験的(たとえば、現バージョンがテストスイートをパスすることに特化し、将来的にも通常利用を目的として開発されていない)ではない。

仕様は、少なくとも6ヶ月の間はCandidate Recommendationのままである。

索引

この仕様によって定義される用語

参考文献によって定義される用語

参考文献

標準情報

[CSS-2023]
Chris Lilley; et al. CSS Snapshot 2023. 7 December 2023. NOTE. URL: https://www.w3.org/TR/css-2023/
[CSS-CASCADE-5]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 5. 13 January 2022. CR. URL: https://www.w3.org/TR/css-cascade-5/
[CSS-COLOR-5]
Chris Lilley; et al. CSS Color Module Level 5. 29 February 2024. WD. URL: https://www.w3.org/TR/css-color-5/
[CSS-COUNTER-STYLES-3]
Tab Atkins Jr.. CSS Counter Styles Level 3. 27 July 2021. CR. URL: https://www.w3.org/TR/css-counter-styles-3/
[CSS-DISPLAY-3]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 3. 30 March 2023. CR. URL: https://www.w3.org/TR/css-display-3/
[CSS-FONTS-4]
Chris Lilley. CSS Fonts Module Level 4. 1 February 2024. WD. URL: https://www.w3.org/TR/css-fonts-4/
[CSS-IMAGES-4]
Tab Atkins Jr.; Elika Etemad; Lea Verou. CSS Images Module Level 4. 17 February 2023. WD. URL: https://www.w3.org/TR/css-images-4/
[CSS-SIZING-3]
Tab Atkins Jr.; Elika Etemad. CSS Box Sizing Module Level 3. 17 December 2021. WD. URL: https://www.w3.org/TR/css-sizing-3/
[CSS-SYNTAX-3]
Tab Atkins Jr.; Simon Sapin. CSS Syntax Module Level 3. 24 December 2021. CR. URL: https://www.w3.org/TR/css-syntax-3/
[CSS-WRITING-MODES-4]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 4. 30 July 2019. CR. URL: https://www.w3.org/TR/css-writing-modes-4/
[CSS2]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. REC. URL: https://www.w3.org/TR/CSS21/
[CSS22]
Bert Bos. Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification. 12 April 2016. WD. URL: https://www.w3.org/TR/CSS22/
[CSS3-BACKGROUND]
Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 11 March 2024. CR. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS3-FONTS]
John Daggett; Myles Maxfield; Chris Lilley. CSS Fonts Module Level 3. 20 September 2018. REC. URL: https://www.w3.org/TR/css-fonts-3/
[CSS3-IMAGES]
Tab Atkins Jr.; Elika Etemad; Lea Verou. CSS Images Module Level 3. 18 December 2023. CR. URL: https://www.w3.org/TR/css-images-3/
[CSS3COLOR]
Tantek Çelik; Chris Lilley; David Baron. CSS Color Module Level 3. 18 January 2022. REC. URL: https://www.w3.org/TR/css-color-3/
[CSS3PAGE]
Elika Etemad. CSS Paged Media Module Level 3. 14 September 2023. WD. URL: https://www.w3.org/TR/css-page-3/
[CSSOM]
Daniel Glazman; Emilio Cobos Álvarez. CSS Object Model (CSSOM). 26 August 2021. WD. URL: https://www.w3.org/TR/cssom-1/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[MEDIAQUERIES-5]
Dean Jackson; et al. Media Queries Level 5. 18 December 2021. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-3]
Tantek Çelik; et al. Selectors Level 3. 6 November 2018. REC. URL: https://www.w3.org/TR/selectors-3/
[SELECTORS-4]
Elika Etemad; Tab Atkins Jr.. Selectors Level 4. 11 November 2022. WD. URL: https://www.w3.org/TR/selectors-4/
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/

参考情報

[CSS-ANIMATIONS-1]
David Baron; et al. CSS Animations Level 1. 2 March 2023. WD. URL: https://www.w3.org/TR/css-animations-1/
[CSS-BOX-4]
Elika Etemad. CSS Box Model Module Level 4. 3 November 2022. WD. URL: https://www.w3.org/TR/css-box-4/
[CSS-BREAK-3]
Rossen Atanassov; Elika Etemad. CSS Fragmentation Module Level 3. 4 December 2018. CR. URL: https://www.w3.org/TR/css-break-3/
[CSS-CASCADE-3]
Elika Etemad; Tab Atkins Jr.. CSS Cascading and Inheritance Level 3. 11 February 2021. REC. URL: https://www.w3.org/TR/css-cascade-3/
[CSS-COLOR-4]
Chris Lilley; Tab Atkins Jr.; Lea Verou. CSS Color Module Level 4. 13 February 2024. CR. URL: https://www.w3.org/TR/css-color-4/
[CSS-EASING-1]
Brian Birtles; Dean Jackson; Matt Rakow. CSS Easing Functions Level 1. 13 February 2023. CR. URL: https://www.w3.org/TR/css-easing-1/
[CSS-GRID-1]
Tab Atkins Jr.; et al. CSS Grid Layout Module Level 1. 18 December 2020. CR. URL: https://www.w3.org/TR/css-grid-1/
[CSS-GRID-2]
Tab Atkins Jr.; Elika Etemad; Rossen Atanassov. CSS Grid Layout Module Level 2. 18 December 2020. CR. URL: https://www.w3.org/TR/css-grid-2/
[CSS-OVERFLOW-3]
Elika Etemad; Florian Rivoal. CSS Overflow Module Level 3. 29 March 2023. WD. URL: https://www.w3.org/TR/css-overflow-3/
[CSS-TEXT-3]
Elika Etemad; Koji Ishii; Florian Rivoal. CSS Text Module Level 3. 3 September 2023. CR. URL: https://www.w3.org/TR/css-text-3/
[CSS-TEXT-4]
Elika Etemad; et al. CSS Text Module Level 4. 19 February 2024. WD. URL: https://www.w3.org/TR/css-text-4/
[CSS-TEXT-DECOR-4]
Elika Etemad; Koji Ishii. CSS Text Decoration Module Level 4. 4 May 2022. WD. URL: https://www.w3.org/TR/css-text-decor-4/
[CSS-TRANSFORMS-1]
Simon Fraser; et al. CSS Transforms Module Level 1. 14 February 2019. CR. URL: https://www.w3.org/TR/css-transforms-1/
[CSS-UI-4]
Florian Rivoal. CSS Basic User Interface Module Level 4. 16 March 2021. WD. URL: https://www.w3.org/TR/css-ui-4/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 12 March 2024. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS-VALUES-5]
CSS Values and Units Module Level 5. Editor's Draft. URL: https://drafts.csswg.org/css-values-5/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[MEDIAQ]
Florian Rivoal; Tab Atkins Jr.. Media Queries Level 4. 25 December 2021. CR. URL: https://www.w3.org/TR/mediaqueries-4/
[RFC6694]
S. Moonesamy, Ed.. The "about" URI Scheme. August 2012. Informational. URL: https://www.rfc-editor.org/rfc/rfc6694