CSS大解剖 14日目: 「カスケード」

これらはスタイルの提供者と利用者の関係にあるといえます。Webブラウザは や などの要素を、適切なスタイルが当てられた状態で提供してくれます。ユーザーや文書の作者は、このデフォルトスタイルの恩恵を受ける側というわけです。いっぽう、ユーザーと文書の作者の関係はいささか恣意的とも言えます。現代においてはユーザースタイルは文書のスタイルを上書きする意図で使われることが多いため、CSS1当時に決定されたこの仕様はいささか不便かもしれません。

上記の3種類以外の特別なオリジンとして以下があります。

• CSS Transitions由来の仮想的な宣言。これは、プロパティの古い値と新しい値の混合値です。現在CSSの中で最も強いオリジンであり、 !important も突き抜けます。
  • CSS Transitionsの値は、元々カスケードに勝った値同士の混合なので、これが優先されることは合理的です。
• CSS Animations由来の仮想的な宣言。これは @keyframes 内で宣言された値の混合値です。通常の (!important のついていない) 宣言の中で最も強いオリジンとして扱われます。
• 文書の作者による表現ヒント。

文書の作者による表現ヒントについてもう少し説明してみます。CSS登場以前には、HTMLがスタイル指定の役割を担っていました。その中には、要素の属性値を用いて直接的にスタイルを指定するもの (表現ヒント) がいくつか存在しました。

body topmargin="30" background="https://example.com/bg.jpg">
table width="80%" height="80%" cellspacing="2" cellpadding="2" border="1">
hr width="50%">
pre wrap>
center>
div align="center">
br clear="left">
font face="sans" color="red" size="4">
ol type="a">

全ての表現ヒントが非推奨というわけではなく、 のwidth/height は現在でも有効な表現ヒントです。また、SVGの表現属性は非推奨というほどではないものの、現在はCSSによる指定が推奨されています。

こうした表現ヒントは、文書の作者の意図をWebブラウザが代理で適用しているため、そのオリジンについては議論の余地があります。これについてCSSは以下の2つの選択肢を提供しています。

• Webブラウザが適用したものとみなし、ユーザーエージェントオリジンに含める。
• 文書の作者が適用したものとみなす。ただし、CSSによる定義よりは低い優先度にしたいため、本来の作者オリジンとは別の特殊なオリジンを割り当てます。これが 「文書の作者による表現ヒント」オリジン です。

HTMLやSVGの表現ヒントは後者です。つまり、これらは作者オリジンに準じる扱いを受けます。これは以下のことを含意しています。

• 表現ヒントに由来する宣言は、ユーザーオリジンの通常の宣言よりも優先される。
• 表現ヒントに由来する宣言は、作者オリジンでの revert 指定により巻き戻される。

!important

スタイル宣言に !important をつけると、以下の2つの効果が発生します。

• その宣言は、!important のない通常の宣言よりも優先されるようになる。
• !important 宣言間でのオリジンの優先度が逆転する。カプセル化文脈とレイヤーの優先度も逆転する。

この2つの効果はいずれも、通常では負けてしまうスタイルをどうしても勝たせたいという背景から説明できます。

なお後者のルールは元々CSS1にはなく、CSS2で導入されたもののようです。おそらく、無節操に !important を使う文書のせいでユーザースタイルが適用できないというような問題が発生して修正されたのではないかと思います。

なお、 !important は強力ですが、CSS Transitionsには勝てません。

シャドウDOMのカプセル化文脈

CSSは文書本体ではなく、シャドウDOMにおけるシャドウ木内で宣言されることがあります。この場合にはカプセル化文脈 (encapsulation context) による優先度が加味されます。

シャドウDOMは、Web Componentsと呼ばれる仕様群のひとつです。Web Componentsは、Reactのコンポーネントのような再利用可能なUIコンポーネントをWebプラットフォームに固有の機能だけで実現する仕組みであり、シャドウDOMはその中で、コンポーネントの呼び出しをその実装に展開するための仕組みを提供しています。

シャドウDOMの登場により、DOMツリーには展開前の木構造と、展開後の木構造 (平坦木 (flat tree)) の2通りの解釈が与えられるようになり、状況に応じてどちらが使われるのかを意識する必要が出てきました。

そして、シャドウDOM内で書かれたCSSには、以下の制約が発生します。

• 特別なセレクターを使わない場合、その影響範囲は展開前の木構造における同じ木の中に限定される。
• 特別なセレクターを使っても、その影響範囲はシャドウDOMの呼び出し元 (シャドウホスト) を起点とした平坦木上のサブツリーに限定される。

後者の制約を要素を起点に言い換えてみます。すると、ある要素にマッチする宣言は全て、その要素の平坦木上の祖先(自分自身を含む)にぶら下がっているシャドウ木内のCSSと、文書全体のCSSに由来するスタイルに限られるということができます。

一般的には木上の祖先/子孫関係は比較可能とは限りませんが、上のような性質を加味すると、ある要素に関係するCSSは、そのルート(文書またはシャドウルート)の祖先/子孫関係に関して弱い全順序をなすことがわかります。

