Experience with html and css architectures and htmlcss Architectures

Experience with html and css architectures and htmlcss Architectures

Css itself can be said to be a very simple and easy-to-get-started language. Making a page or a small business site has very low css requirements. As long as you are familiar with the syntax and can guess the meaning of English words, you can basically spell out a set of styles. Moreover, there are various auxiliary software available on the market.

 

If it is a relatively large website, the requirements for the css architecture will be relatively higher. For example, some parts that can be shared can be extracted as modules. This is the so-called modularization.

 

What are the advantages of modularization?

 

Without google's various results, the main points in my head are as follows:

1. Reduce meaningless development workload-you do not need to copy and paste a certain style code to other files.

2. The code is easy to maintain. If the module style is changed, you only need to modify a css file.

3. Combined with the corresponding annotations and directory structure, the html and css code of the entire project will look clearer.

 

However, modularity is sometimes quite tangled.

During actual development and maintenance of a website, the modules provided by html are usually maintained by functions. However, the so-called css modularization is a module based on the UI presentation, and the module division standards are not uniform.

For css, we want to divide modules according to css. However, html, including the html module, must be provided to downstream departments for development. They do not care about how css is divided and integrated.

 

Therefore, we have the following idea:

Css is divided into five layers

 

Base Layer -- is the basic style and basic module Style Layer shared by the whole site (I have included the clear 0 here ). This layer divides modules according to the UI rendering. In combination with good UI specifications, you can also ensure that the UI of the Basic module of the entire site is consistent. For large websites, this should be guaranteed by professional uidesign. If reliable, the base layer can even be developed into a core style package for a website.

 

Module layer -- is the Style Layer of the function module. This part of css is composed of two parts: Basic module style and non-public style.

 

Patch layer: A patch layer. When functional modules are used to splice pages, place the margins and styles that cannot be included in other modules in the patch. (For example, a page suddenly requires a banner)

 

Pages layer -- it is a style table file that imports the module layer and patch layer to the page. In combination with the software that can Merge css (you can search for some keyword Merge on google), compress all import files into this pages file and publish them online.

 

Tag layer-the top tag is equivalent to the css Code released after compression, and does not consume development costs. In this way, only one http request is allowed for each page css. It also supports local modular development.

 

Structure of html

 

Html is divided into four layers.

Base Layer-corresponds to the base layer of css. It is a reference file for the html code of the UI standard style and standard style.

Module layer-corresponds to the module layer of css. It can be provided to other developers to write all the statuses of the module. This not only ensures that the background developers can easily find the code of a function, but also solves the situation where a complete page is provided at the expense of some States. For example, a button has two statuses. If all the buttons are placed on the page, the page is easy to look like. If it is not placed on the page, it is not convenient for background engineers to develop. Of course, I wrote comments in other states on the page before, but there is still a problem, that is, I often need to repeat comments/uncomment this meaningless work.

Pages layer-is the final page. Since module has provided specific code to backend engineers, what about pages? It means to tell yourself and others where each module needs to be placed. Macro preview is also provided. No preview. It's always unpleasant!

 

Dev layer -- in fact, this is purely for development. Various background languages support include to manage public modules. But html does not. DW also provides a powerful and pitfall template function. However, it is rarely used. I don't know. Is the operation complicated? Not flexible? Or is it because a bunch of comments are generated? Looks very low? I don't know, either. Fortunately, xxx helped develop a local program to solve the html include problem. Files in the dev directory are written according to the syntax requirements of this program. The url address of a module is given, and then html code is automatically merged to generate files under pages.