[Project Summary] overall architecture design of front-end css for e-commerce websites (1)

Recently, I am not busy writing an outsourcing website. The main function of the website is the sale of art bidding and art derivatives. The project has been completed by about 80%, and now there are about lines of front-end code. I am mainly responsible for front-end design and front-end layout. Let's put a website design diagram first, as it involves Party A's "commercial secrets", so we can make a mosaic:

　　

　　

This article is my summary of this project or a summary of some front-end books or experiences I have read at this stage. The design drawing of the entire project was set by the ui at the beginning. Most of the remaining interfaces were created on the basis of the homepage draft and will be renewed in the future. PS: however, in the blog garden, all the gardens are now. net articles. In addition to js, front-end articles are those source files that can be copied and pasted. I hope to see more front-end articles in the future.

There are 3 to 40 single interfaces (not including backend) of the entire website, and more than 10 css files are accumulated (this will be detailed later, this is the most failed part of my project and the reason why I wrote this blog ).

　　

　　

One by one, let me talk about my understanding. If you are not right, you are welcome to talk about it:

1. What is the css architecture? Why is architecture required?

If you are working on a small blog website or a small CMS, you may not need to consider the css architecture in many cases. Because there are few css files, there will be less than 10 interfaces in total, writing styles for each interface and sealing a css file separately does not require much work. However, if you switch to a large website with dozens or hundreds of such 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, three front-ends, and one person is divided into dozens. Well, let's write it, this kind of work efficiency is too low, and it is easy to cause style conflicts and styles to be overwritten. It may be very fast to write, and everyone is very hardworking to write their own code, then, after the combination of the backend, the style was messy. After a change, it was several days slower than the write speed.

The appropriate css structure can help developers reduce the amount of code and help front-end development teams better cooperate in the process of joint development. 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 also greatly improves front-end code reuse and reduces code maintenance costs. For Party A who wants to change the interface once an hour, it is crazy to have a bad css architecture. For example, each page has a title bar, and each page is a separate css. Then one day, Party A said that I want to change the style. At this time, you have only two methods: 1. hold Party A's thigh and cry for no change 2. open the computer and start an interface modification. We can see that many development-experienced comrades should all know that extracting the TITLE section and writing it in a unified css file, each interface references it, if you finally want to change it, you only need to change it in the general css file. This is the simplest modularization. However, there are still many problems in the modularization process: 1. for example, three interfaces have title bars, but the three interfaces have different requirements on the font color of the title bars. What should I do? What should I do if the requirements for upper and lower margin are different? 2. Suddenly there is another interface with a title bar, but it has a background image in the title bar. How can this problem be solved? A little more trouble. There is one more <p> table tag in the title bar. How is the layout of multiple tables displayed? This problem of solving the differences between modules is indeed worth studying.

The general css architecture, or the css framework of the current website, includes resetting the coverage of the default browser style, abstracting the internal modules of the website, agreeing on css code specifications, and resolving conflicts. If other mature frameworks, such as bootstrap and yui, are referenced in the project, how can we separate these frameworks from those written by ourselves to implement styles without conflict? Wait for a while.

How does one implement the css architecture or a simple css structure?

A: write code!

　　

II. Where does the css architecture start?

Before you start a project, you can do it directly without seeing the design drawing. You should first think about how to write it. Just as our teachers often say to us, "only write code. You are just a mediocre programmer. It is a high-end programmer who can make a good architecture or arrange how the project is developed. Mediocre programmers can only eat bananas. High-end Programmers sometimes can eat pineapple or apple ". Start writing directly, and you will find that you are doing repetitive work, constantly copying and pasting, or rewriting one style or another for an interface module, you can also find the "slot, conflict, and messy style", or write it to find that you did not want to go back and modify it, and then start to change the file one by one... this kind of unstructured and clumsy css writing is just a kind of physical activity. A project that was written a long time ago is like this. The 20 interfaces have been changed slowly for two days, all going crazy...

Before you start a project, you should first find out how many css files are there, which css files need to be written into a fixed version, and which css code may be reused in large quantities, which css files may be modified on a large scale. Then start to write the first version according to the detailed requirements of these css.

For example, the most intuitive header column I put above is the same on each interface. You just need to change the style in the workshop, so you don't have to go to "physical activity.

Therefore, the first css front-end architecture is designed by region.

Based on the element or module area on the page, the website can be divided into many areas: header, footer, sidebar, slogan, etc, the independent positioning of these regions can effectively achieve the division of the distribution view, and each region is extracted. When creating a new interface, we just need to work together in it. If you remember correctly, yui does this.

In the cssws of this auction website, I don't have to leave it alone. I think it is a bit redundant to separate header.css footer.css files. The number of css files is increasing, while the number of lines of code in each file is very small. According to the specific code, if dozens of lines are written in a footer style, you can split it into a file. Therefore, in the general css file layout.css, I actually write it by region :. When I want to change the baseline navigation style, I will go directly to layout.css and find it.

　　　　

However, after we split the interface, we found that there are still a lot of code repeated, such as login boxes, such as tables, such as text boxes, so there is a second division method: divided by function.

By function division, you can see what functions are in the element interface. Then, based on the specific functions, you can extract elements and modules with the same functions from the module. The structure is actually the same:

　　　　

It is quite easy to divide by function, because you can add a uniform prefix for each function division, and writing code in the compiler with code prompts is very fast. In other words, if it is divided by region, sometimes it hurts a little. "Oh, what is the css name of the footer? Oh, what is the class name in the sidebar written by Xiao Wang ".

