Get the basics of CSS code for large website projects, from the different techniques used to organize CSS to tips for making website stylesheets that are easy to maintain and extend.
Subscribe to our blog
Unlike small and simple websites, we expect fully-fledged enterprise websites to be dynamic platforms with continuous improvements over time. They’re constantly evolving both on a functional and content level, to provide an ever more interactive and enjoyable experience for visitors. New temporary campaign sections, subsites for different countries or markets, and so on, are just a few examples. However, when the HTML and CSS aren’t built to accommodate this, the project will turn out to be an unmaintainable mastodon. Or worse: a website where changing one end will cause unwanted side effects in a dozen other places.
If you’re part of multidisciplinary teams or long-running, evolving projects, it takes a unified way of working to keep website stylesheets maintainable and easy to debug. This article introduces 3 recommendations for front-end developers to build a scalable CSS code-base. These 3 principles are the foundation for creating a code-base that can scale along with your platform, instead of hindering it.
1. The setup
1.1. The sass-files
The best advice for the general setup is to follow the Inverted Triangle CSS (ITCSS). This CSS architecture organizes your code-base by specificity to facilitate scalability and maintainability. You can include all the partial files into one master file, which then also doubles as a readme-file. The trickiest part of ITCSS is to draw the line between components and objects. As a rule of thumb, I use the following guideline for this: most elements are a component except the ones of the highest level that make up the page structure like a grid-system.
ITCSS organizes CSS based on three metrics: reach, specificity, and explicitness, visualized as an inverted triangle
1.2. Using a CSS framework
You can consider using a front-end framework like Bootstrap when the design, wireframes and specifications of your website align with the elements of the framework. If this is not the case, it’s best not to use one. Pick a framework based on the features you really need and on the browser compatibility you want to provide. Another factor to take into account is the learning curve for developers in your company: if your colleagues are already familiar with a certain framework, don’t change to something new just for the sake of trying out something different.
1.3. Skinning and languages
Enterprise websites often cater for a lot of different languages. When they all use the same Latin-font, your only worry is to provide enough space for labels. However, for languages with an alternative set of characters, such as Russian or Chinese, it’s often a good idea to provide each website with its own CSS file. Using SASS, this can be done neatly by creating one master file that loads all partial files, which remain the same. This master file is then included into a skin-specific file that also includes skin-specific partials.
Another approach especially suited for large websites is creating add-on CSS files. The general idea is to provide one base-CSS file, containing the majority of the styles for the website, such as the general typography, grid-system, navigation, etc. Large additions to this website such as areas with restricted access or an extensive registration flow will typically require a lot of additional CSS, so they should receive a separate stylesheet that builds on top of the one.
1.4. Naming convention
A final thought on the setup is using the naming convention for CSS-classes “Block, Element, Modifier”, which helps to structure CSS. It’s also wise to avoid general CSS class names like “table” because it’s only a matter of time before you’re integrating third-party code that uses the same names.
2. Analyse while creating
In order to write maintainable and flexible code, Atomic Design is an absolute must-have: figure out which elements are molecules and put those together to create a component. Components can be placed into other components, or eventually, into objects. The goal is to create design-patterns that are stable and reusable on different places, e.g. form elements that end up in the website search as well as a registration flow.
Don’t forget to take into account that there can be several states for components: active, empty, error, too many items, and so on. This influences how you put things together. So, it’s often useful to sketch a complicated component with pen and paper. This way the structure and states are clear from the start and you force yourself to think “atomic”.
3. Documentation and component library
It’s important that development team members can always rely on a good documentation and on an up-to-date component library. The ultimate sign of a well-designed system is when back-end developers can create new (simple) components without the need of even a single line of CSS because the HTML is totally reusable.
About the author
Wouter Lemoine is a Business Consultant at Amplexor, based in Belgium. As a creative generalist, he likes working on long-term goals and providing structure along the way. He picks up the roles of Functional Analyst, Product Owner and Scrum Master.