文章を増やすと伸びて、消すと小さくなる入力欄を作りました。自動伸縮を担当するのは、CSSの field-sizing: content です。

同じ4行を入れると、標準の入力欄は高さ90pxのまま内部スクロール、自動伸縮側は146pxになって全文が見えました。ただし、固定の height が残っていると、自動伸縮はそこで止まります。 一行足せば終わり、というより、既存の高さ指定まで見直す必要があるんやなと分かった比較です。

実ブラウザの画面を連続キャプチャして20秒の動画にしたものです。文章の追加 → 長文で上限に到達 → 固定heightを追加 → 解除 → 空欄、を自動操作しています。生成映像ではなく、音声はありません。

→ 入力して比べられるデモを開く

なぜ今、field-sizingを試したか

2026年10月1日に確認したMDNの対応状況では、2026年6月からBaseline Newly availableとされています。今日発表された機能ではありません。古いブラウザまで対応が揃った、という意味でもありません。

海外でも2026年8月のReddit投稿で話題になっていました。今回は導入説明の要約で終わらず、既存フォームへ足すときに気になる「伸びない条件」「空欄の高さ」「長文の上限」を、自分の比較デモで確かめました。

幅はフォームに合わせ、高さを内容に任せる

実装の中心は次のHTMLとCSSです。横幅を100%にして、伸縮する方向を高さに絞っています。rows="2" は、内容に応じたサイズ指定が使われない場合の標準サイズとして残しました。

<label for="memo">メモ</label>
<textarea id="memo" class="auto" rows="2" placeholder="今日のメモ"></textarea>

textarea {
  box-sizing: border-box;
  width: 100%;
  padding: 16px;
  border: 1px solid #8aa091;
  font: 16px / 28px system-ui, sans-serif;
  resize: vertical;
}

textarea.auto {
  field-sizing: content;
  min-height: 92px;
  max-height: 220px;
  overflow-y: auto;
}

今回は空欄でも入力場所が小さくなりすぎないよう最小92pxにし、長文でページ全体が伸び続けないよう最大220pxを設けました。この値は今回の見た目に合わせたもので、どのフォームにも最適な値ではありません。

文字量や scrollHeight を読み、style.height を毎回更新する処理は入れていません。デモのJavaScriptは比較用の文章を入れたり、条件を切り替えたり、計測結果を表示したりするためのものです。利用者が直接入力したときの伸縮もCSSが担当します。

同じ文章を入れて計測した結果

検証日は2026年10月1日。macOS上のChromium 152系の実ブラウザで確認しました。下表は表示幅1000px、入力欄の幅419px、line-height: 28px、上下padding各16px、上下border各1pxの結果です。高さはborderを含む getBoundingClientRect().height で計測しました。

条件 標準の入力欄 自動伸縮側
空欄・短いplaceholder・rows=2 90px 92px
改行を含む4行 90px・スクロールあり 146px・スクロールなし
改行を含む12行 90px・スクロールあり 220px・スクロールあり
4行・自動伸縮側だけheight=120px 90px・スクロールあり 120px・スクロールあり
4行・固定heightを解除 90px 146pxに戻る
4行・両方ともrows=6 202px 146pxのまま
空欄・rows=6・短いplaceholder 202px 92px
空欄・rows=6・12行のplaceholder 202px 220px

標準側には自動伸縮側のmin/max-heightを指定していないため、空欄の90pxと92pxは意図的な下限設定の差です。注目したのは、文章の追加・削除や条件の切り替えに対して、高さがどう変わるかでした。

4行の146pxは、28px × 4行 + 32pxのpadding + 2pxのborder。今回の値では計測結果と一致しました。折り返しが増える幅や別のフォントでは同じ値になるとは限りません。

固定heightが残っていると伸びない

デモの「右に height: 120px を追加」をオンにして、意図的に固定値を足しました。

.auto.locked {
  height: 120px;
}

この状態では4行でも12行でも高さは120pxで止まり、中がスクロールしました。4行のまま指定を外すと146pxへ戻りました。

そのため既存フォームへ追加するなら、まず入力欄自身に設定された height を確認したいです。今回、width: 100% は横方向を揃えるために残しています。高さ方向を伸ばしたいからといって、すべての幅指定まで外す必要はありません。

rowsとplaceholderは、初期サイズを別々に考える

デモでは rows を2から6へ変えると、標準側は90pxから202pxへ変わりました。一方、4行を入れた自動伸縮側は146pxのままです。

「最初は6行分の高さを確保したい」場合、今回のように field-sizing: content を使う欄では rows だけを頼りにせず、min-height で下限を決める方が意図を表せます。

もう一つ比較したのがplaceholderです。入力値を空にして12行のplaceholderを設定すると、自動伸縮側は上限の220pxまで大きくなりました。何も入力していなくても、placeholderがサイズに影響します。この性質はChrome for Developersの解説にも示されています。

今回なら、長い説明をplaceholderへ詰め込むより、短い入力例にして、説明文は欄の外へ置く構成にします。ラベルもplaceholderで代用せず、label 要素で残しています。

長文・狭い幅・非対応環境はどう扱うか

12行を入れたときは高さ220px、内容の高さは368pxでした。上限以降は内部スクロールになるので、後半が消えてしまう構成ではありません。

表示幅390pxでも、直接長文を入力して220pxまで伸びること、ページに横はみ出しがないことを確認しました。ここで行ったのはデスクトップブラウザの表示幅を狭くする検証です。iPhone実機やソフトウェアキーボード表示中の検証はしていません。

field-sizing に対応しない環境ではこの宣言が適用されず、標準のtextareaとして使う方針です。旧ブラウザで同じ自動伸縮まで必要なら、JavaScript等による補完を別途検討します。今回、旧ブラウザそのものでは試していません。デモの field-sizing: fixed 切り替えは既定値に戻す比較で、非対応環境を完全に再現する機能ではありません。

手動での縦リサイズも残しました。ただし、手動リサイズと自動伸縮の関係は利用環境で追加確認が必要です。デモの「リセット」は手動設定されたheightも取り除き、比較をやり直せるようにしています。

今回の採用判断

小さなメモ欄なら、横幅を決め、最小・最大の高さを設けた field-sizing: content を使う構成にします。固定heightを残さないことと、空欄に長いplaceholderを入れないことが、この比較から得た実装上の確認点です。

自動伸縮だけを見ると一行のCSSですが、実際にフォームとして使うなら「どこまで伸ばすか」が大事でした。実装を短くしつつ、長文でも周囲の画面を押し広げすぎない形にできます。

デモのCSSと比較操作のJavaScriptも公開しています。CSSが効かないときに周辺条件を調べる例として、position: stickyが効かない原因の整理も参考になります。