CSS 哲学の誤った提案_html/css_WEB-ITnose

ヒント。この記事は何度か断続的に修正されていますが、まだ満足できていません。もともと、私の散在した CSS の知識体系をまとめたかったのですが、知識体系が不完全なためか、スムーズな内容に結び付けることができませんでした。 。投稿して、みんなで「前世と今世」について語り合いましょう。記事は随時更新される場合があります。

Web の基本的な部分である CSS は、非常に簡単に始めることができます。ただし、CSS は実際にはプログラミング言語ではありません。言語機能が若干弱いため、全体的な保守性が低下することがよくあります。しかし、だからといって誰もが CSS を探求することを止めるわけではありません。彼らは、命名規則、ディレクトリ構造、プリプロセッサ (SASS など)、ポストプロセッサ (PostCSS)、モジュール性などの点で CSS を改善しようと努めています。

私自身の旅について

実際、私は CSS を体系的に勉強したことがありません (今は体系的に学ぶ方法はわかりませんが) いくつかのビデオを見て、中国語版の API をスキャンしてから、写真を切り取り始めました。 . 私のキャリアにおいて、多くの知識ポイントは後から散在するいくつかのブログから学びました。この過程で、私は実際に多くの落とし穴を踏みましたが、そのうちのいくつかは埋められましたが、そのうちのいくつかはプロジェクトの他の学生に害を与え続けました。また、そのせいで、長い間、乱雑でまとまりのない文章を書くことになりました。

おそらく、私が最初に直面した問題は名前の問題でした。なぜなら、私は語彙が少なく、よく使う言葉が足りなくなってしまうからです。当時、メニューやサイドバーなど、真似できる「ネーミングリスト」がネット上にたくさん掲載されていたようです。その後、Bootstrap のような比較的体系的なフレームワークに出会い（学ぶ価値のあることがたくさんあります）、ファイルをカテゴリごとに分割し、固有のプレフィックスを付けるいくつかの管理方法を知りました（当時は SMACSS を知りませんでした）。名詞)、およびいくつかの原子化、機能とスタイルの分離など。 SASS が登場したとき、私は実際に非常に興奮しました。なぜなら、変数、ネスティング、ミックスインなどを使用することで、プログラミングの効率が大幅に向上することは言うまでもありません。その後、同僚のシェアを通じて、BEM の命名方法を知りました（最初はわかりにくかったですが、理解した後は啓発された気分になりました。よく考えてみると、共通の命名規則について全員で合意しました） ）。また、PostCSS を使用して、CSS でいくつかの自動処理タスクを実装します。 React/ES6/Webpack の出現後、JS で CSS を記述する方法が特定の場面で頻繁に現れるようになりました。

上記のすべてが私のプロジェクトに現れました。メンテナンスのためにプロジェクトが切り替えられたとき、私の心にナイフが突き刺さったように感じました。上記の知識が正しいか間違っているというわけではありませんが、チーム内で統一された構造や慣例がないと、プロジェクトの後半になるほど不安定になることがよくあります。これは、CSS の学習曲線を思い出させます (PHP と同様に、ハックがまた登場します)。誰もがスタイルを作成し、それを楽しく維持できるようになります。これは別のレベルです。

個人的にCSSにはセマンティシティと保守性の2つの重要なポイントがあると考えており、最終的にはどちらも開発効率を向上させるためのものです。

意味化は主に読書のニーズに対応したもので、シンプルかつ明確です。チームは一貫したスタイルを維持するよう努めることをお勧めします。その他の場合は、CSS セマンティック思考の内容を参照してください。ここでは説明しません。

保守性は実際には非常に想像上の概念ですが、多くの側面が含まれます。たとえば、十分な拡張性を備えながら、プロジェクトをシンプルかつ柔軟に保つにはどうすればよいでしょうか?もう 1 つの例は、モジュールを機能ごとに分割するかスタイル構造ごとに分割するかということです。スタイルを再利用するにはどうすればよいですか?スタイルの上書きを防ぐ方法、冗長なコードを避ける方法など。

1 回限りの単一ページを除き、一般的なプロジェクト タイプでは、最初に最下層を設定し、全体的なスタイルと使用習慣を統一し、適切な組織構造と命名基準を維持することをお勧めします。行ってもいいし、もっと大きな問題が起きるかもしれない。

例えば、ファイルを階層的に分割する

• 基本フレームワーク（リセット、アイコンフォント、グリッド）

• 共通モジュール（アトミック、統一、標準化されたモジュール）

• ページスタイル（共通モジュールを継承）

BEM/SUIT などと同様の命名方法を使用します。

既存のテクノロジーのオプション

実際、私たちは日常生活の中で、SASS、Compass、BEM、SMACSS、OOCSS のいくつかの概念と設計パターンに多かれ少なかれ触れているはずです。もちろん、絶対的な解決策はありません。現在のプロジェクトに適している必要があるだけです。

BEM

は、プロジェクトの命名規則の問題を解決するために使用されます。 BEM は、親ブロックをプレフィックスとして連結するコネクタを使用して、ブロック、要素、モディファイアの概念を通じて汎用モジュールの命名の一意性を実装します。興味のある学生は、BEM の進化の歴史を見てみることができます。一言で明確に表現するのは難しいことがわかりました。詳しく知りたい場合は、公式ウェブサイトにアクセスしてください。

BEM の独自性と要素間の水平方向の拡張により、少し複雑なプロジェクトでは名前が非常に長くなることがよくあります。現在、BEM から派生したメソッド (SUIT など) が多数存在します。

OOCSS (オブジェクト指向 CSS)

オブジェクト指向 CSS。これは、CSS コードを管理および編成するためのオブジェクト指向のメンテナンス方法です。その哲学は、モジュール性、機能的統一、および関心事の分離です。

OOCSS には 2 つの重要な原則があります

• 構造と外観の分離。スタイルはできる限り独立している必要があり、DOM とは何の関係もありません

• コンテナとコンテンツは分離されている必要があります。 CSS はコンテンツのみに焦点を当てます

OOCSS と SASS の組み合わせは良い選択であり、完全に強力です。

SMACSS(CSS 用のスケーラブルなモジュール型アーキテクチャ)

スケーラブルなモジュール型 CSS。 CSS スタイルを、ベース、レイアウト、モジュール、テーマなど、いくつかの異なるカテゴリのファイルに分割します。一意のプレフィックスの組み合わせをいくつか追加します。

ACSS (アトミック CSS)

アトミック CSS。関心事の分離の原則に従います。

CSS モジュール性

React の急速な爆発に伴い、CSS の他の使用方法も登場しています。 JS でスタイルを定義します。 require/import の助けを借りて、CSS の名前空間の問題が解決され、単一のファイルがシンプルかつ明確になります。組み合わせることにより、迅速な再利用も可能です。一部の CSS であっても、コンポーネントのみにバインドできます。

などの方法があります。上記の方法の方が私にとってはより目を引きます。

今後の方向性

追加予定

多読