Semantic HTML and front-end architecture

Covers HTML semantics, components and methods of the front-end architecture, class naming patterns, and HTTP content compression.

We won't stop exploring
And the end of all our explorations
Will get to where we left off.
So we met this place for the first time.

T.s. eliot-"Little Borer"


About semantics
Semantics is the study of the relationship between marks and symbols, and their meanings. In linguistics, this is primarily a study of the meaning of symbols (such as words, phrases, or sounds) in a language. In the context of front-end Web development, semantics are mostly related to the consistent acceptance of elements, attributes, and attribute values, including extensions like microdata. These identities are often defined in the specification, and they help programmers (that is, humans) to better understand the different aspects of the information on the site. However, even after normalization, the semantics of elements, attributes, and attribute values are subject to the developer's adaptation and absorption. This may result in subsequent modifications to the formal identity semantics (which is also an HTML design principle).


Differentiate between different types of HTML semantics
Writing the "Semantic html" principle is one of the foundations of modern professional front-end development. Most of the semantics are about the intrinsic attributes of existence or expected content (e.g. H1element,langattribute,emailvalue of Thetypeattribute, microdata).

However, not all semantics are rooted in content . The class name cannot be "non-semantic" (unsemantic). No matter what name you use, make it meaningful and purposeful. The semantics of class names can be different from those of HTML elements.　　We can unify the "global" semantic naming of HTML elements, certain HTML attributes, micro-data, and so on, to avoid confusion with "local" Web site/application-specific semantics that are often contained within attribute values, such as Theclassattribute. Although the HTML5 specification section on classes repeats that the "best practice" is as follows ...

..... The author encourages the use of [class attribute] values to describe the display of content, rather than the performance value required for the content described.

..... There is no intrinsic reason to do so. In fact, it is often a barrier to large Web sites or applications when working.

• Content-layer semantics already serve as HTML elements and other attributes.
• The class name has little or no semantic useful information given to the computer or browse, unless it's a small part (computer readable) of the contracted name-micro-format section.
• The primary purpose of the class name is to set the hooks for CSS and JavaScript. If you don't need to add demos and behaviors to your Web document, you may not need to use classes in your HTML file.
• the class name should provide useful information to the developer. when you read a DOM snippet, it helps to understand what a particular class's name is going to do, especially in the early stages of working with multiple development teams, including non-HTML components.

In this very simple example:

1. <div class= "News" >
3. [News content]
4. </div>

Copy Code

From the above example it is clear that the class name news does not tell you anything. It does not give you any information about the organizational structure of the component, it cannot be used to describe whether the content is "news". The semantics of the class name and the nature of the content have been reduced, the architecture has become smaller, or it is easy for other developers to use.


Content-Independent class name
Another alternative is to derive the semantics of the class name from the repeating structure and the functional pattern in the design.Most reusable components have a class name that is not related to the content. 　　

Instead of having a class name that strictly reflects a particular content, we should not be afraid to build relationships between clear and clear hierarchies. Doing so does not make the class "No semantics", it simply means that their semantics are not derived from the content. If additional HTML elements help create robust, flexible, reusable components, we should not be afraid to include these elements. Doing so does not make HTML non-semantic, it simply means that you are using exactly the elements you need to have the least amount of markup content.


Front-end architecture
The component/template/object-oriented architecture is designed to develop a set of reusable components that contain a range of different types. In a canonical application, the semantics of class names are driven and served by the pragmatist's main purpose-to provide meaningful, flexible, reusable connections for developers to use.


Reusable and composable components
A scalable html/css must largely depend on the hierarchy within the HTML so that reusable components can be created. A flexible and reusable component can neither rely on a part of the DOM tree nor need to use a specific element type. It should work with different editors and be easily subject to subjectivity. If necessary, extra HTML elements (except those that need to tag the content) can be used to make the group price stronger. Nicole Sullivan The so-called media object is a good example.

Components can be easily combined to benefit from the revocation and support class of the type selector. The following example shows a simple combination of the BTN component and the Uilist component. The problem is that specifying. BTN is better than specifying. Uilist (which overrides the shared property), and the Uilist component requires an anchor tag as a child node.

1. . btn {/* styles */}
2. . uilist {/* styles */}
3. . uilist a {/* styles */}

Copy Code

1. <nav class= "Uilist" >
2. <a href= "#" >Home</a>
3. <a href= "#" >About</a>
4. <a class= "btn" href= "#" >Login</a>
5. </nav>

Copy Code

Using class to decorate child DOM elements is one way to improve ease of use and to combine other components with uilist. While this helps to reduce the specified rules, the main benefit is that you can apply a structured style to any type of child node.

1. . btn {/* styles */}
2. . uilist {/* styles */}
3. . uilist-item {/* styles */}

Copy Code

1. <nav class= "Uilist" >
2. <a class= "Uilist-item" href= "#" >Home</a>
3. <a class= "Uilist-item" href= "#" >About</a>
4. <span class= "Uilist-item" >
5. <a class= "btn" href= "#" >Login</a>
6. </span>
7. </nav>

Copy Code

JavaScript Specifies class
Using JavaScript to specify the form of class can reduce the risk: the theme or structure of the component changes when the corresponding JavaScript is broken. An effective approach is that JavaScript hooks use only the specific class of js-* and remain.

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

Copy Code

By doing so, you can reduce the risk that any required JavaScript behavior or complex functionality will inadvertently be affected by changes in the structure or theme of the component.


Component editor
Components often have a number of different appearances that differ slightly from the underlying components, such as a background or border of a different color. There are two main patterns that are used to create these different components. I call them "single-class" mode and "multi-class" mode.

"Single-Class" mode

