ホームページ  >  記事  >  ウェブフロントエンド  >  html_html/css_WEB-ITnose のモジュール レイアウトに関する簡単な説明

html_html/css_WEB-ITnose のモジュール レイアウトに関する簡単な説明

WBOY
WBOYオリジナル
2016-06-21 08:50:081017ブラウズ

ウェブサイトの初期開発段階で、最初の PSD デザイン ドラフトを入手したとき、どのように始めましたか?

Web ページの構造は何を基準に分割していますか?

Web ページ内の一般的なスタイルをどのように抽出しますか?

モジュール型レイアウトの最大の利点は、開発と保守が簡単であることです。変化するニーズによりよく対応します。これらのモジュールは相互に依存しておらず、特定の共通点があります。

モジュール型レイアウトは通常、大規模なインターネット Web サイトの開発で使用されます。

Web サイトのアーキテクチャにさらに必要なのは、合理的なネストで最高の堅牢性、拡張性、メンテナンスの容易さを維持することです。

例:

改訂中にいくつかの機能の削除や変更を経験したことがありますか。このとき、この部分の HTML コードと CSS コードを見つけるのに苦労する必要があります。関数の CSS は異なる CSS ファイルで配布される場合があります。他の関数もこのコードを使用することを恐れて、スタイル コードの一部を簡単に削除する勇気はありません。

他の人が開発したプロジェクトを受け入れるなら、おめでとうございます。コードを削除するたびに震えるでしょう。 。このコードを削除しないと、長期的には多くの「歴史的問題」が残ることになります。

例:

開発プロセス中に、クラスのクラス名が臭くて長い名前になったという経験はありませんか。そうしないと、他の部分と混同してしまう可能性が高いからです。クラスの競合、またはスタイルがオーバーライドされます。

スタイル付きのコードを見たことがありますか? .title など。どこで使用されたか思い出せませんが、それを保存し、今後の開発プロセスで .title という名前を付けないようにする必要があります。

....

コードに夢中になっている私たちプログラマーにとって、誰もがきちんと整然としたコードを見たいと思っています。そして、コードの各行が、難しく考えることなく、その機能とアプリケーションのシナリオを簡単に把握できるようになることを願っています。


モジュラー レイアウトには、モジュール ファイルとテンプレート ファイルがあります。

開発プロセス中に、これらのモジュールが抽出されます。別のファイルを作成します。これがモジュール ファイルであり、これらのモジュールを紹介するページがテンプレート ファイルです。 。

以下の例を参照してください:

テンプレート ファイル

モジュール ファイル:

これらのモジュールには、モジュール名 (通常はファイル名) である一意の id 属性があります。

Web 開発のプロセスでは、ドキュメント アーキテクチャ層と識別モジュール名以外の場所で ID を使用することは強くお勧めできません。モジュール名を除いて、常に一意で変更されない関数は基本的に存在しないためです。

これらのモジュールは、独立したモジュールとして識別するための共通のクラス識別子「g-mod」を持ちます。

g-mod はスタイルを持つことができません。その存在は、Web ページ構造内のモジュールを識別するためだけです。

では、モジュールの内部構造は何でしょうか?

まず、モジュールにはヘッドが必要です。ヘッドに .hd という名前を付けます。

ヘッダーにはタイトルが必要です。タイトルがない場合はどうすればよいのかと疑問に思う人もいるかもしれません。タイトルがないと、ページの表示に明確なタイトルが表示されませんが、モジュール自体にはタイトルが必要です。

このタイトルをページ内に記述し、CSS で非表示にすることができます。この利点は、一部の読み取り支援ツールが Web ページをクロールしたときに、ドキュメントの概要が明確になることです。また、Web ページがよりセマンティックになるでしょう。

次に、これはモジュールの主要部分であり、.bd という名前を付けます。

モジュールの大部分をここに書きます。

次に、モジュールの末尾があり、この場所にモジュールの二次的なコンテンツとレースを配置できます。 .ft という名前を付けましょう。

この部分がない場合は、モジュールの末尾は省略できます。

モジュールの構造図は次のとおりです

このとき、すべてのモジュールに次のような名前を付けると、と考える学生もいるかもしれません。これは問題になりますか? スタイルの競合は発生しますか?

