The reasonable structure of web design CSS

css| Architecture | design

In the current browser generally support the premise, CSS has been given to us an unprecedented mission. However, the more CSS you rely on, the bigger and more complex your stylesheet files become. At the same time, the test of document maintenance and organization will follow.

As long as a CSS file is enough-all rules (rule) together, adding and deleting changes 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 the outline. (I think) CSS organization planning is as important as the site directory structure. (Htmlor Note: Use a little exaggeration to deepen your memory) there is no solution universal, so we will discuss some basic organizational scenarios and their respective pros and cons.

Master CSS File

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

Method One: Based on prototype

The most basic strategy is to detach the CSS file based on the prototype page (archetype pages). If a site's home page, subpages and combination page design is different, you can adopt a prototype based strategy. (under this strategy) each page will have an exclusive CSS file.

In the case of a small number of prototypes, this method is straightforward and effective. However, the problem arises when page elements are not step-by-step in each prototype page. What should we do if the subpages and the combined pages share some elements and the home page doesn't?

Put the shared elements into the main CSS file. This is not the purest solution, but it applies to specific situations. But if the site is huge, the main CSS file expands quickly--which violates the original intent of separating the files: Avoid importing unnecessary large files.

Put a style code in a CSS file that combines pages and subpages. This means maintaining redundant code, which we obviously don't want to do.

Create a new file that is shared by both of these pages. That sounds good. But if there are only 10 lines of code, we create this file just to share the 10 lines of code? (Htmlor Note: Overkill?) This approach is pure, but if the site is huge and there are a lot of small elements to share with the page (Htmlor Note: For example, 30 pairs of pages to share 10 lines of code), it seems very cumbersome.

Create 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. A situation can be annoying: Import a large CSS file, but the page uses only a small number of styles-or that sentence, which violates the original intention of the separation of files.

This is what I call an overlapping dilemma (overlap dilemma). Fragmented CSS rules overlap and do not have a completely clear and unambiguous solution to organize them.

Method two: Based on page elements/blocks

This is good if the Web 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, just import your own CSS file. This method is simple and clean, but it may produce many small CSS files.

For example, if the footer style requires only 20 lines of CSS code, creating a single file will not work. And this method will cause each page to contain a bunch of CSS files--because of how many include, how many CSS files.

Method Three: Based on the mark

This program 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 deals with the style of form and only imports it on these 10 pages. If the other 10 pages contain a table, create a file that deals specifically with the table style ... Such.

Other 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. Although this has been clearly defined, it is still a factor to consider when creating a file structure. Once you have to support multiple media types, some of the rules in the master CSS file may have to be reconsidered.

In addition, branding may also be an important factor. (Htmlor Note: such as Google and Nike Joga) if it involves branding, you have to consider which elements should be adjusted to suit another brand. For example, use different CSS files, and so on.

Another technique that is often overlooked is the use of nested @import statements. Contains a series of @import statements, or a few more CSS rules, you can create a CSS file. You can use this method to create a Web site's main CSS file (a @import to import parts of a style file). If each page of the site is imported from 4 to 5 different CSS files, you should consider using this technique.

Organization of rules and selectors

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

Redundancy vs. subsidiary

As Dave Shea in his article "Redundancy vs." (redundancy vs. Dependency), you have to keep abreast of cascading (Cascade). You have to decide whether to group the selectors (meaning to be attached) or to separate them (meaning redundancy). Grouping keeps the code simple and concise, but it creates dependencies, resulting in increased maintenance overhead. If you do not group, the file size is increased, making it difficult to keep a similar selector consistent. Only by doing this trade-off and trade-off can we make the right decision every time.

GROUP BY mutual Relationship/context

Since file organization can be subjective, it is clear that grouping is the best way to follow rules and selectors in relation to other parts. For example, if you use containers, headers, and footers to complete the layout, you should put them in a group.

It seems simple, but it's not. For example, when you add a navigation in the header to the CSS, do you want to group it with the parent element or separate it? In this case, it depends on the context of the rule. Typically, headers are related to page layouts and should be grouped with other layout elements. The navigation is a piece of the header and should be grouped with the other blocks of the header, not the header itself.

Working with annotations

Like most code, annotations are the key to good organization. Should be based on the scope of the control of the CSS, clearly labeled each section. It is a good idea to ensure that annotations are visually prominent so that they are positioned quickly when content scrolls and Islands.

Doug Bowman the CSS annotation in one of his articles CSS organizational techniques: tags (CSS organization Tip #1: Flags). He explained in detail the equal sign before the section name in order to quickly jump to a section using the Text editor's lookup feature.

Don't forget

You should be careful and careful about specificity, cascade and inheritance, and make good use of them. Each of them can be your worst enemy or your most friendly friend. When building a huge web site, whether you understand these subtle subtleties, determine what you are building a rock-solid system, or can not withstand the wind and rain of the Tofu slag project. (Htmlor Note: This sentence completely transliteration, relatively cool)

Organization of attributes

Now that we know the organization of the file and the organization of the rules within the file, there is an important organizational link (not mentioned), which is attributes. Although the attributes are simpler than the first two concepts, there are some very good ways to keep the rules neat and well worth mentioning.

Sort by alphabetical

When it comes to attributes, if you need to follow any principles, it is: press-word-mother-row-order. In fact, this is not helpful for property browsing, but it prevents property values from overwriting this accidental occurrence.

For example, it's not clear how many times I've defined a margin value for a selector, and then one day I accidentally add another (or before or after). In this case, the latter attribute will naturally work. Suppose you don't know that the second attribute exists, no matter how I adjust the first property value, refresh the browser, or see the page change. (Htmlor Note: I have a deep understanding of this problem) if you are in alphabetical order, you will find that the margin is defined two times (because they are together) and this problem can be avoided naturally.

The priority

When the site is complex and involves too many CSS files, a lot of dependencies are created. Once you need to customize an element-specific style, the!important option seems to be the best choice. Yes,!important is a necessary solution, but it's best to figure out the root cause of the problem and then decide whether to use it, based on the Cascade relationship.

If you are familiar with the specificity, cascade, and inheritance mentioned above, you don't have to hold the!important a tree. (Htmlor Note: The whole forest waiting for you ~) Of course it will come in handy, but before use to the specific situation in the chest. Do not take!important as a shortcut or a remedial solution because you don't know the crux of the problem.

Summary

When we become dependent on CSS and make stylesheets more complex, we need the right plan to avoid mistakes and make the code easier to maintain. Since the perfect solution does not exist, then the understanding of how CSS works and files, selectors and attributes of a variety of organizational solutions, will undoubtedly help us write high-quality code, stand the test of time.

Author: Garrett Dimon

Translation: Htmlor