19

.scssファイルがあります。このファイルには特に次のものが含まれています。

nav {
  font-size: 0;
  ul {
    margin: $padding/3;
  }
  li {
    z-index: 10;
    position: relative;
    display: inline-block;
    font-size: $fontSize;
    /**
     * If we want separated, Uncomment!

    margin: $padding/3;
    @include border-radius(5px);

    */
    &:first-child {
      @include border-radius(0 5px 5px 0);
    }
    &:last-child {
      @include border-radius(5px 0 0 5px);
    }
    padding: $padding/3 0;
    @include background(linear-gradient(lighten($textColor, 10%), $textColor));
    border: 1px solid lighten($textColor, 20%);
    a {
      color: $brightColor;
      padding: $padding/3 $padding;
      font-weight: bold;
      text-decoration: none;
      @include transition(.2s all);

    }
    //Nested menues
    ul {
      opacity: 0;
      //display: none;
      position: absolute;
      margin: 0;
      top: 0;
      left: 0;
      right: 0;
      z-index: 5;
      pointer-events: none;
      @include transition(.2s all);
      li {
        @include background(linear-gradient(darken($brightColor, 10%), darken($brightColor, 30%)));
        display: block;
        border: 1px solid lighten($textColor, 20%);
        &:first-child {
          @include border-radius(0);
        }
        &:last-child {
          @include border-radius(0 0 5px 5px);
        }
        a {
          color: $textColor;
        }
      }
    }
    &:hover ul {
      pointer-events: all;
      top: 100%;
      opacity: 1;
      //display: block;
    }
  }
}

それは実際にはどれほど悪い/有害ですか？「ネストされたセレクターを3つ超えないでください！」という話をよく耳にします。しかし、それは本当にどれほど有害ですか？ページの読み込みに目に見える影響はありますか？私が行ったベンチマークはノーと言っていますが、私が見逃しているものはありますか？

4

6 に答える 6

32

これは、ページの読み込み後にDOMとスタイルの動的な操作がどの程度行われるかによって異なります。問題となっているのは、ページの読み込み（ほとんど）や初期レイアウトの遅いセレクターではなく、再描画/リフローです。

さて、スティーブ・スーダースは、平均的なサイトでは、それは単に本当の関心事ではないと言います。ただし、Webアプリや高度にインタラクティブなサイトでは、CSSルールのパフォーマンスが低いと、再描画が必要以上に遅くなる可能性があります。再塗装がたくさんある場合...

Nicole Sullivan、Paul Irish、Steve Soudersなどの専門家は、CSSがJavaScriptと対話する方法と、パフォーマンスの高いCSSセレクターを作成する方法について説明しました。それは深さ以上のものです（セレクターが異なればパフォーマンスも異なります）が、経験則として、問題を回避するために深さと複雑さの両方を制限することですが、パフォーマンスの問題はそれほど多くありません。

ただし、jankfree.orgが指摘しているように、ペイントを高価にするのは特定のコンテキスト（html5rocks.com）の特定のプロパティであるため、子孫や特定のセレクターではありません。長いセレクターや複雑なセレクターは、パフォーマンスの問題というよりも保守性の問題（Nicolas Gallagher）だと思います。保守性はパフォーマンスと相互作用することを忘れないでください。高度に保守可能なコードは、反復が速く、デバッグが容易です（パフォーマンスの問題を見つけて修正するのに役立ちます）。

さて、Sassの最適化について。はい、SassはCSSを最適化できます。ただし、セレクターを最適化することはできません。4レベルのネストされたブロックは、4レベルのネストされたセレクターとして出力されます。Sassは、CSSを機能させずに変更することはできません。著者として、出力を最適化するためにSassの記述方法を最適化する必要があります。私は個人的に、限られた方法でのみネストを使用します（私にとって、Sassのキラー機能は@extend、プレースホルダーを使用してスタイルを作成することです）。ただし、ネストが本当に好きな場合は、 Sass親セレクター参照（または新しい@ at-root ）を使用して出力をある程度微調整できる可能性があります。

私の知る限り、SassにもCompassにも、セレクターを分析して警告するための組み込みツールはありません。ASTを使用してそれを行うためのツールを作成すること（最大深度を設定し、プリプロセッサに警告させること）はおそらく可能です。より直接的には、GooglePageSpeedにはいくつかの情報を提供する既存の機能があります。 SCSSLintにはネストオプションがあります。CSSLintもあります。on_stylesheet_saved（理論的には、GruntやGulpなどをまだ使用していない場合は、Compass構成で実行するために追加できます）。

