CSSをHTMLから分離することが重要なのはなぜですか（または、そうでしたか）。

Question

はじめに

私は最近 React：JSのCSS のスライドを見て、CSSをJSを使用して適用するというアイデアを本当に気に入っています（そしてJSXでは、これはすべてのHTML、JS、CSSを1つのファイルに含めることを意味します、これは、小さな再利用可能なコンポーネントに最適です）;しかし、私はセマンティック/パフォーマンス/何でも起こりうる問題を心配しています、それが私を...

質問

CSSをHTMLから分離することがなぜ重要なのですか？

私が考えることができる明らかな理由は、CSSにスタイル設定を処理させながら、重複を避け、HTMLを純粋にセマンティックに保つことです。私はJSで両方を行うことができます。他に欠けている理由はありますか？

Edit：私はここで非常に重要なことを逃しました-bigWebアプリケーションのアーキテクチャを設計していますが、小さなブログのものではありません。独自のビルドパイプラインがあり、事実上あらゆる構成が可能です。

編集＃2：懸念の分離について多くの議論が見られますが、それらのほとんどは（私の理解では）HTMLだけを変更するか、またはCSSと、HTMLとCSSを並行して編集するのではなく。これは小さなウェブサイトの場合に当てはまるかもしれませんが、私のコミット履歴は私に反対を示しています-私は通常HTMLとCSSの両方を一緒に編集します。したがって、すべてのCSSからすべてのHTMLを分離する代わりに、各コンポーネントを互いに分離します。

これを行うことの重大な欠点はまだありません。

キャッシング？各コンポーネントファイルをキャッシュできます。
意味論？ HTMLではセマンティックスを、CSSではスタイルを1つのファイルに含めることができます。
再利用と保守性？関係が不明確な一連のHTMLファイルとCSSファイルを使用する代わりに、コンポーネントを分離すると、さらに簡単になります。
MVC？各コンポーネント内にミニMVCを含めることができます。

編集＃3：参考までに：@keithjgrantがこの質問についてのすばらしい記事を書きました： http://keithjgrant.com/posts/against-css- in-js.html

Arseni Mourzenko · Accepted Answer

1.なぜwas CSSをHTMLから分離することが重要なのですか？

当初、JavaScriptは空想的な（そして非常に煩わしい）アニメーションに使用され、WebサイトはグローバルにHTMLとCSSの集まりにすぎませんでした。サーバー側では、フレームワークは現在ほど多くなく、強力ではありませんでした。

これはあなたに選択肢があることを意味しました：

コンテンツ（HTML）とスタイル（CSS）を適切に分離するか、
または、CSSコードをHTMLファイル内に配置するか、単にHTMLアナログ（<div color="red">I'm red.</div>）。

最初の選択肢には、2つの重要な利点があります。

コードの重複がないため、Webサイトのevery pageで一般的に使用される要素の色を赤から紫に変更し、コードベースを1つだけではなく数百に変更すると、価値が高まります。
帯域幅使用量の削減（ほとんどのビジターが56 Kbpsインターネット接続）を持っている場合に非常に重要です）、クライアントキャッシュのおかげで、
コンテンツに触れずにスタイルを変更する仮想的な能力：パート3で説明するポイント。

これは、なぜ多くの個人ウェブサイトが<div color="red">I'm red.</div>スタイルは当初、より大きく人気が高まると、純粋なCSSへの移行を余儀なくされました。

2.なぜis今日、CSSをHTMLから分離することが重要なのですか？

Webアプリをアクセシブルにする法的義務がなく（アクセシビリティによってJavaScriptなしのバージョンが必然的にもたらされるため）、アプリがすでにコア機能のためにJavaScriptを広範囲に使用していると想定します。

開発レベル：

コンテンツをスタイルから分離しても、上記と同じ理由、つまりコードの重複のために役立つ場合があります。 2つの要素が同じスタイルを共有する場合は、スタイルを2回記述するのではなく、一度定義してから再利用する必要があります。それを2回書くと、説明がわかりにくいメンテナンスの問題が発生します。

コンテンツの格納方法やスタイルの格納方法は問題ではないことに注意してください。コンテンツは、一般に、（1）データベースからのデータと（2）ビジネスロジックに基づいてWebアプリによって生成されますが、スタイルは静的な形式で定義され、CSSファイル、XAML、またはまったく異なるものになります。

これが2番目のポイントにつながります。このコンテンツとスタイルがどのように提供されるかです。

クライアントレベル：

コンテンツとスタイルを提供し、コンテンツにスタイルを適用する方法は異なる場合があります。通常のHTML/CSS、おそらくAJAXリクエスト、DOMなど）を含む複雑なソリューションです。前の帯域幅引数はここでは関係ありません。ほとんどのユーザーは8 Mbps以上の接続を使用しているだけでなく、AJAXリクエストもキャッシュできます。

