HTML とそれに関連するフロントエンド フレームワークのセマンティクス

意味論について

意味論では、記号と記号の関係と、それらが表す意味を研究します。言語学では、言語における記号 (単語、フレーズ、音など) の意味を研究します。フロントエンド開発の分野では、セマンティクスには主に 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 コンポーネントを扱うのはフロントエンド開発者だけではありません。

非常に簡単な例を挙げてみましょう:

<p class="news">
    <h2>News</h2>
    [news content]   
</p>

内容が明らかでない場合、クラス名ニュースは何も伝えることができません。コンポーネントの全体的な構造に関する情報は得られず、コンテンツが「ニュース」でなくなった後は、このクラス名を使用するのは非常に不適切であると思われます。クラス名のセマンティクスが内容に近すぎるため、このアーキテクチャは拡張するのが簡単ではなく、他の開発者が使用するのも簡単ではありません。
コンテンツに依存しないクラス名

デザイン パターンの構造と機能からクラス名のセマンティクスを抽出することは、より良いアプローチです。クラス名がその内容と何の関係もないコンポーネントは、より再利用しやすくなります。

明確なコンテンツを厳密に反映するためにクラス名を使用するのではなく、各レイヤー間の関係を明確かつ曖昧さのないものにすることを恐れるべきではありません（これは構造レイヤー、コンテンツレイヤーなどを指す必要があります、訳者注）。これを行うとクラス名が「意味論的」になるわけではなく、クラス名が内容に依存しないことを示すだけです。また、より強力で、より柔軟で、より再利用可能なコンポーネントを作成するのに役立つ限り、追加の HTML 要素を使用することを恐れるべきではありません。これを行うと HTML が「セマンティック」になるわけではなく、最小数を超える要素を使用してコンテンツをマークアップすることを意味するだけです。
フロントエンドアーキテクチャ

コンポーネント、テンプレート、オブジェクト指向アーキテクチャ その目的は、特定の範囲内の異なるコンテンツタイプを含めることができる、限られた数の再利用可能なコンポーネントを開発できるようにすることです。大規模なアプリケーションでは、クラス名のセマンティクスで最も重要なことは、開発または使用に意味のある、柔軟で再利用可能なプレゼンテーションや動作フックを提供するという、実用的な目的を達成することです。
再利用可能で構成可能なコンポーネント

一般に、拡張可能な HTML/CSS は、再利用可能なコンポーネントを作成するために HTML のクラスに依存する必要があります。 DOM ツリーの特定の部分に依存せず、特定のタイプの要素も使用しない、柔軟で再利用可能なコンポーネント。さまざまなコンテナに適応でき、テーマは簡単に変更できる必要があります。必要に応じて、(コンテンツのマークアップに必要な要素以外の) HTML 要素を追加すると、コンポーネントをより堅牢にすることができます。ニコール・サリバンのメディア・オブジェクトが良い例です。

避免用类型选择器支持class，可以让组件更容易合并。下面这个例子中，btn组件与uilist组件不易于合并。问题在于.btn的权重比.uilist a要小（这将覆盖任何共享属性）。而且ulist组件需要锚点作为子节点。

.btn { /* styles */ }   
.uilist { /* styles */ }   
.uilist a { /* styles */ }   

<nav class="uilist">
    <a href="#">Home</a>
    <a href="#">About</a>
    <a class="btn" href="#">Login</a>
</nav>

一种让uilist组件与其它组件轻松组合的方法是，uilist的子级DOM元素用class来添加样式。尽管这会降低权重，但是它的主要好处在于，它为你提供了处理子节点的任何结构样式的选择权。

.btn { /* styles */ }   
.uilist { /* styles */ }   
.uilist-item { /* styles */ }   

<nav class="uilist">
    <a class="uilist-item" href="#">Home</a>
    <a class="uilist-item" href="#">About</a>
    <span class="uilist-item">
        <a class="btn" href="#">Login</a>
    </span>
</nav>

JavaScript专用类