シャドウDOMが関与するカスケードでは、この順序に関して、より外側のルートに適用されたスタイルが優先されます。ただし、 !important のついたルールでは順序が逆転します。

このルールは、オリジンによる順序と同様の考え方に基づいています。つまり、シャドウDOMの内側はコンポーネントを提供する側であり、外側はコンポーネントを利用する側なので、原則は提供する側が勝つというわけです。

style 属性の優先

要素のスタイルは、スタイルシートの記述以外に、要素の style 属性 の指定の影響を受けます。 style 属性はスタイルシートの記述より優先されます。

古い仕様書では、このことを「style 属性は最も高い詳細度を持つ」というような形で説明していることがあります。カスケードのルールが複雑化した現代においては、style 属性を詳細度と切り離して説明するほうが明確でよいでしょう。

!important はこのルールを逆転させまん。 !important なルール同士でも、 style 属性が優先されます。

オリジンとカプセル化文脈

style 属性は文書の作者オリジンに属するものとして扱われます。また、当該要素が所属する文書またはシャドウルートに対応するカプセル化文脈に属します。したがって、 style 属性内の通常の宣言はより外側の文脈のスタイルシートの通常の宣言に負けることがあります。また、 style 属性内の !important な宣言も、より内側の文脈のスタイルシートの !important な宣言に負けることがあります。

style 属性内の順序

同じ style 属性内ではオリジン・カプセル化文脈・レイヤー・スコープ近接性・詳細度は意味をなしません。そのため、style 属性内の比較で意味をもつのは !important と出現順のみです。

style 属性のパース後は、同じプロパティに対する複数の宣言を保持する理由はないため、不要な重複は削除されます。これにより style 属性内でのプロパティ宣言の出現順はほとんど意味をなさなくなったように見えますが、実際にはフロー相対プロパティと対応する物理プロパティの前後関係を保持する必要があります。CSSOMでは、この順序をitemメソッドによって観測可能です。

レイヤー

イントロ

レイヤーもWeb Componentsと同様に、コードの共通化と再利用を念頭に置いた仕様です。Web Componentsがマークアップ・スクリプト・スタイルの3つをセットでカプセル化するのに対して、レイヤーはスタイルシート単独での階層化を行う軽量な仕組みであることがポイントです。

レイヤーの考え方は一言で言えば、スタイルをスタイルシート間の依存関係に基づいてカスケードをしようというものです。とはいえ、スタイルシート間の依存関係はすでに @import at-rule という仕組みで実装されてしまっているので、この機能との互換性を壊さないようにしつつも、同時に利用することで効果を発揮しやすいような形で実装されています。

	インライン	外部ファイル
平等にカスケード (レイヤーを生成しない)	その場に記述	@import url(default.css);
依存関係を考慮してカスケード (レイヤーを生成する)	@layer default { ... }	@import url(default.css) layer(default);

レイヤーとは

レイヤーは同じ強さでカスケードされるスタイルシートの集まりです。レイヤー間には依存関係があり、これにより木構造が作られます。これはnpmなどのパッケージマネージャーが作る依存グラフと近いものですが、単なるDAGではなく木構造とみなせる点が異なります。

レイヤーを作る方法は4つあります。

• 通常の方法で宣言されたスタイルシートは、自動的にルートレイヤーに分類されます。
• 子レイヤーを作る:
  • @import at-ruleの layer() オプションにより辺を宣言し、読み込んだスタイルシートをそこに分類する。
  • @layer at-ruleにより辺を宣言し、インラインでスタイルシートを記述する。
  • 空の @layer により辺を宣言する。

レイヤーの依存ツリーの辺には名前がつけられています。たとえば上の例で @layer default { ... } と書いた場合の default は辺の名前をあらわしています。名前を省略すると匿名レイヤーが生成されますが、これはいわば @layer __123__ { ... } のように不可視な名前が内部的につけられたような挙動をします。

レイヤーの順序

さて、レイヤーの目的は依存関係に基づく順序をつけることですが、カスケードの規則として定式化するには全ての組み合わせが比較可能である (弱い全順序である) 必要があります。そこで、レイヤーの順序が定義されます。

レイヤーの順序は、ルートレイヤーから深さ優先探索を行ったときの帰りがけ順です。たとえば、以下の例を考えてみます。

@layer foo {
  @layer bar {
  }
}
@layer baz {
}

この場合、レイヤーの順序は foo.bar, foo, baz, ルートの順です。

辺の順序

深さ優先探索の順序は、辺の順序に依存します。これはスタイルシート内で最初にその辺の名前が宣言されたタイミングの順でソートされます。上の例の順序を変更して

@layer baz {
}
@layer foo {
  @layer bar {
  }
}

とするとレイヤーの順序は入れ替わり、 baz, foo.bar, foo, ルートの順に並ぶことになります。

レイヤーの順序を明示的に制御するための構文として空の @layer at-ruleが用意されています。たとえば上の例は以下のように書き換えられます。

@layer baz, foo;


@layer foo {
  @layer bar {
  }
}
@layer baz {
}

レイヤーによるカスケード順