代わりに、代替の選択は、特定のフレームワークによって提供される特定のソリューションの使いやすさ、および開発者がこのタスクをフレームワークに委任することの快適さに基づいています。

ここに物語があります。

ASP.NET MVCの一部のバージョンには、バンドルと呼ばれる機能が追加されています。 CSSファイルとJavaScriptファイルを自分で提供するのではなく、フレームワークにそれらのファイルを提供するだけで、フレームワークがすべての仕事をしてくれました。ファイルを縮小して、1つのファイル（1つのCSSファイルと1つのJavaScriptファイル）として送信しました。

しかし、どんな魔法の道具としても、それには限界がありました。それは小さなウェブサイトにうまく機能し、ある日、私のおばあちゃんがC＃でプログラミングを開始して彼女の個人的なウェブサイトを作ることにした場合、私は彼女がバンドルを使用するべきだと彼女に最初に説得します。

話はより複雑なものとは異なりました。 LESSファイルを含めたい場合はどうすればよいですか？まあ、ASP.NET MVCの優れたアーキテクチャのおかげで、それを行う可能性がありましたが、これは数十ページのドキュメントを読んで、数十のクラスを作成することを意味しました。ゼロからのバンドルレスソリューションを作成するコードが少なくて30分未満で実行できるのに、なぜそれをしたいのかわかりません。

JavaScriptについても同様です。 ASP.NET MVCにGoogle Closure Compilerを使用してファイルを縮小するように依頼できますか？おそらく簡単ではないか、少なくともASP.NET MVCの以前のバージョンではそうではありません。

フレームワーク機能は優れており、あなたの人生を簡素化することができますが、それらはまた、制限になる場合があります。小規模な個人プロジェクトは、これらから多くの利益を得ることができます。大規模なプロジェクトは、フレームワークを拡張するよりも開発が簡単かつ迅速なカスタムメイドのソリューションに依存する傾向があります。

すべてのページに関連するスタイルを生成したり、キャッシュされたスタイルを管理したりする優れたフレームワークがあると想像してください。

これにより、帯域幅をさらに削減できます。ホームスタイルで600のスタイルがあり、30のみが使用されている場合、これは、570のスタイルが少ないため、ワイヤを介して送信し、クライアントで処理する必要があります。たぶん、私のホームページは数秒速く表示されます。
これにより、たとえばグローバルステートを削除するなどして、私の生活とコードをよりシンプルにすることができます。たとえば、特定のスタイルをそのページにのみ表示する必要があることがわかっている場合、別のページで使用できるセレクターを選択するリスクを冒すことなく、フレームワークにどのセレクターを使用すべきかを判断させます。

今、個人的には、それを行うことができるフレームワークを見たことがありません。また、私が見たものはあまりにも制限されているように見えますが、私の人生を簡素化していません。

プレーンCSSを書く方が簡単ですか？私はそう言うでしょう。 CSSには弱点がありますが、それらの多くはLESSやSassなどのプリプロセッサによって解決されます。フレームワークにコードを縮小されたCSSに処理させながら、LESS/Sassの機能を使用できることは素晴らしいことです。 しかし、今日のツールがこのように機能する方法からより強力で抽象的なものに移行するのに十分成熟しているとは思えません

3.懸念事項の分離。それは...ですか？

質問の中で懸念の分離について言及されていたので、この特定の側面を個別に強調したいと思います。

懸念の分離について多くの議論が見られますが、それらのほとんどは（私の理解では）HTMLまたはCSSを同時に変更するのではなく、HTMLまたはCSSを同時に変更することがより頻繁であるという仮定に基づいています。これは小さなウェブサイトの場合に当てはまるかもしれませんが、私のコミット履歴は私に反対を示しています-私は通常HTMLとCSSの両方を一緒に編集します。したがって、すべてのCSSからすべてのHTMLを分離する代わりに、各コンポーネントを互いに分離します。

HTMLを変更すると、ほとんどの場合、必然的にCSSも変更されます。これはDAL/BL/PLとは異なり、たとえば、他に影響を与えずにデータベースレイヤーを交換できます。コンテンツを変更すると、プレゼンテーションも頻繁に変更される必要があります。

たとえば、要素に新しいボタンを追加しているとします。当然のことながら、要素が小さすぎるため、幅を調整する必要があります。

理論的には、その逆は当てはまりません。CSSコードをすべて破棄し、まったく別のことを実行できることが期待されます。同じコンテンツ、異なるプレゼンテーション。

MicrosoftがリリースしたWPF（一部のWindowsアプリケーションのインターフェイスを強化するテクノロジで、以前よりもインターフェイスを設計してスタイルを適用するのが簡単になりました）と、基盤となるXAML（インターフェイスのコンテンツを説明するために使用される言語）ボタン、リスト、コンボボックス、およびスタイル（丸みを帯びたコーナー、フォント、トランジション）など、広告全体で強調された利点の1つは、コンテンツとは無関係にアプリケーションのスタイルを設定できることでした。

