"title"=>"Thinking About CSS, Part 2 — Preprocessors",
"summary"=>nil,
"content"=>"
To follow my last post, about some of the different ways CSS styles can be defined in the context of a React web app, I wanted to look at some of the ways the basic feature set of CSS can be expanded upon using CSS preprocessors. For those who might not be familiar with the concept, a CSS preprocessor allows you to define selectors and styles using features that aren’t part of CSS syntax, that are compiled by the preprocessor into something your browser can understand, much like Babel allows you to write JavaScript using features that aren’t yet supported by browsers.
Many of the features provided by CSS preprocessors are shared by most of them, with minor differences in syntax, and I’ll discuss some of the more useful features below, but first, a brief overview of some of the most commonly used preprocessors.
Sass
Sass (Syntactically Awesome Style Sheets), created in 2006 and perhaps the most popular preprocessor, is written in Ruby and can be compiled server-side to valid CSS but, with the capabilities provided to us by tools such as Webpack, is more commonly compiled by your toolchain with the resulting CSS integrated into your build.
Less
Less (Leaner Style Sheets), described by its creators as “CSS, with just a little more”, is written in JavaScript and can be compiled at run time by the browser or the server to CSS or, as with Sass, compiled at build time by your toolchain. Less is backwards-compatible with CSS and shares the same syntax, so any valid CSS stylesheet is also a valid Less stylesheet.
Stylus
Stylus is a bit more than a simple preprocessor — it’s a language, written in JavaScript and running on Nodejs, that generates CSS. Offering built-in functions, support for conditionals and logical operators, and a whole host of other features, Stylus supports standard CSS syntax but also supports a much more terse syntax, allowing you to optionally leave out colons, semicolons, and braces in your stylesheets.
There are quite a few other options available for CSS preprocessing, but these three are by far the most widely used and well documented. So, now that we know a little about the most popular CSS preprocessors, what exactly do we get from them?
Variables
// defining variables
$blue: #00f // Sass syntax
@blue: #00f // Less syntax
blue = #00f // Stylus syntax
--blue: #00f // CSS custom properties syntax
// using a variable in Sass
h1 {
color: $blue
}
Variables in CSS are no longer exclusive to preprocessors, having recently been added to native CSS where they’re known as custom properties, allowing for some very powerful functionality, and perhaps eliminating one of the best arguments for using a preprocessor. As you might’ve guessed, variables allow you to assign a value to a property with a name of your choice, and refer to that property by its variable name elsewhere
Mixins
// A mixin in Stylus, used to simplify setting vendor prefixes
border-radius() {
-webkit-border-radius: arguments
-moz-border-radius: arguments
border-radius: arguments
}
form input {
padding: 5px;
border: 1px solid;
border-radius: 5px;
}
Mixins allow you to define a set of CSS properties which can then be “mixed-in” with the properties defined under another selector, potentially saving a lot of time and effort if you need to apply the same properties in a number of different locations.
Nested Selectors
// A nested selector in Less
.component {
width: 300px;
@media (min-width: 768px) {
width: 600px;
@media (min-resolution: 192dpi) {
background-image: url(/img/retina2x.png);
}
} @media (min-width: 1280px) {
width: 800px;
}
}
Nested selectors, as the name indicates, allow you to nest selectors within one another, allowing you to write much more concise CSS. The above selector, written without nesting, would require 5 separate selectors, and nearly twice as many lines. They also allow for more logical organization, letting you group all of the properties for the element you’re styling together, instead of potentially spreading them out over many areas of your stylesheet, as is commonly done when working on a responsive design.
So should you be using a CSS preprocessor? These are just a few of the many benefits afforded by adding one to your workflow, and whether it’s worthwhile to you probably depends on the scope of your project and the other technologies you’re working with. Most of the alternative methods for implementing styles in React apps that I explored in my last post might not integrate easily with these tools, or might render the benefits offered by them unnecessary, or less useful than they would otherwise be.
","author"=>"Kevin Randles",
"link"=>"https://medium.com/@krandles/thinking-about-css-part-2-preprocessors-1696472c9229?source=rss-d451d084d34a------2",
"published_date"=>Mon, 25 Jun 2018 04:15:07.000000000 UTC +00:00,
"image_url"=>nil,
"feed_url"=>"https://medium.com/@krandles/thinking-about-css-part-2-preprocessors-1696472c9229?source=rss-d451d084d34a------2",
"language"=>nil,
"active"=>true,
"ricc_source"=>"feedjira::v1",
"created_at"=>Wed, 03 Apr 2024 14:31:17.880370000 UTC +00:00,
"updated_at"=>Mon, 13 May 2024 18:46:36.026567000 UTC +00:00,
"newspaper"=>"Kevin Randles on Medium",
"macro_region"=>"Technology"}