レイヤーの順序はコード間で提供者(ライブラリ側)と利用者(アプリケーション側)の関係を表したものといえるため、オリジンと同様の方法で優先度が決められます。つまり、

• 通常の宣言においては、レイヤー順で後ろのレイヤーに所属する宣言が優先されます。
• !important 宣言では、順序が逆転します。

スコープ近接性

スコープ近接性 (scoping proximity)はCascading and Inheritance Level 6で提案されている概念で、名前の通りスコープに基づいて優先度を判定します。

スコープ近接性には2種類の異なるモードが提案されており、どちらを採用するかは現時点では未確定です。

• 強スコープ近接性 (strong scoping proximty) はセレクター詳細度よりも優先してスコープ近接性を比較するモードです。
• 弱スコープ近接性 (weak scoping proximty) はセレクター詳細度が同じだった場合にのみスコープ近接性を比較するモードです。

スコープ

スコープはスタイル指定の有効範囲をDOM内の特定範囲に限定する機能です。

シャドウDOMでも同じような効果がありますが、それをシャドウDOMの構造によらずに柔軟に使えるようにしたのがスコープの仕組みだといえます。

スコープによる有効範囲の限定には2つの効果があります。

• スコープルートと呼ばれる要素を1つ指定することで、その要素の子孫(自身を含む)にのみマッチするようになります。
  • シャドウDOMにおいて、シャドウホストや上位要素を参照できない仕組みと対応しています。
• スコープ限界と呼ばれる要素を0個以上指定することで、それらの要素の子孫(自身を含む)を除外できます。
  • シャドウDOMにおいて、スロットを置換する要素を参照できない仕組みと対応しています。

スコープ近接性

スコープは詳細度の計算に寄与しません。かわりに、スコープ近接性 (scoping proximity) という値を計算することで優先度を決定します。

スコープ近接性とは名前の通り、選択された要素がスコープルートにどれくらい近いかをあらわす整数です。たとえば以下の例を考えます。

div class="foo">
  div class="bar">
    div class="baz">
    div>
  div>
div>

@scope (.baz) {
  .baz {
    color: red;
  }
}
@scope (.bar) {
  .baz {
    color: blue;
  }
}
@scope (.foo) {
  .baz {
    color: black;
  }
}

この場合、 .baz 要素は全ての宣言にマッチしますが、それぞれのスコープルートは異なります。

• 最初の宣言は .baz 自身がスコープルートなので、スコープ近接性は0です。
• 2つ目の宣言は .baz の親 (.bar) がスコープルートなので、スコープ近接性は1です。
• 最後の宣言は .baz の親 (.foo) がスコープルートなので、スコープ近接性は2です。

この場合、スコープ近接性が一番小さい color: red が勝ちます。

スコープ限界はカスケードの判定には使われません。

ネストしたスコープの近接性

スコープは2つ以上ネストさせることができます。また逆に、通常の宣言は、0個のスコープの入れ子だと解釈できます。このような場合は、まずマッチした要素と直近のスコープとの距離を計算し、直近のスコープからそのすぐ上位のスコープの距離を計算し、以降同様に上位のスコープの距離を計算していきます。処理するべきスコープがなくなったら、残りはずっと ∞ が入っているものとして扱います。つまり、通常の宣言は [∞, ∞, ∞, ∞, …] というスコープ近接性を持ち、ネストしていないスコープは [n, ∞, ∞, ∞, …] というスコープ近接性を持ちます。これを辞書順で比較します。

特に、スコープされた宣言は通常の宣言よりもスコープ近接性の観点から優先されることになります。

複数のスコープが該当する場合

同じ要素に同じ宣言が、複数のスコープを経由して該当する場合もあります。たとえば以下の例を考えます。

div id="e1" class="foo">
  div id="e2" class="bar">
    div id="e3" class="foo">
      div id="e4" class="baz">
      div>
    div>
  div>
div>

@scope (.foo) {
  .baz {
    color: red;
  }
}

この場合、内部のセレクターの実行やカスケード処理の観点ではスコープルートの数だけ宣言が複製されたものとして扱います。つまり、以下のように展開されたと解釈します。

@scope (#e1) {
  .baz {
    color: red;
  }
}
@scope (#e3) {
  .baz {
    color: red;
  }
}

この場合はスコープ近接性が1の宣言と3の宣言があることになります。近接性が高いほうだけが残されたと考え、全体の近接性は1だとみなしてもいいでしょう。

シャドウDOMによるカプセル化文脈との違い

すでに説明したように、カプセル化文脈とスコープにはアナロジーが成立しますが、技術的には全く別の機能です。細かい部分でも色々と動作が異なります。

• カスケードの適用順序。
• カプセル化文脈では上位の文脈ほど優先されますが、スコープは要素がより下位の位置にあるときに優先されます。また、スコープの優先順序は !important 内でも逆転しません。
  • この意味では、スコープの優先度の考え方は詳細度の考え方 (より詳細な指定が勝つ) に近く、カプセル化文脈の考え方 (より利用側に近いほうが勝つ) とは異なるといえます。
