Organize and optimize styles

In this post I will give an example of organizing styles on a typical project.

A small introduction, I will try to explain the relevance of the problem and why it is needed.
Consider this situation. The developer is given the task to implement the next functionality on the site. This admits includes adding new sections, blocks, elements. Developers often do not trust someone else's code, and when they reach the layout, they find a css-file with a name like main.css and append their new styles to the end.
Some time passes, a new developer comes, they are given a similar task, if he tries to understand the styles, he sees that there is no regularity there, and he repeats the same things that the previous ones did.
The management sets deadlines, all new and new functionality is being developed, the project is growing. As a result, css files turn into trash, the site loads longer, more defects appear, etc.
I think this is familiar to many.


')
Now let's talk directly about the very structuring of styles.
It is unreasonable to keep all styles in one file, with time it becomes quite difficult to navigate. Plus, about 10% of the rules from this file are used on each page, and it weighs a lot.
It is much more optimal to separate styles according to the logical blocks of the site.

It is also necessary to connect a library to work with css (LESS, SASS, SCSS). We need to work with variables, functions.
To reduce requests to the server requires the assembly of files. Files should be glued together using a special design; for example, you can use the standard css- import design. Here you may need the help of a developer to edit the sources of your chosen css library.
Plus, to reduce the volume, the files should come to the client compressed. dotLess , for example, compresses files when <dotless minifyCss=" true " cache="false"/> in web.config.

Each logical block will correspond to a separate css file. This simplifies support, finding the right styles, and indeed, orientation in files. All these files are source, we will contain them in the folder / css / sources /. The rest css-files are assemblers, they are linked to pages and collected by importing source files.
Suppose the project in question is a kind of social network, based on this we can distinguish the following structure:

/ css
/ sources - folder for resources, not laid out on the server
/ global-vars - files of this folder are connected to each css-file collector as needed
locals.css - global variables
functions.css - global functions
/ common
reset.css - I think, no need to explain, it is clear that the styles
utils.css - styles of type .clearfix
/ content
base.css - the main styles for content, namely h1-h6, p, bullets for lists (ul.text, ul.dashed, etc.), dl, dd, dt, images and panels in the text (text wrapping ), text columns, etc.
panels.css - various panels
tables.css - stylesheets for content tables (th, across the strip)
/ controls
buttons.css - button types
forms.css - common styles for input fields (for example, inner shadow, focus (frame), validation messages and their default hide)
tabs.css - tabs, tabs
system-notifications.css - system messages, as a rule, are of 3 types: success (green), failure (red) and info (gray, blue)
pager.css - pager
banners.css - banners on the site
balloons.css - all sorts of balloons, tooltips, custom tooltips, etc.
/ member
thumb.css - user avatar
card.css - user card (avatar, name, brief data)
cards-list.css - for example, grid with cards
profile.css - user profile
/ modules - various modules for the site
search.css
news-list.css
gifts.css
games.css
/ not-auth - for unauthorized users
login.css - login form
registration.css - registration form
/ auth - for authorized users
my-account.css
mail-system.css - inbox messages, outbox, etc.
auth-menu.css - navigation menu in the authorized zone
my-profile.css - view your profile, edit
/ layouts
common.css
header.css
top-menu.css
footer.css
overlay.css - for example, all layers that pop up above will be with dim 0.5
main.css - main collector, linked on all master pages
/ layouts
default.css - the main layout of the site, collects files from the folder / layouts, connects to the wizard with the main layout
popup-windows.css - styles for popups, connected on master pages for popup windows
not-auth.css - collects styles from the / sources / not-auth / folder
auth.css - collects styles from the / sources / auth / folder
/ themes - various themes of the site
new-year.css
st-valentine.css
/% section-name% - any new section of the site, "site in the site", characterized by the presence of its submenu, etc.
/ css
% section-name% .css
layout.css
/ sources
menu.css

Of course, each project has its own unique structure. The principle of file sharing is important.

Additional description for some files:

main.css - collects files from folders:
/ sources / global-vars
/ sources / common
/ sources / content
/ sources / controls
/ sources / member
/ sources / modules

functions.css - contains global functions, such as:

.rounded-corners ( @radius)
{
border-radius : @radius;
-moz-border-radius : @radius;
-webkit-border-radius : @radius;
* behavior : url ( /libs/progressive-IE.htc ) ;
}

sources / layouts / common.css - global styles by layout:

.columns-wrapper
{
display : table ;
* zoom : 1 ;
}
.columns-wrapper .column
{
display : table-cell ;
* float : left ;
}

The inclusion of the not-auth.css and auth.css files depends on the authorization status of the user. For example, in asp.net it will look like this:

< asp:LoginView runat ="server" >
< AnonymousTemplate >
< link href ="/css/not-auth.css" rel ="stylesheet" type ="text/css" />
</ AnonymousTemplate >
< LoggedInTemplate >
< link href ="/css/auth.css" rel ="stylesheet" type ="text/css" />
</ LoggedInTemplate >
</ asp:LoginView >

* This source code was highlighted with Source Code Highlighter .

I want to bring a concept which, I believe, should be held.
New pages should be built from components, "bricks" - css classes. Some misunderstand this concept and build a page from mar-bottom-15 , float-left or pad-20 classes, which is also a big mistake.
The entire style of the elements should be maintained throughout the site, i.e. The h1 header on one page should look the same as h1 on another. Headings, paragraphs, lists, panels, tabs, pagers, content tables, etc. design must comply with a single style.
Before writing styles for a new page of the site, you should analyze the existing css-files of the project, perhaps there are already the necessary styles. Css file should not grow unnecessarily.

In conclusion, I will say that everything described above is also relevant for JS.