HTML and CSS Parsing Engines and Preprocessors
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
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 on December 9th, 2010 at 8: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 on January 29th, 2011 at 12:53am
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 on May 1st, 2012 at 10: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 on May 13th, 2012 at 2:30am
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 on December 6th, 2010 at 6:23pm