[Project Summary] The overall architecture design of the front-end css of the e-commerce website (1)_html/css_WEB-ITnose

Recently I have been busy writing an outsourcing website. The main function of the website is art bidding and the sale of art derivatives. About 80% of the project has been completed. Now the front-end and back-end code volume has reached about 500,000 lines. I am mainly responsible for front-end design and front-end layout. Let’s put a design drawing of the website first. Because it involves Party A’s “commercial secrets”, it is mosaic:

　

　

This article is mainly My summary of this project is probably a summary of some front-end books or experiences I have read at this stage, so I won’t post so many design drawings. The design drawing of the entire project set the tone of the home page draft with the initial UI. Most of the remaining interfaces were made based on the home page draft. I will talk more about it when I have the opportunity. PS: However, the blog garden is now full of .net articles. In addition to js, ​​the front-end articles are those "copy and paste" source code articles. I hope to see more good front-end articles in the future.

There are already 3,40 single interfaces (not including the backend) of the entire website, and there are more than 10 css files accumulated (I will elaborate on this later, this is what I did in this project) The most failed part is also the reason why I write this blog).

　

　

I will talk about my understanding of each question one by one. If anything is not right, welcome to exchange:

1. What is css architecture? Why do architecture?

If you are building a small blog website or a small CMS, you may not need to consider the CSS architecture in many cases, because there are very few CSS files, and there are less than 10 interfaces in total, giving each It doesn’t take much work to write separate styles for the interface and seal a separate css file. However, if you switch to a large website with dozens or hundreds of interfaces, the CSS architecture is very necessary. Moreover, a good architecture can help the team develop together. It is impossible to say that there are dozens of interfaces, 3 front-ends, and more than a dozen per person. Okay, go ahead and write it. This kind of work is too inefficient and can easily lead to style conflicts. and styles were overwritten, it may be very fast to write. Everyone worked very hard to finish writing their own code. Then after the backend was integrated, it was found that the styles were all messed up. It took several days to change them, which was slower than writing.

Appropriate CSS structure can help developers reduce the amount of code and help the front-end development team collaborate better during the joint development process. At the same time, it can also optimize the overall structure of the front end. A reasonable CSS architecture can reduce the number of CSS files and the total size of CSS files, and reduce the access pressure on the server.

　 It can also greatly improve the reuse of front-end code and reduce code maintenance costs. For the kind of Party A who wants to change the interface every hour, it would be crazy to not have a good CSS structure. For example, each of your pages has a title bar, and each page is a separate CSS. Then suddenly one day, Party A Shen Jingbing says, I want to change the style. At this time, you have only two options: 1. Hug 2. Silently turn on the computer and start modifying interface by interface. Seeing here, many comrades with development experience should know that extract this title section, write it in a unified css file, and reference it in each interface. If you want to change it in the end, just go to the general css file and change it. . This is the simplest modularization. However, there are still many issues that need to be paid attention to during the modularization process: 1. For example, three interfaces have title bars, but what should I do if the three interfaces have different requirements for the title bar font color? What should I do if the upper and lower margin requirements are different? 2. Suddenly there is an interface. It has a title bar, but there is an additional background image in the title bar. How to solve this? To make it more troublesome, there is an extra

tab in the title bar. How to lay out the extra tab? This problem of resolving differences between modules is indeed worthy of careful study.

The usual CSS architecture, or the CSS framework of the current website, includes functions such as overwriting and resetting the browser's default style, extracting and abstracting the internal modules of the website, agreeing on CSS code specifications, and conflict resolution. If the project references other mature frameworks, such as bootstrap and yui, how can we separate these frameworks from those written by ourselves, so that we can implement styles without conflict? Talk slowly later.

How to create a css structure or how to implement a simple css structure?

Answer: Write code!

　

2. Where to start the CSS architecture?

Before starting a project, you should not just start working on the design drawings when you see them. You should first think about how to write them. Just like what our teachers say to us most often, "If you can only write code, you are just a mediocre programmer. Those who can make a good architecture or arrange how the project is developed are high-end programmers. Mediocre programmers Programmers can only eat bananas, and high-end programmers can sometimes eat pineapples, apples, etc.” Just start writing. As you write, you will find that you are doing repetitive work many times, copying and pasting, or rewriting one style after another for an interface module, or you will find that "fuck... Conflict, the style is messed up." Or, as you write, you find that what you wrote is wrong and want to go back and correct it, and then start to modify the files one by one... This kind of clumsy and unstructured writing of CSS is just physical work, and it takes a long time. A project I wrote before was like this. I slowly changed the 20 or so interfaces. I changed it for two whole days and I was going crazy...

