Use 'Five Whys' to write CSS_html/css_WEB-ITnose

I believe most people have had painful experiences with CSS. From the time I joined the company to now, less than two years ago, the most common discussion about CSS is that it is ‘difficult to adjust’. So I have been exploring what kind of problems there are, why many people find CSS difficult to write, and how to make others write CSS more elegantly. During the Code Review, I gradually discovered the problem. In fact, many people have mastered rich CSS knowledge, but they don’t know how to group attributes and write them as classes. In the end, I had to randomly name the element that needs to be styled as a class and throw all the attributes to be written into this class. If the priority is not enough, add all the previous selectors. The result is that CSS code continues to accumulate, duplication and redundancy continue to increase, and maintenance becomes difficult.

The problem was found, but how to solve it? Although I shared it several times within the project team and often raised some questions during Code Review, I still had little success. Sometimes it’s easy to know what’s right, but it’s hard to know how to get it right. Until recently, after reading several books, I discovered a method that is very suitable for guiding the design of CSS, which is the Five Whys or Five Questions method. The Five Questions method comes from Toyota's lean production, and later was naturally derived from lean entrepreneurship. This method can be seen in DDD and UX related books. Its purpose is to deeply discover the real reasons hidden behind a large number of phenomena. At first glance, it seems to be a management method, but in fact I think it is a way of thinking, that is, to find the root cause of the problem and solve it. Therefore, it is used in various fields, and it is naturally suitable for the problems faced by CSS.

Scenario example

Let’s take an example first. One day Code Review found a CSS code written like this:

.max-width {    max-width: 300px;}

This resulted in the following dialogue (Purely fictional):

UI Dev: "You shouldn't write it like this. What's the difference between this and writing inline styles directly?"

Dev : "If I don't increase the maximum width, there will be an extra part on the left side of the element on the page. Otherwise, can I add a margin?"

UI Dev: "This... I'm not sure, I've never encountered such a problem, there must be something wrong somewhere."

Dev: "It's really not good to write like this. I don’t know what this line of code means, and I don’t dare to modify it. But how should I write it? "

UI Dev: "Well, let’s try five. Why, find the root cause of the problem. "

Dev: "Okay, the CSS problem has been bothering me for a long time. It would be best if it could be solved."

UI Dev: "First of all, why do we need to add a maximum width to the element?"

Dev: "Because if you don't add it, there will be an extra part. "

UI Dev: "Then why does this element have an extra part?"

Dev: "Because the maximum width is not added. Just a joke, don’t be angry. Actually, I’m not sure, but after looking at it with DevTools, it seems that the width of its parent element is also wrong. "

UI Dev: "It’s close. Why is the width of the parent element wrong? "

Dev: "Because the padding of the parent element is different on both sides. "

UI Dev: "Why are the padding of the parent element inconsistent?"

Dev: "Ah, I know. It turns out that a last pseudo-selector was written for the parent element of the parent element. It is Used to set padding-right to 0, because the parent element is now the last one, so it is affected. "

UI Dev: "Don't worry, why should the last one be used? Set the padding-right of the element to 0? "

Dev: "Because the original last element contains a control that cannot modify the style, so you need to set the padding-right to 0. Can let it go. "

UI Dev: "So this is the problem. Our intention is to add a padding-right attribute of 0 to the container of the space, right? Instead of adding it to the last element, you should write a class, maybe called 'widget-container' or something like that, put it on that container, and then delete the last pseudo-selector, so everything will be normal. The original problem is actually fine. "

Dev: "So that's it, great. I learned that the problem with the style is not necessarily the problem with the code. The five whys are so useful. ”

Asking "why" repeatedly in this way can help us find the root of the problem. If we only solve the problem from the superficial phenomenon, it may lead to the opposite consequences. Moreover, the last pseudo-selector in the example was caused by simply writing such a line of code without finding the root cause. This example also illustrates the benefits of Five Whys to CSS, which not only finds the root cause of the problem, but also makes our intentions clearer when writing CSS. In this way, the problem of difficult class naming is solved. The element whose padding-right should be 0 is the container of that control, so it is easy to come up with a name like "widget-container" because it was found through the five why method. The real intention is that at this time, it is clear what the class is called and where it should be placed.

Invest proportionally

But sometimes the projects we face are not so kind. The more layers of "why" there are, the more complicated the relationship between CSS is, so let's talk about it now Let’s talk about an important principle among the Five Whys, invest in proportion. The main idea is that small problems require small investment, and big problems require large investments. The higher the level of the problem, the greater the investment. In terms of CSS, when a style anomaly is found, the more repetitions of the root cause found using the Five Whys, the more serious the problem is and the more investment should be invested in the solution to the problem.

Going back to the above example, through the problem of an abnormal element position, we found that the root cause came from a control that required a container element with an inner margin of 0. Since we discovered it for the first time, we chose to invest a smaller amount. The solution is to add a class to the control to remove the padding. It seems to be very correct at the moment, but if you find this control in depth from different problems one after another, it means that the level of the problem has increased, and you should not just add this class to each container that calls the control. At this point we can consider other methods, such as setting the inner margins of all containers to 0, and adding targeted margins to internal elements. If the problem level continues to increase, we can also modify or even replace the controls, or reconstruct other parts. to adapt to the control. In short, it is necessary to choose the means to solve the problem according to the problem level. The advantage of this is not only that it can automatically adjust the efficiency as in the original lean, but also that it can be restructured accordingly when the style requirements are clearer.

Due to the descriptive nature of CSS, it is very free, so there are often a hundred implementations of the same requirement by a hundred developers. When encountering a requirement for the first time, it is even more difficult to write the best implementation. You can only write a targeted exclusive class and throw in the required attributes. In fact, the problem is not here, but whether the original code can be reconstructed when the same problem occurs later, and a more universal class can be written based on all related problems. Experienced UI Devs sometimes judge by experience and write such classes directly, as is the case with frameworks such as Bootstrap, but developers with no or less experience will have doubts. The proportional investment principle of the Five Whys can drive the development of CSS very well, using in-depth root causes to connect problems that occur on different elements or even different pages. This allows us to organize the code according to the current problem level with peace of mind, and wait until next time After encountering a problem and finding it here, I refactored it to solve the problem.

Original link