于 2012-12-11T15:07:12.553 に答える
10

実際のcssセレクターをどのように記述したいかを考えてみてください。要素の子であるという理由だけですべてをネストしないでください。

nav li ul li a { 
    /* over specific, confusing */
}
.sub-menu a {
    /* add a class to nested menus */
}

その数のセレクターをチェーンし始めると、オーバーライドするのが面倒になり、特異性の問題につながる可能性があります。

于 2012-12-13T09:31:13.307 に答える
6

CSSをネストしないでください。cssは、HTMLで行うことを厳密に反映しているため、快適にネストできます。ネストは、.some-child内部にあるコンテキストを提供します.some-parent。これにより、カスケードをある程度制御できます。しかし、他にはあまりありません。

SMACSSが示唆しているように、代わりにクラス名をネストします。つまり、または.child-of-parentの代わりに使用します.parent .child.parent > .child

実際にひどくネストすると、ページが非常に遅くなる可能性があります。githubがどのように差分ページを高速化したかをご覧ください.4レベルを超えてネストしてはならないという開始ルールに従う必要があります。

ただし、さらに一歩進んで、CSSをネストするべきではないと言います。私は自分の意見をブログに投稿しました。これがお役に立てば幸いです。

于 2013-09-10T17:56:26.217 に答える
4

チャイムを鳴らして、他の人が言ったことを強制するだけです。これは、必ずしもパフォーマンスの観点からは悪い習慣です（セレクターを最適化するよりも、ぼかし/影や丸みを帯びたコーナーを削除する方が、ペイント時間が長くなる可能性があります）が、保守性の観点からは悪い習慣です。

セレクターのネストが多いほど、結果のCSSルールはより具体的になります（既に知っています）。したがって、ある時点でそのルールを「切り詰める」場合は、カスケードのさらに下に等しい（またはそれ以上の）特異性のルールを記述して、最初のルールを無効にする必要があります。そこにIDがある場合は、それもはるかに具体的になります（したがって、IDが必要で、後からオーバーライドする必要がないことがわかっている場合を除いて、IDは避けてください）。

これを論理的な結論に導くために、必要がない限りネストしないでください。次のようなルールはありません。

.selector .another .yeah-another {}

これが同じ仕事をするとき：

.yeah-another {}

それは、将来のすべての人（あなたを含む）の生活を楽にするだけです。

于 2013-02-11T22:26:48.127 に答える
4

私の意見：

あなたはあなたの目にどちらが悪いか教えてください

作戦から

nav li ul li a {color: $textColor;}

または提案されているように

.nav-menuitem-menu-menuitem-link {color: $textColor;}

それで...

質問は「SCSSにハイパーネストするのは悪い習慣ですか？」です。（またはそれはSASSですか？）私はノーと言います。しかし、それは補助的な議論です。

WORSEの慣例は、SASS（またはSCSSですか？）の出力を、マシン駆動の状態で本番環境に残すことにあります。

S * SSは、Notepad ++、Git、Chromeと同じように、トリックのバッグに含まれる唯一のツールです。その役割は、いくつかの非常に一般的なプログラミングの概念をいくつかのcssを構築するという点に持ち込むことによって、あなたの生活を少し楽にすることです。その役割はあなたのCSSを構築することではありません。あなたはそれがあなたのためにあなたの仕事をし、完全に使用可能で、読みやすく、実行可能な出力を作成することを期待することはできません。

必要なだけ深くネストしてから、グッドプラクティスに従ってください...

...これは後でCSSを通過し、手作業で調整します。ハイパーネストされた出力を使用して、テスト、ビルドなどを行います。そして、S * SSが上記の最初の例を作成するとき、そのアンカーにクラスを与え、それをで呼び出しますnav .class。

于 2013-09-24T19:13:15.897 に答える
1

あなたの質問に対する直接の答えではありませんが、あなたはあなた自身の目的のために高度にネストされたsassを保持することができますが、それでも使用できます@at-root。こちらをご覧ください。

.parent {
  @at-root {
   .child1 { ... }
   .child2 { ... }
  }
} 

// compiles to ... 

.child1 { ... }
.child2 { ... }
于 2014-05-10T10:32:39.857 に答える