5

私はウェブサイトのIT側全体(インフラストラクチャと開発の両方)を監督する責任があり、主要なフロントエンド開発者と意見の相違があります。彼のアプローチは、それぞれが1つの機能をもたらす個々のクラスを作成し、要素のスタイルを設定するために必要な数のクラスを組み合わせることです。

HTML
<div class="float_left padding_10 width_60_percent"></div>
<div class="float_left width_30_percent"></div>
<div class="float_left padding_10 width_10_percent"></div>
CSS
.float_left { float: left; }
.padding_10 { padding: 10px; }
.width_60_percent { width: 60%; }
.width_30_percent { width: 30%; }
.width_30_percent { width: 10%; }

長所:

--HTMLを介したCSSの理解:HTMLのクラス名を見るだけで、CSSが何をしているのかを理解できます。
-作成のしやすさ:クラスのセットを定義したら、それらをHTMLで組み合わせるだけで、常に新しいCSSを作成する必要はありません。
-メンテナンスのしやすさ:上記と同じ理由。
-移植性:どのWebサイトでも同じアプローチを使用できます(彼はさまざまなプロジェクトに取り組んでいる請負業者であるため、これは彼にとって理にかなっています)。
-小さいCSS:レイアウトが特定のクリティカルサイズに達し、同じクラスが何度も再利用されている限り(これは適切なレイアウトの場合ですが、例が簡潔であるため、上記には明らかに反映されていません)。

短所:

-より大きなHTML
-CSSの部分に興味がない場合はHTMLが読みにくくなります(ビューを作成する私のバックエンド開発者は興味がありません)。
-クラスセレクターに基づいてJavascriptを統合するのは難しい(jQueryを使用しています)。

私のアプローチは、CSS自体の記述/保守の容易さによって決まるのではなく、HTMLコードの大部分がCSSの統合のみを目的として使用され、パフォーマンスに影響を与えるという懸念によって決まります。一度提供されてキャッシュされる大きなCSSと、すべてのページビューで帯域幅を節約する小さなHTMLを使用する方が、逆ではありません。したがって、私は次のアプローチを選択します。

HTML
<div id="column_left"></div>
<div id="column_middle"></div>
<div id="column_right"></div>
CSS
#column_left { float: left; padding: 10px; width: 60%; }
#column_middle { float: left; width: 30%; }
#column_right { float: left; padding: 10px; width: 10%; }

長所/短所
上記の反対。

軽量のHTMLコードを使用することは、Webサイトの成長を実現するために重要であると感じています。ページの
読み込みが速くなり、SEOとユーザーエクスペリエンスに役立ちます。
-同じ帯域幅でより多くのページを提供できるため、インフラストラクチャのコストを節約できます。

事実上の回答を得るために、「大きな」Webサイトをスキャンして、IDとクラスを使用してHTMLのどの部分が割り当てられているかを確認しました。コードは次のとおりです。

<?php
require_once 'simple_html_dom.php';
$pages = array('http://www.amazon.com', 'http://www.ebay.com', 'mywebsite.html', 'http://stackoverflow.com','facebook.html');
foreach ($pages as $page) {
    echo "\n$page\n";
    $html = new simple_html_dom();
    $string = file_get_contents($page);
    $total = mb_strlen($string);
    echo "HTML = " . $total . " characters\n";
    $html->load($string);
    foreach (array('id', 'class') as $attribute) {
        $count = 0;
        $elements = $html->find("*[$attribute]");
        foreach ($elements as $element) {
            // length of id or classes, + id="..." or class="..."
            $count = $count + mb_strlen($element->$attribute) + mb_strlen($attribute) + 3;
            //echo $element->$attribute . "\n";
        }
        echo "  -from $attribute attributes = $count -> " . round($count / $total * 100) . "%\n";
    }
}

結果は次のとおりです。

http://www.amazon.com
HTML = 101680 characters
  -from id attributes = 943 -> 1%
  -from class attributes = 6933 -> 7%

http://www.ebay.com
HTML = 71022 characters
  -from id attributes = 1631 -> 2%
  -from class attributes = 4689 -> 7%

ourwebsite.html
HTML = 35929 characters
  -from id attributes = 754 -> 2%
  -from class attributes = 2607 -> 7%

http://www.imdb.com/
HTML = 74178 characters
  -from id attributes = 1078 -> 1%
  -from class attributes = 5653 -> 8%

http://stackoverflow.com
HTML = 204169 characters
  -from id attributes = 3376 -> 2%
  -from class attributes = 39015 -> 19%

facebook.html
HTML = 419001 characters
  -from id attributes = 6871 -> 2%
  -from class attributes = 85016 -> 20%

これまで「my」アプローチを使用してきましたが、クラスのid and属性に関連するコードの割合が他の大きなWebサイトと同じ割合(それぞれ約2%と7%)に保たれていることを嬉しく思います。それでも、その選択を検証するために、経験豊富な開発者/ウェブマスターが答えられることを願って、次の質問をしたいと思います。

Q1:2つのアプローチのいずれかに賛成/反対する他の賛否両論がありますか?

