In-depth analysis of the semantics of HTML and related front-end frameworks_HTML/Xhtml_Web page production

About semantics

Semantics studies the relationship between signs and symbols and the meanings they represent. In linguistics, it is the study of the meaning of symbols (such as words, phrases, or sounds) in language. In the field of front-end development, semantics mainly involves the agreed meanings of HTML elements, attributes, and attribute values ​​(including extensions like Microdata). These formal convention semantics, commonly used in specifications, can help programs (and later people involved in development) better understand all aspects of a website. However, even if the semantics of these elements, attributes, and attribute values ​​are formalized, they are still subject to developer adaptation and collective choices. This makes it possible that the formal contract semantics may be modified in the future (and this is one of the HTML design principles).
Distinguish different types of HTML semantics

Adhering to the principle of writing "semantic HTML" is one of the foundations of modern professional front-end development. Most of the semantics are related to the current or expected nature of the content (eg: h1 element, lang attribute, email value of type attribute, Microdata).

However, not all semantics need to be content-oriented. Class names cannot be "semantic". No matter what the names are, they must have meaning and purpose. The semantics of class names can be different from those of HTML elements. We can use the "global" semantics of HTML elements, certain HTML attributes, Microdata, etc., and then use the "local" specific semantics of the website or application to differentiate. These specific semantics are usually included in attribute values, such as class attributes. .

Although this supposed "best practice" is reiterated in the HTML5 specification's class attribute section...

…encourage developers to use the class attribute value to describe the actual content, rather than describing the content expected to be displayed.

…there’s no inherent reason to do this. In fact, when this approach is used on large websites or applications, it can often become a hindrance.

HTML elements and other attributes already provide content-level semantics
For machines or visitors, class names can reveal little or no useful semantic information. Unless it is a small part of the name that has been agreed upon (also machine-readable) - Mircoformats
The main purpose of the class name is to become a hook for CSS and JavaScript. If you don't need to add presentation and behavior to your pages, then you probably don't need to add class names
to your HTML. Class names should convey useful information to developers. When you read a DOM fragment, it will help to understand the specific purpose of a certain class name. Especially in a multi-person development team, front-end developers are not the only ones who deal with HTML components.

Give a very simple example:

XML/HTML CodeCopy content to clipboard

1. <div class="news" >
2.  <h2>Newsh2>
3. [news content]
4. div>

The class name news cannot tell you anything when the content is not obvious. It gives you no information about the overall structure of the component, and once the content is no longer "news", it seems very inappropriate to use this class name. The semantics of the class names are too close to the content, and the architecture is neither easy to extend nor easy to use by other developers.
Content-independent class name

Extracting the semantics of class names from the structure and functionality of a design pattern is a better approach. Components whose class names have nothing to do with their content are more reusable.

