의미론에 대하여
의미론은 기호와 상징의 관계, 그리고 그것이 나타내는 의미를 연구합니다. 언어학에서는 언어에서 이러한 기호(단어, 구, 소리 등)의 의미를 연구합니다. 프런트 엔드 개발 분야에서 의미론은 주로 HTML 요소, 속성 및 속성 값(마이크로데이터와 같은 확장 포함)의 합의된 의미를 포함합니다. 사양에 일반적으로 사용되는 이러한 공식적인 규칙 의미는 프로그램(및 나중에 개발에 참여하는 사람들)이 웹 사이트의 모든 측면을 더 잘 이해하는 데 도움이 될 수 있습니다. 그러나 이러한 요소, 속성, 속성 값의 의미가 형식화되더라도 여전히 개발자의 적응과 집합적 선택의 대상이 됩니다. 이는 공식적인 계약 의미가 미래에 수정될 수 있음을 가능하게 합니다(그리고 이는 HTML 디자인 원칙 중 하나입니다).
다양한 유형의 HTML 의미론 구별
"의미론적 HTML" 작성 원칙을 따르는 것은 현대 전문 프론트엔드 개발의 기초 중 하나입니다. 대부분의 의미 체계는 콘텐츠의 현재 또는 예상되는 특성(예: h1 요소, lang 속성, 유형 속성의 이메일 값, 마이크로데이터)과 관련됩니다.
그러나 모든 의미론이 콘텐츠 중심일 필요는 없습니다. 클래스 이름은 "의미론적"일 수 없습니다. 이름이 무엇이든 의미와 목적이 있어야 합니다. 클래스 이름의 의미는 HTML 요소의 의미와 다를 수 있습니다. 우리는 HTML 요소, 특정 HTML 속성, 마이크로데이터 등의 "글로벌" 의미를 사용할 수 있으며, 그런 다음 웹사이트나 애플리케이션의 "로컬" 특정 의미를 사용하여 구별할 수 있습니다. 이러한 특정 의미는 일반적으로 다음과 같은 속성 값에 포함됩니다. 클래스 속성 .
이러한 "모범 사례"가 HTML5 사양의 클래스 속성 섹션에서 반복되지만...
...개발자는 실제 콘텐츠를 설명하기보다는 클래스 속성 값을 사용하는 것이 좋습니다. 설명보다 표시될 것으로 예상되는 콘텐츠입니다.
…내가 이 일을 해야만 하는 본질적인 이유는 없습니다. 실제로 대규모 웹사이트나 애플리케이션에서 이 접근 방식을 사용하면 종종 방해가 될 수 있습니다.
HTML 요소 및 기타 속성은 이미 콘텐츠 수준 의미 체계를 제공합니다.
컴퓨터나 방문자의 경우 클래스 이름은 유용한 의미 체계 정보를 거의 또는 전혀 나타내지 않습니다. 합의된 이름의 작은 부분이 아닌 한(기계 판독 가능) - Mircoformats
클래스 이름의 주요 목적은 CSS 및 JavaScript에 대한 연결이 되는 것입니다. 페이지에 프리젠테이션 및 동작을 추가할 필요가 없다면 HTML에 클래스 이름
을 추가할 필요가 없을 것입니다. 클래스 이름은 개발자에게 유용한 정보를 전달해야 합니다. DOM 조각을 읽으면 특정 클래스 이름의 구체적인 목적을 이해하는 데 도움이 됩니다. 특히 여러 사람으로 구성된 개발팀에서는 프론트엔드 개발자만이 HTML 구성요소를 다루는 것은 아닙니다.
아주 간단한 예를 들어보세요.
<p class="news">
<h2>News</h2>
[news content]
</p>로그인 후 복사
내용이 명확하지 않으면 학급명 뉴스로는 아무 것도 알 수 없습니다. 이는 구성 요소의 전체 구조에 대한 정보를 제공하지 않으며 내용이 더 이상 "뉴스"가 아닌 경우 이 클래스 이름을 사용하는 것은 매우 부적절해 보입니다. 클래스 이름의 의미가 내용과 너무 가깝고 아키텍처가 확장하기 쉽지 않고 다른 개발자가 사용하기도 쉽지 않습니다.
콘텐츠 독립적인 클래스 이름
디자인 패턴의 구조와 기능에서 클래스 이름의 의미를 추출하는 것이 더 나은 접근 방식입니다. 클래스 이름이 내용과 관련이 없는 구성 요소는 재사용성이 더 높습니다.
클래스 이름을 사용하여 명확성을 엄격하게 반영하기보다는 다양한 계층 간의 관계를 명확하고 모호하지 않게 만드는 것을 두려워해서는 안 됩니다(구조 계층, 콘텐츠 계층 등을 참조해야 함, 번역자 주). 콘텐츠 . 이렇게 한다고 해서 클래스 이름이 "의미론적"이 되는 것은 아니며 단지 해당 의미론이 내용에 의존하지 않는다는 것을 보여줄 뿐입니다. 또한 더 강력하고 유연하며 재사용 가능한 구성 요소를 만드는 데 도움이 되는 한 추가 HTML 요소를 사용하는 것을 두려워해서는 안 됩니다. 그렇게 한다고 해서 HTML이 "의미론적"이 되는 것은 아니며, 단지 최소 요소 수 이상을 사용하여 콘텐츠를 마크업한다는 의미일 뿐입니다.
프런트 엔드 아키텍처
구성 요소, 템플릿 및 객체 지향 아키텍처의 목적은 특정 애플리케이션 내에 포함될 수 있는 제한된 수의 재사용 가능한 구성 요소를 개발할 수 있도록 하는 것입니다. 범위 다양한 콘텐츠 유형. 대규모 애플리케이션에서 클래스 이름 의미론에 대한 가장 중요한 점은 실용주의를 바탕으로 기본 목적을 수행한다는 것입니다. 즉, 개발 또는 사용을 위한 의미 있고 유연하며 재사용 가능한 성능 또는 동작 후크를 제공합니다.
재사용 가능하고 구성 가능한 구성 요소
일반적으로 확장 가능한 HTML/CSS는 재사용 가능한 구성 요소를 만들기 위해 HTML의 클래스에 의존해야 합니다. DOM 트리의 특정 부분에 의존하지도 않고 특정 유형의 요소를 사용하지도 않는 유연하고 재사용 가능한 구성 요소입니다. 다양한 컨테이너에 적용할 수 있어야 하며 테마를 쉽게 변경할 수 있어야 합니다. 필요한 경우 콘텐츠를 마크업하는 데 필요한 요소 외에 추가 HTML 요소를 사용하여 구성 요소를 더욱 강력하게 만들 수 있습니다. Nicole Sullivan이 언급한 미디어 객체가 좋은 예입니다.
避免用类型选择器支持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 중국어 웹사이트를 주목하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
