Decouples HTML, CSS, and JS

Currently, on the internet, any slightly complex website or application will contain many HTML, CSS, and JavaScript. With the development of Internet application and our increasing dependence on it, it is absolutely necessary to set a plan for organizing and maintaining your front-end code. Currently, on the internet, any slightly complex website or application will contain many HTML, CSS, and JavaScript. With the development of Internet application and our increasing dependence on it, it is absolutely necessary to set a plan for organizing and maintaining your front-end code.

Today's large Internet companies are attempting to stick to code modularization as more and more people are exposed to the increasing number of front-end code. In this way, changing part of the code of the program will not inadvertently affect the subsequent execution of irrelevant parts.

Preventing unexpected consequences is not an easy solution, especially HTML, CSS, and JavaScript are essentially mutually dependent. What's worse, when it comes to front-end code, some traditional computer science principles, such as focusing on separation, are rarely discussed in the long term used in server development.

In this article, I will explain how I learned to decouple my HTML, CSS, and JavaScript code. The best way to get from personal and others' experiences is not so obvious, but usually not intuitive, and sometimes it is contrary to many so-called best practices.

Target

Coupling always exists between HTML, CSS, and JavaScript. In any case, these technologies are born to interact with others. For example, a flash conversion effect may be defined with a class selector in the style sheet, but it is often initialized by HTML and triggered through user interaction, such as writing JavaScript. Some front-end code coupling is inevitable, so your goal should not simply eliminate coupling between codes, but reduce unnecessary dependency coupling between codes. A backend developer should be able to change the tags in the HTML template without worrying about unexpected destruction of CSS rules or some JavaScript Functions. As today's web teams are growing and specialized, this goal is even worse than ever.

Reverse Mode

The tight coupling of front-end code is not always obvious. In fact, the complexity is that, on the one hand, it seems to be loosely coupled, but on the other hand, it is tightly coupled. The following are all anti-patterns that I have done or read many times, and learned from my mistakes. For each pattern, I will try to explain why coupling is so bad and point out how to avoid it.

Overly Complex Selector

CSS Zen Garden shows the world that you can completely change the appearance of the entire website without changing any HTML Tag. This is a typical example of Semantic Network Movement. One of the main principles is to avoid the use of representations. At first glance, CSS Zen Garden may look like a good example of decoupling. After all, separating styles from the markup language is the focus. However, if you do this, the problem arises. You often need to have such a selector in your style sheet, as shown below:

#sidebar section:first-child h3 + p { }

In CSS Zen Garden, although HTML is almost completely separated from CSS, CSS is strongly coupled to HTML. At this time, you need to have a deep understanding of the structure of the markup language. This may not seem very bad, especially when someone maintains CSS and HTML at the same time, but once you add more people, this situation becomes uncontrollable. If a developer is in the first

Added

The above rules cannot take effect, but he does not know the reason.

CSS Zen Garden is a very good idea as long as your website tag is rarely changed. However, this is not the case with today's Web applications. Compared with lengthy and complex CSS selectors, the best way is to add one or more class selectors to the root element of the visualization component itself. For example, if a sub-menu exists in the sidebar, you only need to add a submenu class selector for each sub-menu element, instead of using the following format:

ul.sidebar > li > ul {  /* submenu styles */}

This method requires more class selectors in HTML, but in the long run, this reduces coupling and makes the code more reusable and maintainable, it also enables you to tag your documents. If there is no class selector in HTML, developers who are not familiar with CSS do not know how HTML changes affect other code. On the other hand, using the class selector in HTML can clearly see the styles or functions used.

Responsibilities of multiple class selectors

A class selector is often used as a hook for style and JavaScript at the same time. Although this seems very economical (because at least one class tag is reduced), in fact, it is to couple the Expression and Function of elements.

Add to Cart

The preceding example describes a "add to shopping cart" button with the add-item style.

If developers want to add a click event listener for this element, it is very easy to use an existing class selector as the hook. I mean, since one already exists, why should I add another? But think about it, there are a lot of buttons like this, all over the website, all calling the same JavaScript function. If the marketing team wants a button that looks completely different from others but has the same functionality. Maybe more significant colors are needed.

The problem is that the JavaScript code that listens to the Click Event wants the add-item class selector to be used, but your new button cannot use this style (or it must clear all declared, and then reset the new style ). In addition, if you want to use the add-item class selector for the code you are testing, you have to update the code and use it. Worse, if the "add to shopping cart" function is not only used by the current application, that is, the code is abstracted as an independent module, even a simple style modification may cause problems in different applications.

The best way to use javaScript Hooks is to avoid coupling between styles and behavior class selectors if you need to do so.

My personal suggestion is to use a prefix for JavaScript hooks, for example, js -*. In this case, when the developer sees such a class selector in the HTML source code, he will fully understand the original cause. Therefore, the preceding "add to shopping cart" example can be rewritten as follows:

Add to Cart

Now, if you need a button that looks different, you can easily modify the style class selector regardless of the behavior class selector.

Add to Cart

More style operations in JavaScript

JavaScript can use class selectors to search for elements in the DOM. Similarly, it can also change the style of elements by adding or removing class selectors. However, if these class selectors are different from when the page is loaded, the problem may also occur. When JavaScript code uses too many style operations, those CSS developers can easily change the style sheet, but do not know that the key functions are broken. It does not mean that JavaScript should not change the visual component appearance after user interaction, but should use a consistent interface if so, use a class selector that is inconsistent with the default style.

Similar to the class selector with the js-* prefix, we recommend that you use the class selector with the is-* prefix to define the State of the visualization component to be changed. Such CSS rules can be like this:

.pop-up.is-visible { }

Note that the status class selector (is-visible) is connected after the component class selector (pop-up), which is very important. Because the status Rules describe a status and should not be listed separately. Different state styles can be used to differentiate more different from the default component styles.

In addition, we can write test scenarios to ensure that prefix conventions like is-* are followed. One way to test these rules is to use CSSLint and HTML Inspector.