In the code of this project, I actually use the first mode and the second mode, which can be seen from the previous css file, I not only abstracted the code of the repeated regional module, but also abstracted the functional modules such as sidebar and mask to improve the reusability of my code as much as possible.

Previously, I felt that the architecture of my project was doing well, but later I began to write more and more, because I often did nothing. My silly x error:

1. Restrictions on module abstraction. For example, if a form requires a special element, the previously written module cannot be used, and you have to write it again.

2. The module abstraction is incomplete. When I thought I had already written the module abstraction almost, I began to write it with my full strength. I wrote it and found that some modules were forgotten, and many modules needed to write it again and again.

3.css class names are not standardized. In the end, modules are not well divided. This website writes to the present, my name is already poor, it has many interfaces: add to shopping cart, add to Favorites list, view shopping cart, confirm payment, fill in Confirm order, fixed price payment... it's a nightmare to have a good English background... therefore, only Chinese names can be translated, and the camper method is AddCart. In fact, there are still many naming methods. The biggest advantage of the camper naming method is that it can be intuitively named without consideration. However, the camper naming method is a headache when naming sub-classes, one long word after another... another naming method is the underline method. In order to avoid the trouble of using the underline without using the middle bar add_cart, this naming method is especially nice for subclass naming, which will be repeated in the subsequent summary.

------------ The following --------- is ------------ this article ------- core ---

The following is the [core] of this article. It is also my painstaking reflection on the status of T ^ T's recent project being blocked and being half-written, so I read some summary books on front-end code specifications and website front-end development, and then found a new structure method. After reading this, it was really bad for the whole person. We recommend this book writing high-quality code-practices for web Front-end development

Another recommended method of css architecture is to divide the architecture by interface functions. Here, the entire front-end of the website is abstracted into a software or a project, at this time, we need to consider what is the bottom layer of the project and what is the performance Layer of the project. Similar to the mvc idea, we also divide the front-end architecture into mvc-like architectures, you can classify all css files into three types:

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

These three types of architecture do not share the same role as the regional architecture or functional architecture. Instead, they use the base class as the underlying layer, with layer-by-layer effects and cascade effects. A Role diagram is drawn:

Indeed, just like this pyramid structure, the role of each class is described in detail below.

　　

[1. base Class]

As the name implies, basic is the most basic part of the css architecture. It provides browser default style resetting and basic functions. Speaking of the basic function implementation in base, it mainly refers to the implementation of the function class at the atomic level that involves a very small scope and a high degree of abstraction. For example, the most common. f12 {font-size: 12px ;},. mt30 {margin-top: 30px;}, each atomic class is only responsible for implementing one function. It does not involve the specific page ui, but only provides atomic functions for the previous layers, the implementation of a specific module involves the combination of these atomic classes. Of course, the base class is also responsible for reset of the default browser style. I think yui implementation is very reliable. Currently, many websites

The base class is the foundation of the entire css architecture. All interfaces reference the entire file, which puts forward the following requirements for this file: 1. the file size cannot be too large. file reliability is high, so multiple versions are not allowed. reduce the number of maintenance times or avoid maintenance. In addition, the base classes of different websites can be shared, because the base classes do not involve any specific ui styles and are highly portable.

What are the specific base-class files? Let's take a look at this next lecture. It's unavailable today.

[2. common class]

A common class is a css file of the Basic module implemented by the css basic class. We have extracted the text, margin, color, and other atomic projects from the interface, now we need to customize the module for the current website.

In the design principle, the "uniformity principle" requires that you maintain the same style on the same website. You cannot flat the Home Page. When you go to the List page, you can see a high-gloss and high-shadow web style page with a cool flash. Therefore, the search box, text box, button, and list in the same website are in a uniform style in most cases, so this gives us a chance, remove these recurring modules from the common class, similar to the model in MVC, and similar to the specific functional file of the Architecture Function Division described above. To ensure reuse and flexible use, we need to complete the encapsulation of these modules.

What should I do when the module needs to be customized?

I have come up with two methods: one is to reserve a style interface for the module using less and other languages, directly modify the configuration file, and then dynamically output the css file. 2. Try to reduce the ui attributes of the module, such as bgcolor or border, which can be vacant. In actual use, combine them with the atomic class according to your own needs. However, this method may have requirements for atomic classes and may have an impact on base files. So I wrote another word: molecular class, it is obvious that you can customize the original sub-classes for the modules and customize the exclusive style classes for each module. Similarly, for the common layer, you only need to combine the modules when you need to customize the module styles. In the subsequent articles, write something to demonstrate.

[3. page class]

The page class can also be seen from the catalog. It is at the top of the pyramid, and its function scope is also the smallest, that is, every page does not have a css for every page, but it is similar. The page class provides page-level styles. Page css may cause some tangled problems: 1. There are too many pages, so there are too many single pages in page css. Every file is an http request. Can the server afford it? 2. When page cssis not many, it is merged into a page.css file, but what should I do? Such as. part,. one,. main,. theme..., and these frequently-occurring class name merging conflicts. What should I do?

The second problem can be solved by specifying the name range.

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

　　　　　　

Therefore, the code in the page layer is odd. If the distributed view is applied, an entire page is actually made up of several small interfaces. How can we avoid conflicts? How to Avoid style overwrite? I will discuss it in detail later.

 

　　　　

_ (: Busy "success) _ I am exhausted by so many characters. I will write this code first today. For more information, see ~~ [Ask for communication, ask the master to push for inner, and do not speak out ...]

In the next article, let's talk about the css files of the base class and the reconstruction of the Project css by myself.

Finally, I want to talk about zookeeper