経験則 - レイアウトで CSS をいじりすぎている場合は、フレームワークに切り替えてください。私は数十のグリッド/レイアウト フレームワークを検討してきましたが、それらのほとんどは従来のドキュメント グリッド レイアウトに焦点を当てています。
私のページはどちらかというと SPA (シングル ページ アプリケーション) です。これは、デスクトップ アプリケーションで使用されるレイアウトに似ています。明らかに、HTML はこれをうまく処理できず、多くの CSS をいじる必要があります。
私が達成しようとしているレイアウトの例を次に示します (これは画面全体を埋める必要があります)。
固定メニューは、その背後にあるスクロール コンテンツの上に移動してはならないことに注意してください。各ブロックは独自の「フレーム」に存在する必要があります。つまり、左側の長いリストのスクロールバーは固定メニューの下に表示されます。
これをサポートする軽量のグリッド フレームワークを見つけることができませんでした (Sencha や Kendo UI のようなフレームワークは少し過剰です)。CSS を手動で行うのは非常に面倒です。特に、モーダル ダイアログ ボックスを表示することに決め、このダイアログ ボックス内に同様のレイアウトが必要な場合 (最終的に私を殺したのはこれです)。または、一番下に別の固定メニューが必要だと判断した場合、すべての地獄が解き放たれます.
これが CSS のみで可能かどうかさえわかりません (スクロールバーが重ならないように、その背後にあるコンテンツを縮小するために、少なくとも固定された下部メニューには CSS にハードコードされた値が必要であることはわかっています)。JS ソリューションが必要で、ブラウザ画面のサイズ変更イベントを処理する必要がある場合は、それを行う簡単な一般的なイベントがないため、再びすべての地獄が解き放たれます。
保守可能/柔軟な方法でこれにどのようにアプローチすればよいですか?
コメント: お気づきのとおり、HTML テーブルを使用してこのレイアウトを実装することを提案する回答を自分で追加しました。私は自分の答えを受け入れるつもりはありません。テーブルを提案するほど「勇敢」な人は誰もいないだろうと感じていました(結局のところ、それは物議を醸しています)、議論のために反対票を投じても構わないと思っていました
明確化:保守可能で柔軟性があると言うとき、私は十分に明確ではなかったようです。私が言いたいのは、さまざまなシナリオや必要な変更を伴うレイアウト処理を適切に (つまり、私の代わりにほとんど作業を行わずに) 行うことです。絶対に具体的にするために、いくつかの例を挙げましょう:
レイアウトは、ページ全体として表示されるか、固定モーダル ダイアログ (つまり、ブートストラップ ダイアログ) 内に表示されるかを気にする必要はありません。これらのシナリオを切り替えても、レイアウト コードはできるだけ変更しないでください。
レイアウトは、幅と高さ (つまり、サイド バーの幅またはトップ メニューの高さ) を記述するさまざまな方法をサポートする必要があります。具体的には、次のサイジング方法をサポートする必要があります。
- 正確な固定ピクセル サイズ。
- コンテナーのパーセンテージを使用した相対的なサイズ設定。例: サイド バーの幅は、コンテナー全体 (フル ページまたはダイアログ) の幅の 30% です。別の例: トップ メニューの高さは、コンテナー (フル ページまたはダイアログ) の全体の高さの 20% です。
- 独自のコンテンツをラップします。例: トップ メニューの高さは、その中のコンテンツによって異なります。1 行のテキストを入力すると、スクロールせずに折り返されます。2 行のテキストを入力すると、2 倍の大きさになり、スクロールせずに保持されます。
- ボーナス: 2 つの単純な組み合わせ。サイドバーの幅が 20% で、50 ピクセル以上あるようなものです。
Ian Clark が最も専門的に指摘したように、CSS はこれらの要求のほとんどをすぐに実現できます。それについての議論はありません。未加工の CSS が最も使いやすいかどうか、フレームワークやフレックスボックスやテーブルなどの別のメカニズムによって開発者からオフロードできるものがあるかどうかという疑問が残ります。