January 27, 2015 at 17:14Conducting a CSS Audit: Style Sheets Shouldn't Be Terrible
- Transfer
When we begin work on an existing code base, we first need to conduct a CSS audit. The main harm from poorly organized and launched CSS tables is to slow down the development process, as the development team has to wade through the jungle of code, and in a non-working site, if incorrectly defined selectors cause collisions and style overlays.
Such an audit helps to assess how well the CSS tables of the project are organized, how the pipeline responsible for their evaluation and assembly corresponds to modern requirements, and how well the CSS writing team is structured and disciplined. Here are some of the steps you can use to conduct your own CSS audit:
CSS systems
What to look for
Does your project have a CSSReadme file or other similar document that describes the principles of writing CSS for this project? The most successful projects start with more rigid systems, such as SMACSS, BEM, or OOCSS, and modify them to suit subsequent proposals and structure. If this is not in the Github wiki repository, in the main README file of the project or in the instructions for the new developer in the team, consider that it does not exist.
In the end, the CSS system should contain instructions on the following:
• How to name the newly created files and when to create them
• How to choose names for the class and id
properties • What CSS3 properties are supported on the site
• What syntax options are preferred within the project (is it possible to use single-line scripts?)
How it helps
CSS site increases due to the whims of individual developers. Some of them, before writing a rule, spend time looking to see if there is a selector, while others do not. The system extracts assumptions and opinions from CSS records, the developers can only give it a good appearance, and not invent their own rules.
First Steps in Cleaning
Up Consider the systems described above and present their advantages and disadvantages. Discuss with the rest of the project team what they consider most important in their style sheets, and choose the one that best suits your goals.
The safest way to integrate a new system into an existing website is to take some time, one page at a time. New developments can be performed using the system, and then backport the reapplied styles to previously created pages. In addition, if the conveyor undergoes a redesign, this is a great opportunity to start over with a complete recycling of the material. Sometimes this is the only way in which you can be sure.
Style Guide Things to Look
For
The responsible CSS team must have a “kitchen sink” for the components and styles that make up the website for which they are responsible. When a new developer is given a task to design a page, it is not always convenient to wade through CSS pages or even know where to find one or another element in a product. A style guide is a developer-only page that shows which styles and components have already been created for the site, so that legend can be attached to it, which saves time and reduces the number of duplicate styles.
How does it help
The presence of an active page, which can always be checked, makes it easier to find the very blue text from the pop-up window from the computer that you just put on your desktop. Not every developer knows the entire website thoroughly, so this “help window” encourages the developer to use existing styles, rather than reinvent the wheel to the detriment of his time.
First steps in putting things in order
Next time, as soon as someone creates a new property or element, you need to mark it and use it somewhere on a new page on which existing stylesheets are already included. This will become the germ of your style guide, and you should first of all try to create new elements and components on this page in order to test their functionality in an isolated space, and then transfer them to the page for which they were originally intended.
Pipeline
What to look for
Somewhere among the documentation for your site there should be a description of the pipeline for processing digital objects, in particular, we are interested in CSS processing. This can be a Gruntfile that points to the tasks that need to be completed, or you can use a shell like Rails, which has many processing functions.
How it helps to
Write raw CSS - this is not solid. Pre-processing programs like Sass and Less remove most of the sharp edges from the CSS process and develop good habits related to functions and variables.
Before submitting your functions to work, it is important to validate the CSS in some way. Recent studies by Quick Left have shown hundreds of created properties, such as colro and z-margin, passed into the work without any effect. It is practically harmless, but it is certainly annoying to have such a thing on your website, it shows your inattention to trifles.
In addition to preprocessing programs, to speed up your site, it’s important to concentrate and minimize your CSS into a digital object that can be transmitted via CDN and reliably cached by the browser using the appropriate cache control headers.
First steps in putting things in order
If your program shell initially does not have a concept for a pipeline for processing digital objects that can process your CSS and JavaScript, you can try a stand-alone tool. We like two of these tools - Grunt and Gulp. They are embedded in large deployment systems to either create designs during deployment, or to ensure that they are created, and to accept an artifact (compiled CSS) before deployment, which are two equal options with their advantages and disadvantages.
Keeping CSS in order and full functionality is not easy, it requires constant monitoring, and developers are often given more “heavy” tasks, such as internal properties, or working in an external MVC shell. However, there are tools that can add to the process of writing their design and verification, and which can help each site get what it lacks: easy-to-maintain CSSs that do not need to be completely changed every few months. The simplest thing from the above is to start with a simple style guide, so if your site still does not have it, go ahead and start improving your workflow today !!!
Such an audit helps to assess how well the CSS tables of the project are organized, how the pipeline responsible for their evaluation and assembly corresponds to modern requirements, and how well the CSS writing team is structured and disciplined. Here are some of the steps you can use to conduct your own CSS audit:
CSS systems
What to look for
Does your project have a CSSReadme file or other similar document that describes the principles of writing CSS for this project? The most successful projects start with more rigid systems, such as SMACSS, BEM, or OOCSS, and modify them to suit subsequent proposals and structure. If this is not in the Github wiki repository, in the main README file of the project or in the instructions for the new developer in the team, consider that it does not exist.
In the end, the CSS system should contain instructions on the following:
• How to name the newly created files and when to create them
• How to choose names for the class and id
properties • What CSS3 properties are supported on the site
• What syntax options are preferred within the project (is it possible to use single-line scripts?)
How it helps
CSS site increases due to the whims of individual developers. Some of them, before writing a rule, spend time looking to see if there is a selector, while others do not. The system extracts assumptions and opinions from CSS records, the developers can only give it a good appearance, and not invent their own rules.
First Steps in Cleaning
Up Consider the systems described above and present their advantages and disadvantages. Discuss with the rest of the project team what they consider most important in their style sheets, and choose the one that best suits your goals.
The safest way to integrate a new system into an existing website is to take some time, one page at a time. New developments can be performed using the system, and then backport the reapplied styles to previously created pages. In addition, if the conveyor undergoes a redesign, this is a great opportunity to start over with a complete recycling of the material. Sometimes this is the only way in which you can be sure.
Style Guide Things to Look
For
The responsible CSS team must have a “kitchen sink” for the components and styles that make up the website for which they are responsible. When a new developer is given a task to design a page, it is not always convenient to wade through CSS pages or even know where to find one or another element in a product. A style guide is a developer-only page that shows which styles and components have already been created for the site, so that legend can be attached to it, which saves time and reduces the number of duplicate styles.
How does it help
The presence of an active page, which can always be checked, makes it easier to find the very blue text from the pop-up window from the computer that you just put on your desktop. Not every developer knows the entire website thoroughly, so this “help window” encourages the developer to use existing styles, rather than reinvent the wheel to the detriment of his time.
First steps in putting things in order
Next time, as soon as someone creates a new property or element, you need to mark it and use it somewhere on a new page on which existing stylesheets are already included. This will become the germ of your style guide, and you should first of all try to create new elements and components on this page in order to test their functionality in an isolated space, and then transfer them to the page for which they were originally intended.
Pipeline
What to look for
Somewhere among the documentation for your site there should be a description of the pipeline for processing digital objects, in particular, we are interested in CSS processing. This can be a Gruntfile that points to the tasks that need to be completed, or you can use a shell like Rails, which has many processing functions.
How it helps to
Write raw CSS - this is not solid. Pre-processing programs like Sass and Less remove most of the sharp edges from the CSS process and develop good habits related to functions and variables.
Before submitting your functions to work, it is important to validate the CSS in some way. Recent studies by Quick Left have shown hundreds of created properties, such as colro and z-margin, passed into the work without any effect. It is practically harmless, but it is certainly annoying to have such a thing on your website, it shows your inattention to trifles.
In addition to preprocessing programs, to speed up your site, it’s important to concentrate and minimize your CSS into a digital object that can be transmitted via CDN and reliably cached by the browser using the appropriate cache control headers.
First steps in putting things in order
If your program shell initially does not have a concept for a pipeline for processing digital objects that can process your CSS and JavaScript, you can try a stand-alone tool. We like two of these tools - Grunt and Gulp. They are embedded in large deployment systems to either create designs during deployment, or to ensure that they are created, and to accept an artifact (compiled CSS) before deployment, which are two equal options with their advantages and disadvantages.
Keeping CSS in order and full functionality is not easy, it requires constant monitoring, and developers are often given more “heavy” tasks, such as internal properties, or working in an external MVC shell. However, there are tools that can add to the process of writing their design and verification, and which can help each site get what it lacks: easy-to-maintain CSSs that do not need to be completely changed every few months. The simplest thing from the above is to start with a simple style guide, so if your site still does not have it, go ahead and start improving your workflow today !!!
