Geekly Articles each Day

「窒息を伴う」CSSコード

Chris Coyerは最近、Smashing Magazineの読者からの質問に答えました。 質問の 1つは、「ダーリン」でCSSコードを認識する方法についてでした：
CSSが機能しているかどうかはどうすればわかりますか？ コードが最適ではないこと、または開発者がスリーブを介してコードを作成したことを示す兆候は何ですか？ コードが悪いか良いかを判断するために、最初は何を見ていますか？

自分の経験に基づいて、クリスの答えを拡大し、補完できると思った。

私はBSkyBで働いています。 大規模なサイトを作成しています-最後のサイトで1年以上取り組んでいます。 悪いCSSコードは私に多くの問題を与えます。 あるサイトで何ヶ月も作業していると、悪いコードを買う余裕はないので、修正する必要があります。

CSSコードの品質、保守性、および清潔さの印象を与えるために、まず注意を払ういくつかのことを共有したいと思います。

スタイルをキャンセル


以前に設定されたスタイルをオーバーライドするCSSルール（スタイルのリセット時を除く）は、ウェイクアップコールです。 カスケードスタイルシートは、定義により、以前の定義を継承して補完する必要があり、キャンセルしないでください。

次のような定義：

border-bottom:none; padding:0; float:none; margin-left:0;

