CSSフレームワークについてのディスカッション

最近、CSS フレームワークの紹介をよく見かけます。数日前に「私の狭い視野では、本当に CSS フレームワークと呼べるものを見たことがありません～」と言ったことがあります。私の視野が狭すぎるのか、それとも世界が広すぎるのか、まだ見えないものがたくさんあると感じています。

まず、私が同意する概念を見てみましょう:

フレームワークは、ホワイト ボックスとブラック ボックスの 2 つのフレームワークに分けることができます。

継承に基づくフレームワークは、ホワイトボックスフレームワークと呼ばれます。いわゆるホワイト ボックスには可視性があり、継承された親クラスの内部実装の詳細はサブクラスに知られています。ホワイトボックス フレームワークを利用するアプリケーション開発者は、サブクラスを派生するか、親クラスのメンバー メソッドをオーバーライドすることによってシステムを開発します。サブクラスの実装は親クラスの実装に大きく依存しており、この依存関係により再利用の柔軟性と完全性が制限されます。ただし、抽象クラスは基本的に具体的な実装を提供しないため、この制限を解決する方法は、抽象親クラスを継承することだけです。ホワイトボックス フレームワークはプログラムのスケルトンであり、ユーザー派生のサブクラスはこのスケルトンの付属品です。

オブジェクトコンポーネントの組み立てに基づくフレームワークはブラックボックスフレームワークです。アプリケーション開発者は、オブジェクトを整理して組み立てることによってシステムを実装します。ユーザーはコンポーネントの外部インターフェイスについてのみ知る必要があり、特定の内部実装について知る必要はありません。さらに、アセンブリは継承よりも柔軟であり、継承は静的なコンパイル時の概念にすぎません。

理想的な状況では、必要な機能は既存のコンポーネントをアセンブルすることで得られますが、実際には、利用可能なコンポーネントがニーズを満たすには程遠い場合もあります。既存のコンポーネントを使用して新しいコンポーネントをアセンブルするよりも、継承によって新しいコンポーネントを取得する方が効率的である場合があります。 . 簡単なのでホワイトボックスとブラックボックスを同時にシステム開発に活用します。ただし、ホワイト ボックス フレームワークはブラック ボックス フレームワークに向かって発展する傾向があり、ブラック ボックス フレームワークはシステム開発が達成したい理想的な目標でもあります。

今日インターネット上にある数多くの CSS フレームワークを振り返ってください (YUI は「YUI CSS Frameworks」ではなく「YUI Library CSS Tools」と呼ばれています)。実際にフレームワークの概念に基づいて記述されているものはいくつあるでしょうか。スタイルの基本クラスを定義するだけですか？もちろん、このフレームワークに対する理解は全員が同じではないかもしれませんし、私の言うことに同意できないかもしれません。

またCSSフレームワークの話をします。私は1、2年前からこのようなことを試していたわけではありません。大規模な Web サイトの場合、フロントエンド開発にはソリューションが必要です。当然、フレームワークが第一の選択肢になります。遠すぎて残念です、私は弱すぎますT_T、必要なのは次の2点だけです:

以下のコンテンツを管理するもの
クラス/コンポーネント
明らかに、最初の点はCSSでは実行できません。 2番目の点は、他のものと比較して、言語が非常に弱いです。

1 年ほど前、中規模の Web サイトに取り組んでいたとき、怠け者になるために、コンテンツをモジュール化してプログラマーにページをまとめてもらうことを考えました。一般的な方向性は、機能ブロックを次々にカプセル化することです。プログラマは、どのコンテンツを使用するかに応じて、対応する HTML と CSS を使用する必要があります。これは、誰にとっても便利です。コードを繰り返す必要はありません。皆さんこんにちは。

同じようなコンテンツブロックが同じウェブサイト上で複数回使用されるのは普通です。これにより、画像リスト、おそらくユーザーアバターのリスト、またはグループアイコンのリストなどのモジュール化も可能になります。 ?同じものをこのように使用しますか？

.photoListUesr,.photoListGroup{ /*_*/ }

不可能というわけではありませんが、突然似たようなものを追加したくなったらどうしますか？この時点でスタイルを調整する必要がある場合があります。そして私？このように使ってみました:

この場合、共通の式を最初から分離し、プロトタイプとして .photoList を使用し、追加のクラスで詳細を処理します。数日前、私はオブジェクト指向の XHTML と CSS プログラミングについて書きました。実際、残りの半分は詳細なサンプルでしたが、あまりにも多くのサンプルを作成しなければならなかったので、書き終わりませんでした。コアはすでに作成されています ^^ もちろん、これにも特定の問題があります。つまり、最初のプロトタイプの定義には細心の注意を払う必要があり、将来改訂される場合でも定義する必要がないようにする必要があります。変更されました。 CSS では、基本的に、フレームワークは最大でも 1 つの Web サイトにのみ適合します。 もちろん、Web サイトが十分に大きい場合は、この方法で使用するのが合理的です。

HTMLやCSSのモジュール化が進むほど、ファイルの分散化が進み、この問題はより深刻になります。 HTML は、アプリケーションが最終的にマージして 1 つのコピーを出力するため、扱いが簡単ですが、CSS は通常、破棄されて直接使用されます。先ほどの例でいうと、WebページにCSSをインポートする方法は次のようになります:

@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/ xxx/GroupCt.css);

プログラムを使用してページを結合することも検討できますが、それは使いやすく、リクエストの数に比例するので、一般的には誰もが手動でファイルを結合することを選択します。人間の脳はコンピューターよりも知能が高いですが、多くの場合、人間の脳の計算能力はコンピューターほど優れていません。私はかつて、CSS リリースのメカニズムをサーバー側のプログラムで処理するというアイデアを持っていました。大まかな方向性としては、Web サイトのアクセス ログを通じてサイト全体のさまざまなページの使用状況を分析し、そのプログラムを使用して一般ユーザーがどのページを使用しているかを計算するというものです。順序 (CSS ファイルの順序は優先順位に影響します) など、さまざまな計算と圧縮出力が必要です。

残念ながら、このような複雑なプログラムは、1 つの Web サイト、または同じシリーズの Web サイトのグループにのみ適している可能性があります。少し面倒ではありますが、ポータルレベルのWebサイトではこの方法を使う必要があると思います。もちろん、チーム全体が同じデザインパターンを使用することが前提です。

PS: 上記の CSS 公開プログラムはまだ試していないので、興味のある方は試してみてください。何か事故が起きても、私たちは責任を負いません。

もちろん、上記は CSS フレームワークと呼ぶことはできず、おそらくシステムレベルのソリューションとしか呼ぶことができません。結局のところ、CSS は単なる記述言語です。

昨夜、Yueying と私がローストダックを食べていたとき、このことについて話しました。そして、彼は私に統合されたフロントエンド ソリューションがあるかどうか尋ねました。 JS がコンポーネント化される場合にも同じ問題に直面することになるため、同様の公開メカニズムを JS にも適用できるはずです。でも、完全に統合された解決策はまだ見つけられていない。たぶん、岳英が私にあと数回アヒルのローストをごちそうしてくれるだろう、そうすれば分かるだろう。

上記は CSS フレームワークに関する説明です。その他の関連記事については、PHP 中国語 Web サイト (www.php.cn) に注目してください。