A little experience of html and css architecture_html/css_WEB-ITnose

CSS itself can be said to be a very simple and easy to get started language. To create a page or a small business website, the CSS requirements are very low. As long as you are familiar with grammar and guess the meaning of English words, you can basically spell out a set of patterns. What’s more, there are a variety of auxiliary software on the market.

If it is a relatively large website, the requirements for CSS architecture will be relatively high. For example, there are some public parts that can be extracted and made into modules. This is called modularity.

What are the advantages of modularity?

Without going through various Google results, the main things that come to my mind are the following:

1. Reduce meaningless development work There is no need to copy and paste a certain style code into other files.

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

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

But modularization is sometimes very confusing.

In the actual process of developing and maintaining a website, the modules provided by html are usually maintained according to functions. However, the so-called modularization of CSS refers to modules based on UI presentation, and the standard for dividing modules is not uniform.

For the organization of css itself, we would like to divide modules according to css. But for html, including when providing it to downstream departments for development, of course the html module must be provided. They don't care about how CSS is divided and integrated.

So, I came up with the following idea:

css is divided into 5 layers of structure

The base layer?? is some basic styles and basic module style layers common to the entire site (I include Qing 0 here). This layer is equivalent to dividing modules according to UI presentation. If you cooperate with good UI specifications, you can also ensure that the basic module UI of the entire site is consistent. For large websites, this should be guaranteed by professional UI design. If it's reliable, the base layer can even be developed into a website's style core package.

The module layer?? is the functional module style layer. This part of css is composed of basic module style and non-public style.

patch layer?? is the patch layer. When using functional modules to combine pages, put margins and other styles that cannot be included in modules in patches. (For example, a page suddenly requires adding a banner)

pages layer?? It is a style sheet file that uses the import method to introduce things from the module layer and patch layer to the page. . With the help of software that can merge css (you can search for some by searching the keyword "Merge" on Google), compress all imported files into this pages file and put them online.

tag layer ?? The top tag is equivalent to the css code that is actually compressed and launched online, and does not consume development costs. This basically ensures that there is only one http request for each page's css. It can also meet local modular development.

The corresponding structure of html

html is equivalent to being divided into 4 layers.

base layer ?? Corresponds to the base layer of css. It is a reference file for the entire UI standard style and standard style HTML code.

Module layer?? Corresponds to the module layer of css. It can be provided to other developers, and all the status of the module must be written in it. This not only ensures that backend developers can easily find the code for a certain function, but also solves the problem of sometimes sacrificing part of the state to provide a complete page. For example, a button has two states. If they are placed on the page, the page will be easily distorted. If it is not placed on the page, it will be inconvenient for backend engineers to develop. Of course, I used to write comments on other states on the page, but there is still a problem, that is, I often need to repeat the meaningless labor of commenting/uncommenting.

The pages layer is the assembled pages. Since the module has provided specific code to the backend engineers, what does the pages do? Its purpose is to tell yourself and others where each module needs to be placed. A macro preview is also provided. It’s always frustrating to not have a preview!

dev layer?? Actually, this is purely for development. Various backend languages ​​have includes that can be used to manage common modules. But html does not. For this reason, DW also provides a template function that is both powerful and cheating. But it feels like few people use it. I don’t know if it’s because the operation is complicated? Not flexible? Or is it because a bunch of comments were generated? Looks vulgar? I don’t know, I don’t have one anyway. Fortunately, xxx people helped develop a local program to solve the include problem of html. The files in the dev directory are written according to the syntax requirements of this program. Given a url address under a module, the html code is automatically merged to generate files under pages.