Blogs

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

• Remove barriers to LESS adoption. Anyone that wants to use LESS just deploys a LESS file (along with a fallback JavaScript pre-processor for older browsers). Using LESS becomes: <link type=”text/less” href=”styles.less” />.  Done.
• 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.
• Reduces run-time performance concerns. Of course, you can avoid run-time perf problems today with a build-step pre-processor, but if you choose to do run-time processing (especially using JavaScript) there is a performance penalty. Putting the processing in the browser engine should make it fast to the point of being “instant.”
• 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

• Two “styling” file types for the web. With the introduction of native LESS support, CSS support should not end. It should be a choice made by developers to deploy LESS or CSS. The added LESS file format could clutter the beautifully simple HTML, JavaScript, CSS trifecta we have today.
• 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.
• Browsers doing too much? Do we want browsers doing more processing? Older JavaScript engines we’re painfully slow and constant sources of memory leaking. We definitely don’t want CSS to contribute similar problems.
• 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.

Why LESS?

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.

The specs for adding LESS-like features for CSS continue to be debated today. Unfortunately, all of today’s formal proposals are hopelessly focused on creating a language that feels more like JavaScript than CSS, and none have the proven popularity/adoption of something like LESS.

Sadly, the solution is staring the spec authors in the face.

Lobby Your Browser Authors

Here we go. My call to action.

Let’s help end the debate and steer browser authors towards a CSS enriching solution that has been proven in the market. Let’s help make the next step for CSS something that elegantly extends our working knowledge of CSS and doesn’t try to make CSS the next JavaScript. Let’s tell the browser authors we want to see native LESS support!

Until then…

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.

About the Author
Todd Anglin is an avid HTML5, CSS3, and JavaScript advocate, and geek about all things web development. He is an active speaker and author, helping developers around the world learn and adopt HTML5. Todd works for Telerik as VP of HTML5 Web & Mobile Tools, where his current technical focus is on Kendo UI. Todd is @toddanglin on Twitter.