ビジネスWebサイトのCSS構造のヒント(またはそのことについては任意)
公開: 2020-12-17CSSとHTMLは簡単に理解できます。 ただし、Webサイト(およびアプリ)を再利用可能で、将来的に保守可能にし、開発者を満足させる方法で構築する場合、最良のアーキテクチャーアプローチについて学ぶには何年もの練習が必要です。
ここでのアーキテクチャとはどういう意味ですか? これはCSSコードの構造です。 ファイルに分割する方法、クラス名の背後にあるルール、セレクターの深さ、カスケードする方法、継承されるもの、コンポーネント、ページ、要素、および修飾子の設定方法。
数百のページ、さまざまなタイプのコンテンツ、画面ビュー、エッジケースを含むこれらすべてのウェブサイトコンポーネントにベストプラクティスを適用し、さらに上に追加して既存のコンポーネントを変更することを検討するのは難しい部分です。
ページではなくコンポーネントを使用してビルドする
これは、考慮すべき主要な部分の1つです。 現在のページに基づいてスタイルを設定するべきではありません。 .homepage…{}スタイルを実行しないでください。 ページにセクションがある場合は、セクションのスタイルを設定します。 これで、他のページでも再利用できます。 ボタンがある場合は、ボタンのスタイルを.button {}のようにして、他の場所で再利用します。 すべてのビューに有効です。
これは、最も一般的なアドバイスであり、(これまでのところ)利用できる最もパフォーマンスの高いアプローチです。
では、ページ固有の違いをどのように管理しますか? これがページごとにスタイルを設定する最も一般的な理由だからですか? さて、いくつかのアプローチがあります:
修飾子を使用します。
「BEM」では、「M」は修飾子を表します。 これは.block__child–modifierの外観です。 BEMを使用しない場合でも、修飾子はとにかく存在します。 コンポーネントまたはセクションにバリエーションがある場合は、その修飾子を追加します。
理想的には、設計者はコードをクリーンに保つために思慮深く、バリエーションを最小限に抑える必要がありますが、コードにさらに追加することを恐れないでください。 バリエーションは、理想的にはいくつかのプロパティを上書きするだけで、同じマークアップで機能する必要があります。 これは、HTMLフェーズでコンポーネントにアプローチするための良い方法です。必要なタグを追加し、サイト全体で一貫性を保ちます。 モディファイアクラスのため、新しいものを追加しないでください。
子コンポーネントのスタイルを設定します。
もう1つのアプローチは、コンテキストに基づいてスタイルを設定することです。 ボタンは常にボタンであり、.buttonクラスとすべてがありますが、別のコンポーネントの一部である場合は調整できます。 これは不整合を引き起こすため、一般的には良い考えではありませんが、非常に現実的なユースケースでもあります。 そうしないと、奇妙な名前の20個の修飾子が作成されてしまいます。
コンテキストごとのスタイルとは、あるコンポーネントが別のコンポーネントの子である場合にのみ、そのコンポーネントのスタイルを設定することです。 記事カードを例にとってみましょう。 デフォルトでスタイルがあります。 ただし、横にテキストが表示されたカラフルなセクションの一部である場合、デザインでは、カードの周囲に他のいくつかの要素(アニメーションの形状など)が必要です。
その場合、.parent .card {}セレクターを使用してスタイルを設定します。 モディファイアを使用する場合と同様に、いくつかのプロパティを上書きするだけで済みます。 これを行うと、カード自体がスタイルを複雑にすることはありませんが、その特定のエッジケースで適切に動作します。
これについて考えると、「ページごと」にどのように適用できるかもわかります。 デザインに奇妙なエッジケースがいくつかあり、標準のコンポーネントビュー(およびそれらがすべて相互作用する方法)とのわずかな違いがある場合は、.homepage {}セレクターを使用してそれだけのスタイルを設定できます。 慎重に使用することを覚えておいてください。 私たちの経験では、そのようなスタイルが数行のコードを超えることはめったにありません。
追加する重要な注意事項:コンテキストごとのスタイルは、一般的には良い習慣ではありません。 理想的には、それさえ必要とすべきではありません。 ほとんどの場合、十分に機能するはずの修飾子があります。 一部のビルドでは現実的ですが、厳密なルールを使用して適切に抽象化されたコードを深く掘り下げると、コストがかかりすぎる可能性があります。
セクションでの作業
ほとんどのビジネスWebサイト(およびその他の多くのWebサイト)は、コンテンツをセクションに分割しています。 各セクションは、さまざまなプロパティを定義する修飾子クラスを備えた独自のコンポーネントです。 クラスの構造を使用するための1つの提案は次のとおりです。
- section.section-container –必要に応じて、これは「コンポーネント名」にすることができます。これは、一貫したパディング/マージンまたは必要なものを保持します。
- section.section-border-top –修飾子です。 これはBEMを使用しませんが、必要に応じて、BEMをsection-container-borderに「変換」できます。
- section.section-welcome –セクションの名前になります。
ここでも、命名規則は関係ありません。 このようなセクションを使用すると、デザインによって作成されたエッジケースで再利用可能なコンポーネントに合わせてスタイルを自由に調整できます(従う必要のある不整合や、より複雑なビューが原因であるため)。