We should not be afraid to make the relationship between each layer clear and unambiguous (this should refer to the structure layer, content layer, etc., translator's note), rather than using class names to strictly reflect clear content. Doing this doesn't make the class names "semantic", it just shows that their semantics does not depend on the content. We also shouldn't be afraid to use additional HTML elements as long as they help you create stronger, more flexible, and more reusable components. Doing so does not make the HTML "semantic", it just means that you mark up the content using more than the minimum number of elements.
Front-end architecture

The purpose of components, templates, and object-oriented architecture is to be able to develop a limited number of reusable components that can contain different content types within a certain range. In large applications, the most important thing about class name semantics is that they serve their primary purpose with pragmatism - providing meaningful, flexible, reusable performance or behavioral hooks for development. or use.
Reusable and composable components

In general, extensible HTML/CSS must rely on classes in HTML in order to create reusable components. A flexible, reusable component that neither relies on a certain part of the DOM tree nor uses a specific type of element. It should be adaptable to different containers and the theme can be changed easily. If necessary, additional HTML elements (beyond those necessary to mark up the content) can make a component more robust. Nicole Sullivan's media object is a good example.

Avoiding the use of type selectors to support classes can make components easier to merge. In the following example, the btn component and the uilist component are not easy to merge. The problem is that .btn has a smaller weight than .uilist a (this will override any shared properties). And the ulist component requires anchor points as child nodes.

XML/HTML CodeCopy content to clipboard

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist a { /* styles */ }
5. <nav class="uilist" >
6.  <a href="#" >Homea>
7.  <a href="#" >Abouta>
8.  <a class="btn" href="#">Login a> 
9. nav>

One way to easily combine the uilist component with other components is to use classes to add styles to the child DOM elements of uilist. Although this reduces weight, its main benefit is that it gives you the option to handle any structural style of child nodes.

XML/HTML CodeCopy content to clipboard

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist-item { /* styles */ }
5. <nav class="uilist" >
6.  <a class="uilist- item" href="#">Homea> 
7.  <a class="uilist- item" href="#">Abouta> 
8.  <span class="uilist- item"> 
9.  <a class="btn" href="#">Login a> 
10.  span> 
11. nav>

JavaScript-specific classes

Using some form of JavaScript-specific classes can reduce the risk of JavaScript failure due to changes in component style or structure. A method I've found that works very well is to use a specific class just for JavaScript hooks - js-* - and don't add any description to the class name.

XML/HTML CodeCopy content to clipboard

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

When you modify the structure or style of a component, you may inadvertently affect necessary JavaScript behaviors and complex functions. This method can reduce the possibility.
Component Modifier

Components often have variations that differ only slightly from the base component. For example, different background colors or borders. There are two main modes for creating variations of these components. I call them the "single class name" pattern and the "multiple class name" pattern.

Single class name pattern

XML/HTML CodeCopy content to clipboard

1. .btn, .btn-primary { /* Button template style */ }
2. .btn-primary { /* Special style of primary button */ }
4. <button class="btn" >Defaultbutton>
5. <button class="btn- primary">Loginbutton>

Multiple class name patterns

XML/HTML CodeCopy content to clipboard

1. .btn { /* Button template style */ }
2. .btn-primary { /* Special style of primary button */ }
4. <button class="btn" >Defaultbutton>
5. <button class="btn btn -primary">Loginbutton>

If you use a preprocessor, you can use Sass's @extend functionality to reduce some of the maintenance work involved when using the "single class name" pattern. However, even with the help of the preprocessor, I still prefer to use the "multiple class names" mode and modify the class names in the HTML.

I find this to be a more scalable pattern. For example, you want to implement a basic btn component and add 5 types of buttons and 3 additional sizes. If you use the "multiple class name" mode, you only need 9 classes, and if you use the "single class name" mode, you need 24 classes.

It also makes it easier to adapt the context to the component if needed. You may want to make some detailed adjustments to any btn that appears in other components.

XML/HTML CodeCopy content to clipboard

1. /* "Multiple class name" style adjustment */
2. .thing .btn { /* Corresponding style adjustment */ }
4. /* "Single class name" style adjustment */
5. .thing .btn,
6. .thing .btn-primary,
7. .thing .btn-danger,
8. .thing .btn-etc { /* Corresponding style adjustment */ }

The "multi-class name" mode means that you only need to use a single internal component selector to change the style of all types of btn elements. The "single class name" pattern means that you have to consider all possible button types and adjust the selector when creating a new button variant.
Structured class name

When you create a component - and add a "theme" to it - some classes are used to distinguish each component, some classes are used as modifiers of the component, and other classes are used to associate DOM nodes. Together they are contained within a larger abstract component.

It is difficult to judge the relationship between btn (component), btn-primary (modifier), brn-group (component) and btn-group-item (component sub-object) because these names are not clear Express the purpose of class. There is no consistent pattern.

Over the past year, I have been experimenting with naming patterns to help me quickly understand the relationship between the representations of nodes in a DOM fragment without having to switch back and forth between HTML, CSS and JS files to piece together. The structure of the website. This pattern is largely influenced by the BEM system's naming approach, but adapted into a form that I think is easier to navigate.

Copy code

The code is as follows:

t-template-name
t-template- name--modifier-name
t-template-name__sub-object
t-template-name__sub-object--modifier-name

component-name
component-name--modifier-name
component-name__sub-object
component-name__sub-object--modifier-name

is-state-type

js-action-name
js-component-type

I treat some structures as abstract "templates" and others as clearer components (often built on "templates"). But this distinction is not always necessary.

This is just one naming pattern I've found useful so far. The naming pattern can take any form. But the advantage of this naming pattern is that it eliminates ambiguous class names and relies only on (single) connectors, or underscores, or camel case format.
Notes on raw file size and HTTP compression

Any discussion of modular and extensible CSS will involve concerns about file size and "bloat". Nicole Sullivan's remarks frequently mention file size storage (and maintenance improvements), citing the experience of companies like Facebook adopting this approach. Going a step further, I thought I'd share some of the HTTP compression effects I've had on preprocessing output, as well as some heavy use of HTML classes.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better compare the size to manually manipulated files. After minimizing all files, the manually operated CSS file was 10% smaller than the preprocessor output. But when all files are compressed by gzip, the CSS file output by the preprocessor is 5% smaller than that of manual operation.

This emphasizes the importance of comparing file sizes after HTTP compression, as reduced file size does not tell the whole story. It implies that experienced CSS developers using preprocessors should not be too concerned about a certain degree of duplication in the compiled CSS, since it will become smaller after HTTP compression. The benefits of processing more maintainable CSS code through a preprocessor outweigh concerns about the aesthetics or file size of the raw CSS and minified output CSS.

In another experiment, I scraped a 60KB HTML file from the Internet (composed of many reusable components) and deleted each of its class attributes. After this processing, the file size is reduced to 25KB. When both the original file and the extracted file are compressed by gzip, their sizes become 7.6KB and 6KB respectively - a difference of only 1.6KB. The actual file size consequences of liberal use of classes are no longer worth stressing.