left:50%とwidth:fit-contentを組むとmax-widthが効かない

結論

position:absoluteの要素でwidthがauto（shrink-to-fit）、leftが指定済みでrightがautoのとき、shrink-to-fitの計算に使うavailable widthはcontaining blockの幅からleftオフセット分を差し引いた値になる。 left:50%で中央寄せしていると、それだけでavailable widthがcontaining block幅の半分に縮み、maxWidthをいくら大きく指定しても、その値に到達する前にavailable widthの天井へぶつかって折り返される。maxWidthは一度も評価されない。

症状

動画レンダリング（Remotion）のシーン内に、字幕テキストを表示するプレート要素があった。横幅は文字数に応じて可変にしたいのでwidth:fit-contentを使い、画面中央に固定するためleft:50%+transform:translateX(-50%)で中央寄せしていた。

<div
  style={{
    position: 'absolute',
    left: '50%',
    bottom: 80,
    transform: 'translateX(-50%)',
    opacity: enter,
    width: 'fit-content',
    maxWidth: 1600,
    padding: '16px 32px',
    borderRadius: radiusSm,
    backgroundColor: bg,
    textAlign: 'center',
  }}
>
  <span style={{ color, fontSize: 42, fontWeight: 500, lineHeight: 1.5, letterSpacing: '0.02em', wordBreak: 'keep-all' }}>
    {lines[lineIdx]}
  </span>
</div>

containing blockは1920px幅の合成キャンバスで、想定していた最大幅は1600pxだった。1600px以内に収まる長さの文字列でも、実際には途中で強制的に2行へ折り返される行がいくつも発生した。fit-contentが伸びきる前に幅が頭打ちになっている挙動で、maxWidth:1600を1600のまま変えても症状は変わらなかった。

副作用として、2行化した分だけプレートの高さが増え、プレート上端が想定より高い位置までせり上がって、下に重なっている別レイヤーの表示と干渉していた。

原因

CSS 2.1のposition:absolute要素に対する幅算出アルゴリズムでは、width: auto（shrink-to-fit）かつleftが数値指定・rightがautoの場合、shrink-to-fitの計算に使う available width は次の式で決まる。

available width = containing block の幅 - left オフセット - margin

このケースでは containing block 幅が1920px、left: '50%' はcontaining block基準で960pxに解決されるため、

available width = 1920 - 960 = 960px

となる。transform: translateX(-50%) は描画後の見た目の位置をずらすだけで、幅算出アルゴリズムが参照する left の値そのものには影響しない。shrink-to-fitのアルゴリズムは、コンテンツの内容幅（preferred width）と available width を比較し、内容幅の方が大きければ available width で頭打ちにする。maxWidth: 1600 はこの後の段階でmin/maxの制約として適用されるはずの値だが、頭打ちが960pxの時点で先に確定してしまうため、1600という指定は一度も意味を持たない。

left の値を50%より小さくすればavailable widthは広がるが、それでは中央寄せができなくなる。left:50%+transform:translateX(-50%)という中央寄せの定石そのものが、shrink-to-fit幅の計算とは相性が悪い。

直し方

absoluteの対象を「中央寄せ」ではなく「containing blockいっぱいに広げるラッパー」に変え、中央寄せ自体はflexboxに任せた。可変幅の本体はflexアイテムとして通常のフローに置くことで、leftオフセットの影響を受けるabsoluteの幅算出から切り離した。

<div style={{ position: 'absolute', left: 0, right: 0, bottom: 80, display: 'flex', justifyContent: 'center', pointerEvents: 'none' }}>
  <div
    style={{
      opacity: enter,
      width: 'max-content',
      maxWidth: 1500,
      padding: '16px 32px',
      borderRadius: radiusSm,
      backgroundColor: bg,
      textAlign: 'center',
    }}
  >
    <span style={{ color, fontSize: 46, fontWeight: 500, lineHeight: 1.5, letterSpacing: '0.02em', wordBreak: 'keep-all' }}>
      {lines[lineIdx]}
    </span>
  </div>
</div>

外側のdivはleft: 0; right: 0でcontaining block全幅を占有する。これはwidth: autoだがleftとrightが両方指定されているケースなので、先述のshrink-to-fitアルゴリズムは使われず、幅はそのままcontaining block全幅として確定する。中央寄せは内側のjustify-content: centerが担う。

内側のdivはpositionを持たない通常フローの要素として、外側のflexコンテナに1個だけ子として並ぶ。この位置ではshrink-to-fit幅の算出にleftオフセットが関与しないため、width: max-contentとmaxWidth: 1500が意図どおりに効く。あわせてmaxWidthを1600から1500へ、フォントサイズを42から46へ調整しているが、これは見た目の再調整であって幅バグの直しの本体ではない。

再発防止

修正後のコードには、幅算出の仕組みに触れたコメントを残した。

// 旧 left:'50%'+width:'fit-content' は shrink-to-fit の
// available width が 1920-960=960px に固定され、maxWidth:1600 が一度も効かず全行が2行化
// →プレート上端が想定より高くせり上がり下段レイヤを覆う副作用の根だった。
// フルブリードのflexラッパ+max-contentで実幅に。

position: absoluteでleftだけを指定して中央寄せする書き方は見た目上は動くため、幅が固定長のコンテンツでは症状が出ない。可変長のテキストをwidth: fit-contentやwidth: max-contentと組み合わせたときにだけ、available widthの縮小が表面化する。中央寄せ目的のabsoluteに可変幅を持たせたくなったら、まずabsoluteをcontaining block全幅に広げてflexで中央寄せする形に倒すのが安全だとわかる。