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.
PROS: Making LESS Native
- Makes native LESS debugging in browsers possible. With LESS syntax preserved, it becomes possible to extend browser developer tools to natively work with LESS at runtime.
- It’s not changing CSS! The beauty of LESS is that we’re just improving the language syntax- not its capabilities. Browsers don’t need to reinvent their CSS engines or adopt proprietary CSS features. They just need to give us more powerful language parsing.
And to be fair…
CONS: Making LESS Native
- Legacy browser pain. Unless developers are careful to include the needed “fallback” pre-processing, older browsers would be presented with style-less (wha, wha….) pages.
- Language complexity for designers. Believe it or not, this is probably one of the key blockers to native LESS support. I’ve been approached by multiple designers after doing LESS talks at conferences stating that LESS makes CSS too much like a programming language. And I guess at certain level, they’re right. Today, CSS is a very basic static styling language. What you type is what you get. Adding LESS does require runtime processing to see the final results.
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.
The Past and Present
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.
Lobby Your Browser Authors
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.