通常は良いことを意味しません。 borderをリセットする必要がある場合は、おそらくインストールが早すぎます。 これを説明するのは難しいので、例を挙げます。

 h2{ font-size:2em; margin-bottom:0.5em; padding-bottom:0.5em; border-bottom:1px solid #ccc; }

ここでは、 h2要素にフォントサイズとパディングだけでなく、タイトルと残りのコンテンツを視覚的に区別するためのマージンとアンダースコアも指定します。 しかし、別の場所では、フィールドも下線も必要ない場合が非常によくあります。 おそらく次のように書きます。

 h2{ font-size:2em; margin-bottom:0.5em; padding-bottom:0.5em; border-bottom:1px solid #ccc; } .no-border{ padding-bottom:0; border-bottom:none; }

これで、10行のコードとanいクラス名ができました。 これを行う方がはるかに良いでしょう：

 h2{ font-size:2em; margin-bottom:0.5em; } .headline{ padding-bottom:0.5em; border-bottom:1px solid #ccc; }

8行、スタイルのキャンセルなし、美しく意味のあるクラス名。

スタイルシートを下に移動して、ルールを追加してください。 以前に設定したスタイルを元に戻す必要がある場合は、おそらくすぐにスタイルを追加しました。

同様のスタイルのキャンセルを含む数万行のCSSファイルを想像してください。 たくさんの追加コード！ 古い定義のシンプルな定義の上に新しい定義を徐々に追加します。すぐに複雑なルールを作成しないでください。さもないと、より多くのコードを書くことになり、やることが少なくなります。

いくつかのルールが前のルールをオーバーライドするのを見ると、スタイルが適切に編成されておらず、作り直す必要があることをほぼ確実に知っています。

マジックナンバー


特に嫌いです！ マジックナンバーは無意味な値であり、「機能する」ために使用されます。 例：

 .site-nav{ /* [styles] */ } .site-nav > li:hover .dropdown{ position:absolute; top:37px; left:0; }

top:37px; マジックナンバーです。 ここにある唯一の理由は、リストアイテムの高さが37ピクセルであり、ドロップダウンサブメニューがメニューアイテムの下部に表示されることです。

問題は、これらの37ピクセルは単なる偶然の一致であり、この定数に完全に依存することはできないということです。 誰かがメニュー項目のフォントサイズを変更すると、高さが37ピクセルではなく29になりますか？ Chromeでメニュー項目の高さが37ピクセル、IEで36ピクセルの場合はどうなりますか？ この番号は、1つの特定のケースでのみ機能します。

「機能する」値を使用しないでください。 前の例では、 top:100%;と書く方がはるかに良いでしょうtop:100%; top:37px;代わりにtop:37px;

そして、これがマジックナンバーの唯一の問題ではありません。 不安に加えて、コミュニケーションの問題も生じます。 別の開発者は、この番号がどこから来たのかをどのように理解できますか？ コードが上記の例よりも大きくて複雑で、一部のマジックナンバーが突然機能しなくなった場合、次の問題が発生します。


マジックナンバーは悪いです。 それらはすぐに時代遅れになり、他の開発者に干渉し、説明できず、頼ることができません。

他の誰かのコードにそのような不可解な数字を見つけたとしても、それ以上悪いことはありません。 なぜここにあるのですか？ それはどういう意味ですか？ 触ってもいいですか？ 私はそのような数字を見るたびにこれらの質問をします。 そして、主な質問：「魔法なしで同じ結果をどのように達成できますか？」

ペストのような魔法の数字から走りましょう！

過度に狭いセレクター


このようなもの：

 ul.nav{} a.button{} div.header{}

これらはセレクターであり、完全に不必要な改良を追加します。 悪いのは：


実際、これらは次のように書くことができます（そうすべきです）：

 .nav{} .button{} .header{}

これで、 .navをol 、 .buttonをinput適用し、サイトをHTML5に合わせたときに、 divをheader要素を持つクラス.headerすばやく置き換えることができます。

ブラウザーのパフォーマンスは、このようなセレクターの影響をあまり受けませんが、それでも影響を受けます。 クラス.button検索してaすべての要素を.buttonするように強制するのはなぜですか。 さらに極端な例を次に示します。

 ul.nav li.active a{} div.header a.logo img{} .content ul.features a.butto

それらはすべて大幅に削減または書き換え可能です。

 .nav .active a{} .logo > img {} .features-button{}

過度に詳細なセレクターに出くわすたびに、なぜこのように設定されているのかを見つけようとしますが、それらを減らすことは可能ですか？

ハードコードされた絶対値


マジックナンバーと同様に、それらはうまく機能しません。 以下に例を示します。

 h1{ font-size:24px; line-height:32px; }

書く方がはるかに良いでしょう： line-height:1.333;

line-height:1.333;

インライン化は、コードの柔軟性を高めるために常に設定する方が適切です。 フォントサイズを変更すると、自動的に変更されます。 また、ピクセル単位で設定する場合は、次のように記述する必要があります。

 h1{ font-size:24px; line-height:32px; } /** * Main site `h1` */ .site-title{ font-size:36px; line-height:48px; }

そのため、ヘッダーのフォントサイズが変更されるたびに。 これははるかに優れています：

 h1{ font-size:24px; line-height:1.333; } /** * Main site `h1` */ .site-title{ font-size:36px; }

違いは小さいようですが、大規模なプロジェクトでは非常に重要になる可能性があります。

ところで、これはline-heightだけに適用されるわけではありません。 コードにハードコードされているほとんどすべての絶対値は疑わしいはずです。

絶対値をハードコードすることが本当に理にかなっている唯一のケースは、スプライトなど、常に特定のサイズが必要なものを扱う場合です。

ブルートフォース


これは、ハードセットマジックナンバーの非常に特殊なケースの1つであり、レイアウトを機能させるために使用されるいくつかの他のトリックです。

 .foo{ margin-left:-3px; position:relative; z-index:99999; height:59px; float:left; }

これはひどいスタイルです！ これらのいルールはすべて、すべての費用をかけて適切な場所にアイテムを詰め込むという唯一の目的のために空想的でした。 このようなコードは、非常に不十分に設計されたレイアウトか、CSSブロックモデルの動作の理解不足、またはその両方を示しています。

よく考えられたレイアウトがあり、ブロックモデルを理解している場合、ブルートフォースを使用する必要はほとんどありません。 そのようなコードを見つけた場合、私はすぐに問題が何であるか、そしてそのような松葉杖を書く必要を取り除くためにいくつかのステップに戻る必要があるかどうかを理解しようとします。

危険なセレクター


危険なセレクターとは、必要以上に幅の広いセレクターを意味します。

 div{ background-color:#ffc; padding:1em; }

なぜ、ページのすべてのdivをこのカーペット爆撃で覆うのですか？ なぜaside{}ようなセレクターが必要なのでしょうか？ またはheader{} 、またはul{}ですか？ このようなセレクターは、必要以上に幅が広く、既に説明したスタイルをキャンセルする必要があるという事実につながります。

header{}例をさらに詳しく見てみましょう。 多くの人がこの要素を使用してページヘッダーを作成しますが、これは完全に正しいものです。 ただし、次のようなスタイルを記述した場合：

 header{ padding:1em; background-color:#BADA55; color:#fff; margin-bottom:20px; }

これは完全に間違っています。 header要素は必ずしもページ全体の見出しを意味するものではなく、異なるコンテキストで何度も使用できます。 .site-header{}などのクラスを使用することをお.site-header{}ます。

このような一般的なセレクターの詳細なスタイルを定義することは非常に危険です。 この要素を再利用し始めるとすぐに、それらは完全に予測不可能な場所に漏れます。

セレクターがターゲット上で正しくヒットすることを確認してください。

別の例を次に示します。

 ul{ font-weight:bold; } header .media{ float:left; }

この例のように、スタイルが要素または非常に一般化されたクラスにどのように適用されるかを見ると、パニックになり始めます。 私はそれらが普遍的すぎることを知っており、私は問題を抱えています。 これらのスタイルは、完全に望ましくない場所で継承される可能性があるため、キャンセルする必要があります。

リアクティブ使用！重要


使用できます!important 。 そして、これは本当に重要なツールです。 ただし、賢明に使用する必要があります。

!importantは、リアクティブではなくプロアクティブに使用する必要があります。

これは、このスタイルが常に優先されることが絶対に必要であり、事前に知っている場合に使用できることを意味します。

たとえば、常にエラーを赤で表示したいことが確実です。

 .error-text{ color:#c00!important; }

テキストの色が青のブロック内にエラーメッセージが表示された場合でも、エラーが赤のままであることを確認できます。 エラーを常に赤で報告したいので、すぐに書き!important 。

しかし、私たちがリアクティブに使用する場合、つまり、発生した問題に対応して、混乱して整理する代わりに先に進むと、これは悪いことです。

!importantリアクティブ使用は問題を解決せず、それを隠すだけです。 症状ではなく病気を治療する必要があります。 問題は解決しませんでした。リファクタリングとアーキテクチャを行う必要がありましたが、スーパー固有のセレクターでブロックしました。

ID


この種の「悪臭」は、大規模なチームで働く場合に非常に重要です。 セレクターの特異性を大幅に高めるため、 IDが悪いとすでに書いています。 これらは役に立たないため、CSSで使用しないでください。 これらを使用して、HTML要素をJavaScriptコードに関連付けますが、スタイルは設定しません。

この理由は簡単です：


これで十分でない場合は、他に何を言うべきかわかりません...

idが表示されたら、すぐにクラスに置き換えようとします。 セレクタの過度の特異性は、大規模なプロジェクトを破壊するため、可能な限り低く保つことが重要です。

最後に、少し練習します。 この問題をエレガントに解決してください。 ヒント： そう -エレガントではありません。 なども。

ぼやけたクラス名


あいまいな名前は、クラスの目的を具体的に説明していない名前です。 .cardクラスを想像して.card 。 彼は何をしていますか？

これは非常にあいまいな名前であり、あいまいな名前は主に次の2つの理由で不適切です。


最初のポイントは非常に簡単です： .cardは.card意味ですか？ 彼はどんなスタイルを求めますか？ プロジェクト管理システムのタスクカード？ オンラインカジノのトランプ？ クレジットカードの画像？ 名前があいまいすぎるため、言うのは難しいです。 クレジットカードを意味するとしましょう。 次に、クラスに.redit-card-image{}という名前を付ける方がはるかに適切です。 はい、はるかに長いですが、はるかに優れています！

あいまいな名前の2番目の問題は、誤ってオーバーライドするのが非常に簡単であることです。 オンラインストアサイトで作業しているとします。 .cardクラスを使用します。これは、アカウントに.cardたクレジット.card番号を意味します。 また、この時点で別の開発者がギフトを購入してお祝いカードを添付する機会を追加します。 また、彼は.cardクラスを呼び出し、 .card競合する独自のルールを作成します。

これは、より正確なクラス名を使用することで簡単に回避できます。 .cardや.userクラス.user霧.user多すぎます。 それらは情報価値がなく、誤って再定義するのは簡単です。 クラス名はできるだけ正確でなければなりません。

おわりに


そのため、「最愛の人」というコードの例をいくつか見てきました。 これらは、常に覚えて、避けなければならないものであり、むしろそれらのごく一部だけであり、実際にはもっとたくさんあります。 数か月から数年続く大規模なプロジェクトで作業する場合、コードを適切な状態に保つことが重要です。

もちろん、各ルールには例外がありますが、個別にアプローチする必要があります。 ほとんどの場合、このコードは慎重に回避する必要があります。

Source: https://habr.com/ru/post/J160177/

More articles:


All Articles