In-depth analysis of HTML semantics and its related front-end frameworks

About semantics

Semantics is the study of the relationship between signs and symbols and the meanings they represent. In linguistics, it is the study of the meaning of these tokens (such as words, phrases, or sounds) in language. In the field of front-end development, semantics mainly refers to the agreed meanings of HTML elements, attributes, and attribute values ​​(including extensions such as Microdata). These formally agreed semantics, often used in specifications, can help programmers (and later developers) better understand various aspects of a website. However, even though the semantics of these elements, attributes, and attribute values ​​are formalized, they are still subject to developer comfort and collective choice. This makes it possible that the formal agreed semantics may be modified in the future (which is one of the design principles of HTML).
Differentiate between 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 semantics are related to the nature of the current or expected content (e.g. h1 element, lang attribute, email value of type attribute, Microdata).

However, not all semantics need to be content-oriented. Class names cannot be "semantic-free". Whatever they are named, 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 distinguish them. These specific semantics are usually contained in the attribute value, such as the class attribute.

Despite this supposed "best practice" being reiterated in the HTML5 specification's section on the class attribute...

…encourages developers to use class attribute values ​​to describe actual content, rather than desired content.

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

HTML elements and other attributes already provide semantics at the content level
Class names reveal little or no useful semantic information to a machine or human visitor. Unless it is one of the small set of names that have been agreed upon (and are also machine readable) - Mircoformats
The main use of class names is to be hooks into CSS and JavaScript. If you don't need to add presentation or behavior to your page, then you probably don't need to add classes to your HTML.
Class names should convey useful information to developers. When you're reading a DOM snippet, it helps to understand what a certain class name does. Especially in a multi-person development team, it’s not just the front-end developers who deal with HTML components.

Let's take a very simple example:

When the content is not obvious, the class name news doesn't tell you anything. It tells you nothing about the overall structure of the component, and once the content is no longer “news” it becomes a poor choice to use this class. 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.
Class names that are not relevant to the content

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

We should not be afraid to make the relationships between layers clear and explicit, rather than using class names to strictly reflect specific content. Doing this doesn't make the class names "semantic-free", it just means that their semantics don't depend on the content. We also shouldn’t be afraid to use additional HTML elements as long as they help you create more powerful, flexible, and reusable components. Doing this doesn't make your HTML "unsemantic", it just means that you're using more than the minimum number of elements to mark up your content.
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 a range of different content types. In large applications, the most important thing about class name semantics is that they can be used pragmatically to serve their primary purpose - to provide meaningful, flexible, reusable hooks for developers to use for presentation or behavior.
Reusable and composable components

In general, extensible HTML/CSS must rely on classes in HTML to create reusable components. A flexible, reusable component that does not rely on a certain part of the DOM tree or require the use of a specific type of element. It should adapt to different containers and be easily re-themed. If necessary, additional HTML elements (beyond what is necessary to mark up the content) can make the component more robust. Nicole Sullivan's media object is a good example.

Avoiding type selectors in favor of classes makes components easier to merge. In the following example, the btn component and the uilist component are not easy to merge. The problem is that the .btn has a smaller weight than the .uilist a (which will override any shared properties). And the ulist component needs an anchor as a child node.

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

JavaScript-specific classes

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

This approach reduces the likelihood that you will inadvertently break necessary JavaScript behavior and complex functionality when modifying a component’s structure or styles.
Component Modifier

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

Single class name mode

Multiple class name pattern

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 a preprocessor, I still prefer to use the "multiple class names" pattern and modify the class names in the HTML.

I find this to be a more scalable pattern. For example, to implement a basic btn component, and add 5 types of buttons and 3 additional sizes. If you use the "multiple class names" mode, you only need 9 classes to do it, while 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 within other components.

The "multiple class names" pattern means that you can change the style of all types of btn elements using only a single internal component selector. The "single class name" pattern means that you have to account for all possible button types and adjust the selector when creating a new button variant.
Structural class names

When creating a component - and adding a "theme" to it - some classes are used to distinguish between components, some classes are used as modifiers of components, and other classes are used to associate DOM nodes, all of which are included together in a larger abstract component.

It is difficult to determine the relationship between btn (component), btn-primary (modifier), brn-group (component), and btn-group-item (component child) because these names do not clearly express the purpose of the class. There is no consistent pattern.

Over the past year, I’ve been experimenting with naming patterns that help me quickly understand the relationships 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 site’s architecture. This pattern was heavily influenced by the naming approach of the BEM system, but adapted into a form that I think is easier to navigate.

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

This is just a naming pattern I've found useful so far. The naming pattern can be of any form. But the benefit of this naming pattern is that it eliminates ambiguous class names, relying only on (single) hyphens, or underscores, or camelCase.
Notes on original file size and HTTP compression

Any discussion about modular and scalable CSS will inevitably bring up concerns about file size and "bloat". Nicole Sullivan often mentioned the file size storage (and maintenance improvements) in her remarks, and mentioned the experience of companies like Facebook taking this approach. Going a step further, I thought I'd share some of the things I do with HTTP compression when preprocessing output, and some things that make heavy use of the HTML class.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better compare the file size with what I could do manually. After minifying all files, the manually manipulated CSS file is 10% smaller than the preprocessor output. But when all files were gzipped, the preprocessor's output CSS file was 5% smaller than the manual process.

This emphasizes the importance of comparing file sizes after HTTP compression, as the reduced file size does not tell the whole story. It implies that experienced CSS developers don't have to be too concerned about a certain level of duplication in the compiled CSS when using preprocessors, because it will be smaller after HTTP compression. The benefits of more maintainable CSS code through a preprocessor outweigh concerns about the aesthetics or file size of the original CSS and the minified output.

In another experiment, I scraped a 60KB HTML file from the internet (composed of many reusable components) and removed every class attribute from it. After this processing, the file size is reduced to 25KB. When both the original file and the ripped file are compressed using 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 not worth emphasizing anymore.