Is CSS condemned to suck forever?

CSS sucks. You’ve read it in countless blog posts. You’ve seen the memes. You’ve heard developers fuming about it. You’ve noticed it in angry commit messages. Maybe even your t-shirt says so.

However, CSS is a living standard as the W3C constantly adds new features to it. Its workflow has also changed in many ways as tools, methodologies and frameworks were created by our amazing community of developers. All of these have improved greatly the life of front-end developers, and there is more to come!

So, is it possible that CSS will stop sucking one day? Let’s see some of the criticisms the language faces and how we can address them.

Building layouts is a pain, and impossible without hacks

As Brad Frost reminds us in the brilliant Atomic Design, initially the web was only meant to be a network for sharing documents. HTML and CSS were languages describing webpages, not applications. As a result, there has been nothing in place dedicated to build complex and interactive layouts.

Different hacks have been used to solve this problem, involving tables then float based layouts. The latter has been the foundation of countless column based CSS frameworks. On a positive side, these frameworks helped creating a shared layout structure between developers and designers. But really float’s purpose is to define how to position an image within a block of text, not to support entire interfaces.

We may see the end of all these hacks, 20 years after the creation of CSS. Grid layouts finally provide an adequate solution. The browser support is not sufficient enough to use it on production yet, but in a few months we could start playing with it and at some point, ditch layout frameworks forever! Also, clearfix, you won’t be missed.

Maintaining CSS constantly leads to breaking stuff

CSS has this particularity of being easy to learn but hard to master. Building interfaces for large projects and making them maintainable, modular and optimised requires experience, organisation and discipline. Meanwhile, working with a poorly written CSS codebase can lead to an explosion of frustration, development times and side effects.

Thankfully, methodologies and naming conventions have emerged to standardise how to write CSS better. At carwow, we have embraced BEM and it is helping us write more semantic and modular code as well as lowering the specificity of the selectors we use. Writing good class names is less simple than it sounds and takes dedication. To sum things up, I would quote one of my front-end heroes, Harry Roberts:

I wish that only people who wanted to write good CSS would actually write it. Too many people openly don’t care about quality CSS, and that’s where we get problems.

CSS doesn’t even have variables

Variables are one of the main reasons CSS preprocessors were created. And they have been a big step forward to consistently style interfaces. The only problem is, these variables only exist in the sass codebase and can’t be accessed in the browser.

This could be a thing of the past as CSS custom properties comes in. As opposed to Sass variables, they have the ability to cascade, which means they can be set or overridden inside a selector. Even better, custom properties are accessible during runtime, which means they can changed in Javascript and that the browser repaints whenever their value is changed, for example in a media query.

At the time of writing this post, CSS custom properties lack a sufficient browser support in order to be used in production. But this is a very exciting feature to look forward to, as some amazing demos already showcase its potential.

All styles are in the global scope

CSS only has one, implicit global scope. It is one of its most powerful but also dangerous features. At scale, the absence of namespaces make design changes at risk of regressions and conflicts due to selector collision.

Many strategies exist to reduce the risks, such as using over qualified selectors or naming conventions like BEM. These help addressing scoping issues but show some limits, like the remaining difficulty to identify dead code.

Another solution is CSS modules, which generate locally scoped class names for components. It brings the advantages of having components which encapsulate styling as well as removing the fear of global scope issues when writing CSS. It is currently supported by loaders for Webpack, Browserify, JSPM as well as a plugin for PostCSS.

Centering vertically is a nightmare

Yes. For years, centering anything vertically wasn’t easy. Not only you had to rely on hacks and crafty techniques that didn’t work in every situation, but you also had to face the looks of designers who couldn’t see why something so simple could be so troublesome.

But this was before Flexbox arrived. It now only takes a few lines of code to centre anything both horizontally and vertically, and flex properties are now widely supported by browsers with even IE10 using its legacy syntax.

Flexbox offers a lot of other advantages and possibilities, which translates to more options for designers when it comes to sizing, aligning and ordering interface elements.

Cross device and browser compatibility is extremely tedious

Anyone who had to support a project’s compatibility with IE6 once in their life has had a foretaste of hell if it exists.

Thankfully its user base has plunged and we can now focus on browsers and that work… ish. Still, in order to cover different browsers, we rely on vendor prefixes as their different rendering engines accept different property names. Maintaining vendor prefixes in a large codebase would be very tedious and repetitive. Using sass mixins is a viable option, but you still need to make sure to consistently use them. At carwow we recently switched to autoprefixer. The postcss plugin automatically adds vendor prefixes for properties that need them during the build process. It has helped us making our sass codebase cleaner and the best thing is, we don’t need to think about it anymore!

When it comes to detecting browser feature support, one option is to rely on Modernizr. The javascript library adds a set of classes to the body tag with the names of all CSS3 properties handled by the user’s browser. This is useful to implement progressive enhancement, but it would be great to handle this without involving javascript. Thankfully, feature queries come to rescue and provide a way to declare a set of statements based on the condition that the user’s support one or more features.

This was a non-exhaustive list of drawbacks of CSS, and you may have more in mind. The same apply to the new features and techniques I have mentioned, there are certainly more to discuss and I will be happy to do so here when opportunities to experiment come.

Do you still think CSS sucks, or are you as excited as I am about how the language is evolving? Do you have other tools and techniques in mind to write good CSS? Or maybe you think front-end developers are just plain masochists? Feel free to engage the conversation with a comment!

Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)