Quantcast
Channel: Develop with Purpose » Innovation
Viewing all articles
Browse latest Browse all 49

A Step Beyond the Style Guide

0
0

Lately, there has been a lot of talk about Style Guide and Pattern libraries. These tools allow teams to have a point of reference for the style elements (fonts, buttons, etc.) of the project being built. While these are great, there is an extra step that I am seeing some teams make that seem just as important, if not more important than the style guide itself: a guide on writing CSS.

The CSS guide doesn’t focus on the visual elements of your project. Instead, the guide reads as documentation for how the team should be authoring their CSS files. Why does this matter, you ask? Allow me to highlight just a few of the many benefits below.

Clarity
When working on a project as a team, communication plays a massive role. The best thing we can do for our team is to establish a common language from which to work from. Being intentional early and defining guidelines for how we are going to go about our work is key to a successful project.

While a language like Ruby comes with solid predefined assumptions and conventions, the same is not true for HTML and CSS. The same layout or component can be marked up and styled in a multitude of ways. The coding guide documents specific conventions that the team will use when structuring our markup and authoring CSS.

Performance
If we are not careful in planning and defining guidelines, our project will quickly become a mess. Before we know it, we will end up with a bloated code base that might work, but could have been built with much more thought.

For CSS, this bloat most often manifests itself with poorly written selectors, the heavy use overrides and unnecessary specificity. All of these play a role in the performance of your CSS. A CSS code guide can define how to best write your selectors and provide guidance on how to format and order your rulesets for optimum performance.

Maintainability
If we fail to establish standards and documentation, we are free to write it how we want. This freedom may sound desirable until you realize that the way you mark a section of a given page may be totally different than the developer next to you. Before you know it, your entire team has been implementing CSS the best way they know how, which may not always be the best or most efficient approach.

This lack of planning really comes back to get us when we come back to the project later. If we need to make a change or add a feature, there are a slew of roadblocks we could encounter. Furthermore, if there are a lot of overrides going on in your CSS, you may find yourself stumped as to why a new feature or change isn’t styling as you wrote it. All of this time you find yourself spending debugging and fixing could have been spent getting more important things done.

While taking the time to set this standard up for your team early may not seem valuable, or may feel like a waste of time, it is important keep in mind the long-term effects. Defining a clear direction in how your team should write CSS now will go a long way to preventing headaches later.


Viewing all articles
Browse latest Browse all 49

Latest Images

Trending Articles





Latest Images