プロンプトとコンテキスト
プロダクトにおいて、検索フィールド、タグ入力、複数行メモをコンテンツに合わせて拡大または縮小させたいという要望があります。デザイン面では、グリッド内に収まり、レイアウトシフトを防ぎ、古いブラウザでも利用可能な状態を維持することが求められます。field-sizing: content がフォームコントロールの推奨サイズ（preferred size）をどのように変更するか、また境界、フォールバック、アクセシブルなインタラクションをどのように設定するかを説明してください。
この質問は、フロントエンド、デザインシステム、フォーム体験に関する面接に適しています。ポイントは、コンテナ、スクロール、バリデーション規約ではなく、推奨サイジングを変更する点にあります。
面接官がテストしていること
優れた回答では、content によってテキストコントロールがコンテンツに合わせて伸縮する一方で、fixed が初期値であることに言及します。最小幅がない場合、空のコントロールはキャレット幅にしかならない可能性があり、プレースホルダーがあると初期サイズが大きくなることがあります。min-inline-size、max-inline-size、textarea の高さ、長いコンテンツのスクロール、レイアウトの安定性、フォールバック、ラベルとエラーの関連付けについて網羅してください。
最初に確認すべき明確化のための質問
- 適応させるべきコントロールはどれか：単一行 input、textarea、select、それとも表示されるファイル名か？
- インラインサイズとブロックサイズの両方が変化してよいのか、それとも上限でコントロール内部をスクロールさせるべきか？
- グリッド列、モバイル幅、隣接するボタンからの制約（ハードコンストレイント）は何か？
- 空の値、プレースホルダー、長い文字列、ペーストされたコンテンツはどのように表示されるべきか？
- どのブラウザが対象範囲か、またフォールバックは固定サイズにするかスクリプトによる拡張にするか？
30秒の回答フレームワーク
「私は field-sizing: content を、完全な自動レイアウトソリューションではなく、推奨サイズの拡張（プログレッシブエンハンスメント）として扱います。input と textarea に min-inline-size と max-inline-size を指定し、textarea の高さに上限を設け、上限到達後はコントロール内部でスクロールさせます。明示的なラベル、エラーの関連付け、フォーカススタイルを維持し、未対応のブラウザでは固定サイズを保持します。空の値、プレースホルダー、長いテキスト、ズーム、キーボード操作、レイアウトシフトをテストして、フォームの契約が損なわれないようにします。」
ステップごとの詳細な回答
ステップ 1: fixed と content を理解する
field-sizing の初期値は fixed であるため、コントロールはブラウザのデフォルトの推奨サイズを使用します。content を指定すると、サポートされているテキスト入力はコンテンツに合わせて調整され、テキストの変更に応じて縮小または拡大します。このプロパティはセマンティクス、バリデーション、送信ルールを変更しません。
ステップ 2: 単一行コントロールのインラインサイズ境界を設定する
最小値のない空の input はキャレットのみの表示となり、見つけにくくなる可能性があります。また、プレースホルダーがあると広がりすぎることがあります。論理プロパティの最小サイズと最大サイズを使用して、適応がグリッド内に収まるようにします。
.tag-input {
field-sizing: content;
min-inline-size: 8rem;
max-inline-size: min(100%, 28rem);
}ステップ 3: 両軸における textarea の拡大を処理する
幅が制限された textarea は、コンテンツを表示するために行を追加する場合があります。ブロックサイズの最大値を設定し、上限後は内部スクロールを許可してください。そうしないと、ペーストされたテキストによって後続のフィールドがビューポート外に押し出される可能性があります。resize、overflow、line-height については、依然として明確なプロダクト判断が必要です。
ステップ 4: レイアウトシフトとグリッドの崩れを防ぐ
コンテンツが大きくなると、特にテーブル、ツールバー、ダイアログなどで隣接する要素が動かされます。フィールドを柔軟なグリッドトラック内に配置し、隣接するボタン用のスペースを確保し、クリティカルなアクションエリアではサイズに上限を設けます。初期スクリーンショットのみを確認するのではなく、CLS と現実的な入力シーケンスを測定してください。
ステップ 5: プレースホルダー、空の値、ファイル名を考慮する
content を使用すると、コントロールはプレースホルダーに十分な大きさで開始される場合があります。プレースホルダーがない空のコントロールは非常に狭くなることがあります。ファイルコントロールも、表示されるファイル名が変わるとサイズが変化する可能性があります。各コントロールに視認可能な最小値と省略（トランケーション）ポリシーを設定してください。プレースホルダーは永続的なラベルの代わりにはなりません。
ステップ 6: フォームのアクセシビリティを維持する
field-sizing はラベル、エラー、可視フォーカスを作成しません。すべてのコントロールには、プログラムによって関連付けられたラベル、エラーメッセージ、キーボード操作パスが引き続き必要です。リサイズによって現在のフォーカスが覆われたり、エラーが画面外に押し出されたりしてはなりません。ズームやハイコントラストテーマは個別にテストしてください。
ステップ 7: フォールバックを計画する
MDN ではこれを比較的新しい機能として説明しており、古いブラウザでは無視される可能性があります。デフォルトの CSS で適切な固定サイズまたは伸長可能なサイズを提供し、サポート対象のブラウザで content によって上書きされるようにします。キーストロークごとの計測スクリプトを安易に追加するのではなく、レガシー環境での適応が本当に必要な場合にのみ、入力イベント、スロットリング、アクセシビリティへの副作用を評価してください。
ステップ 8: 再現可能な検証を構築する
空、短いテキスト、長いテキスト、ペースト、多言語、プレースホルダー、削除、元に戻す（undo）、ズーム、キーボードナビゲーション、エラーの各状態をテストします。Chromium、Firefox、Safari、およびこのプロパティを無視するブラウザ全体で、コントロールの寸法、スクロールバー、CLS、フォーカス位置、隣接ボタンへの到達性を記録します。
トレードオフと境界
適応型サイジングは余白とスクリプトを削減できますが、レイアウトの変更やブラウザ間の差異をもたらします。固定サイズの方が予測可能性が高くなります。content は、サイズがその意味に沿うタグや検索語に適しています。主要なフォームフィールドについては、動的な寸法を選択する前に、発見可能性、操作性、エラー回復を優先して確保してください。
field-sizing: content を自動折り返し、バリデーション、オーバーフロー防止として扱わないでください。コンテナの境界、スクロール、エラー表示の責務は引き続きコンポーネント側にあります。
ロールアウト計画とエビデンス
タグ入力1つとメモ用 textarea 1つでパイロット運用を行います。デフォルトの寸法、コンテンツ長の分布、上限境界、レイアウトメトリクスを記録します。まずは固定サイジングから開始し、CLS、フォーカス、スクロール、完了率を観察しながら、サポートされているブラウザで content を有効化します。
最小・最大サイズ、プレースホルダーポリシー、textarea の上限、フォールバックスタイル、ブラウザマトリクスをドキュメント化します。ビジュアルリグレッションテストと並行して、リサイズによってラベル、エラー、送信ボタンの順序が崩れないよう、キーボードとスクリーンリーダーの受け入れテストを実行します。
よくある落とし穴とフォローアップ
最小幅の指定漏れ
空の input がキャレット幅のみになり、見つけにくくなることがあります。視認可能な最小インラインサイズを設定し、可視ラベルを維持してください。
textarea を無制限に拡大させる
大きなドキュメントをペーストすると、ページ全体が動いてしまうことがあります。ブロックサイズに上限を設け、制限を超えたらコントロール内部でスクロールさせます。
プレースホルダーをラベルとして扱う
プレースホルダーは初期サイズに影響を与え、入力時に消えます。永続的かつ関連付けられたラベルの代わりにはなりません。
サポート対象ブラウザのみでテストする
古いブラウザではこの宣言が無視されます。固定または伸長可能なデフォルト値が単独で機能し、同じフォーム受け入れテストの一部になっている必要があります。
リサイズによってボタンが操作できなくなったらどうするか？
グリッドトラック、最大サイズ、スクロールコンテナ、フォーカス位置を調査します。単に適応を無効化するのではなく、CLS、キーボードナビゲーション、長文テキストシーケンスを用いて再テストしてください。