Problems with pre-processors, alternatives to Sass and CSS4

Tags: , &

problems-with-pre-processors-alternatives-to-sass-and-css4-by-zing-design

Problems with CSS pre-processors

CSS presentation has long been seen as a tedious and repetitive task in a web designer’s workflow, and pre-processors have been instrumental in speeding up the process and making stylesheets fun again. While tools like Compass do encourage best practices, pre-processors should be used with a little caution.

  • Watch out for code duplication, as smart as pre-processors are, style double-ups can be generated when mixins and extensions are combined.
  • Avoid massive selector lists. It’s easy to get carried away with embedded rules, and big CSS rules can lead to bloated stylesheets, which can tax browser processing power.
  • Remember the Inception Rule: don’t go more than 4 layers deep. Specificity is great, it means less IDs & classes in the markup, but get too specific and you can compromise reusability.

inception-fourth-dream-level-580x243

  • Another minor problem is that you’ll lose the benefits of the browser’s built-in element inspector. This feature (particularly on Chrome’s inspector) has proved tremendously useful in the past when trying to investigate baffling CSS issues on specific HTML elements. Using a pre-processor will mean having to trace your steps back through the generated CSS. Ugh… Exhausting!

Other pre-processors available

Stylus

A relatively new contender, Stylus offers a lot of the same features as Sass and Less. The differences being that it handles error-reporting really nicely and the Ruby/Python style indent-based syntax looks awesome.

One slight drawback would be that as Stylus is such a new tool, we can’t expect as much support or community contribution at this point. If you’re tired of Less and Sass, Stylus might be worth a go. Personally I think I’ll stick with Sass, but I’ll definitely be keeping an eye on Stylus.

CSS-crush

This is a pre-processor built with PHP, once again it has many of the similar features of the others. CSS-crush is more like CSS on crack allowing you write plain CSS, which is pre-processed and cached with PHP.

As it is just a PHP library, it’s crazy-fast to get started in a PHP project, and it can be extended with PHP plugins to do insane stuff like dynamically generating SVG textures. CSS-crush also automatically adds the cross-browser prefixes, which I think is quite a nifty feature. Have a play with this one as well, it’s kind of restricted to PHP, so I think I’ll stick with Compass until my next PHP project.

CSS 4

The current draft of the specification shows some promising features, such as:

Example: Consider the following Sass…

[role="main"] {
  aside,
  #specific-article,
  .article-series
  {
    h2 {
      font-size: 2.4em;
      margin-bottom: 1em;
    }
  }
}

Could potentially be replaced with CSS4

[role="main"] :matches(aside, #specific-article, .article-series) h2 {
  font-size: 2.4em;
  margin-bottom: 1em;
}

Example: Imagine a big, messy table where every third column needed to be a different colour for some bizarre reason… We could do some hacky Sass like so:

#my-big-messy-table {
  td, th {
    &:nth-child(3n+1) {
      background-color: cornflowerblue;
    }
  }
}

Or with CSS4:

#my-big-messy-table :nth-column(3n+1) {
  background-color: cornflowerblue;
}

Example: I’ve dreamt up an obscure, elaborate scenario where the parent selector might be useful. Let’s say you have a shopping cart element with a list of items inside. You want to show a message and change the background colour if the cart is empty…

With Sass you could do it like so:

.shopping-cart {
  ul {
    li.empty-message {
      display: none;
    }
    &.empty {
      background-color: yellow;
      li.empty-message {
        display: block;
      }
    }
  }
}

In this case, you’d need to toggle an ’empty’ class on the shopping cart list with JavaScript when the cart element got down to one child.
In the future we might be able to do it with CSS4 alone, using the parent selector:

//By using the ! the unordered list becomes the subject...
.shopping-cart !ul > li:only-child {
  background-color: yellow;
}
.shopping-cart ul li.empty-message {
  display: none;
}
.shopping-cart ul li.empty-message:only-child {
  display: block;
}
  • Greater accessibility support like :past, :present, :future for screen-readers and directionality with the :dir pseudo-selector.

OK, it’s still just a draft and a lot of these cool features probably won’t see the light of day for a wee while yet, but it’s still pretty cool. The new proposed selectors could make for much tidier, less repetitive CSS, which could pull devs back to writing vanilla CSS.

Imagine if they could also include Sass-like features such as variables, mixins and calculations! Pre-processors could be made obsolete… or maybe they’ll become even more powerful, we’ll just have to wait and see…

People who have viewed this post also viewed

Comments

  1. Danny Revenant

    Hi Sam,

    I notice that one of the drawbacks to using preprocessors that you talked about is that its difficult to use chrome inspector to debug code written in Sass. This actually isn’t a problem any longer, as long as you’re using the prerelease of Sass and are outputting with the –sourcemap flag enabled: Chrome will be able to read the source map file that Sass produces and will run that info into Chrome Devtools Inspector for you automagically!

    You can find out more at https://developers.google.com/chrome-developer-tools/docs/css-preprocessors

    Cheers,

    Reply
    1. Sam Post author

      Thanks Danny, this is great news… It was a funny little problem which I thought I’d mention as it put me off Sass a bit at the start… Great to hear there’s a solution for it though, cheers!

      Reply

Leave a comment

* Required fields

captcha

Please enter the CAPTCHA text