最近、CSS フレームワークの紹介をよく見かけますが、先日「私の狭い視野では、本当に CSS フレームワークと呼べるものは見たことがありません～」と言いました。私の視野が狭すぎるのか、それとも世界が広すぎるのか、まだ見えていないものがたくさんあると感じています。
まず、私が同意する概念を見てみましょう。
フレームワークは、ホワイトボックスとブラックボックスの 2 つのタイプに分類できます。
継承ベースのフレームワークは、ホワイトボックス フレームワークと呼ばれます。いわゆるホワイト ボックスには可視性があり、継承された親クラスの内部実装の詳細はサブクラスに知られています。ホワイトボックス フレームワークを利用するアプリケーション開発者は、サブクラスを派生するか、親クラスのメンバー メソッドをオーバーライドすることによってシステムを開発します。サブクラスの実装は親クラスの実装に大きく依存しており、この依存関係により再利用の柔軟性と完全性が制限されます。ただし、抽象クラスは基本的に具体的な実装を提供しないため、この制限を解決する方法は、抽象親クラスを継承することだけです。ホワイトボックス フレームワークはプログラムのスケルトンであり、ユーザー派生のサブクラスはこのスケルトンの付属品です。
オブジェクトコンポーネントのアセンブリに基づくフレームワークは、ブラックボックスフレームワークです。アプリケーション開発者は、オブジェクトを並べ替えて組み立てることによってシステムを実装します。ユーザーはコンポーネントの外部インターフェイスを理解するだけでよく、特定の内部実装を理解する必要はありません。さらに、アセンブリは継承よりも柔軟であり、継承は静的なコンパイル時の概念にすぎません。
理想的な状況では、必要な機能は既存のコンポーネントをアセンブルすることで得られます。実際には、使用可能なコンポーネントがニーズを満たしていない場合があります。したがって、既存のコンポーネントを使用して新しいコンポーネントをアセンブルするよりも簡単である場合があります。システム開発ではホワイトボックスとブラックボックスを同時に使用します。ただし、ホワイト ボックス フレームワークはブラック ボックス フレームワークに向かって発展する傾向があり、ブラック ボックス フレームワークはシステム開発が達成したい理想的な目標でもあります。
現在インターネット上にある数多くの CSS フレームワークを振り返ってみましょう (YUI は「YUI CSS Frameworks」ではなく「YUI Library CSS Tools」と呼ばれています)。実際にフレームワークの概念に基づいて記述されているものはどれだけあるでしょうか。スタイルの基本クラスを定義するだけです。もちろん、このフレームワークに対する理解は全員が同じではないかもしれませんし、私の言うことに同意できないかもしれません。
CSS フレームワークについてもう一度話しましょう。私はこのようなことを 1 ～ 2 年前から試していました。大規模な Web サイトの場合、フロントエンド開発にはソリューションが必要です。当然、フレームワークが第一の選択肢になります。遠すぎるのと弱すぎるのが残念ですT_T 必要なのは次の2つだけです。
以下のコンテンツを管理するもの
クラス/コンポーネント
明らかに、1 番目の点は CSS ではそれができないということであり、2 番目の点は他の言語に比べて非常に弱いということです。
1 年ほど前、中規模の Web サイトを制作していたとき、怠け者になるためにコンテンツをモジュール化し、プログラマーにページをまとめてもらうことを考えました。一般的な方向性としては、プログラマーは、どのコンテンツを使用するかに応じて、対応する HTML と CSS を使用するだけで済みます。これは、誰にとっても便利です。コードを繰り返す必要はありません。皆さんこんにちは。
同じ Web サイトでは、同様のコンテンツ ブロックが複数回使用されるのが通常です。これにより、画像リスト、ユーザー アバターのリスト、グループ アイコンのリストなどのモジュール化も可能になります。同じ単語をこのように書くべきですか？
.photoListUesr,.photoListGroup{ /*_*/ }
不可能というわけではありませんが、この時点で、似たようなスタイルを追加する必要がある場合はどうすればよいでしょうか。私はどうですか？次のように使ってみました。
<div class="写真リストUesrCt" />
<div class="photoList GroupCt" />
この場合、共通の式を最初から分離し、プロトタイプとして .photoList を使用し、追加のクラスで詳細を処理します。数日前、私はオブジェクト指向の XHTML と CSS プログラミングについて書きました。実際、残りの半分は詳細なサンプルでしたが、あまりにも多くのサンプルを作成しなければならなかったので、書き終わりませんでした。コアはすでに作成されています ^^ もちろん、これにも特定の問題があります。つまり、最初のプロトタイプの定義には細心の注意を払う必要があり、将来改訂される場合でも定義する必要がないようにする必要があります。変更されました。 CSS では、基本的に、フレームワークは最大でも 1 つの Web サイトにのみ適合します。もちろん、Web サイトが十分に大きい場合は、この方法で使用するのが合理的です。
HTML と CSS のモジュール化が進むほど、ファイルの断片化が進み、この問題はさらに深刻になります。 HTML は、アプリケーションが最終的にマージして 1 つのコピーを出力するため、扱いが簡単ですが、CSS は通常、破棄されて直接使用されます。先ほどの例で言えば、Web ページに CSS をインポートする方法は次のようになります。
@インポートURL(/xxx/photoList.css);
@インポートURL(/xxx/UserCt.css);
@インポートURL(/xxx/GroupCt.css);
プログラムを使用してページを結合することも検討できますが、それは使いやすく、リクエストの数に比例するため、一般的には誰もが手動でファイルを結合することを選択します。人間の脳はコンピューターよりも知能が高いですが、多くの場合、人間の脳の計算能力はコンピューターほど優れていません。私はかつて、CSS リリースのメカニズムをサーバー側のプログラムで処理するというアイデアを持っていました。大まかな方向性としては、Web サイトのアクセス ログを通じてサイト全体のさまざまなページの使用状況を分析し、そのプログラムを使用して一般ユーザーがどのページを使用しているかを計算するというものです。順序 (CSS ファイルの順序は優先順位に影響します) など、さまざまな計算と圧縮出力が必要です。
残念ながら、このような複雑な番組は、1 つの放送局、または同じシリーズの放送局のグループにのみ適している可能性があります。少し面倒ではありますが、ポータルレベルのWebサイトではこの方法を使う必要があると思います。もちろん、チーム全体が同じデザインパターンを使用することが前提です。
PS: 上記の CSS 公開プログラムはまだ試していないので、興味のある方は試してみてください。何か事故が起きても、私は責任を負いません。
もちろん、上記のものを CSS フレームワークと呼ぶことはできません。結局のところ、CSS は単なる記述言語にすぎません。
昨夜、Yueying とローストダックを食べていたとき、このことについて話したところ、統合されたフロントエンド ソリューションがあるかどうか尋ねられました。 JS がコンポーネント化される場合にも同じ問題に直面することになるため、同様の公開メカニズムを JS にも適用できるはずです。でも、完全に統合された解決策はまだ考えていない。たぶん、Yuying が私にあと数回アヒルのローストをごちそうしてくれるだろう、そうすれば分かるだろう。