Reasonable structure of website design CSS

Schema CSS

Under the premise that the current browser is universally supported, CSS has been given an unprecedented mission. However, the more CSS you rely on, the more complex the style sheet file becomes. At the same time, the test of file maintenance and organization comes along with it.

(Once upon a time) as long as a CSS file is enough-all rules (rule) come together, and additions and deletions are very convenient-but this day has long gone. When building a new website, it takes time to plan how to organize and structure CSS.

Organization of documents

The first step in building a CSS system is the elaboration of an outline. (I think) the importance of CSS organization planning is comparable to the site directory structure. (Htmlor Note: Use words to exaggerate a bit, let you deepen your memory) there is no universal, so we will discuss some basic organizational options, and their respective pros and cons.

Main CSS File

You can usually use a main CSS file to place rules for all page sharing. This file will contain default fonts, links, headers, and other styles. With the main CSS file, we begin to explore advanced organizational strategies.

Method One: Prototype-based

The most basic strategy is to detach the CSS file based on the prototype page (Archetype page). If a site's home page, sub-pages and composite page design are different, you can use a prototype-based strategy. Each page will have a dedicated CSS file (under this strategy).

In the case of a small number of prototypes, this method is straightforward and effective. However, the problem arises when the page elements are not on the individual prototype pages. What should we do if the child pages and composite pages share some elements and the home page does not?

Put the shared elements into the main CSS file. While this is not the purest solution, it applies to specific situations. But if the Web site is large, the main CSS file will swell quickly-which violates the original intention of separating the files: Avoid importing unnecessary large files.

Put a copy of the style code in the CSS file of the combined page and sub-page. (doing this) means maintaining redundant code, and obviously we don't want to do that.

Create a new file that is shared by both pages. That sounds good. But if there were only 10 lines of code, we created the file just to share the 10 lines of code? (Htmlor Note: Overkill?) This approach is pure, but if the site is large enough to share a small number of elements on the page (Htmlor Note: For example, 30 pairs of pages sharing 10 lines of code), it is very cumbersome.

Creates a separate CSS file that contains the styles for all shared elements. This method may be simpler, depending on the size of the site and the number of shared elements. There is a situation that is annoying: import a large CSS file, but the page only uses a small number of styles-or that sentence, which violates the original intention of separating the file.

This is what I call the overlapping dilemma (overlap dilemma). The overlap of fragmented CSS rules does not have a completely clear and unambiguous scheme to organize them.

Method two: Based on page elements/blocks

This approach is good if the site uses server-side include. For example, if you use the header include, it will have its own corresponding CSS file. The footer or other part of the include can do the same, only need to import their own CSS files. This method is simple and clean, but it may produce a lot of small CSS files.

For example, if the footer style only requires 20 lines of CSS code, creating a separate file will not be drawn. And this method causes each page to contain a bunch of CSS files-because there are so many include, you have to have as many CSS files.

Method Three: Tag-based

This scheme is intuitive and practical, similar to the previous one. If the site has 30 pages, 10 of which contain a form, you can create a CSS file that specifically handles the style of the form and imports it only on those 10 pages. If another 10 pages contain table, create a file specifically for the table style ... Such.

Additional Organizational skills

In addition to organizing files in a subjective way, we also consider a variety of media types such as printing, handheld devices, and screens. While this is clearly defined, it is still a factor to consider when building a file structure. Once you have to support multiple media types, some rules in the main CSS file may have to be reconsidered.

In addition, brand union may also be an important factor. (Htmlor Note: If Google and Nike join the Joga), if it involves branding, you have to consider which elements should be adapted to another brand. For example, the use of different CSS files.

There is also a technique that is often overlooked: using nested @import statements. You can create a CSS file with just a series of @import statements, or a few more CSS rules. In this way, you can create a Web site's main CSS file (using @import to import each part of the style file). If you have imported 4 to 5 different CSS files on every page of your site, you should definitely consider using this technique.

Organization of rules and selectors

Finish talking about the file organization, and then discuss how to organize things in the file. Naturally, we want to navigate through the file and quickly find the selector (selector) or rule to edit.

Redundant vs. affiliated

As Dave Shea in his article "Redundancy vs." (redundancy vs. Dependency), you have to constantly learn about cascading (Cascade). You decide whether to group the selectors (which means they are subordinate) or separate them (meaning redundancy). A group can keep the code concise and brief, but it will establish a subordinate relationship, resulting in increased maintenance overhead. If not grouped, the file size is increased, making it difficult to keep similar selectors consistent. Only by doing this trade-offs and tradeoffs can we make the right decisions every time.