• カプセル化文脈による制限は部分セレクターにも再帰的に適用されますが、スコープによる制限は最上位のセレクターの結果にのみ適用されます。
• etc.

CSS Nestingとの違い

@scope は、CSS Nestingで定義されるネストしたスタイルルールと構文的にもよく似ています。しかし、その意味論は大きく異なります。

• カスケードの適用順序。外側のセレクターは、CSS Nestingにおいてはセレクターの詳細度に寄与します。一方、 @scope においては外側のセレクターはセレクターの詳細度には寄与せず、スコープ近接性による比較に使われます。どちらが強いかは今後スコープ近接性の優先度がどう定義されるかにもよりますし、場面ごとにその結果は変わってきます。
• CSS Nestingは単に親セレクターの再利用をしやすくするだけの機能であり、書き方次第では親セレクターで指定された要素の子孫以外に対してマッチさせることも可能です。
• CSS Nestingでは親セレクターは総体として評価されますが、 @scope では親セレクターは個体として評価されます。これにより、たとえば以下のような記述では違いが発生します。

  .foo {
    
    & + & {
      color: red;
    }
  }
  @scope (.foo) {
    
    & + & {
      color: red;
    }
  }
  

  ただし、現行ドラフトの記述では & をCSS Nestingと同様に展開するように指示されているので、実装がこの記述通りに変更されれば & に関してはこの差異は無くなります。明示的に :scope を使うのであれば同じ差異が引き続き発生します。

スコープ限定子孫結合子

Cascading and Inheritance Level 6は @scope に加えて、スコープ限定子孫結合子 >> も提案しています。これは原則として子孫結合子と同様に動作しつつ、マッチ時に >> の左辺に対応する要素をスコープルートとしてスコープ近接性を再計算するというもののようです。 >> を複雑な位置 (:is() の中など) で使った場合の挙動がどのように規定されるのかは現時点では不明です。

セレクターの詳細度

宣言の重要度・オリジン・カプセル化文脈・レイヤーが同じで両者とも style 属性に由来していなければ、セレクターの詳細度が比較されます。より詳細度の大きいほうが勝ちます。

セレクターの詳細度について、本稿でもごく簡単に説明しておきます。詳細度は3つの非負整数の組 (a, b, c) で表される値で、セレクターの構文上の構造から決定されます。a, b, cはざっくり以下を意味しています。

• a: IDセレクターの個数
• b: クラスセレクターや、それと同等な条件の個数
• c: 要素型セレクターや、それと同等な条件の個数

この組を辞書順で比較して大きいほうが勝ちます。たとえば、 (1, 3, 0) は (1, 2, 3) よりも大きいことになります。

詳細度はたとえば、「a よりも a.foo のほうが詳細な指定なので、後者が前者を上書きする意図だと解するべきだ」というような素朴な場面 (セレクター間に論理的な包含関係が成立する場合) ではうまく動作します。このような理由もあって詳細度は長らくCSSのカスケードの中心的な存在でした。しかし、より複雑なケースでは、詳細度は運用ミスを誘発しやすい側面があります。ここでは筆者の実体験をもとに加工した例をもとに説明してみます。当初、以下のような定義がありました。

.Button {
  background-color: #ccf;
}


.Button.DeleteButton {
  background-color: #fcc;
}

この時点では、詳細度に基づくカスケードは意図通りに動作しています。ここに以下のような変更が加わったとします。

.Button {
  background-color: #ccc;
}
.Button.ButtonPrimary {
  background-color: #ccf;
}
.Button.ButtonPrimary:hover {
  background-color: #aad;
}


.Button.DeleteButton {
  background-color: #fcc;
}

このようにコンポーネント側の進化にあわせてスタイルを変更したときに、それまでよりも強い詳細度のスタイルが宣言されてしまうと、アプリケーション側での上書きが無効化されてしまいます。実際の例ではもう少し意識しにくい形でこのような問題が発生していました。

ここで問題なのは、詳細度がコンポーネントのインターフェースの一部になってしまっていることです。もちろん、これは詳細度という仕組みが100%悪いわけではなく、スタイルのルールを適切に制定して運用すればこうした問題はある程度回避できます。

しかし、現代のCSSは、このようなスタイルの共通化・再利用に強く依存する開発スタイルのために、様々な道具を提供しています。作ろうとしているソフトウェアの要件次第では、なるべく詳細度の影響を受けないような書き方を検討する余地はあるでしょう。

出現順

ここまでの条件のいずれでも順序が決定できなければ、最終的に宣言の出現順により優先度が決定されます。あとに出現した宣言が優先されます。

この出現順は、その時点での文書の状態から決定されるものであり、スタイルシートが挿入された動的な順序で決まるわけではありません。時間的にあとから挿入されたスタイルであっても、DOM上で手前のほうに挿入されれば、出現順では優先度が低くなります。

出現順がもっとも重要になるのは、同一スタイルブロック内での比較です。これには主に2つの使い道があります。ひとつは、新しい機能が使えなかった場合のフォールバックスタイルを記述する場合です。

#hero {
  height: 100%;
  height: 100vh;
  height: 100svh;
}