1. . btn,. btn-primary {/* button, template styles */}
2. . btn-primary {/* Styles specific to save button */}

Copy Code

"Multi-Class" mode

1. . btn {/* button template styles */}
2. . btn-primary {/* Styles specific to Primary button */}
4. <button class= "BTN" >Default</button>
5. <button class= "btn btn-primary" >Login</button>

Copy Code

If you use a preprocessor, you can use the @extend feature of Sass to reduce some of the maintenance work involved in using the "single-Class" mode. However, even with the help of the preprocessor, I would prefer to use the "multi-Class" mode and add the edit class to the HTML.

I found this to be a more scalable model. For example, with the base BTN component, add 5 Types of buttons and 3 additional sizes to it. Using the "Multi-Class" mode, you will eventually get 9 kinds of classes that can be mixed. But using the "single class" mode you will have 24 species.

It is also easier to make some contextual changes to the component if it is really necessary. You might want to make some slight adjustments to the appearance of any btn in another component.

1. /* "Multi-Class" adjustment */
2. . thing. BTN {/* adjustments */}
4. /* "Single-class" adjustment */
5. . thing. BTN,
6. . thing. Btn-primary,
7. . thing. Btn-danger,
8. . thing. btn-etc {/* adjustments */}

Copy Code

The

Multi-class mode means that in a component, you only need a selector within a component to mark any type of btn-style element. The "single-class" mode means that you have to assume any possible button type and adjust the selector when a new button variable is created.


structured class name
at the time of creating the component and the "subject" on that basis, Some classes are used as the boundaries of components, some are used as decorators for components, and some are used to render some DOM nodes into a larger, abstract presentation component.

It is difficult to infer the relationship between these styles of btn (components), btn-primary (decorators), btn-group (components), and Btn-group-item (child objects in the component), because these names do not clearly reveal the purpose of these classes.　　There is no unified pattern.

as early as 2011, I started using naming patterns, which allowed me to quickly understand the external relationship between DOM fragment nodes, which is much faster than trying to cobble together the entire site by moving html,css and JS files back and forth. The mark in the main points is mainly influenced by the way the BEM system is named, but I changed it into a way that I think is easy to use.

Since I started writing this article, several other teams and frameworks (translators plus: authors) have adopted this approach. Montagejs changed the symbol to another style, which I prefer and is currently using the Suit Toolkit:

1. /* Utility */
2. . U-utilityname {}
4. /* state-utility */
5. . U-isstatename {}
7. /* Component */
8. . ComponentName {}
10. /* Component modifier */
11. . Componentname--modifiername {}
13. /* Component descendant */
14. . Componentname-descendant {}
16. /* Component descendant modifier */
17. . Componentname-descendant--modifiername {}
19. /* Component State (scoped to Component) */
20. . Componentname.is-stateofcomponent {}
22. /* Component mixin (ancestor style dependencies) */
23. . With-componentname {}

Copy Code

This is just one of the useful naming patterns I have found at the moment and it can take any form. But the advantage is to eliminatejustThe ambiguity of a dependent (single) hyphen or underscore, or a camel-case class name.


Note the original file size and HTTP compression
With the discussion of modularity and extensibility, CSS becomes a concern about file size and bloat. Nicole Sullivan's conversations are often mentioned to save file size (and maintenance improvements). Saving file size is a problem that some companies such as Facebook face when adopting this modular and extensible approach. Further, I want to share the effect of HTTP compression on my finished files when I write on the preprocessor and use a lot of HTML elements.

When Twitter bootstrap came out, I rewrote the compiled CSS to better reflect how I wrote and compared the size of the file before and after. After streamlining the two files at the same time, handwritten semantics of CSS are about 10% smaller than those written by the preprocessor. But when two files are compressed with gzip, the preprocessor writes about 5% less CSS than handwritten semantics.

This highlights the importance of file size comparisons after HTTP compression, because the size of the compressed file does not fully explain the problem. This also implies that experienced CSS developers do not have to dwell too much on a certain amount of repetition in a compiled CSS when using a preprocessor, because its size will naturally become smaller after HTTP compression. The benefits of more maintainable CSS code processed by the preprocessor outweigh the size or aesthetic considerations of the original file and the compressed output of the CSS file.

In another practice, I downloaded a 60KB-size HTML document from an online website, removing all of the class attributes (which make up many reusable components). This process reduces the size of the document to 25KB. When both the original document and the detached document are respectively gzip compressed, their size becomes the difference between 7.6KB and 6kb– only 1.6KB. The actual effect on the size of the file by free use of class is really not worth emphasizing and amplifying.


how to learn to Stop worrying ...
The experience of many skilled developers has led to huge shifts in large-scale website and application development over the years. Nonetheless, for the ideologically weaned individuals, "semantic html" refers to the use of content-derived class names (even as a last resort), which usually requires you to complete a large application before you become acutely aware of the impractical nature of the method. You have to be prepared to abandon old ideas, look at alternatives, and even regain the methods you've abandoned before.

As soon as you start writing about the extraordinary sites and applications that you and others not only want to maintain but actively iterate over, you will quickly find that, despite your best efforts, your code is becoming more and more difficult to maintain. Some people come up with their own way of solving these problems, and you're worth the time to explore their work: Nicole's blog and object-oriented CSS project, Jonathan Snook's Scalable CSS modular architecture, and Yandex's block element modifier approach.

When you choose to write with HTML and CSS and try to reduce the time you spend on writing and editing CSS, this involves having to accept that if you want to change the style of HTML elements, you have to spend more time modifying the elements on the class. This proves to be quite practical, whether for front-end or back-end developers-anyone can rearrange the pre-built Lego bricks; it turns out that no one can invent CSS alchemy.

Semantic HTML and front-end architecture