CSS スタイルを記述するとき、各モジュールのスタイルはスタイルの前に独自の「名前空間」を宣言します。したがって、異なるモジュール内の同じ名前の要素のスタイルが重複したり、相互に干渉したりすることはありません。

例:

名前の付け方について一言言いたいのですが、

ID 名通常、それは完全である必要があります 、少なくともモジュールの ID を通じて、それがどのモジュールであるかを見つけることができます。それは何をするのですか?

スタイルのクラス名については、冗長性を避けるために、場所やモジュールの情報をできるだけ簡潔にすることが最善です。 命名プロセス中に他のモジュールとの名前の競合を心配する必要はありません。また、セマンティクスも少しあります。

このようにして、CSS の行を読んで、この CSS 行がどのスタイルに対応しているかを頭の中ですぐに知ることができます。

たとえば、#apprise.list{} のこの行のスタイルを読むと、このページとリストに「評価」関数を持つモジュールがあることがわかります。そして #apprise li .date{} とすると、この行の CSS は「評価」モジュールのリストの時刻情報を記述していることが分かります。

上の図では、モジュール型レイアウトでは、CSS の記述方法によっても「カプセル化」と同様の視覚効果が得られることがわかります。特定の場所を変更する必要がある場合、その場所のスタイルをより迅速に見つけることができます。

つまり、

.bd{} ;

.title{};

.name{} を直接表示する必要はありません。 ;

そのようなスタイル。なぜなら、この書き方は私たちを混乱させ、どこで使われているのか疑問にさせるからです。さらに、.title や .bd などの名前を使用すると、次回のページ作成時にこれらのクラス名を任意に使用できなくなります。

そして、私たちが望むのは

#crumb .bd{}

#curmb .title{}

#newslist .name{}

です。

こうすることで、彼がどこに現れるかを一目で知ることができます。

これにより、スタイルの各行の前に無邪気に奥行きのレイヤーが追加されると言う人もいます。パフォーマンスに影響を与えます。

しかし、私たちの現在のコンピュータはもはや 486 N 年前のものではなく、現在のブラウザももはや N 年前の IE5 ではありません。このようにもう 1 層のネストを作ります。パフォーマンスにはまったく影響しませんが、大規模なインターネット サイトの開発では、コードがより堅牢になり、読みやすくなります。バージョンは常にアップグレードされ、反復されます。コードの保守性はパフォーマンスをはるかに上回る必要があります。

モジュール間に大きな類似性がある場合、共通のモジュールを直接書くことができます。 例:

/* g-newlist モジュール news1 、 news2 */

.g-newlist{};

.g-newlist .hd{ } ;

.g-newlist .bd{};

.g-newlist .ft{};

モジュール ファイル内でこのように使用できます。

…….

…….

g-newlist の「g-」は global の略です。 「g-」を見ると、それがグローバル スタイルであることがすぐにわかります。基本的なクラス。

共通モジュール スタイルの場合、どのモジュールが提供されるかについてコメントする必要があります。

これら 2 つのモジュールは似ていますが異なり、両方とも少しパーソナライズされている場合はどうなるでしょうか?

ご存知のとおり、ID の優先順位はクラスの優先順位よりも一段高いです。

公開部分:

.g-newlist{};

.g-newlist .hd{};

.g-newlist .bd{ };

.g-newlist .ft{};

パーソナライゼーション セクション:

#news1 .ft{}

#news1 .ft リンク{}

#news2 .bd{}

それは完璧な解決策ですか?

モジュール間に大きな類似性はなく、どこでも使用されるアイコンなどの小さな場所のみの場合。

.g-ico{}

.g-ico-sina{}

.g-ico-pptv{}

待ってください。 。 。 。

開発プロセス中に特定のパブリック スタイルの粒度を制御できます。ただし、すべてのモジュールがあまり類似していない場合は、より小さい粒度を使用することをお勧めします。親構造に基づいているほど良いです。

モジュール型開発手法を使用すると、チーム内の全員のコードはほぼ同じになるため、他の人のコードを変更するのは自分のコードを変更するのと同じです。より速く、より簡単に。

全員に私たちのコードを理解してもらいましょう。反復のバージョンがいくつであっても、理解できないコードの束を残すことなく、対応するモジュール ファイルとそれに対応するスタイルを追加、削除、変更するだけで済みます。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。