包含ブロックと位置指定（position）の解決過程

包含ブロックがすべての基準を握る

要素の位置やパーセンテージ寸法は、単独では決まりません。必ず**包含ブロック（containing block）**という基準矩形が先にあり、top/left などのオフセットや width: 50% はその矩形に対して解決されます。つまり「absolute がどこに吸い付くか」「fixed が本当に画面に固定されるか」「width: 100% が何の100%か」は、すべて包含ブロックの決まり方ひとつで説明できます。逆に言えば、位置指定のバグの大半は「想定と違う矩形が包含ブロックになっている」ことが原因です。

包含ブロックは要素の position の値によって、まったく異なるルールで決定されます。まずはこの対応表が出発点です。

ここで「位置指定された祖先（positioned ancestor）」とは、position が static 以外（relative/absolute/fixed/sticky）の祖先を指します。absolute 要素は親をさかのぼり、最初に見つかった positioned 祖先のパディング領域を基準にします。途中の祖先がすべて static なら、最終的に**初期包含ブロック（initial containing block、おおよそビューポート）**にたどり着きます。これが「position: relative を付け忘れた親を absolute の子が突き抜けて、ページ全体の左上に飛ぶ」現象の正体です。

パーセンテージ解決の非対称性

包含ブロックは「位置」だけでなく「サイズのパーセンテージ」の基準でもあります。ここに方向ごとの非対称があります。width: 50% は包含ブロックの幅、height: 50% は包含ブロックの高さを基準にします。問題は高さ側で、包含ブロックの高さが auto（自動）だと、縦方向のパーセンテージは解決できず無視される点です。これが「親に高さ指定がないと子の height: 100% が効かない」の原理です。

さらに padding と margin は、縦横どちらも一律で包含ブロックの幅を基準にします。padding-top: 50% が親の高さでなく幅基準なのはこのためで、正方形を作る古典的アスペクト比ハックの根拠でした（現在は aspect-ratio で代替可能）。

width:  50%   → 包含ブロックの「幅」基準
height: 50%   → 包含ブロックの「高さ」基準（高さが auto なら無視）
padding/margin の % → 縦横とも包含ブロックの「幅」基準

transform/filter が包含ブロックを生む例外

最も事故が多いのが、fixed（および absolute）の包含ブロックを通常はあり得ない要素が奪うケースです。原則として fixed の基準はビューポートですが、祖先に次のいずれかが効いていると、その祖先が新たな包含ブロックを生成し、fixed 子はビューポートではなくその祖先を基準にしてしまいます。

仕組みは一貫しています。transform や filter は要素に独立した座標系・合成レイヤーを与えるため、その内側の子は「画面」ではなく「この変換された箱」を基準にしなければ整合が取れません。結果として、transform: translateZ(0) を高速化目的で付けた親の内側にある position: fixed のモーダルが、スクロールに追従して動いてしまう——という典型バグが生まれます。will-change も同じ理由で、ブラウザが事前にレイヤーを用意するため包含ブロックを生成します。

sticky の計算過程

position: sticky は relative と fixed の中間的な振る舞いをします。要素は通常フロー上の位置（relative と同じ）を保ちつつ、最近接のスクロールポートに対して指定した閾値（top/bottom/left/right）に達すると、その閾値の位置で**貼り付き（stuck）**ます。重要なのは、sticky には2つの異なる基準が同時に関わることです。

• 粘着の閾値：最近接の**スクロールコンテナ（スクロールポート）**を基準に、top: 0 なら「ビューポート上端から0px」で貼り付き始める。
• 可動域の上限：sticky 要素は自分の包含ブロック（=ブロックレベルの親要素の矩形）からはみ出せない。親矩形の下端まで来たら、それ以上は貼り付かず親と一緒にスクロールアウトする。

この2条件から、各フレームでの位置は次のように解けます。

1. 通常フロー上の本来位置 flow_pos を求める
2. スクロール量から「閾値に貼り付くべき位置」stuck_pos を求める
   （例 top:10px なら スクロールポート上端 + 10px）
3. 親（包含ブロック）の上端・下端で許される範囲 [min, max] にクランプ
4. 最終位置 = clamp( max(flow_pos, stuck_pos), min, max )

つまり sticky は「relative の本来位置」と「fixed 的な貼り付き位置」のうちより進んだ方を採用し、さらに親矩形の範囲でクランプします。ここから「効かない sticky」の二大原因が導けます。

解決の全体フロー

position 別の包含ブロック決定を、判定の流れとしてまとめると次のようになります。

position == static / relative
    → 直近のブロックコンテナ祖先のコンテンツ領域

position == absolute
    → 祖先を上へ探索
       transform/filter/contain 等を持つ祖先があれば、それ
       なければ直近の positioned 祖先のパディング領域
       それも無ければ初期包含ブロック（≒ビューポート）

position == fixed
    → 祖先に transform/filter/perspective/will-change/contain
       を持つ要素があれば、そのパディング領域
       なければビューポート

position == sticky
    → スクロール閾値は最近接スクロールポート基準
       可動域は直近ブロック祖先の矩形でクランプ

まとめ