ファイルの分離
ほとんどの場合、Sassまたは他の同様のプリプロセッサを使用します。 ファイルの分離に関しては、多くのアプローチがありますが、私たちが採用するアプローチは、次の一般的な構造に従います。
- 一般–一般は通常、グリッドを機能させるなどのセットアップコード、HTMLタグへのスタイル、リセット/ノーマライザー、一部のCMS固有のスタイルなどで構成されます。
- ページ–上記で説明したページスタイル。 理想的には、ここにコードをほとんど残さないでください。
- コンポーネント–ビルドのコア–さまざまなコンポーネントがここにあります。 1つのヒントは、80ファイルではなく1つのファイルにコンポーネントの小さなチャンクを収める「要素」または「その他」を使用できることです。 もちろん、大きなものは別々のファイルに入れるのが理想的です。
- レイアウト–グローバルスタイル。たとえば、ヘッダー、フッター、ページレイアウト、グリッドの修飾子など。
- プラグイン–プラグイン、拡張機能などから生成される外部のもの。 他のプロジェクトで再利用できるので、それらを分離するのは良いことです。
セレクターを清潔に保つ
クリーンなコードの良い兆候は、それがいかにシンプルに見えるかです。 奇妙な特性はなく、すべてに目的があり、インデントが低くなっています。 不要なときに「スマートに見える」セレクターは、コードを「クール」にしません。 #container> .row div [rel =” something”]のようなものを.rel-something(意味のあるクラス名だと想像してください)に置き換えることができる場合は、マークアップを少し更新する必要があります。 これの目標は、すべてをより単純に保つことです。
インデントを低く保ちます。 3つ以上のレベルに進む必要はめったにありません。 たとえば、.entryクラスを見てみましょう。
.entry {...} .entry-title {...}
.entry内で.entry-titleを実際にインデントする必要がないことを確認してください。 後でファイルに修飾子を追加すると、.entry-modifier {}と.entry-modifier.entry-title {}を持つことができます。
このアプローチを使用すると、将来のスタイルの上書きがはるかに簡単になります。 別の一般的な例を見てみましょう。nav.site-nav> ul.list-menu> li.list-items * 5> a(emmet)のマークアップがあります。
さて、スタイルを整えるのに必要なのは:
.site-nav {}-コンポーネント1 .list-menu {}-コンポーネント2 .list-menu .list-item {} .list-menu a {}
追加のドロップダウンなど、より多くのコンポーネントが内部にある場合は、それらを.list-menu内に直接ネストできます。 .list-menu .dropdown {}の2つのレベルを持つことができる場合、.site-nav .list-menu .list-item .dropdown {}(4レベルの深さ)を記述する必要はありません。
修飾子のより抽象的なクラス名を書く
これは保守性のためです。 同様の投稿に見られる一般的な例は、色変数を$ redに設定せず、代わりに$ primaryまたは$ secondaryに設定することです。
その理由は、変更が必要になったときに、変数$ redが青を出力するためです。 赤い色ではなく、原色を変更したい方が理にかなっていますよね?
他の種類の色やプロパティについても同じことが言えます。 一部のコンテンツ(<hr>タグなど)を区切る行があるとします。 破線であるため、その.line-dashという名前を付けます。 完全に理にかなっています。 しかし、その後、変化が起こり、それを点在させる必要があります。 行って名前を.line-dottedに変更しますか? これは修飾子ではなく、コンポーネントです。 これの代わりに、.line-separatorという名前を付けることができます。 また、具体的にしたい場合は、.dottedまたは.dashedの修飾子を追加できます。 このタイプの命名は、多くの場合、サイトを構築するときに最も時間がかかるものです。
要約すれば
良い習慣と悪い習慣は無数にあります。 より良い結果を達成する1つの方法は、ルールを定義してそれに従うことです。 このようなルールを思いつくのは難しいので、Webを閲覧して、命名規則、グッドプラクティス、保守可能なコードの記述方法など、アーキテクチャで可能なすべての情報を収集することをお勧めします。
優れたコードを作成するには、多くの時間と数十万行のコードが必要です。 その間、常に「そのスケールはありますか?」、「再利用できますか?」、「上書きしすぎましたか?」、「このように名前を付けるのは理にかなっていますか?」と自問してください。 そうすればするほど、意思決定が最適になり、作業速度が向上します。
優れたファンダメンタルズへの投資により、プロジェクトのやりとりが少なくなり、必要な将来の変更を実装するのがはるかに簡単になります。