Before starting a project, at the very least, you should think clearly about the general outline. How many css files are there, which css files need to be written out in a fixed version first, which css codes may be reused in large quantities, and which css files may undergo large-scale changes. Then start writing the first version according to the detailed requirements of these css.

For example, in the screenshot I posted above, the most intuitive header bar: is the same in every interface. Of course, we can use distributed view layout in the backend to achieve this, but in the early stage of interface front-end implementation, should we also extract this piece of html, css, and js, so that when the backend is finally integrated? It can also be faster, and if it happens to be Christmas, the customer says to change the background color above to blue, so you can just go to header.css and change the style, without having to do "manual work" "Yes."

Therefore, the first way to design the CSS front-end architecture is to divide it according to regions.

Based on the regional positioning of elements or modules within the page, the website can be divided into many areas: header, footer, sidebar, slogan, etc. Individual positioning of these areas can effectively achieve the division of distributed views. Each area has been extracted, and when creating a new interface, we only need to work together in it. If I remember correctly, this is what yui did.

I did not extract the css of this auction website separately because I think it is a bit redundant to separate it into a header.css and footer.css file. The number of css files is increasing, and each file The number of lines of code inside is very small. This depends on the specific code. If a footer style contains dozens of lines, then separate it into a file. So in the general css file: layout.css, I actually write it according to the area:. When I want to change the bottom navigation style, I just go to layout.css, search down, and change it.

　

　However, after we divided the interface, we found that there are still a lot of codes that appear repeatedly, such as login boxes, tables, text boxes, etc., so we have the third Two ways of division: Divide according to function.

The division by function is to look at the function of the element in the interface, and then extract elements and modules with the same function according to the specific function: font, color, button, form, etc. This should be now The model adopted by many mature frameworks, for example, my big bootstrap does this. Below is a screenshot of the less folder of bootstrap2.3. Obviously, they are all functional modules. In the end, what we directly apply is all integrated and compressed. min.css actually still has this structure in it:

　

　 It’s quite cool to divide it according to functions, because you can add a unified prefix to each function division. When there are code prompts Writing code in the compiler is extremely fast. If it were divided by area, sometimes it would be a little painful. "Oh, what is the css name of the footer? Oh, what is the class name of the sidebar that Xiao Wang wrote?"

In the code of this project, I actually used a mixed mode of the first method and the second method. As you can see from my last screenshot of the css file, I not only combined the repeated The code of the area module is abstracted, and functional modules such as sidebars and masks are also abstracted and organized to maximize the reusability of my code.

I used to think that the structure of my project was pretty good, but then the more I wrote, the more I got stuck, because most of the time I was doing useless work. Silly mistakes I made:

1. Module abstraction has limitations. For example, if the form is missing a special element, the originally written module will no longer be usable, and you will have to write it all over again.

2. Module abstraction is incomplete. When I thought I had almost done the module abstraction, I started writing with all my strength. As I wrote, I found that some modules had been forgotten, and many modules needed to be written by hand over and over again.

3. The css class name is not standardized. In the final analysis, the modules are not divided well. Until now, I have run out of words to name this website. It has many interfaces: add to shopping cart, add to favorites list, view shopping cart, confirm payment, fill in confirmation order, pay at a fixed price... I don’t have a good English foundation. What a nightmare... So I can only translate the Chinese name, and then use the camel case naming method: AddCart. In fact, there are many naming methods. The biggest advantage of the camel case naming method is that it can be named very intuitively without considering other things. However, the camel case naming method is more troublesome when naming subclasses, one long word after another...another One naming method is the underline method. In order to avoid trouble, use the underscore directly instead of the dash add_cart. This naming method is particularly good for naming subclasses. I will talk about this in the next few chapters.

　-------------The following---------is---------this article------- Core-----Now---

The following is the [core] of this article, and it is also my sad reflection T^T The recent project has been blocked and half-written, so I read some A book on front-end code specifications and a summary of website front-end development, and then I discovered a new structural method. After reading it, I felt really bad. Recommend this book "Writing High-Quality Code-Web Front-End Development Cultivation Method"