ここで新しい機能を使った宣言ほど下に書くのは、有効な宣言の中で出現順で最後のものが勝つことが保証されているからです。

また、略称プロパティの一部を正称プロパティで上書きするという使い方も頻出です。

all: unset;
display: block;
box-sizing: content-box;

また、常に単一のクラス名を使ってスタイルを当てるような書き方の場合は、同じ詳細度のブロックがたくさんできるので、運用次第では意図せずこのような競合が発生する可能性もあります。このような場合にも、スタイルの出現順を意識するか、なるべく意識しなくていいような書き方への転換が必要になるかもしれません。

var() の展開と遅延構文解析

カスケード値が決定したら、次に指定値を決定するのですが、その前にもう1つ処理しておくことがあります。それは var() の展開です。また、 var() の有無とは無関係に、登録カスタムプロパティの構文解析もこのタイミングで処理します。

保証無効値

カスタムプロパティの値は保証無効値 (guaranteed-invalid value)という特別な値を持つことがあります。名前の通り、これはそのカスタムプロパティが無効であることを意味しています。これは以下の状況で発生します。

• 初期値
• カスタムプロパティが計算値時無効になった場合
  • カスタムプロパティ内の var() が保証無効値を参照しており、デフォルトが指定されていなかった場合
  • カスタムプロパティ内の var() の展開が循環参照になった場合

一般的な「無効」のニュアンスとは異なり、カスタムプロパティにおける保証無効値は必ずしも悪い状況をあらわしているわけではなく、正常なCSSスタイリングの一環として出現することがあります。

var() の展開

var() には2種類の形式があります。

• 1引数形式。 var(--foo) など、コンマを使わない形。
• 2引数形式。 var(--foo,), var(--foo, bar), var(--foo, bar, baz), var(--foo,,) など、コンマを使う形。

指定したカスタムプロパティに保証無効値ではなくトークン列が入っていれば、 var() 呼び出しはそれに置換されます。保証無効値が入っていた場合は、2引数目を使います。2引数目がない場合は無効な呼び出しと判定されます。

	1引数形式 var(--foo)	2引数形式 var(--foo, bar)
--foo は無効	無効	bar
--foo: 12345	12345	12345

トークンは並べるだけ

規格中でも注意されているように、 var() の展開はトークン単位で並べるだけです。

トークンは結合されないので、以下のようなスタイルは意図した通りに動作しません。

逆に、以下のようなスタイルは width に複数の値を入れようとしているので一見おかしいように思えますが、実際には有効な宣言として機能する可能性があります。

width: var(--foo) var(--bar);

遅延構文解析と計算値時無効

以下の場合には、このタイミングまで構文解析が遅延されています。

この時点で構文エラーまたは何らかの静的な条件への違反があった場合は計算値時無効 (invalid at computed-value time)という特別な状態になります。

計算値時無効の場合は、その値を unset か initial のいずれかとして再解釈します。どちらになるかは以下のルールで決められます。

• UA定義プロパティの場合: unset として扱う。
• カスタムプロパティの場合
  • 未登録のカスタムプロパティの場合: initial として扱う。 (= 保証無効値)
  • 登録されたカスタムプロパティの場合
    • 登録された構文が普遍構文定義の場合: initial として扱う。 (= 保証無効値)
    • 登録された構文が普遍構文定義以外の場合: unset として扱う。

通常の無効プロパティと計算値時無効なプロパティの違いは、それがカスケードの前か後かという点にあります。通常、プロパティが無効であればカスケード順位で下位の宣言にフォールバックしますが、計算値時無効ではカスケードのフォールバックがありません。

var() とグローバルキーワード

var() の第2引数がグローバルキーワードである場合、展開後の値がグローバルキーワードと一致する可能性があります。

border: var(--something, inherit);

このような場合は、展開後のグローバルキーワードはグローバルキーワードとして指定された通りに解釈されます。

またその帰結として、カスタムプロパティの計算値がグローバルキーワードに一致することはありません。ここで述べたように var() がグローバルキーワードに展開されるのは、第2引数の値が使われたときに限られると考えていいでしょう。

依存関係と循環参照の解決

CSSのプロパティ計算では、素朴に解釈すると循環参照に陥るケースがあります。UA定義プロパティではそれぞれに固有の方法で循環参照を解決しますが、カスタムプロパティの場合はそのような回避策を事前に定義することはできません。

そこで、カスタムプロパティでは、循環参照は var() の展開のタイミングで検出することになっています。

循環参照が発生した場合、循環参照に関与したカスタムプロパティは全て計算値時無効として扱うことになっています。

アニメーションと循環参照

アニメーションとカスタムプロパティは以下のように相互作用します。

• @keyframes を経由して、アニメーションがカスタムプロパティの値に影響を与えます。
• animation-* プロパティを経由して、カスタムプロパティの値がアニメーションに影響を与えます。

この2つによって発生するループはアニメーション汚染という処理によって解消されます。 @keyframes の影響を直接的または間接的に受けるカスタムプロパティは「アニメーション汚染されている」 (animation-tainted) とみなされ、アニメーション関連プロパティの計算時は無効化 (初期値が入っているものとみなす)されます。

