Rational architecture of website design CSS Architecture
With the general support of browsers, css has been given an unprecedented mission. However, the more css dependencies, the more complex the style sheet file will become. At the same time, the file maintenance and organization tests also follow.
(Once Upon a Time) as long as a css file is enough-all the Rules (rule) gather together to facilitate addition, deletion, and modification-The days have long gone. (Now) when creating a new website, you must spend some time planning how to organize and structure css.
File organization
The first step in building a css system is to draw up the outline. (I think) css organization planning is more important than website directory structure. (Note: The words are exaggerated to help you better remember them.) There is no universal solution, so we will discuss some basic organizational plans and their respective advantages and disadvantages.
Main CSS file
Generally, you can use a primary css file to place rules shared by all pages. This file contains default fonts, links, headers, and other styles. With the main css file, we began to explore advanced organizational strategies.
Method 1: Prototype-based
The most basic policy is to separate css files based on the archetype page. A prototype-based policy can be used if the homepage, subpage, and group page of a website are different in design. (Under this policy) each page will have an exclusive css file.
This method is simple, clear, and effective when the number of prototypes is small. However, when the page elements are not step-by-step on each prototype page, the problem arises. What should we do if the child page and the group page share some elements but the home page does not?
Put the shared element into the main css file. Although this is not the most pure solution, it applies to some specific situations. However, if the website is large (in this case), the main css file will expand rapidly-This violates the original intention of splitting the file: avoid importing unnecessary large files.
Put a style code in the css file of the combination page and sub-page. This means to maintain redundant code. Obviously, we don't want.
Create a new file, which is shared by the two pages. This sounds good. But if there are only 10 lines of code, we create this file to share the 10 lines of code? (Note: How can I use a cool knife to kill chickens ?) This method is pure, but if the website is large and has many elements that share a small number of pages (Note: for example, 30 pairs of pages share 10 lines of code respectively), it will be very cumbersome.
Create a separate css file that contains the styles of all the shared elements. This method may be relatively simple, but it depends on the size of the website and the number of shared elements. There is a situation that will be annoying: A large css file is imported, but the page only uses a small part of the style-or that sentence, which violates the original intention of file separation.
This is what I call overlap dilemma ). Fragmented css rules overlap, and there is no clear solution to organize them.
Method 2: Based on page elements/blocks
If the website uses the server side include, this method will be very good. For example, if you use the header include, it will have its own css file. The include of the footer or other parts can be processed as an example. You only need to import your own css file. This method is simple and clean, but may generate many small css files.
For example, if the footer style requires only 20 lines of css code, you cannot create a single file. In addition, this method will cause each page to contain a bunch of css files-the number of css files is required because of the number of include files.
Method 3: tag-based
This solution is intuitive and practical, similar to the previous one. If the website has 30 pages, 10 of which contain form, you can create a css file to process the form style and only import it on these 10 pages. If the remaining 10 pages contain tables, create a file to specifically process the table style ...... And so on.
