CSS is very flexible since it doesn’t impose on how you should write your CSS rules but putting CSS rules in different spots can make your stylesheet less predictable than what you’d want to go for. Maintainability problems will most likely arise when the CSS selectors cascade – this applies to other CSS pre-processors such as Sass and LESS as well.
In most projects the SASS code follows the DOM structure – this means that the CSS structure is linked to the DOM. This can result in larger file sizes and the component becomes non-reusable. If the markup needs to be changed or moved, the CSS rule needs to be changed as well. Using ID selectors could lead to maintainability problems.
At this point most developers would try to write a stylesheet with very specific rules – since there can be only one single element using the same ID, these are not reusable. Other aspects include ever-longer CSS files – some have over 1000 lines of code.
Think Components
Think about the fact that a web page is composed of multiple components. Let’s take a services page as an example. The page is composed out of three components:
- Services is the entire services section
- Container is simply a generic container that limits size and adds some padding
- Service-item is a single service item
Styling VS layouting
In order to make a component easily reusable and to make the CSS layout more manageable, the concepts of styling and layouting need to be differentiated.
Styling means changing paddings, borders, fonts and colours. All these changes take place inside the component itself and hence do not interfere with the layout or structure of other components. The following elements fall into styling:
- Text align
- Padding
- Font
- Colour
- Border
- Background
Layouting on the other hand implies moving elements around your page and sizing them – this can affect other elements on the page. The following fall into the layouting category:
- Height and width
- Left, bottom, right or top
- Transform
- Position
- Margin
- Float
- Clear
Do not layout yourself
You shouldn’t layout yourself because a component should style itself but give up the task of layouting to its parent. What this means is that the component doesn’t need to float on its own or have its own margins but the parent-component should layout its child components.
This makes it much easier to build responsive user interfaces because the layout itself becomes more predictable. There’s no need to worry if two components look good on a screen if the parent component layouts its child component appropriately.
Components should be simple
If your components have too many lines of code, you should create a different component to handle it all. In the same time, having too many components can turn into a maintenance burden – hence the option to create sub-components.
Nesting subcomponents together is not allowed, so if the subcomponent needs to have its own sub-components then it should become a top level component. These rules are enforced in order to keep components simple and working smooth.
Component inheritance
Sometimes a component is a specialization of another component. Adding modifier classes to the HTML markup could make it redundant and not friendly to refactoring. By using Sass we can use @extend in order to extend other components. Eg: The “services” component is a specialization of an inverted section. In this case we use @extend only for component inheritance, which is a valid use case. It’s possible to use either @extend or @mixin as long as both are used in a controlled manner.
The bad thing about using @extend is that it won’t necessarily work for generated CSS files and you can’t extend from inside a @media query. If it needs to be done, the CSS structure needs to be reworked.
File structure
CSS files with a large amount of lines are very hard to work with. In some cases, depending on the project’s complexity, it may be possible to put all the CSS code in a single file. For larger projects it may necessary to organize assets via controller.
Directory structure
Having stylesheets with a large number of files can be very difficult to handle, so grouping them accordingly is crucial – keep in mind that each project is different and each directory structure needs to be different. Try to find a directory structure that fits your current project. Sometimes you can put all the CSS in a single directory but at other times you need to organized them by type, media type or screen size.
Wireframe – Design – Wireframe
Sometimes it’s a good idea to draw another wireframe from the already finished design. But why?
- With the wireframe in place we’re able to look at the page as a whole, not just little portions.
- Naming and componentization – viewing the whole page in a glance lets you name sections easily
- Hierarchy and structure – it’s easier to structure your pages into sections or subsections with the wireframe in place
- Margins – with the wireframe you can plan your paddings and margins more efficiently
Responsive design
Breakpoints can be defined for desktop, tablet, mobiles or they can be created based on content. Creating breakpoints based on content means that the site will look good on any screen size. Start with the smallest screen size and resize your window accordingly. When a component looks out of place, modify it and create a breakpoint there. Repeat the process until you reach the largest screen size you want to support.
Conclusions
These are the basic ways to write more predictable and maintainable stylesheets – by applying these tips you’ll save yourself a lot of tweak work in the long run. Happy coding!
