UI controls for ASP.NET AJAX, MVC, WPF,Silverlight, Windows 8 and Windows Phone
Cross-platform Mobile Development Toolwith cloud-based architecture
One easy tool for Functional, Performance,Load and Mobile software testing
Everything for your online business - contentmanagement, ecommerce, emarketing
Simple and intuitive project managementand collaboration software
It’s no secret. I’m a LESS fan. A BIG fan.
If you’re not familiar with LESS, it’s an elegant CSS pre-processor that imbues the CSS syntax you already know with the kind of super powers you wish your styling language had out-of-the-box.
Variables. Operations. Hierarchal rules. Mix-ins.
LESS is all about making CSS more maintainable and reducing the kind of repetitive programming often required to maintain complex stylesheets. If you’ve ever caught yourself copying-and-pasting HEX color values, re-typing the CSS browser prefixes over and over and over, or crafting repetitive, long, chained selectors, then LESS is for you. It gives you the tools you need to organize these common pieces of CSS and reuse them throughout your stylesheet, all without forcing you to throw away everything you already know about CSS.
Sadly, though, LESS is a CSS pre-processor.
Browsers do not natively understand LESS. When you work with LESS, you must process it at some point, transforming the rich syntax in to vanilla CSS that any browser can understand. This pre-processing can happen at runtime (on the server or client) or (preferably for performance) at design/build time. Ultimately, it’s not usually a big deal to perform this processing step- part of the reason LESS is already awesome today- but it is a barrier to broad adoption.
Isn’t it time to enhance the power of the CSS language natively in browsers? Let’s break it down.
And to be fair…
So while there are some drawbacks to native LESS support, I think they can all be mitigated with minimal effort, especially since anyone (ahem…designers) that doesn’t want to use LESS can keep deploying “raw” CSS files.
As much as I love it, LESS is not the only CSS pre-processor in town. There are other solutions that attempt to achieve similar results, of which the most popular alternative is definitely SASS. Where LESS tends to win in my book is in its elegant reuse of the CSS syntax you already know. It adds very little to the functional CSS operators and does not try to force “developer” constructs on CSS, like variable typing or verbose syntax.
The “new” variant of SASS, Sassy CSS (SCSS), tries very hard to be more LESS-like. It adopts the idea of naturally extending the CSS language rather than overhauling the syntax, but in my opinion it still feels more “developery” than LESS.
LESS is the perfect balance of power and elegance. It feels like a natural step for CSS, not a big jump.
I’m not the first to think that browsers need to make CSS syntax more powerful and DRY. This argument has been raging for more than a decade. In fact, way back in 2008, Webkit nightlies briefly featured experimental support for CSS variables. Browser authors seem to recognize that enhancing CSS is necessary to evolve the productivity of developers (and designers), but so far most attempts have failed to come-up with a solution as elegant as LESS.
Sadly, the solution is staring the spec authors in the face.
Here we go. My call to action.
With or without the browser authors, LESS is still great. Kendo UI will continue to use LESS under the covers to make more maintainable themes. In fact, if you use the Kendo UI ThemeBuilder, you can even get the LESS output for your own use/tweaking.
I will keep educating people about the benefits of LESS and maintaining resources like LessCssIsMore.com (a LESS playground/scratchpad).
Join the movement, won’t you? Do you want to see native LESS support in browsers? I’d love to hear your thoughts in the comments.
Copyright © 2011 - 2013 Telerik Inc. All rights reserved.