Deprecated: Non-static method HTML_strip::usage() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/plugins/pi.html_strip.php on line 29

Deprecated: Non-static method Edit_this::usage() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/plugins/pi.edit_this.php on line 31

Deprecated: Non-static method imgsizer::usage() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/plugins/pi.imgsizer.php on line 32

Deprecated: Non-static method Gravatar::usage() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/plugins/pi.gravatar.php on line 9

Deprecated: Non-static method Comment::form() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/core/core.template.php on line 2691

Deprecated: Non-static method Char_limit::usage() should not be called statically, assuming $this from incompatible context in /nfs/c08/h04/mnt/172770/domains/novahurst.com/html/novahurst_system/plugins/pi.char_limit.php on line 29
Novahurst Creative / Blog / HTML and CSS Parsing Engines and Preprocessors

HTML and CSS Parsing Engines and Preprocessors

by Steve Hurst Steve Hurst on December 6th, 2010 at 2:06pm 5 comments

I came across an article on Smashing Magazine on the LESS CSS preprocessor and I just don't understand our need to complicate what is a relatively simple, straight-forward language.

LESS claims to produce "leaner" CSS code, but you're adding a language and a compiler on top of your standard CSS documents. HAML does something similar for HTML. The beauty of programming is that any two people can come at a problem with entirely different answers and both essentially be right, but I can't help but see these parsing engines as a fix to the inflexibility of either CSS or HTML to be wrong.

Beyond the false claim of leaner code, LESS does bring some interesting things to the table, such as variables, operations and nested rules. These have valid uses, such as this example:

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

The use of the @brand_color variable there is neat, and would definitely come in handy during a lot of projects. But it can also cause you to lose focus of core optimization at the gain of a little bit of flexibility.

Projects with different scope require a variety of approaches to CSS optimization, and focusing on these shortcuts can cause a narrower view of CSS in general.

The above example, leaner:

#header, h2 {
  color: #4D926F;
}

True, this is ignoring other declarations to both #header and h2, but in the project case where the brand color is important and consistent across a wide variety of elements, I would argue that separating the color declarations away from other font and layout declarations makes more sense. It's also much easier to change and track for later updates. New developers on the project adapt much more quickly to the second example, as well.

Parsing engines such as LESS and SASS for CSS, or HAML for HTML, have good intentions, and usually come with some very interesting features, but at a cost to simplicity. The CSS and HTML specs are by no means complete and perfect, but there is a reason why enhancements that LESS , SASS and HAML bring to the table aren't part of spec. They're solutions to narrow problems, and only one way to solve issues you might have with HTML and CSS.

5 Comments

Of course, in your trivial example, Sass or Less seem like overkill and they are. In a real-world app, the approach you specify is not very maintainable. You have to remember where those selectors are scattered about, or you have to scatter the values around. Variables, mixins, and selector inheritance (in sass) give you tools to avoid duplication and quickly propagate change.

Give them a try on a real app before you discard them.

by Chris Eppstein Chris Eppstein on December 6th, 2010 at 3:23pm

I’ve always considered HAML and SASS to be merely extensions of ruby so that hardcore developers don’t have to switch between “back-end mode” and “front-end mode”.  Less seems to be more of the same.

by Chris Mears Chris Mears on December 9th, 2010 at 5:28pm

@Chris Eppstein Granted, it was a trivial example, but it is a fundamental building block of CSS optimization, and I wanted to give as basic an example as possible to avoid the reader losing the point.

Every project is different, and the above example won’t be useful for some, and postprocessors will be a necessity for others.

My point, probably lost in my curmudgeonly rant, was to look at what you have before adding a potentially unnecessary layer.

by Steve Hurst Steve Hurst on January 28th, 2011 at 9:53pm

Nice tutorial! I think LESS, SASS, HAML are the best addition to apply it for its new features. Hope the new comers will be benefited by these. Thanks for your cooperation.
Skateboard wheels

by Norbert Morris Norbert Morris on May 1st, 2012 at 7:44pm

Useful allocation!! As a new worker of LESS, SASS, HAML works, I found the info of this post beneficial for me. English song  Thanks

by English Songs English Songs on May 12th, 2012 at 11:30pm

Got something to add?