CSS_html/css_WEB-ITnose のロジックについて

この記事は、元の著者である @csswizardry の同意を得て、彼のブログの記事「Cyclomatic Complexity: Logic in CSS」を翻訳したものです。元々は私の個人ブログ「The Taste of Chewing」で公開されました。さらに、@hax 先輩はこの記事の元の著者の理論を嘲笑しました。そこで私は一文を付け加えたいと思います。本を信じるよりは、本をまったく持たないほうが良いのです。読者の皆さんはご自身で比較検討してみてください~

これまで長い間、CSS にはロジックがないと述べてきました。これは、CSS には制御フローがなく、それに類似したものも存在しないことを意味します。他のプログラミング言語が CSS を編成する方法。 CSS には本質的にロジックが欠如しているため、プリプロセッサの出現につながりました。ただし、業界では CSS プリプロセッサについてさまざまな意見があります。プリプロセッサを支持する人は、CSS に欠けている機能を補うと信じています。一方、プリプロセッサに反対する人は、CSS は本来の設計では論理的であるべきではないと信じています。本質的に論理的ではありません。プリプロセッサの概念はまったく導入されるべきではありません。

しかし、最近、独特の考え方が突然頭に浮かびました。 CSS にはロジックがあるような気がします。実際にそのように考えている人はほとんどいません。おそらくこれが、CSS にはロジックが欠けていると私たちが常に考える最大の理由です。

複合セレクターは、本体部分 + 条件部分 として理解できることがわかりました。まず例を見てみましょう:

1. div.sidebar .login-box a.btn span {
2. /*...*/
3. }

コードをコピー

この複合セレクターでは、メイン部分は span で、条件部分は IF (.btn 内) AND IF (a) AND IF (.login- 内) です。ボックス) AND IF (.sidebar 内) AND IF (div 上)。

言い換えると、セレクターの各部分は、セレクターを解析するときに満たされる (または満たされない) 必要がある if ステートメントです。この微妙で新しい理解を得て、今までに書いた CSS コードを振り返ってみると、セレクターが適切に記述されているかどうかが効率に直接影響することがわかります。本当に次のロジックを書くのでしょうか? (疑似コード):

1. @if doesn't(span) {
2. @if is-inside(.btn) {
3. @if is-on (a) {
4. @if is-inside(.login-box) {
5. @if is-inside(.sidebar) {
6. @if is-on ( div) {
7. # これを実行します。
8. }
9. }
10. }
11. }
12. }
13. }

コードをコピー

おそらくそうではありません。これはあまりにも間接的で冗長に思えます。これを書くだけで十分かもしれません:

1. @if doesn't(.btn-text) {
2. # Do this.
3. }

コードをコピー

セレクターに制限のレイヤーを追加するたびに、実際には if ステートメントを追加することになります。これは循環的複雑性を引き起こす可能性があります。

循環的複雑度

ソフトウェア工学では、循環的複雑度はプログラムの複雑さの尺度であり、通常、プログラム内の制御フロー (if、else、while など) の数をカウントします。 。プログラム内の制御フローが増えるほど、循環的な複雑さは高くなります。循環的複雑度が高くなるほど、コードが失敗につながる可能性のある潜在的な問題を推測するのが難しくなるため、当然、循環的複雑度はできるだけ低くする必要があります。変更、保守、再利用が難しいため、より多くのコードの実行結果と副作用を考慮する必要があります。また、テストコードを書くのもより困難になります

循環的複雑さの観点から CSS 解析プロセスを考える。 、ブラウザがスタイルをレンダリングしていることがわかります。これまでに多くの決定を下す必要がありました。セレクター内で if ステートメントを作成するほど、セレクター

の

循環的複雑度が高くなります。これは、作成するセレクターの品質が低下することも意味します。このセレクターのルールを満たすためには、より多くの一致が必要になります。条件。同時に、不必要な if ステートメントを導入しすぎると不正確なマッチング (誤検知) が発生するため、私たちが作成するセレクターは明確さと再利用性に欠けます。 .btn 内にスパンをネストして多くの制約を記述するよりも、このスパンを記述する新しいクラス .btn-text を作成する方が良い方法です。これは、より単純で、簡潔で、堅牢です (@if ステートメントが増えると、セレクター ルールが満たされる可能性が低くなります)。

ブラウザーが作成したセレクターを右から左に解釈する方法に注目する価値があります。セレクターを作成するときに最初に頭に浮かぶ疑問が「これはスパン要素ですか?」である場合、通常はセレクターを冗長にしすぎます。別の角度から考えて、明確かつ正確なセレクター ルールを作成し、冗長な条件ステートメントを完全に放棄する必要があります。

あまりにも広範なルールを記述しないでください。その結果、作成したセレクターが一致の開始時に多数の DOM 要素を選択し、その後、より多くの条件ステートメントを使用して一致したオブジェクトを徐々に削除する必要があります。より良いアプローチは、セレクターのルール解析の開始時から可能な限り少数の要素と一致するようにすることです。

循環的複雑性は CSS にとって比較的高レベルの原則ですが、作成するセレクターに含まれるロジックを考慮するためにそれを使用すると、より優れたコードを作成できる可能性があります。

いくつかの分かりやすい小さなルール

セレクターを最小限にします: セレクターにルールを追加するたびに、余分な if ステートメントを追加することになります。これらの if ステートメントを声に出して読み、追加する必要があるかどうかを慎重に検討してください。作成するセレクターは常に合理的かつ簡潔にする必要があります。 循環的複雑さが最小化されていることを保証します: Parker などのツールを使用して、作成したセレクターの循環的複雑さをテストします (参考ドキュメント: セレクターごとの識別子) このチェック条件が必要ない場合は、セレクター には入れないでください。CSS で入れ子構造を使用する必要がある場合もありますが、ほとんどの場合はそうではなく、インセプション ルールを完全に信頼することさえできません。 右側からセレクターを記述する方法を検討します: 一致する必要がある要素のタイプから始めて、正しい一致を完了するために余分な CSS コードをできるだけ少なく記述します。 明確な目的を持ってセレクターを作成します

: ページを適切に表示するために偶然作成されたコードではなく、作成するセレクターが実際に必要なものであることを確認してください。

セレクターは CSS 構造の最も基本的な部分であり、作成するコードが合理的かつ簡潔であることを確認してください。