マイクロソフトはそのためのツールさえ作った。これはMicrosoft Blendと呼ばれます。チームの理論的なワークフローは次のとおりです。

インタラクションデザイナーは、アプリケーションのワイヤーフレームを紙の上に作成します。
ソフトウェア開発者はこの紙を選び、Visual Studio（Microsoftの世界で開発者のツールナンバー1）でアプリケーションのさまざまなウィンドウを作成し、ボタン、リスト、コンボボックスを配置します。
次に、Visual Studioではなくソースコードを開くインタラクションとグラフィカルデザイナに未完成のアプリケーションを提供します。これらはデザイナであり、IDEを使用しません。ただし、Microsoft Blendでは、ソースコードではなく、見栄えのよいインターフェイスが表示されます。コントロールの移動、色とフォントの設定、トランジションとアニメーションの追加など、アプリの視覚的な側面を視覚的に変更できます。その間、開発者はボタン、リスト、コンボボックスの背後にある機能の実装を完了します。

ここにあります：

同じ初期要件：コンテンツとは無関係にスタイルを変更できること、現在のプレゼンテーションを別のプレゼンテーションに完全に置き換えることができること。
同じ制約：コンテンツが変更された場合、プレゼンテーションはほとんどの場合影響を受け、変更も必要になります。

MicrosoftはWPFとXAMLで素晴らしい仕事をしましたが、小さな問題がまだあります。時々、スタイルを変更する必要があるときは、コンテンツも変更する必要があります。つまり、チームのワークフローはむしろ：

インタラクションデザイナーは、アプリケーションのワイヤーフレームを紙の上に作成します。
ソフトウェア開発者はこの紙を選び、Visual Studioでアプリケーションのさまざまなウィンドウを作成し、ボタン、リスト、コンボボックスを配置します。
インタラクション、グラフィックデザイナー、ソフトウェア開発者は、将来のアプリケーションのインターフェースを並べて作業し、定期的なコミュニケーション、定期的な会議などを確実にします

これがまさにHTMLとCSSで起こることです。理論的には、スタイルで作業するときにHTMLに触れないでください。実際には、CSSで作業するときは常にマークアップを調整しています。

現在のマークアップでは特定のスタイルが不可能な場合、
または、現在のマークアップでそれを行うと、あまりにも多くのCSSコードが必要になるか、非常に不明瞭で保守が難しいコードが生成されます。

HTMLを変更するとき頻繁に CSSに取り組んでいるとき、これは次のような兆候である可能性があります。

そもそもHTMLコードはうまく機能していませんでした。
HTMLコードは「スタイリングを考慮せずに」作成されました。 CSSを熟知している経験豊富なプログラマーは、スタイル設定が簡単なHTMLコードを生成します。 HTMLを習得しているが、CSSについて何も知らないプログラマは、大量の変更を必要とするコードを記述します。

極端な例として、 CSS Zen Garden は、元々よく行われていた変更されていないHTMLコードに基づいて、純粋なCSSで何ができるかについての興味深い研究事例です。

実際には、ほとんどのWebサイトとWebアプリケーションは反対側にあります。視覚的に「再設計」されたことがわかっているすべてのサイトが完全に変更されました：異なるCSS、異なるHTML、異なるJavaScript、異なるコードビハインド。

^{L LESSのサポートは、ASP.NET MVCの新しいバージョンでは自動的に行われると思います。}

Bhojendra Rauniyar · Answer

重要な点は懸念の分離：

読みやすさ：

巨大なHTMLファイルが原因を探す代わりに、CSSルールを含むファイルを開く方が間違いなく簡単です。したがって、あなたのウェブサイトを維持する方が簡単です。

キャッシュ可能性：

HTMLコードはサイトのすべてのページで異なりますが、CSSは異なりません。すべてのページでそれらをリロードするのはばかげています。別個のファイルでCSSスタイルを分離すると、キャッシュ可能になります。そのため、ページの読み込み時間にも影響します（CSSを縮小して、ページの読み込み時間を短縮します）。

sareed · Answer

それはすべて分離についてです。 HTML、CSS、JSを分離することは、可読性と保守性のために必要です。あなたが[〜＃〜] could [〜＃〜]小さなサイトのためにそれらをすべて一緒にメッシュ化している間、絶対にそうすべきではありません。設計するときは、常にサイトを（可能な範囲内で）できるだけ保守可能で拡張可能なものにしようとする必要があります。

また、JSは重すぎて、マークアップやスタイルに定期的に使用することはできません。大規模なサイトの場合、これによりパフォーマンスが大幅に低下します。

Yannic Welle · Answer

Html、css、jsをコードごとに分離することで、Web開発はModel-View-Controller-Patternに準拠していると言えます。

また、html、css、jsは非常に絡み合っていることが多いため、異なるウィンドウでそれらを見ると、時々非常に便利です。