つまり、アニメーション汚染フラグによる場合分けを通じて、アニメーションとカスタムプロパティの相互作用は 「アニメーション汚染されていないカスタムプロパティ」 → 「アニメーション関連プロパティ」 → 「アニメーション汚染されているカスタムプロパティ」 のように順序づけられ、一方向化されます。

……というのが仕様上の規定ですが、現行のChrome/Firefoxの実装では、単にアニメーション関連プロパティの評価時は @keyframes の影響を無視してカスケードを処理するという挙動のようです。

デフォルト値の処理

カスケード値が決定したら、そこから指定値を決定します。このときに行うのがデフォルト値の処理です。

カスケード値(の展開後の値)が以下の場合に、デフォルト値の処理が発生します。

	非継承プロパティの場合	継承プロパティの場合
カスケード値なし	初期値	⬇️継承値
unset	初期値	⬇️継承値
initial	初期値	初期値
inherit	⬇️継承値	⬇️継承値
revert	※再計算	※再計算
revert-layer	※再計算	※再計算

非継承プロパティと継承プロパティ

CSSのプロパティは、あらかじめ非継承プロパティと継承プロパティ (inherited property)のいずれかに分類されています。これは仕様書のプロパティ定義に記載されています。たとえば次の例では “Inherited: yes” と書いてあり、 color プロパティは継承プロパティであることがわかります。

また、未登録のカスタムプロパティは全て継承プロパティですが、Houdiniの仕様を通じて登録された場合は継承の有無を選べます。

非継承プロパティにはデフォルトで初期値が設定され、継承プロパティにはデフォルトで継承値が設定されます。しかし、非継承プロパティであっても明示的に継承を行うことができる点にも注意が必要です。

あるプロパティが継承プロパティかどうかをある程度予測する方法があります。それは余計な

や を挿入する思考実験をしてみることです。

たとえば以下のマークアップを考えます。

span style="color: red">Hello!span>

ここでマークアップに余計な階層を増やして以下のようにしてみます。

span style="color: red">span>Hello!span>span>

もし color が継承しないとすると、後者の Hello! は初期の色 (黒など) で描画されることになってしまいます。ここでは元のマークアップと同じように赤で描画されるのが自然なので、このプロパティは継承されるのだろうと予測することができます。

いっぽう、以下の例ではどうでしょうか。

div style="background-color: green">
  Hello!
div>

ここで

の階層を増やしたとしても、外側の div が塗り潰す範囲は変わりません。内部の要素で同じ色でもう一度塗り潰す必要はないため、このプロパティは継承されないのだろうと予測することができます。

もちろん、これは継承の有無について完全なルールを与えるものではありません。古い規格で継承プロパティとして定義されていたものが、諸般の事情から非継承プロパティに変更されたプロパティや、初期値の計算時に実質的に継承と近い効果が発生するプロパティもあり、これらは継承の有無が完全にアプリオリに決まるものではないことを表していると言えます。

初期値

初期値は各プロパティごとに定められる固有の値です。継承プロパティにも初期値は存在します。

未登録のカスタムプロパティは保証無効値 (guaranteed-invalid value)と呼ばれる特別な初期値を持ちますが、Houdini仕様を通じて登録されるときは初期値の指定が可能です。

初期値は以下のような場面で使われます。

• 非継承プロパティのカスケード値がない場合や unset が指定された場合
• initial が指定された場合
• 継承元となる要素がない場合の継承値
• 略称プロパティで記述が省略された部分の値 (別途指定がない場合)

継承値

継承値は指定値計算の前に算出される値で、以下のように決まります。

• 文書のルート要素の継承値は、そのプロパティの初期値である。
• それ以外の要素の継承値は、そのプロパティの親要素における計算値である。

非継承プロパティでも継承値は存在します。継承値は以下のような場面で使われます。

• 継承プロパティのカスケード値がない場合や unset が指定された場合
• inherit が指定された場合
• 個々のプロパティの計算値や使用値の算出にあたって、そのプロパティの記述にしたがって利用される場合がある。

継承値は、親要素の計算値を参照します。このことが計算値という概念の重要度を規定しているといっても過言ではないでしょう。

継承とシャドウDOM

シャドウDOMが関与する場合、継承は展開後の木構造である平坦木に沿って行われます。これは以下を意味します。

• ライト→シャドウ継承: シャドウホストのプロパティは、シャドウルート以下の要素に継承されます。
• シャドウ→ライト継承: スロットのプロパティは、スロットに割り当てられたスロッタブルに継承されます。

Web Componentsの文脈でいうと、カスタム要素とそれを利用する文書は、継承を通じて互いにスタイルの情報を交換していることになります。もちろん、それが不都合である場合は all: initial などを使って明示的に継承をオプトアウトすることも可能です。

ボックスと擬似要素の継承

ボックスは要素を表示の都合にあわせて分割・再構成して得られる単位です。レイアウト時には、要素のプロパティ値に基づいてボックスのプロパティ値を決定することになります。ボックスのプロパティ値は、そのボックスが生成された状況に応じて個別に決められますが、原則は以下の通りです:

