In-depth analysis of the semantics of HTML and its related front-end framework _ HTML/Xhtml _ webpage Creation

This article mainly introduces the semantic analysis of HTML and its related front-end framework. simple HTML is also well learned! For more information, see About Semantics

Semantics studies the relationship between signs and symbols and their meanings. In linguistics, it mainly studies the meaning of these signs (such as words, phrases, or sounds) in language. In front-end development, semantics mainly involves HTML elements, attributes, and attribute values (including extensions such as Microdata. These formal conventions commonly used in the specifications can help the program (and those who later participated in the Development) better understand all aspects of a website. However, even if the semantics of these elements, attributes, and attribute values are formal, they must be subject to the developer's degree of adaptation and the result of joint selection. This makes the formal conventions and semantics possible to be modified in the future (and this is one of the HTML design principles ).
Differentiate different types of HTML Semantics

Complying with the "semantic HTML" principle is one of the foundations of modern professional front-end development. The vast majority of semantics are related to the current or expected content nature (such as the email value of the h1 element, lang attribute, type attribute, and Microdata ).

However, not all semantics must be content-oriented. The class name cannot be "speechless ". No matter what names are used, they must be meaningful and objective. The semantics of class names can be different from those of HTML elements. We can use the "global" semantics of HTML elements, some HTML attributes, and Microdata, and then distinguish them by the "local" specific semantics of websites or applications, these specific semantics are usually included in attribute values, such as class attributes.

Although the "best practices" of this assumption is reiterated in the class attribute section of the HTML5 standard "...

... Developers are encouraged to use the class property value to describe the actual content, rather than the content expected to be presented.

... There is no internal reason not to do so. In fact, when this method is used on large websites or applications, it often becomes an obstacle.

HTML elements and other attributes provide the semantics of the content layer.
For machines or visitors, the class name can reveal very little or no useful semantic information. Unless it is the agreed small part of the name (the machine is also readable) -- Mircoformats
Class names are mainly used to become CSS and JavaScript hooks. If you do not need to add Performance and behavior to your page, you may not need to add a class name in your HTML.
The class name should convey useful information to developers. When you read a DOM snippet, it helps you understand the specific role of a class name. Especially in a multi-person Collaborative Development Team, dealing with HTML components is not limited to front-end developers.

A very simple example:

Copy XML/HTML Code to clipboard

2. News

3. [News content]

When the content is not obvious, news cannot tell you anything. It does not provide you with information about the overall structure of this component, and once the content is no longer "news", it is very inappropriate to use this class name. The semantics of the class name is too close to the content, and the architecture is neither easy to expand nor easily used by other developers.
Class Name irrelevant to content

It is better to extract the semantics of class names from the structure and functions of a design pattern. Components whose class names are irrelevant to the content are more reusable.

We should not be afraid to make the relationship between the layers clear and clear (here we should refer to the structure layer, content layer, etc., the Translator's note), rather than using the class name to strictly reflect the clear content. This does not make the class name "speechless", but only indicates that their semantics does not depend on the content. We should not be afraid to use additional HTML elements, as long as they can help you create stronger, more flexible, and more reusable components. This will not make HTML "speechless", which only means that the number of elements used by your tag content exceeds the minimum value.
Front-end architecture

The purpose of components, templates, and object-oriented architecture is 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 for the class name semantics is, utilities serve their main purpose-providing meaningful, flexible, reusable performance or behavior hooks for developers to use.
Reusable and composite components

In general, extensible HTML/CSS must depend on the class in HTML to create reusable components. A flexible and reusable component does not depend on a part of the DOM tree or any specific type of elements. It should be able to adapt to different containers and can easily change themes. If necessary, additional HTML elements (elements beyond the elements required for the TAG content) can make the component stronger. Nicole Sullivan's media object is a good example.

Avoid using the type selector to support class and make it easier for components to be merged. In the following example, the btn component and the uilist component are not easy to merge. The problem is that the weight of. btn is smaller than that of. uilist a (this will overwrite any shared attribute ). In addition, the ulist component must use an anchor as a subnode.

Copy XML/HTML Code to clipboard

1. . Btn {/* styles */}
2. . Uilist {/* styles */}
3. . Uilist a {/* styles */}
6. Home
7. About
8. Login

One way for the uilist component to be easily combined with other components is to use the class to add styles for the uilist Sub-Level DOM elements. Although this will reduce the weight, its main advantage is that it provides you with the right to process any structure style of the child node.

Copy XML/HTML Code to clipboard

1. . Btn {/* styles */}
2. . Uilist {/* styles */}
3. . Uilist-item {/* styles */}
6. Home
7. About
9. Login

Specialized JavaScript classes

Using some form of JavaScript specialized classes can reduce the risk of JavaScript failure caused by component style or structure changes. I have found a very effective method, that is, to use a specific class -- js-* -- for JavaScript hooks. Do not add any description on the class name.

Copy XML/HTML Code to clipboard

When you modify the structure or style of a component, it may inadvertently affect the necessary JavaScript behavior and complex functions. In this way, this possibility can be reduced.
Component Modifier

Components often have some variants, which are slightly different from basic components. For example, different background colors or borders. There are two main modes to create these component variants. I call them the "single-class name" mode and the "multi-class name" mode.

Single-class name Mode

Copy XML/HTML Code to clipboard

1. . Btn,. btn-primary {/* button template style */}
2. . Btn-primary {/* special style of the main button */}
4. Default
5. Login

Multi-class name Mode

Copy XML/HTML Code to clipboard

1. . Btn {/* button template style */}
2. . Btn-primary {/* special style of the main button */}
4. Default
5. Login

If you use a Preprocessing Program, you can use the @ extend function of Sass to reduce the maintenance work involved when using the single class name mode. However, even with the help of the Preprocessing Program, I still prefer to use the "multi-class name" mode and modify the class name in HTML.

I found this is a more scalable mode. For example, to implement a basic btn component, add 5 types of buttons and 3 additional sizes. In the "multi-class name" mode, only nine classes are required. In the "single class name" mode, 24 classes are required.

If necessary, it also makes it easier for the Context Environment to adapt to components. You may want to adjust any btn in other components.

Copy XML/HTML Code to clipboard

1. /* Adjust the "multi-class name" style */
2. . Thing. btn {/* corresponding style adjustment */}
4. /* Adjust the "single class name" style */
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 component internal selector to change the style of all types of btn elements. The "single class name" Mode means that you must take into account all possible button types and adjust this selector when creating a new button variant.
Structured Class Name

When a component is created -- and a "topic" is added to it -- some classes are used to differentiate components, and some classes are used as component modifiers, other classes are used to associate DOM nodes. They are included in a large abstract component.

It is difficult to determine the relationship between btn (component), btn-primary (modifier), brn-group (component), and btn-group-item (Component sub-object, this is because these names cannot clearly express the purpose of the class. There is no consistent mode.

In the past year, I have been trying the naming mode to help me quickly understand the relationship between nodes in a DOM fragment, instead of switching back and forth between HTML, CSS, and JS file to piece together the website architecture. This mode is mainly influenced by the naming method of the BEM system, but it is adapted into a form that I think is easier to browse.

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", while others as clearer components (usually based on "templates ). However, this distinction is not always necessary.

This is just a useful naming method I have found. The naming mode can take any form. However, the benefit of this naming mode is that it eliminates fuzzy class names and only relies on (single) connectors, underscores, or camps.
Precautions for raw file size and HTTP Compression

Any discussion about modularity and extensible CSS will talk about the worries about file size and "expansion. Nicole Sullivan's remarks often mention the storage of file sizes (as well as maintenance improvements) and the experiences of companies like Facebook adopting this approach. Further, I would like to share my HTTP compression effects during preprocessing and output, as well as some things about the extensive use of HTML classes.

When Twitter Bootstrap was just launched, I overwritten the compiled CSS to better compare the size with the manually operated file. After all files are minimized, the manually operated CSS file is 10% smaller than the output by the Preprocessing Program. However, after all the files are compressed by gzip, the CSS file output by the Preprocessing Program is 5% smaller than that operated manually.

This emphasizes the importance of comparing the file size after HTTP compression, because the reduced file size does not indicate all problems. It implies that experienced CSS developers do not have to pay too much attention to the repeated CSS after compilation when using preprocessing programs, because it will become smaller after HTTP compression. The benefits of processing easier-to-maintain CSS code through preprocessing programs are better than focusing on the appearance or file size of the original CSS and the CSS output after compression.

In another experiment, I acquired a 60 kb HTML file (consisting of many reusable components) online and deleted each of its class attributes. After this process, the file size is reduced to 25 kb. After both the original and extracted files are compressed by gzip, their sizes are changed to 7.6KB and 6KB, respectively. The difference is only 1.6KB. The actual file size result caused by the free use of class is no longer worth emphasizing.