4 CSS techniques that will work in any CSS preprocessor, any framework
You often experience a plethora of development environments when you’re working at a Digital Product Studio (agency). Unlike working at a product company—where you’re tooling and refining your technology stack over time—working on client projects often involves being thrown into the deep-end of someone else’s frankenstein-brain-child.
Changes in development environments are usually good. Thinking evolves over time as it should. Depending on which Javascript framework you may be using (ex: React, Vue, Ember), and whether or not you’re using a component-based architecture (where all of the Markup, CSS, and Javascript live in one file) your CSS can look very different from project to project.
I’ve found the following rules to be helpful in almost every scenario. They’re rules that can be applied at the beginning of a project, or into a working production application. Pick and choose, do what you will. This list is by no means exhaustive. It assumes you’re using some type of preprocessor (SASS, LESS, etc.) and hints at using Javascript frameworks (examples above).
1. Declare all CSS variables in one file
Keeping one variable file helps prevent collisions of variables with the same name. It also allows you to manipulate multiple variables that are associated with each other. For example, if you’re maintaining a strict typography grid, you may have the related properties: font-size, line-height, margin, and padding. If you maintain all variables in single file, you could have:
$fontSize: 1rem;
$lineHeight: $fontSize*1.395;This is a very basic example, but maintaining a complex (real) version of this would be near impossible if you were also declaring variables in many files (CSS module style or in component files).
2. When possible, name your variables camelCase’d to their respective CSS property
Naming your variables in a camelCase format with the name of their respective CSS property keeps your variables consistent, easy to find, and simple to manipulate. For example, if you’re using a standard font-size variable across your CSS, consider naming the variable $fontSizeand go from there. This allows you to make single-hypthen modifications and keeps everything clean.
$fontSize: 1rem;
$fontSize-heading: 3rem;VS$font-size-normal: 1rem;
$font-size-heading: 3rem;OR WORSE$small-font_size: 1rem;
This brings me to my next point, and it’s a weird pet peave of mine. Make sure you name color variables starting with $color-* (this is an oddly important one), I know what you’re thinking:
Isn’t this what you just said?
You’re exactly correct. It’s so important that I used it again. Without this rule, the following can quickly happen:
$border-color: #fafafa;
$text-color: #000000;Using this naming scheme, I have to remember the name of the variable first and then append color. These variables are hard to remember, and by the time I get to append color, it doesn’t do me much good.
If I start all of my variables with$color-*, as soon as I type the property color: I already know what I need to do next.
If I don’t have this type of auto-suggesting in my development environment, I will still have $color-* occupying this mental space. It’s easier to remember, and ordered alphabetically in my variable file.
Bonus Points
Name your color variables like you’re describing the color, then make additional references to it for convenience.
$color-demure: #fafafa; // describing the color
$color-border: $color-demure; // referencing the description
$color-underline: $color-demure;$color-dark: #1a1a1a;
$color-text: $color-dark;
$color-heading: lighten($color-dark, 5%);
3. Use Mixins (or your non-SASS equivalent)
Especially with a component architecture, you get stuck in an alternate reality where you’re repeating yourself very often and all of these xkcd comics are entering into your mind. Use mixins to prevent repetition, and promote consistency in your design and codebase.
If you're wondering why not to use placeholders over mixins… Let’s remember to be careful with those, as it can hurt your performance and alter your source order.
In your app, you can create a little home for mixins, and use them for everything from text styles, to complete components. Using mixins is perfect for hard-to-wrangle input styles like: textarea, input, and button.
4. Still use a naming-scheme, like BEM
Using a BEM (or similar) naming scheme promotes consistency in your code and keeps it maintainable. Examples of a naming scheme include:
$block__element--modifier: 1px;OR$block-element--modifier: 1px;
I know, it seems verbose, redundant, and everything else you hate. Why would I do this when Webpack takes care of it 😝? The thing is:
- You’re otherwise tempted to nest selectors, causing confusion in the future if you have more than that specific element, add a class, etc.
- It’s nicer/faster to write code that relates to your selector name.
- If your classes aren’t being anonymized, it performs better.
- You can use state classes to manipulate your elements
It’s very tempting to nest selectors when you’re writing components. Since you’re inside a component, you can “safely” nest, because 1. Your framework is just going to anonymize your selectors and 2. There’s not enough selectors in a component to matter (you won’t have any naming collisions, will you?).
This is a dangerous mentality, as there could be someone who comes along, adds an h2 not realizing you already had one, and the styles go awry. In this situation, you can take care of multiple h2 elements inside your .grid.
Conclusion
Despite recent advancements in Javascript frameworks, build technologies, and CSS preprocessors, a few tried and true techniques still go far in making your code more readable, easier to write, and more performant. Maybe you could even use one of these ideas in your own project?
I would love feedback, thoughts, and anything you think I may have missed. Feel free to leave me a response 😺