• 主ボックスには、対応する要素のプロパティ値がそのままコピーされる。
• それ以外のボックスは、ボックス木の構造に沿って all: unset のように継承される。

つまり、主ボックスの値の計算はボックス木の構造ではなく、要素の木構造に従う点に注意が必要です。

revert / revert-layer

revert と revert-layer はカスケードから再計算を行う特殊なコマンドです。もちろん、ただ再計算するのではなく、現在のオリジンまたはレイヤーを無効化して再計算します。この無効化は、この要素のこのプロパティに対して一時的に適用されるもので、指定値が決定できたタイミングでリセットされます。

revert の目的は、すでに行った宣言を取り消すことにあります。たとえば以下の例では、 all: unset でユーザーエージェントのスタイルをリセットしていますが、 list-style についてだけその設定を除外しています。

/* color以外の全てのスタイルをリセットする (colorはWebブラウザの指定を使う) */
all: unset;
list-style: revert;

この場合、 revert を発見したことで all: unset と list-style: revert の両方を宣言値のリストから除外してカスケードから再計算します。すると今度はユーザーエージェントが指定した list-style がカスケードで勝つため、ここで指定値が確定することになります。

無効化される宣言の範囲は、 !important が関与するとややこしくなります。 !important はオリジン・カプセル化文脈・レイヤーの優先度を逆転させるため、この状態でどのように優先度を判定させるかは自明ではありません。この問題を踏まえた正しいルールは以下のように定義されています。

• revert/revert-layer の元となった宣言について、その通常の宣言と**!important 宣言**の両方のバリエーションを仮想的に想定する。
• これらの2種類の宣言の間にある宣言を全て無効化する。これは以下のように決定される。
  • revert の場合: 「オリジンと重要度」だけで、カスケード優先度に基づき比較する。
  • revert-layer の場合: 「オリジンと重要度」「カプセル化文脈」「style 属性の優先」「レイヤー」の4つの要素だけで、カスケード優先度に基づき比較する。

ただし、それぞれにはさらに注意すべきコーナーケースがあります。

まず、 revert の場合は、文書の作者による表現ヒントを文書の作者によるオリジンと同一視します。たとえば color: revert を指定すると の指定も一緒にリバートされます。

また、 revert-layer の場合、 style 属性との関係に注意する必要があります。

というのも、上のルールでわざわざ !important 宣言に言及している背景は、 !important 宣言と通常の宣言に関する対称性を考慮したものだと考えられるからです。しかし、 revert-layer の場合、 revert-layer が対象とするカスケード要件のうち、 style 属性の優先ルールのみ !important による逆転の影響を受けません。この非対称性をどうするかという議論の結論として、revert-layer の処理にあたっては、本来のカスケード順とは異なり、 !important な style 属性は同列の他の宣言より優先度が下であるかのように扱うという仕様になっています。

カスタムプロパティのrevert

カスタムプロパティでもプロパティごとにrevertを処理すればよいだけですが、このrevertはカスタムプロパティ間での依存関係の処理中に発生するので停止性が少しだけ非自明です。1つの文書中で出現するレイヤーの個数は有限であることから、ある要素に関するカスタムプロパティのrevert回数は (レイヤーの個数) × (カスタムプロパティの個数) 回で抑えられるため、これを考慮したループ変量を考えることになります。

計算値の決定

指定値が決定されたら、これを計算値 (computed value)へと加工していきます。 (なお、本稿では計算値の算出処理の一部である var() の展開と遅延構文解析を2つ前の節で処理済みとして扱っています)

計算値の算出過程において、様々な文脈依存の式や相対値が展開されます。何が展開され、何が展開されないかを理解することは、継承の挙動を理解する上でとても大切です。

計算値の決定方法はプロパティごとに独立に定められています。同じような式でも、プロパティごとに展開されるものと展開されないものがあります。

たとえば、以下は width, height の定義です。

このうち、

Computed value: as specified, with values computed

と書かれていることから、width/heightの計算値では %, em, calc() の展開が(可能な範囲で)行われるいっぽう、 auto などの指定はそのままであり使用値計算まで遅延されることがわかります。

計算値が観測される例

たとえば以下のスタイルを考えます。

#parent {
  color: blue;
  border: 1px solid currentColor;

  font-size: 16px;
  min-height: 10em;
  
  padding: 1px;
}


#child {
  color: red;
  border: inherit;

  font-size: 2px;
  min-height: inherit;
}

この例における border-color と min-height は、いずれも他のプロパティの値を参照する形で指定されています。ところが、この2つは計算値の算出方法が異なるため、以下のように継承時に異なる結果が得られることになります。

• border-color ... #child 側で再計算される (#child の color を参照する)
  • #parent における計算値は currentColor。
  • #parent における使用値は rgb(0, 0, 255)。 (#parent における color の使用値を参照するため)
  • #child における計算値は currentColor。 (親の計算値を継承するため)
  • #child における使用値は rgb(255, 0, 0)。 (#child における color の使用値を参照するため)
