セマンティクスについて
意味論は、記号とシンボルの関係と、それらが表す意味を研究します。言語学では、言語における記号 (単語、フレーズ、音など) の意味を研究します。フロントエンド開発の分野では、セマンティクスには主に HTML 要素、属性、属性値 (Microdata などの拡張機能を含む) の合意された意味が含まれます。仕様で一般的に使用されるこれらの形式的な規約のセマンティクスは、プログラム (およびその後開発に携わる人々) が Web サイトのあらゆる側面をよりよく理解するのに役立ちます。ただし、これらの要素、属性、および属性値のセマンティクスが形式化されていても、依然として開発者の適応と集団的な選択の影響を受けます。これにより、正式なコントラクトのセマンティクスが将来変更される可能性があります (これは HTML 設計原則の 1 つです)。
さまざまなタイプの HTML セマンティクスを区別する
「セマンティック HTML」を記述する原則に従うことは、現代のプロフェッショナルなフロントエンド開発の基礎の 1 つです。セマンティクスのほとんどは、コンテンツの現在または予想される性質に関連しています (例: h1 要素、lang 属性、type 属性の電子メール値、Microdata)。
ただし、すべてのセマンティクスがコンテンツ指向である必要があるわけではありません。クラス名を「意味論的」にすることはできません。どのような名前であっても、それらには意味と目的がなければなりません。クラス名のセマンティクスは、HTML 要素のセマンティクスとは異なる場合があります。 HTML 要素、特定の HTML 属性、Microdata などの「グローバル」セマンティクスを使用してから、Web サイトまたはアプリケーションの「ローカル」特定のセマンティクスを使用して区別することができます。これらの特定のセマンティクスは通常、次のような属性値に含まれます。クラス属性。
この想定される「ベスト プラクティス」は HTML5 仕様のクラス属性セクションで繰り返されていますが...
…表示されると予想されるコンテンツを記述するのではなく、クラス属性値を使用して実際のコンテンツを記述することを開発者に推奨します。
…これを行う固有の理由はありません。実際、このアプローチを大規模な Web サイトやアプリケーションで使用すると、障害になることがよくあります。
HTML 要素とその他の属性は、コンテンツレベルのセマンティクスをすでに提供しています。
マシンまたは訪問者にとって、クラス名からは有用なセマンティクス情報がほとんど、またはまったく明らかにならない可能性があります。合意された名前の一部でない限り (機械可読でもあります) - Mircoformats
クラス名の主な目的は、CSS と JavaScript のフックになることです。ページにプレゼンテーションや動作を追加する必要がない場合は、HTML にクラス名
を追加する必要はありません。クラス名は開発者に有益な情報を伝える必要があります。 DOM フラグメントを読むと、特定のクラス名の特定の目的を理解するのに役立ちます。特に複数人で構成される開発チームでは、HTML コンポーネントを扱うのはフロントエンド開発者だけではありません。
非常に簡単な例を挙げてください:
クラス名ニュースは、内容が明らかでない場合は何も伝えることができません。コンポーネントの全体的な構造に関する情報は得られず、コンテンツが「ニュース」でなくなった後は、このクラス名を使用するのは非常に不適切であると思われます。クラス名のセマンティクスが内容に近すぎるため、このアーキテクチャは拡張するのが簡単ではなく、他の開発者が使用するのも簡単ではありません。
コンテンツに依存しないクラス名
デザイン パターンの構造と機能からクラス名のセマンティクスを抽出する方が、より良いアプローチです。クラス名がその内容と何の関係もないコンポーネントは、より再利用しやすくなります。
明確な内容を厳密に反映するためにクラス名を使用するのではなく、各層間の関係を明確で曖昧さのないものにすることを恐れるべきではありません (これは構造層、コンテンツ層などを指す必要があります、訳者注)。これを行うとクラス名が「意味論的」になるわけではなく、クラス名が内容に依存しないことを示すだけです。また、より強力で、より柔軟で、より再利用可能なコンポーネントを作成するのに役立つ限り、追加の HTML 要素を使用することを恐れるべきではありません。これを行うと HTML が「セマンティック」になるわけではなく、最小数を超える要素を使用してコンテンツをマークアップすることを意味するだけです。
フロントエンド アーキテクチャ
コンポーネント、テンプレート、およびオブジェクト指向アーキテクチャの目的は、一定の範囲内でさまざまなコンテンツ タイプを含めることができる、限られた数の再利用可能なコンポーネントを開発できるようにすることです。大規模なアプリケーションでは、クラス名のセマンティクスで最も重要なことは、開発または使用に意味のある、柔軟で再利用可能なパフォーマンスや動作のフックを提供するという、実用的な目的を達成することです。
再利用可能で構成可能なコンポーネント
一般に、拡張可能な HTML/CSS は、再利用可能なコンポーネントを作成するために HTML のクラスに依存する必要があります。 DOM ツリーの特定の部分に依存せず、特定のタイプの要素も使用しない、柔軟で再利用可能なコンポーネント。さまざまなコンテナに適応でき、テーマは簡単に変更できる必要があります。必要に応じて、(コンテンツのマークアップに必要な要素以外の) HTML 要素を追加すると、コンポーネントをより堅牢にすることができます。ニコール・サリバンのメディア・オブジェクトが良い例です。
クラスをサポートするために型セレクターの使用を回避すると、コンポーネントをマージしやすくなります。次の例では、btn コンポーネントと uilist コンポーネントをマージするのは簡単ではありません。問題は、.btn の重みが .uilist a よりも小さいことです (これにより、共有プロパティがオーバーライドされます)。また、ulist コンポーネントには子ノードとしてアンカー ポイントが必要です。
uilist コンポーネントを他のコンポーネントと簡単に組み合わせる 1 つの方法は、クラスを使用して uilist の子 DOM 要素にスタイルを追加することです。これにより重量が軽減されますが、主な利点は、子ノードのあらゆる構造スタイルを処理できるオプションが得られることです。
JavaScript 固有のクラス
何らかの形式の JavaScript 固有のクラスを使用すると、コンポーネントのスタイルや構造の変更による JavaScript の失敗のリスクを軽減できます。私が見つけた非常にうまく機能する方法は、JavaScript フックのためだけに特定のクラス (js-*) を使用し、クラス名に説明を追加しないことです。
コンポーネントの構造やスタイルを変更すると、必要な JavaScript の動作や複雑な機能に誤って影響を与える可能性があります。この方法により、その可能性を減らすことができます。
コンポーネント修飾子
コンポーネントには、基本コンポーネントとほんのわずかしか異なるバリエーションがあることがよくあります。たとえば、異なる背景色や境界線などです。これらのコンポーネントのバリエーションを作成するには、主に 2 つのモードがあります。私はこれらを「単一クラス名」パターンと「複数クラス名」パターンと呼んでいます。
単一クラス名のパターン
複数のクラス名のパターン
プリプロセッサを使用する場合は、Sass の @extend 機能を使用して、「単一クラス名」パターンの使用時に必要なメンテナンス作業の一部を軽減できます。ただし、プリプロセッサの助けを借りたとしても、私は依然として「複数クラス名」モードを使用し、HTML 内のクラス名を変更することを好みます。
これはよりスケーラブルなパターンだと思います。たとえば、基本的な btn コンポーネントを実装し、5 種類のボタンと 3 つの追加サイズを追加するとします。 「複数クラス名」モードを使用する場合は 9 クラスのみ必要で、「単一クラス名」モードを使用する場合は 24 クラスが必要です。
必要に応じてコンテキストをコンポーネントに適応させるのも簡単になります。他のコンポーネントに表示されるボタンを詳細に調整することが必要な場合があります。
「マルチクラス名」モードは、単一の内部コンポーネント セレクターを使用するだけで、すべてのタイプの btn 要素のスタイルを変更できることを意味します。 「単一クラス名」パターンは、新しいボタン バリアントを作成するときに、考えられるすべてのボタン タイプを考慮し、セレクターを調整する必要があることを意味します。
構造化クラス名
コンポーネントを作成し、それに「テーマ」を追加すると、いくつかのクラスは各コンポーネントを区別するために使用され、いくつかのクラスはコンポーネントの修飾子として使用され、他のクラスは DOM ノードを関連付けるために使用されます。より大きな抽象コンポーネント内に含まれます。
btn (コンポーネント)、btn-primary (修飾子)、brn-group (コンポーネント)、btn-group-item (コンポーネントサブオブジェクト) の名前が明確ではないため、関係を判断するのが困難です 目的を表現しますクラスの。一貫したパターンはありません。
私はこの 1 年間、HTML、CSS、JS ファイルを行き来することなく、DOM フラグメント内のノード表現間の関係を素早く理解できるように、名前付けパターンを実験してきました。ウェブサイトの構造。このパターンは BEM システムの命名アプローチに大きく影響されていますが、ナビゲートしやすいと思われる形式に適応されています。
コンポーネント名
コンポーネント名--修飾子名
コンポーネント名__サブオブジェクト
コンポーネント名__サブオブジェクト--修飾子名
is-state-type
js アクション名
js コンポーネントの種類
私は一部の構造を抽象的な「テンプレート」として扱い、その他の構造をより明確なコンポーネント (多くの場合「テンプレート」に基づいて構築される) として扱います。しかし、この区別は必ずしも必要というわけではありません。
これは、私がこれまでに便利だと感じた命名パターンの 1 つにすぎません。命名パターンは任意の形式を取ることができます。ただし、この命名パターンの利点は、曖昧なクラス名を排除し、(単一の) コネクタ、アンダースコア、またはキャメル ケース形式のみに依存することです。
RAW ファイルのサイズと HTTP 圧縮に関する注意事項
モジュール式で拡張可能な CSS について議論する場合、ファイル サイズと「肥大化」に関する懸念が伴います。 ニコール・サリバン氏の発言 では、ファイル サイズのストレージ (およびメンテナンスの改善) について頻繁に言及し、Facebook のような企業がこのアプローチを採用した経験を引用しています。さらに一歩進んで、出力の前処理で得た HTTP 圧縮効果の一部と、HTML クラスの多用例を共有したいと思いました。
Twitter Bootstrap が最初に登場したとき、私は手動で操作したファイルのサイズと比較しやすくするために、コンパイルされた CSS を書き直しました。すべてのファイルを最小化した後、手動で操作した CSS ファイルはプリプロセッサの出力より 10% 小さくなりました。ただし、すべてのファイルを gzip で圧縮すると、プリプロセッサによって出力される CSS ファイルは手動操作よりも 5% 小さくなります。
これは、ファイル サイズの縮小だけではすべてがわかるわけではないため、HTTP 圧縮後のファイル サイズを比較することの重要性を強調しています。これは、プリプロセッサを使用する経験豊富な CSS 開発者は、コンパイルされた CSS 内のある程度の重複についてあまり心配する必要がないことを意味します。これは、HTTP 圧縮後に重複が小さくなるからです。プリプロセッサを通じてより保守しやすい CSS コードを処理する利点は、生の CSS と縮小された出力 CSS の美しさやファイル サイズに関する懸念を上回ります。
別の実験では、インターネットから 60KB の HTML ファイル (多くの再利用可能なコンポーネントで構成されている) をスクレイピングし、その各クラス属性を削除しました。この処理により、ファイルサイズは 25KB に減少します。元のファイルと抽出されたファイルの両方を gzip で圧縮すると、そのサイズはそれぞれ 7.6KB と 6KB になり、その差はわずか 1.6KB です。クラスを多用した場合の実際のファイル サイズの影響については、もはや強調する必要はありません。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
