Style Points – CSS in 2021
If you’ve written CSS for any length of time, you recognize that being able to “write CSS” in the modern tech ecosystem means much more than simply understanding and regurgitating the syntax. Developers today are increasingly expected to have a rich understanding of the dynamic ecosystem that is poised to take CSS from a somewhat boring and clunky necessity, to a truly transformative source of competitive edge. A lot has changed in the world of CSS lately so without further ado, let’s get up to speed…
More and more codebases are beginning to utilize some sort of pre-processor when writing CSS to make the development experience more intuitive and less repetitive (more DRY). Gone are the days of monolithic, unmaintainable stylesheets draining development resources; supersets of CSS3 such as SCSS (and it’s ancestor “SaSS” or “indented syntax”) have revolutionized the way CSS is written with a host of features not currently available in the CSS main spec. Put simply, they give you access to tomorrow’s CSS, today. Here are a few noteworthy pieces of functionality:
$Variables & Functions()
By allowing developers access to variables when writing stylesheets, it is possible to create central sources of truth that lend themselves naturally to theming and other global config required for a given design system. We can now extract our color palettes, typography preferences, spacing defaults and more for rapid vibe changes on-the-fly! But wait, if we have variables…..do we have….functions? Why yes we do.
_partials and _modules
Ever gone toe-to-toe with a monolithic beast of a stylesheet? No fun. Partials and modules allow developers to refactor ludicrously long stylesheets into logically separated, manageable chunks that can be scoped as needed. Fundamentals of writing good code (separation of concerns, modularity, maintainability, DRYness etc) are not only good hygiene but essential to maintaining our sanity, why wouldn’t the rules apply to CSS? They do now!
The New Kid on the Block – PostCSS
If you’ve kept your ear to the ground, you’ve no doubt heard of PostCSS; I had many misconceptions about what this library actually did in the beginning, but when I finally understood its function and place in the stack, it blew open doors I my head I didn’t even know existed. I initially thought PostCSS was some kind of preprocessor and left it at that. Man was I wrong. PostCSS is not a preprocessor, even though it can act like one if you want it to.
In a sense, PostCSS sets the stage for limitless possibilities regarding manipulation and processing of your stylesheets. It abstracts your syntax into something you can write plugins for called an abstract syntax tree. C’mon, that just sounds cool. Functionally, this allows you to process your stylesheets in any way you see fit with the help of popular build tools and task runners such as Webpack, Grunt, and Gulp. The most famous of these plugins (which you probably use without knowing it) is Autoprefixer, the processor plugin used to append browser prefixes to all your CSS classes, handling the dreaded task of cross-browser compatibility in one pass! PostCSS has a diverse and rapidly growing ecosystem of plugin packs which do everything from simulate color blindness for accessibility testing of your UI to the now popular Lost grid system by Cory Simmons. Suffice to say, if you ever meet Andrey Sitnik, Ben Briggs, or Bogdan Chadkin in person, buy them a beer! This stuff is awesome!
Moving forward, the future of CSS is bright and has no doubt accelerated over the last couple years. If you write any PostCSS plugins let me know! I’ll do my best to contribute where I can!