Q2:あなたの経験から、軽量のHTMLコードを使用することを心配することは重要ですか、それとも圧縮やその他の基準を使用すると無視できるようになりますか(たとえば、フロントエンド開発者との戦いにより多くのお金を費やします)?

結果を見ると、属性idclass属性に関連するコードの量にパターンがあるように見えることがわかります(ただし、より多くのWebサイトをスキャンすると、より正確な画像が得られることはわかっています):-すべての
Webサイトの画像は約1%から2です。id属性に関連するHTMLコードの% 。
-4つのWebサイトには、HTMLコードの約7%がに関連していclassesます。
-他の人は、HTMLコードの約20%がに関連していclassesます。

Q3:これらのパターンの技術的な説明(たとえば、FacebookとStackoverflowが同じフレームワークを使用してCSSを生成している)はありますか?

4

3 に答える 3

3

フロントエンド開発者が行っていることは、オブジェクト指向css(OOCSS)と呼ばれ、サイトの速度に役立つと信じられている人もいます。

ここでOOCSSの議論を再ハッシュする気はないので、このFAQを読んでください。

https://github.com/stubbornella/oocss/wiki/faq

編集:コーディング標準に関しては、amazon/ebayよりもfacebook/stackの方が間違っています。よりプログレッシブなサイト(fb / stack)のクラスの割合が高いように見えることに注意してください。

于 2012-05-02T10:11:05.123 に答える
3

私は企業のWebソフトウェアプロジェクトのフロントエンド開発者であり、約50人がコードを記述しており、そのほとんどがバックエンドです。最初は、cssで多くの継承を使用して、コードを軽量化するためにクラスをできるだけ少なくすることに同意しました。そのため、「できるだけ少ないクラス」のアプローチを使用してきました。

A1:いくつかのクラスのアプローチでは、多くのcss定義が要素名を使用してスタイルを追加します。このようなものは、開発者の作業を楽にしますが、cssは右から左に分析される.left-column section li a ため、実際にはcssが遅くなります。私の例では、ブラウザは最初にすべてのリンクをチェックし、次にすべてのリスト要素をチェックします。私がa.lc-linkcssを持っていれば、検索する要素が少なくなり、使用が速くなります。

私たちが遭遇するもう1つの問題は、モジュール性の欠如です。私は素敵な要素をスタイリングすることができます、それを呼びましょう、.flight-datesそしてそれは素晴らしい働きをします。次に、新しいユースケースが登場し、誰かがプライマリページモジュールとしてではなく、フォームの途中で使用したいと考えています。ただし、フォームはフォームタグで単一のクラスを使用するように構築されており、他のすべては継承を使用します。すべての継承は.flight-datesを汚染するため、戻ってcssにさらに高い特異性を追加する必要があります。したがって、すべての.flight-datesスタイルには、フォームの子である場合の追加の定義があります。

そのようなことは週に3、4回起こります。クラスが少ない=柔軟性が低い+非常に高い特異性を持つ醜いスタイルシートは、私がそれから取り除いたものです。

A2:ページで発生するJavaScriptの量により、使用されるクラスの量はほとんど無関係になりました。私が知っているDOM操作速度には何の違いもありません。したがって、いくつかのクラスのアプローチから得た可能性のある利点はすでに失われています。

テストに関しては、cssのダウンロードとcssの解析は同じではないことを忘れないでください。

また、前述のcssの修正により、バックエンド開発者とフロントエンド開発者の両方の処理が実際に遅くなりました。バックエンドを簡単にするためにできるだけ少ないクラスを使用しようとしたため、バックエンドには、新しいコンテキストに置くと赤ちゃんのように泣くコンポーネントが残り、フロントエンドは6か月前に作成したcssを変更する必要があります。私は個人的に何週間も無駄にしてきました。

作業が遅くなり、パフォーマンス上の利点はありません。

A3:SassやLessのようなものは、cssで一般的なパターンにつながる傾向があります。また、多くの優れたグリッドと関連するcssフレームワークは、共通のクラス名を使用しています。jQueryuiまたは960グリッドを考えてみてください。

私たちの過ちから学びたいのなら、フロントエンドの人の話を聞いてください。 コンポーネントは常に期待どおりに動作するため、バックエンドの人々はより幸せになります。フロントエンドの人々は、堅牢でファイアアンドフォーゲットのcssを記述できるため、ポップアップするたびに新しいユースケースを再ハッシュする必要がないため、より幸せになります。あなたのhtmlは少し大きくなりますが、正直なところ違いはごくわずかです。それが重大なボトルネックにつながるとは思わない。あなたのcssはより速く実行されます。最終的には、作業にかかる時間が短縮されます。

于 2012-05-02T10:41:38.390 に答える
0

私は最近グーグルからoocssアプローチを奨励しているように見える記事を見ました、しかしそれはほぼ確実により大きなhtmlとcssを作成します、そしてそれはより大きなサイトで本当に重要です。

oocssを使用している開発者に会ったことはありません。そのため、サイトが他の開発者によって作業されている場合、または将来的にそうなる可能性がある場合は、より多くの開発者が従うアプローチを採用する方がよいかもしれません。

于 2012-05-02T10:15:46.170 に答える