Summary of CSS specifications in team development

There are many common solutions on the Internet. Here I will focus on three points:

 

1. modular CSS to improve code reuse we know that a mature website requires a unified style and consistent user experience, such as: website color, font size, interaction behavior consistency should be determined at the beginning of the design, rather than being freely defined by individual developers. At the same time, the website should have a common style section (for example, the container and title on the right side of the personal homepage of Renren are the same as those on the "recent visit", "recommended", and so on ). In this way, we can extract the font size, public control, and style of the shared module from the website and use it as a separate module. In this way, everyone in the team can use this public style if they need this style to improve the code reuse rate. I think the CSS of a project can be split into two parts: Public CSS and business CSS. The modular CSS that we extracted in the project can be classified as public CSS. This part of code naming should not involve specific services, but should only be responsible for the specific logic in the module.

For business CSS, we need to have a uniform name. For example, a website has the following topics: files, communities, social relations, etc. During project planning, you need to set the name of this module, such as file-files, community-cmty (Community abbreviation), so that developers can use a public prefix when writing styles ,. cmty-cmtydetail. community or. commu, which is important for the unified style, and facilitates the slave to take over the work.

In this regard, you can look at the object-oriented CSS/oocss on the Internet.

 

 

2. CSS merging and compression, as the name suggests, in team development, developers will separately process the style of their respective units. The website is launched, in order to reduce the number of HTTP connections, we need to combine these CSS into a file for loading. At the same time, we may add some comments and line indentation during development, which will waste our bandwidth, we need to compress the merged CSS file. In fact, this optimization effect is very obvious, and the file size will be reduced by at least 20%. Currently, there are two types of CSS merge processing on the Internet: static merge and dynamic merge. Static merge means that CSS merging has been completed before the website is deployed and launched, and a static file is generated. Dynamic merge is implemented in combination with the back-end files. When CSS is requested, pass all CSS names to be merged as parameters to a backend file (such as ASP, PHP, and aspx). The merged style is dynamically generated and output by the backend file. The two solutions have their own advantages and disadvantages.

What I want to express here is that in our project, we should apply different merger schemes based on the project type. portal websites have high requirements on the loading speed for the first time, we do not need to merge all the CSS into the website. For a community-type website, You need to log in to access the website. Then, you can use the time entered by the user to load all the CSS, you can save the CSS request time for future access.

 

3. The benefits of unified CSS writing specifications are self-evident. Whether it is the background front-end, unified code specifications are necessary. 1. use letters 2. use shorthand as much as possible, in font, margin, padding, background 3. when processing parent-child nodes, use. parent-Child-grandson (most of the time, the parent name is related to the module name of the specific business. parent. child. grandson, it turns out that the latter is more likely to overwrite inter-module styles in team development, but also less readable. A simple example: there is a list in Module 1, and the second method is roughly as follows :. informationlist {}. informationlist. listitem {} and a list exists in Module 2, which is also used by developers. listitem, and think this name is not common, there is no limitation before, directly use. listitem, which can easily cause style conflicts. Maybe you have different opinions: We force all the styles to have a limitation on their module names, and change the. listitem in Module 2 to. module2. listitem. Isn't it OK? However, this is not good, because in actual applications, it is not required that all style Writing be limited by modules. For example, if a floating node under the body node is used, we cannot do this. At the same time, for the first writing method, we can also release a CSS detection software to detect syntax and determine coverage. (We know that we can determine that. A. B,. A> B and. B are much more complex than. A-B)