• min-height ... #parent 側で計算した値が使用される (#parent の font-size を参照する)
  • #parent における計算値は 160px。 (#parent における font-size の計算値をもとに展開されるため)
  • #parent における使用値は 160px。
  • #child における計算値は 160px。 (親の計算値を継承するため)
  • #child における使用値は 160px。

また、 line-height のように、ひとつのプロパティの中でも指定の仕方によって計算値で解決されるもの (e.g. 120%) と使用値で解決されるもの (e.g. 1.2) が混在する場合があります。

%

% は相対的な単位のひとつですが、これが何に対する相対値であるかはプロパティごとに異なります。各プロパティの Percentages: の欄にその意味が書いてあります。

• 長さ
  • インラインサイズまたは主軸方向のサイズを参照
    • 包含ブロックのインラインサイズ (margin-*, flex-basis など)
    • それ以外のインラインサイズ
  • 同じ軸の大きさを参照
    • 包含ブロックの大きさ
    • それ以外の大きさ (border-radius など)

  • それ以外の大きさ

• フォントサイズの継承値 (font-size)
• 無次元量 (opacity など)
• 意味をもたない
  • 未登録あるいは普遍構文のカスタムプロパティ
  • 色系のプロパティ (color, background-color など)
  • 択一系のプロパティ (border-*-style など)
  • 名前系のプロパティ (page など)

TODO

相対長 (em 等)

相対長は一般的に計算値中で解決されます。これにはフォント相対長、ビューポート百分率長、コンテナ相対長が知られています。

フォント相対長

フォント相対長は以下のように決定されます。

• 前進尺度を参照する ch, rch, ic, ric は writing-mode と text-orientation に依存するため、先にこちらの計算値を導出しておきます。これらはキーワード指定のみのため、循環参照になることはありません。
• 全てのフォント相対長さはフォント指定 (特に font-size の値) に依存するため、これらを先に計算しておく必要があります。
  • もし font-* プロパティの中で em, ex, cap, ch, ic, lh などの r のついていない単位が使われた場合は、循環参照回避のために、計算値ではなく継承値を参照します。
    • たとえば、 font-size: 2em は親要素のfont-sizeの2倍に解決されます。
  • 同様に、ルート要素の font-* プロパティの中で rem, rex, rcap, rch, ric, rlh などの r のついた単位が使われた場合も、計算値ではなく継承値 (=初期値) を参照します。
• lh, rlh は line-height にも依存するため、これを先に計算しておきます。循環参照回避のために、 line-height の中でこれらの単位が使われた場合は計算値ではなく継承値を参照します。

ビューポート相対長とコンテナ相対長

ビューポート百分率長とコンテナ相対長は、それぞれ計算値において絶対長に解決されます。

ビューポートの大きさはレイアウト時に所与であるため、循環参照の心配はありません。

一方、コンテナの大きさはコンテナの外側のレイアウトの計算によって決まります。コンテナはこのように「内側の要素の(広義の)カスケードの挙動を、外側の要素のレイアウトに依存して決定させる」という目的のために導入されたものであり、循環参照を防ぐために、コンテナ外のレイアウトをコンテナ内のカスケードに依存させないよう設計されています。

var()

すでに説明したように、var()は計算値の算出より前に展開されます。現行規格では名目上これが計算値の計算の一部であるとして扱っていますが、実態としては指定値計算前の前処理と考えたほうがいいでしょう。

数式

CSSにおいて数値を指定する構文 ( や , など) は数式を許容するように定義されています。

数式は数学関数と呼ばれる関数記法のいずれかを使って記述される値です。これは一般的な意味での「値」の範囲を超えていますが、CSSの用語としての「値」が指す範囲には含まれます。

現行の安定した仕様であるCSS Values and Units 3では1段階の calc() のみが数式として定義されていますが、Working DraftであるValues and Units 4では数式が大幅に拡張されているため、本稿ではこの定義をもとに説明します。

数学関数は数値を引数にとります。再帰的に数学関数を指定することも可能です。

width: max(10px, min(20px, 30px));

数学関数の中では四則演算も利用可能です。数学関数の外では利用できません。

width: max(100%, 50% + 10px); 
width: max(50%, 10px) + 50%; 

特に利用したい数学関数はなく、四則演算だけを利用したい場合は、式を calc() で囲みます。これは恒等関数として振る舞います。

width: calc(max(50%, 10px) + 50%);

TODO: calc() とinvalid判定について

TODO: calc() の解決

if()

url()

attr()

anchor()

css-easing

システム設定

関連するプロパティの影響を受ける計算値

その他

• >
• >
• >
• 'contain'
• 'content'
• 'display'
• 'font-weight'
• 'font-width'
• 'font-style'
• 'font-variation-settings'
• snap as a border width
• 'continue'
• clamped to the range
• outline-color/currentColor

使用値の決定

currentcolor

関連するプロパティの影響を受ける使用値

• currentColor (outline-color etc.)
• border-width

Style/Layout interleaving -- @container と anchor()

解決値

CSSOM View

---

バッジを贈る