loading...

What's Wrong with CSS?

hoangbkit profile image hoangbkit Originally published at advancedweb.dev ・3 min read

Some noted problems that might hold CSS back and open up new development of preprocessors or CSS-in-JS.

CSS is enjoyable to write until it’s getting really messy in big projects, the problem with CSS isn’t CSS, it’s humans; This problem is compounded as styles grow, each developer needs to know more context in order to style effectively.

CSS was initially designed with simplicity in mind and it worked very well as dominant styling language for the web. The things that many JS developers hate about CSS are the same things that make it so powerful. Let’s look at some noted problems with CSS until today:

Lacking of built-in namespaces — any programming languages lacking built-in namespaces will have problems at scale and CSS is obviously one of them. Global namespace was designed as core feature of CSS to enable portability and cascading. This is the DNA of CSS, CSS-in-JS fixed that very well when build tools can intercept and generate scopes automatically for you.

Too static to change — vanilla CSS is just a set of static layout rules; even though variables and expression have been added recently, CSS is still too simple to keep up with dynamic web pages. It’s hard to implement theming and dynamically changing styles based on incoming data from JavaScript.

Unavoidably repeating yourself — lack of variables so we have to repeat colors all over the place. Lack of nesting so we have to repeat huge blocks of CSS all over the place. In short, CSS violates the living crap out of the DRY principle.

Stuck with the past — three cornerstones HTML, CSS, JavaScript must not break the web; maintaining backward and forward compatible is the number one priority when design new features. Even though we can introduce new features but we can’t get out of bad decisions from the past completely, adoption rate and browser support are too important to revolutionize the language.

Resistant from static analysis — how can we apply some static analysis like dead code elimination and minification to CSS? we can’t! the global nature and cascading styles from inline, internal and external sources make it impossible to perform those kinds of optimization.

Non deterministic resolution to human — according to how css works, styles are merged from multiple sources (inline, internal, external stylesheets) and origins (user agent, user, author, !important, …), going though specificity calculation, inheritance and defaulting. This complicated process is not for human, it is for machine.

The modern web is moving very fast, more dynamic and at a higher level of abstraction. People don’t build websites with vanilla HTML, CSS, JavaScript anymore, it’s possible but too slow and missing out too many cooked production optimizations provided by frameworks and tools.

How can CSS meet the incompatible demands for simplicity (from developers), flexibility (from designers), and responsiveness (from users)? It can’t by itself, it needs help from more abstract high-level tools and techniques like pre-processors, post-processors, css-in-js to make it closer to a programming language.

Above problems will prevent CSS from being used on daily basis by developers but it still mostly works just fine behind the scenes. We’re generating plain vanilla CSS using general-purpose programming languages, this could be done at project build time, or even dynamically on every page load if you have a good caching strategy.

We don’t need to make CSS great again and accept it as a low-level technology, we should focus on building more supporting tools and languages that ultimately compiled to vanilla CSS so it can run perfectly in all browsers.


Originally published on advancedweb.dev — a tutorial site focused on creating high quality web development tutorials, books and courses.

Posted on Mar 3 by:

hoangbkit profile

hoangbkit

@hoangbkit

I turn ☕ into {code} using #javascript

Discussion

markdown guide
 

Some good points there. However I would mention that I think the lacking of built-in namespaces and unnavoidably repeating yourself points can be overcome with good CSS architecture. We can use mixins and SASS variables to not repeat ourselves. We can also artificially create namespaces for ourselves by creating a name that's not used anywhere else.

The rest of the points I agree with completely.

I would like to add my personal points as well.

Here are some of the top level problems I find with it:

  • Developers tend to completely neglect programming principles when writing CSS, creating awful messes which is just a bunch of conflicting globals everywhere.
  • CSS is by far the most inconsistent tool I've ever used. It completely disregards how you would think it works.
  • It's difficult, having multiple display modes and things to be aware of. Unfortunately some of these are necessary due to how much CSS can do.
  • CSS is very slow to catch up. SASS has been out since 2006. We're only now getting CSS variables, nesting, and other things. In fact many of them are not stable in the spec yet.

However the problems can be overcome:

  • You need to know CSS inside and out so its inconsistencies don't hurt you.
  • You need to know good CSS architecture.
  • You need to use SASS, for essential features.

In this case, using CSS can be okay.

Just to expand a bit on CSS architecture. In includes:

  • BEM.
  • Semantic class names.
  • Proper variable refactoring, ideally driven by design systems. These variables will be used in components when appropriate, instead of hardcoded values.
  • Along with BEM modifiers, you can also use CSS variables for more granular modifications. Both of these are essentially arguments for components.
  • "Parent class" technique. This one is uncommon (in fact I had to discover it for myself, I never learnt it anywhere), but I always use it. Every component accepts an optional "parentClass" prop. This class exists on the parent component. The parent component can set layout information here for the child component, such as width and margin. This ensures components never know of their surroundings, so they can be reused anywhere in the codebase without having to play tetris with whitespace in different locations. You can also have defaults by using CSS variables.
 

I agree, CSS as it stands does not allow for a lot of head room when it comes to creating websites. I recently have learned how to use postcss and many plugins that come with it, notability purgecss. When you learn, SASS, postcss it all makes your life developing CSS (and I cannot overstate this) so much easier. Gone the days of 5000 line css files, gone the days of ctrl F an ctrl H to find and replace certain colors. I do not know if CSS itself should get features like postcss or purge, and in no doubt in the future it will come close, but I also think the scarcity of CSS's functionality is ultimately also a great thing. Allowing the user base to create tooling that applies to their specific case and thus keeping the base CSS intact.

(PS: autoprefixer for the win by the way)

 

Yes CSS will be similar to webassembly when becoming a compilation target of higher-level more dynamic tools & languages

 

CSS is too verbose imo, sass solved most of its problem

 

Yes sass is enjoyable to write. I used to like it but moving completely to css-in-js rerecently.

 

You can now use variables in CSS. that reduces a lots of headaches. Try it!