Organization and optimization of 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 tasked with implementing the next functionality on the site. This includes adding new sections, blocks, elements. Developers often do not trust other people's code, and when they get to the layout, they find a css file with a name like main.css and add their new styles to the end.
Some time passes, a new developer comes, he is given a similar task, if he tries to figure out the styles, he sees that there is no pattern there and repeats the same as the previous ones.
The management sets deadlines, more and more 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 many people are familiar with this.
Now let's talk directly about the very structuring of styles.
Keeping all styles in one file is unreasonable; over time, it becomes quite difficult to navigate in it. Plus, each page uses about 10% of the rules from this file, and it weighs quite a bit.
It is much more optimal to separate styles by logical blocks of the site.
Also, a library must be connected to the project to work with css (LESS, SASS, SCSS). We will need to work with variables, functions.
To reduce server requests, file assembly is required. Files must be glued together according to a special design, for example, you can use the standard css - import construct . Here, you may need help from the developer to edit the sources of the css library of your choice.
Plus, to reduce the volume, the files must come to the client compressed. dotLess , for example, compresses files at a value
Each logical block will have a separate css file. This simplifies the support, the search for the desired styles, and indeed the orientation in the files. All these files are source, we will contain them in the folder / css / sources /. The remaining css files are collectors, they link to the pages and collect the sources by import.
Suppose the project in question is a certain social network, based on this, the following structure can be distinguished:
/ css
/ sources - the folder for resources is not laid out on the server
/ global-vars - the files of this folder are connected to each css file collector as necessary
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 are styles like .clearfix
/ content
base.css- the main styles for the content, namely h1-h6, p, bullets for lists (ul.text, ul.dashed, etc.), dl, dd, dt, images and panels in the text (text wrap), text columns etc.
panels.css - various panels
tables.css - styles for tables in content (th, through strip)
/ controls
buttons.css - types of buttons
forms.css - general styles for input fields (for example, inner shadow, focus (frame), registration of validation messages and their hiding by default)
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 - any balloons, tooltips, custom tooltips, etc.
/ member
thumb.css - user avatar
card.css - user card (avatar, name, short data)
cards-list.css - for example, a grid with cards
profile.css - user profile
/ modules - various modules to 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 on top will be dimmed with 0.5
main.css - the main collector, linked to all master pages
/ layouts
default.css - the main layout of the site, collects files from the / layouts folder, connects to the master with the main layout
popup-windows.css- styles for popups, connects on master pages for popup windows
not-auth.css - collects styles from the / sources / not-auth /
auth.css folder - collects styles from the / sources / auth /
/ themes folder - various topics site
new-year.css
st-valentine.css
/% section-name% - any new section of the site, “site in site”, characterized by the presence of its own 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 :
sources / layouts / common.css - global styles by layout:
The connection of the not-auth.css and auth.css files depends on the user's authorization status. For example, in asp.net it would look like this:
I want to give a concept that I think should be held on.
New pages should be built from components, "bricks" - css classes. Some people misunderstand this concept and build a page from classes like mar-bottom-15 , float-left or pad-20 , which is also a big mistake.
A uniform style of elements should be maintained throughout the site, i.e. The heading h1 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, you should analyze existing css-files of the project, perhaps there are already the necessary styles. The css file should not grow unnecessarily.
In conclusion, I will say that everything described above is also relevant for JS.
A small introduction, I will try to explain the relevance of the problem and why it is needed.
Consider this situation. The developer is tasked with implementing the next functionality on the site. This includes adding new sections, blocks, elements. Developers often do not trust other people's code, and when they get to the layout, they find a css file with a name like main.css and add their new styles to the end.
Some time passes, a new developer comes, he is given a similar task, if he tries to figure out the styles, he sees that there is no pattern there and repeats the same as the previous ones.
The management sets deadlines, more and more 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 many people are familiar with this.
Now let's talk directly about the very structuring of styles.
Keeping all styles in one file is unreasonable; over time, it becomes quite difficult to navigate in it. Plus, each page uses about 10% of the rules from this file, and it weighs quite a bit.
It is much more optimal to separate styles by logical blocks of the site.
Also, a library must be connected to the project to work with css (LESS, SASS, SCSS). We will need to work with variables, functions.
To reduce server requests, file assembly is required. Files must be glued together according to a special design, for example, you can use the standard css - import construct . Here, you may need help from the developer to edit the sources of the css library of your choice.
Plus, to reduce the volume, the files must come to the client compressed. dotLess , for example, compresses files at a value
in web.config. Each logical block will have a separate css file. This simplifies the support, the search for the desired styles, and indeed the orientation in the files. All these files are source, we will contain them in the folder / css / sources /. The remaining css files are collectors, they link to the pages and collect the sources by import.
Suppose the project in question is a certain social network, based on this, the following structure can be distinguished:
/ css
/ sources - the folder for resources is not laid out on the server
/ global-vars - the files of this folder are connected to each css file collector as necessary
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 are styles like .clearfix
/ content
base.css- the main styles for the content, namely h1-h6, p, bullets for lists (ul.text, ul.dashed, etc.), dl, dd, dt, images and panels in the text (text wrap), text columns etc.
panels.css - various panels
tables.css - styles for tables in content (th, through strip)
/ controls
buttons.css - types of buttons
forms.css - general styles for input fields (for example, inner shadow, focus (frame), registration of validation messages and their hiding by default)
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 - any balloons, tooltips, custom tooltips, etc.
/ member
thumb.css - user avatar
card.css - user card (avatar, name, short data)
cards-list.css - for example, a grid with cards
profile.css - user profile
/ modules - various modules to 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 on top will be dimmed with 0.5
main.css - the main collector, linked to all master pages
/ layouts
default.css - the main layout of the site, collects files from the / layouts folder, connects to the master with the main layout
popup-windows.css- styles for popups, connects on master pages for popup windows
not-auth.css - collects styles from the / sources / not-auth /
auth.css folder - collects styles from the / sources / auth /
/ themes folder - various topics site
new-year.css
st-valentine.css
/% section-name% - any new section of the site, “site in site”, characterized by the presence of its own 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 connection of the not-auth.css and auth.css files depends on the user's authorization status. For example, in asp.net it would look like this:
* This source code was highlighted with Source Code Highlighter.
I want to give a concept that I think should be held on.
New pages should be built from components, "bricks" - css classes. Some people misunderstand this concept and build a page from classes like mar-bottom-15 , float-left or pad-20 , which is also a big mistake.
A uniform style of elements should be maintained throughout the site, i.e. The heading h1 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, you should analyze existing css-files of the project, perhaps there are already the necessary styles. The css file should not grow unnecessarily.
In conclusion, I will say that everything described above is also relevant for JS.