Reasonable structure css for website design

Architecture CSS

Under the premise that current browsers generally support it, CSS has been given an unprecedented mission. However, the more you rely on CSS, the larger and more complex the style sheet file will become. Along with this comes the challenge of file maintenance and organization.

　(Once upon a time) only one css file was enough - all the rules were gathered together, and it was easy to add, delete or modify them - but these days are long gone. When building a new website (now), you have to spend some time planning how to organize and structure the CSS.

　Organization of files

　The first step in building a CSS system is the formulation of an outline. (I think) the importance of CSS organization planning is comparable to the website directory structure. (htmlor note: use exaggerated words to enhance your memory) There is no one-size-fits-all solution, so we will discuss some basic organizational solutions and their respective pros and cons.

　Main css file

　 Usually you can use a main css file to place the rules shared by all pages. This file will contain default fonts, links, headers, and other styles. With the main css file in place, we started exploring high-level organizational strategies.

　Method 1: Based on prototype

　The most basic strategy is to separate css files based on archetype page. If a website's homepage, subpages, and portfolio pages are designed differently, a prototype-based strategy can be used. (Under this strategy) Each page will have its own css file.

　When the number of prototypes is not large, this method is simple, clear and effective. However, problems arise when page elements are not located in each prototype page step by step. If the subpages and the combination page share some elements, but the homepage does not, what should we do?

　 Put the shared elements into the main css file. This isn't the purest solution, but it works for some specific situations. But if the site is huge, the main css file will quickly bloat - which defeats the purpose of separating files: to avoid importing unnecessarily large files.

　Put a copy of the style code in the css files of the combination page and sub-page. (Doing this) means maintaining redundant code, and obviously we don't want that.

　Create a new file to be shared by these two pages. sounds great. But if there are only 10 lines of code, do we create this file just to share these 10 lines of code? (htmlor note: Killing a chicken with a knife?) This method is very pure, but if the website is huge and there are many pages sharing a small number of elements ( htmlor note: For example, if 30 pairs of pages each share 10 lines of code), it will appear very cumbersome.

　Create a separate css file containing styles for all shared elements. This method may be simpler, but it depends on the size of the site and the number of shared elements. There is a very annoying situation: a large css file is imported, but only a small part of the style is used on the page - again, this defeats the original purpose of separating files.

This is what I call the overlap dilemma. There's a lot of overlap in fragmented CSS rules, and there's no completely clear-cut way to organize them.

　Method 2: Based on page elements/blocks

　If the website uses server-side include, this method will be very good. For example, if you use header include, it will have its own corresponding css file. The include in the footer or other parts can be done in the same way, just import your own css file. 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, it is not worthwhile to create a separate file. And this method will cause each page to contain a bunch of css files - because there are as many css files as there are include.

　Method 3: Based on tags

　This solution is intuitive and practical, similar to the previous one. If the website has a total of 30 pages, 10 of which contain forms, then you can create a css file to specifically handle the style of the form, and import it only on these 10 pages. If the other 10 pages contain tables, create a file specifically to handle table styles...and so on.

　Additional Organization Tips

In addition to subjective methods of organizing documents, we also need to consider multiple media types such as print, handheld devices, and screens. Although this is clearly defined, it is still a factor that should be considered when establishing the file structure. Once multiple media types must be supported, some rules in the main CSS file may need to be reconsidered.

In addition, brand co-operation may also be an important factor. (htmlor note: such as joga jointly launched by Google and Nike) If it involves brand co-branding, you have to consider which elements should be adjusted to suit the other brand. For example, use different css files respectively.

Another often-overlooked tip: use nested @import statements. A css file can be created by just containing a series of @import statements, or adding a few css rules. This method can completely create the main css file of the website (use @import to import the style files of each part). If each page of your website imports 4 or 5 different css files, you should undoubtedly consider using this technique.

　Organization of rules and selectors

After talking about file organization, let’s discuss how to organize the things in the file. Naturally, we want to browse unimpeded in the file and quickly find the selector or rule to be edited.

　Redundancy vs. Dependency

　As Dave Shea said in his article "Redundancy vs. Dependency", you must constantly understand the cascade. You have to decide whether to group selectors (meaning dependency) or separate them (meaning redundancy). Grouping can keep code concise and concise, but it will establish dependency relationships, resulting in increased maintenance overhead. Without grouping, you increase file size and make it difficult to keep similar selectors consistent. Only by making these trade-offs and trade-offs can we make the right decision every time.