CSS has quietly been improving by leaps and bounds lately. So much so, that you may not even recognize it much anymore. While you weren’t looking, the CSS community has developed real solutions to many of the oddities, hacks, and deficiencies that made CSS the black sheep of the front end family in the past.
In this post I’ll reveal 5 old-fashioned CSS things that you don’t need to do anymore, and what you should do instead.
- You don’t need a naming convention.
- You don’t need float.
- You don’t need a grid framework.
- You don’t need a preprocessor.
- You don’t need CSS.
You don’t need naming conventions.
And we begin with the number one problem with CSS, especially at scale: everything is global.
Because all selectors exist in the same global namespace, over time it becomes very likely that you’ll run into unexpected side effects such as selectors targeting elements that you didn’t intend, or selectors being overridden by other selectors. So, we have side-stepped these issues with methodologies (OOCSS, SMACSS, or the more popular BEM) that define naming conventions to help us avoid class name collisions.
While we can’t discount the importance of these methodologies, they are merely a workaround. They don’t actually solve the problems. We needed something more. And then this happened.
Mark Dalgleish and others have since pioneered the concept of locally scoped CSS, which led to the development of CSS Modules, and which has now been incorporated into modern tooling, most notably webpack’s css-loader.
This is huge. When using CSS Modules, name your classes however you like. At build time, all local selectors are replaced by unique identifiers, completely removing the need for a global naming convention. Check out the docs above for CSS Modules for a deeper dive.
You don’t need float.
Float has managed to become both the positioning property of choice and the bane of many a developer’s existence by weaseling its way into everything from helper classes to entire grid systems. While occasionally using float to push an element left or right doesn’t get you into too much trouble, pervasive use of it for full page layouts leads to odd behavior that is a pain to figure out and fix, often requiring hacks. Pretty soon you find yourself copying the admittedly elegant, yet unintuitive “clearfix” onto every element and hoping for the best.
Thankfully, CSS3 introduced a new layout module called flexible boxes, or Flexbox for short. Flexbox is a mostly 1-dimensional layout system that ensures elements behave predictably on various screen sizes and devices. It also solves the common, yet previously frustrating task of vertical and horizontal centering. When you switch to Flexbox, you no longer have any use for float.
While Flexbox is fully supported by all modern browsers, you will run into issues on older ones. So, if you have to support IE < 10 you will likely still need to fall back to floats, tables, or some other layout method.
Some browsers also need vendor prefixes, so I recommend using Autoprefixer to get the most coverage.
You don’t need a grid framework.
Everyone uses a grid. It’s a crucial part of every CSS codebase, letting you build complex full-page layouts by aligning elements along rows and columns. While rolling your own simple grid using traditional techniques is fairly straightforward, no one does it. Instead, we reach for one of the many grid frameworks, such as the original 960gs or the Sass-based Bourbon Neat.
Finally, as of March 2017, most browsers added support for the CSS Grid Layout, a 2-dimensional layout system built directly into CSS. Since most traditional grid frameworks still rely on float, CSS Grid is an attractive alternative. CSS Grid makes it easy to define your own grid without the help of a framework by providing an intuitive interface for defining the number and sizes of rows and columns, the gutter spacing, alignment of elements within the grid, named areas, and more.
You don’t need a preprocessor.
Undeniably, CSS language extensions such as Sass and Less brought game-changing features to CSS, including data reuse with variables, better organization with nesting, and property reuse with mixins. But, these languages didn’t change anything about the core language of CSS; they added a layer of abstraction on top of it. In the case of Sass, you also need an additional binary to compile the Sass files into CSS. When using one of these preprocessors, you now have to learn CSS and the preprocessor specific syntax.
But, while most developers were blissfully coupling to their preprocessors, CSS was quietly progressing. Modern browsers now have native support for CSS variables and calc(). Other features such as color modifications, and mixins are not far behind.
Writing plain CSS and transforming it with PostCSS plugins produces more future-proof CSS with less cognitive and technical overhead than old preprocessors.
You don’t need CSS.
From a CSS perspective, this rethinking has even been given a catchy name: CSS-in-JS.
At first, CSS-in-JS libraries used the HTML “style” attribute to attach styles onto elements, a flawed approach because the “style” attribute can’t do everything CSS can do. Now, most libraries generate real style sheets with the full power of CSS, eschewing use of the “style” attribute for the most part.
JSS is a very popular choice, with an active community and a stable interface; but I’m especially excited about the direction of styled-components, which cleverly attaches CSS to components via tagged template literals.
CSS is dead. Long Live CSS.
- You don’t need naming conventions because locally-scoped styles by default are now baked-in to libraries.
- You don’t need float because Flexbox is more powerful and less hacky.
- You don’t need a grid framework because there’s one built into CSS.
- You don’t need a preprocessor because CSS has more advanced features now.