Another recommended CSS architecture method is: dividing according to interface functions: here the entire front-end of the website is abstracted into one Software or a project, what we have to consider at this time is what is the bottom layer of the project and what is the presentation layer of the project. Similar to the idea of ​​MVC that everyone often talks about, the front-end architecture is also divided like MVC, and all css can be Files are summarized into three categories:

1.base class 2.common class 3.page class

These three categories are not models that work side by side like regional architecture and functional architecture, but are based on The base class is the bottom layer, affecting layer by layer and cascading effects. I roughly drew a function diagram:

　 Indeed, it is like this pyramid structure. Let’s introduce the functions of each class in detail below.

　

　[1.base class]

　　　 As the name suggests, base, it is the most basic part of the entire CSS architecture. It is responsible for providing browser default style reset and basic function implementation. When it comes to basic function implementation in base, it mainly refers to the atomic level functional class implementation that involves a very small scope and a high degree of abstraction. For example, our most common .f12{font-size:12px;}, .mt30{margin-top:30px;}, each atomic class is only responsible for implementing one function, and it definitely does not involve the specific page UI, but is just for the above Several layers provide atomic functions, and the implementation of a specific module is achieved by combining these atomic classes. Of course, the base class is also responsible for the reset of the browser's default style. I think yui implements this very reliably. Nowadays, the on many websites is not bold, so this needs to be written in the reset section in advance.

The base class is the foundation of the entire CSS architecture. All interfaces will reference the entire file, which imposes requirements on this file: 1. The file size cannot be too large. 2. The file must be highly reliable and cannot have multiple versions. 3. After writing, try to reduce the number of maintenance times or try to avoid maintenance. Moreover, the base classes of different websites can be shared, because the base class does not involve any specific UI style and is highly portable.

What are the specific base class files? I will talk about this next time. I don’t have time today.

　[2.common class]

　Common class, which is the css file of the basic module implemented using css basic classes. We have put the text, margins, colors and other atoms in the entire interface The project has been extracted, and now we need to customize the module for the current website.

The "Uniformity Principle" in the design principles requires that the same website must maintain a consistent style. You cannot have a flat homepage. When you enter the list page, you will have a web 2.0 style with high lights, high shadows and cool flash. Page. Therefore, the search box, text box, button, and list within the same website are mostly of the same style, so this gives us an opportunity to extract these recurring modules into a common class, similar to MVC The model inside is also similar to the specific function files of the architectural function division we described above. In order to ensure reusability and flexible use as much as possible, we need to completely encapsulate these modules.

By the way, what should I do when the module needs to be customized?

I thought of two methods. One is to use less and other languages ​​​​to reserve style interfaces for modules, directly modify the configuration file, and then dynamically output the css file. 2. Minimize the UI attributes of the module, such as bgcolor or border, which can be left blank, and be combined with atomic classes according to your own needs during actual use. However, this method may have requirements for atomic classes and have an impact on the base file, so I made up a word myself: molecular class. Obviously, it provides large atomic class customization for modules, and customizes exclusive items for each module. Style classes, as well as the common layer, only need to be combined with each other when you need to customize the module style. I will write something to demonstrate in the next article. ​

　　[3.page class]

　　　　　　　　　　　　　　　　　　　　One css per page, but that’s about it. The page class is responsible for providing page-level styles. Page css may cause some troubling problems: 1. There are too many pages, so there are too many single files of page css, and each file is an http request. Can the server bear it? 2. In order to reduce the number of page css, they are merged into one page.css, but what about naming? For example, .part, .one, .main, .theme... What to do with these frequent class name merge conflicts?

The second problem can be solved by naming scope restriction.

As for the first question, you can merge single css files, and then you can look at the answer to the second question.

　　

　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　There is a lot of code in it. If applied to distributed view, a whole page is actually composed of several small interfaces. So how to avoid conflicts? How to avoid style override? More on that later.

　

　　_(:з　∠)_I am exhausted from coding so many words, so I will write this first today. See you in the next article~~ [Please communicate with me, please bring me some inferences, please don’t complain...]

In the next article, we will talk about the base css file in detail, and my own reconstruction of the project css.