使用某种形式的JavaScript专用类，可以降低因组件样式或结构的改变导致JavaScript失效的风险。我已经找到了一种非常有效的方法，那就是专为JavaScript的钩子使用一种特定的类——js-*——不要在这个类名上添加任何描述。

<a href="/login" class="btn btn-primary js-login"></a>

在你修改组件的结构或样式的时候，可能会不经意间对那些必要的JavaScript行为和复杂的功能造成影响，用这种方法的话，可以降低这种可能性。
组件修改器

组件常常会有一些变体，它们与基本组件只有细微的差别。比如，不同的背景色或者边框。主要有两种创建这些组件变体的模式。我将它们称为“单类名”模式和“多类名”模式。

单类名模式

.btn, .btn-primary { /* 按钮模板样式 */ }   
.btn-primary { /* 主按钮的特殊样式 */ }   

<button class="btn">Default</button>
<button class="btn-primary">Login</button>

多类名模式

.btn { /* 按钮模板样式 */ }   
.btn-primary { /* 主按钮的特殊样式 */ }   

<button class="btn">Default</button>
<button class="btn btn-primary">Login</button>

如果你使用预处理程序，你可以用Sass的@extend功能，以减少一些在使用“单类名”模式时所涉及的维护工作。然而，即使有预处理程序的帮忙，我依然倾向于使用“多类名”模式，并在HTML中修改类名。

我发现这是一种更具扩展性的模式。比如，要实现一个基本的btn组件，并增加5种类型的按钮与3种额外的尺寸。用“多类名”模式的话只要9个class就可以搞定，用“单类名”模式则需要24个class。

如果需要的话，它也更容易让上下文环境适应组件。你可能想对出现在其它组件中的任一btn做一些细节调整。

/* “多类名”样式调整 */   
.thing .btn { /* 相应的样式调整 */ }   

/* “单类名”样式调整 */   
.thing .btn,   
.thing .btn-primary,   
.thing .btn-danger,   
.thing .btn-etc { /* 相应的样式调整 */ }

“多类名”模式意味着，你只需要用一个单独的组件内部选择器，便可以改变所有类型的btn元素的样式。“单类名”模式意味着，你必须顾及所有可能的按钮类型，并在创造一个新的按钮变体时调整这个选择器。
结构化的类名

当创建一个组件时——并为之添加了“主题”——其中一些class被用来区分各个组件，一些class被当做组件的修改器，其它的class则被用来关联DOM节点，它们一起被包含在一个较大的抽象组件中。

很难去判断btn（组件）、btn-primary（修改器）、brn-group（组件）和btn-group-item（组件子对象）之间的关系，这是因为这些名字不能清晰地表现class的目的。没有一致的模式。

在过去的一年中，我一直在尝试命名模式，目的是能帮助我快速理解在一个DOM片段中节点的表象之间的关系，而不用为此来回切换HTML、CSS与JS文件拼凑网站的架构。这种模式主要受到BEM系统的命名方法的影响，但被改编成一种我认为更容易浏览的形式。

t-template-name
t-template-name--modifier-name
t-template-name__sub-object
t-template-name__sub-object--modifier-name</p> <p>component-name
component-name--modifier-name
component-name__sub-object
component-name__sub-object--modifier-name</p> <p>is-state-type</p> <p>js-action-name
js-component-type

我将一些结构当做抽象的“模板”来处理，其它的则视为更清晰的组件（通常建立在“模板”上）。但是这种区分并非总是必要的。

这仅仅是我目前发现的一种有用的命名模式。命名模式可以采用任何形式。但这种命名模式的好处在于消除了模糊的类名，只依赖（单）连接符，或者下划线，或者是驼峰格式。
原始文件大小和HTTP压缩的注意事项

任何关于模块化与可扩展的CSS的讨论都会谈及对文件大小与“膨胀”的担心。Nicole Sullivan的言论中经常会提到文件大小的存储（以及维护改进），并提到了像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 です。クラスを多用した場合の実際のファイル サイズの影響については、もはや強調する必要はありません。

HTML および関連するフロントエンド フレームワークのセマンティクスに関するその他の記事については、PHP 中国語 Web サイトに注目してください。