What you think about LESS CSS?

Like I said in the title… What you all think about LESS CSS or The dynamic stylesheet language.

More info on this subject can be found here LESS « The Dynamic Stylesheet language and here [url=http://coding.smashingmagazine.com/2011/08/23/the-semantic-grid-system-page-layout-for-tomorrow/]The Semantic Grid System: Page Layout For Tomorrow - Smashing Magazine but I would like to hear something from the first hand.

So, any experiences with this LESS CSS?

Me thinks it’s stupid. :slight_smile:

Any arguments?

I’ve looked into both of them, out of curiosity. I tend to disagree with almost everything that comes out of Stubbornella’s mouth for some reason : ) I apparently do CSS in a completely different way from how she does it.

For the work I do, they (LESS or SASS) would be
-adding extra work (converting the made-up new syntax to what I really am trying to say, installing stuff on my server)

-adding Yet Another Layer Where Things Can Go Wrong between me and my rendered page (I hear there’s a firebug plugin/patch that lets it help you debug your LESS’d or SASS’s CSS, but dunno about the other browsers’ dev tools)

It seems to be one of those things where, programmers are constantly complaining about how much CSS sucks because… because it’s not a programming language. So that is one thing LESS/SASS does is let programmers pretend it is a programming language, by adding things like loops, variables, scope, conditions… and lets them avoid some of the syntax of CSS (complicated stuff like… comma-separated values, or vendor prefixes. Darn, that stuff’s so hard and takes me so long to type. Oh wait, it doesn’t, I have an excellent text editor! Using non-crappy tools really does help).

It also seems like something a group of developers trying to stay coherent and know/understand what everyone else is doing would use, especially if they are working with lots and lots of crappy HTML. Crappy HTML leads to crappy CSS, and it seems LESS or SASS would help a developer’s head not explode trying to write CSS for crappy HTML.

It kinda reminds me of CoffeeScript, in that you basically learn a whole new syntax… to write Javascript. Instead of writing… Javascript. If your project is big, you can use that same syntax for other languages and whatnot, and it can become a benefit in that situation.

LESS has the option of sitting on your dev server, and you can write your styles in LESS and then when you’re done just have it spit out regular CSS (like what it feeds your browser) so that you don’t have to burden users with a steaming pile of Javascript simply to see styles (and you can more easily debug). The other option is to have Ruby installed on your server (which would be perfect if you’re already using Ruby to serve your pages and does all your scripting needs) and run SASS back there.

The second link about CSS grids I think shows my point. I don’t write CSS for crappy grid HTML, so I don’t need to go install some tool to help me do that. All those arguments about using LESS to me are arguments against using grids, and I don’t use grids, because I don’t like all those reasons the guy points out.

But again, if you are some poor guy stuck with using grids because they are the Hot New iThing!, then LESS or SASS may help your head not explode while you try to style them.

I also got feeling that LESS is made only for grid system layouts and I must admit that I don’t use it when I make layouts. It kind of seems too complicated without any really good reason for that.

Heaving read the documentation and being responsible for building medium scale web applications there are many aspects of LESS that look appealing. That said, I would never deploy it without a server-side parser and proper caching because client-side parsing would be an efficiency nightmare.

I think it is unfair to say it is only used to offset *****y HTML. All concepts shared between LESS and SASS aid in code consolidation, reuse and maintenance regardless of good or bad HTML. For small websites it would probably be an over kill but for web applications deployed multiple times with client-side customization having the tools it provides would improve workflow.

CSS variables would be nice to have I always have a need for variables. Right now I meet that need by passing CSS files through server-side code, which works but it would be nice to have in CSS itself. That is probably the one thing I wish there was native support, everything else I can probably do without.

Using js to simulate CSS seems self defeating. You could use js to do ALL your styling in a site. This would get kinda complicated quick and would immediately ruin your site if js is off; I suppose I am a purist. Am also a minimalist, add a library just so you can do CSS differently ( read: non standard)? change your class structures so that the js can work?

I agree with Stommes, it seems LESS was develop as a way to “correct” poor code ( or rather … poor code planning that was executed as poor code)… It just seems as something that would make more work instead of LESS in the end.

I fail to understand the rational behind that.

I think it is unfair to say it is only used to offset *****y HTML.

It may be unfair. But I have never seen the accompanying HTML look anything close to good.

[ot]
Then again, my HTML standards are very high, and it seems anything touched by robots (like a CMS) always fails my standards. And maybe that’s unfair, because if a site is ginormous, we likely need robots to write and manage it for us. And I have worked on sites who were not products of ginormous CMSes.

But for example, I write HTML forms, and I like them. I am happy.
Then a colleague has his back-end build them using something called a “form builder”. I don’t know what it is, except that it was an English-language program who kept trying to turn my “jaar” into “year” for some reason.

The code coming out of that form builder was a poor imitation of the excellent HTML I had started with (so, the work of writing the HTML was already done and maybe this is where the problem was, I dunno). This is why I have a poor view of all template systems and all builders. I have yet to see one not rake my code to shreds and then pathetically glue the bloody pieces together and call it “alive”.[/ot]

That is probably the one thing I wish there was native support, everything else I can probably do without.

I would like parent selectors, and LESS/SASS kinda can imitate the result in a roundabout way.

But when the articles do the “don’t you hate it having to look up a colour…” thing. Why don’t I have that problem? It’s like those late-night ads where you see someone pathetically trying to “clean” something, like OJ Simpson trying to fit his hand into a glove: it’s theatrical. I watched a man horribly trying to shave, throwing up his hands like “omidog! it’s just not possible!”

and then the product appears. The one that will allow housemoms to clean tiles and men to shave and OJ to fit his hand in a glove. It slices! It dices! It does Windows!

Again, this isn’t the fault of LESS or SASS, but the poor arguments articles use to show why they are better: o noes front-enders just can’t easily find and copy colours! (or something)
Hm, not an issue I have. I recognise most of my colours and I have an excellent text editor that finds things for me and changes them on the fly. Likely someone has written a plugin that will actually even show me the colour right in the editor, if I wasn’t so lazy I could go install it.

Using js to simulate CSS seems self defeating. You could use js to do ALL your styling in a site. This would get kinda complicated quick and would immediately ruin your site if js is off;

You don’t have to do it this way, though.

Here is the situation they are referring to which I can relate.

We have a single website, that is deployed multiple times with small CSS changes for colors and images. It would be an efficiency nightmare to copy the styles sheets only to change one or two things every time the site is deployed for a new customer. Instead one single code set exists and CSS changes are made by passing the style sheets through the server-side code so that variable replacements can take place. That prevents duplicating the style sheets and ultimately those style sheets becoming out of sync, or worse when a change needs to be made having to go through all the duplicates and update those as well. Obviously this would not be a need with a single site, but when managing multiple sites using the same code et, keeping everything in one place avoiding duplicating the code set for a single customer to make a small change promotes ease of maintaining the software.

Just to put this in perspective I work for company that owns several newspapers and we have about 3 separate code sets for news, autos and real estate management. There are about 13 individual news papers that deploy these products with slight changes to match their individual branding. So we don’t have 36 separate code sets floating around CSS variable replacement is necessary to keep everything together, yet make it possible to slightly customize the deployments. If CSS supported variables there could be a single style sheet to assign server side variables to CSS variables avoiding the need to pass all style sheets through server-side code and output dynamically.

My husband does that in Perl since they kinda have the same thing: multiple pages with mostly the same styles except each is for a different newspaper, so there are small changes that match the paper’s house style.

It might not be exactly true, but for whatever reason Ruby does have this reputation of being slower than other interpreted languages. I wonder if the Perl solution is just so much better for such a situation than something like LESS or SASS?

Well the only thing you can really achieve by passing CSS through server-side code is really variables without getting creative and probably quit convoluted. Of course its more efficient then LESS, since LESS needs to actually run parsing where as merely serving a php file with CSS content type does not require any additional server-side parsing. That is always required in some capacity if there is a need to change styles dynamically. The only other alternatives are inline (which sucks), embedded (which sucks) and JavaScript application (which sucks).

Less functions are pretty neat though if you think about the idea of decoupling implementation from interface especially in terms of CSS3. While it may not be that big of a deal to repeat 5+ lines of CSS to support many CSS3 properties in all capable browsers, it does quickly become a pain. Even worst is if implementation changes there isn’t a single thing to change, you need to go through and update all occurrances of the code. Using less a single function can be created to apply the CSS3 and easily updates once if something changes.

I have to agree with Stomme poes. I’ve tried both and found that they took up more time than going straight to my editor of choice and hand-coding the design right away. It’s indeed an extra layer that I neither need nor want. Besides, I’m a control freak, I want to write each line of my code. I memorize things a lot better that way. Such systems take away lots of work for the grey matter, and especially with CSS, that isn’t necessarily a good thing. Not for me, anyway. For the same reason, I have problems using pre-made templates like HTML Boilerplate and their kin. It just doesn’t feel like a pragmatic choice to me, though it’s intended to be just that. Then again, I’m pretty inflexible with changing my ways. I started learning HTML and CSS through coding manually, having any parts auto-inserted by a tool, makes me uneasy.

I’ve toyed around with PHPLess a while back, and after I’d finally set it up to work with my PHP framework of choice (Yii) correctly I ditched it because I didn’t like it after all (why do you always figure that out after hours of testing and implementing).

Anyway, what I didn’t like about it was:

  • My editor (NetBeans) has auto complete for classes and ids when I’m editing HTML. So I can type <div class=" and then hit ctrl+space and it will show me a list of all classes available in all css files in the project. Very handy, especially if you’re not entirely sure what name you gave the class; you can just look for it without opening up the CSS file and looking for it there – this saves me quite some time. But, this doesn’t work with LESS files, which sucks.
    (unless they have been compiled --o.e. I’ve looked at the website after I’d changed the LESS file – requesting the page parsed the LESS to CSS, but I can switch from HTML to CSS – or indeed LESS – a lot without looking at the website once).
  • There was no decent plugin for my editor. There was a plugin, but it didn’t retain the color settings I set, so I had to redo that every I restarted my editor. Annoying.
  • Last but not least, it is my opinion that LESS promotes bad CSS code practice by allowing to nest like they do. It’s very easy to lose track of how deep you’re nesting using their markup, so you can end up (and I did) with 4 levels deep where in pure CSS I would have never done that (my person aim is to go no further than 2, or 3 if I really have to). This was just an abstraction too far where you lose sight of what you’re actually doing.

The one thing I really did like are the variables and how you can use calculations in there. For example with sticky footers there are some values that turn up repeatedly all over the CSS. With less you just define variables footerheight, footerborderheight, footerpadding, etc somewhere, and use that everywhere. When you need to change one of these values you just change the variable and everything will automatically be changed to suit.
This doesn’t weight up against the cons I listed above though (especially because you really don’t change the height of a sticky footer all that often …)

If I were to use something like LESS it would be for:

  • mixins Because I get sick of adding:

    -webkit-border-radius: 8px; -moz-border-radius: 8px; border-radius: 8px;

    in 20 (exaggeration!) different places.
  • variables because variables are more DRY than #fe045 in 20 places
  • Math!!! Because all the cool kids are doing it.

I think the one thing I would probably skip out on for sure is the nesting. As was mentioned before, it could potentially be quite easy to lose where you’re at, and since selector specificity is affected, it is something that could potentially prove troublesome.

Having said all that, I still haven’t convinced myself that I should use LESS since there will inevitably be some hassle associated with it. For most things I work on, the hassle/time/pain involved would outweigh the benefits of it.

I do agree however that if you would start building a big application or framework, that LESS might be worth using. Especially for frameworks where the aim is to have a sort of boilerplate of stuff there that requires some tweaking for your Next Big Thing Project.

What do you think of a tool like Less.app: LESS.app For Mac OS X where you basically write the .less file save it, and it automatically compiles the css directly into your chosen folder and you upload the compiled CSS. Personally, I would never rely on javascript for my CSS to work. I hate the idea of something solving the developer’s problem at the expense of the user. Web devs should be solving the user’s problems.

However, if you can upload the straight CSS, you could enjoy the scripting conventions, without worrying about that. I haven’t used LESS yet, but I am more than just a little intrigued at the possibility of setting variables, not for the creation of the CSS, but for the maintenance.

There definitley is something to be said, though, for staying familiar with the standard, because if you get used to LESS, and then have to work in an environment without it, that could become pretty distressing.

Grid idiocy and an unnecessary framework… Oh yeah, bloody brilliant. RIGHT.

LESS is just more… more work, something new to learn, and doesn’t do anything you couldn’t just handle in a more reasonable fashion. It also makes pages harder to maintain as it just adds another step to it. Put this into the same category as other idiocy like jquery, mootools, YUI, etc…

Then “semantic grid” – it’s not semantic, and it defeats the entire POINT of using CSS in the first place as saying “grid_6” is still saying what it should look like in the CSS – so when it comes time for “responsive” design you’ve pretty well shtupped yourself with an enormous schwanzstucker.

CSS frameworks – more idiotic than javascript frameworks and that’s really saying something… but of course such idiocy is how one ends up with megabyte sized pages to deliver 4k of plaintext – right Yahoo?

Of course that the entire site is from someone who has apparently embraced the whole HTML 5 bull is hardly shocking – given I bet they never once actually wrote a page practicing separation of presentation from content or semantic markup… and just two years ago was probably vomiting up HTML 3.2, slapping a tranny doctype on it and saying “close enough”.

Besides, if you have to shove 34k of javascript (12k after compression) at a page just to have a CSS file be 10% smaller than if you wrote it properly, that’s BS no matter how you color it… Naturally though it tries to hide what a fat bloated mess it is since no tool out there will even tell you exactly how big the .less files actually are… which btw ends up 5k in five files once you deal with all the @import idiocy. Because of course saving a few bytes is so worth it when you quintuple the number of handshakes. RIGHT.

Actually, let’s do a fair comparison… take their simple demo page which consists of the following files:

The Semantic Grid System | Fixed-width Example = 883 bytes
http://semantic.gs/examples/fixed/fixed.less = 603 bytes
http://semantic.gs/css/reset.less = 1062 bytes
http://semantic.gs/css/grid.less = 861 bytes
http://semantic.gs/css/demo.less = 438 bytes
http://semantic.gs/js/less-1.1.3.min.js = 33.9k

So that’s six files in 37.7k – about 2k of which is what the coder had to write… let’s redo it using a RECOMMENDATION doctype, PROPER separation of presentation from content, and normal CSS. Just to make it as fair as possible I’ll use XHTML 1.0 with ALL the extra stuff that HTML 5 supposedly “saves you time not having to do” since I’m going to be axing a few elements. I’ll also toss in some closing comments:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

</head><body>

<div id="pageWrapper">
	<h1>
		<a href="http://semantic.gs/">
			The Semantic Grid System
		</a>
	</h1>
	
	<div id="content">
		<h2>Main</h2>
	<!-- #content --></div>
	
	<div id="sidebar">
		<h2>Sidebar</h2>
	<!-- #sideBar --></div>
		
<!-- #pageWrapper --></div>

</body></html>

751 bytes, so our markup is certainly smaller… Their demo being a PERFECT example of why I think elements like HEADER are pointless wasteful bloat and HTML 5 so far as markup is concerned is nothing more than “because we could” instead of “because it’s better”.

Then identical functioning CSS as a single file. Again to try and give their approach as much advantage as possible, I’ll code in some IE5 support… and bother with things they skipped like say… fallback font-families?


/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

body {
	text-align:center; /* center #pageWrapper IE 5.x */
}

#pageWrapper {
	overflow:hidden; /* wrap floats */
	width:960px; /* also trips haslayout, so IE is float wrapping */
	margin:0 auto;
}

h1 {
	padding:1em;
	margin:0 10px 20px;
	text-align:left;
	font:normal 200%/120% georgia,times,serif;
	color:#FFF;
	background:#000;
}

h1 a {
	text-decoration:none;
	color:#FFF;
}

h2 {
	font:normal 150%/120% georgia,times,serif;
	padding:5.25em 0;
}

#content,
#sidebar {
	float:left;
	display:inline; /* prevent IE margin bugs */
	width:220px;
	color:#666;
	background:#CCC;
}

#content {
	width:700px;
	margin:0 20px 0 10px;
}

Which comes out to 924 bytes. Where’s the big savings in effort or code from using that nonsense again? Especially since their example breaks javascript off, their example doesn’t work in IE7 or lower due to faulty CSS, etc, etc… When mine works just fine all the way back to IE 5.01

… and of course i can SHOCK easily make it a fluid layout, something NONE of these idiotic grid systems can even attempt to do… I can send print an entirely different layout since I’m targeting things by what they ARE, NOT what they look like.

Notice that even if we omit the javascript AND the grid framework AND their reset – I’m still using less code overall… 1,924 bytes for their html, demo.css and fixed.css combined vs. 1,729 for mine… with mine not needing the additional 34+k of framework bloat. It’s honestly why I think the people who come up with these types of systems to make things “easier” have failed to grasp how HTML and CSS even work in the first place! This is why whenever I see things like <div class=“center”> I feel like screaming at them “At that point just go back to coding HTML 3.2 as apparently that’s all you’re good at!”

Someone needs to explain to the nimrods who come up with these types of garbage exactly what semantic markup IS. It takes giant bronzed monkey cojones to call that grid system of theirs “semantic” – as if that’s what they think it means, they need to do the world a favor, back the devil away from the keyboard, and go take up something a bit simpler like bocce or horseshoes.

I like a lot of the ideas in it, but wish they were in CSS natively. The nesting is one thing that seems like a good idea but actually isn’t that useful when you look at it. Variables, mixins, expressions etc I can see being quite useful. Even regular expressions being used in the selectors would be useful as well, with back references being able to be used in the rule as part of an expression or something.

I don’t understand the resistance to change on these things, for the very artificial reason that people don’t want CSS to become a ‘programming language’. The primary purpose of the language should be to make it useful, not to please some people who don’t want to have learn some new concepts. Oh well.

Can someone please tell me where the actual benefit is here? I looked through the examples, and it seems like most of the LESS code samples requires more lines than the actual CSS output.

Things like globally updating colours in one move is nice, but this can be done much faster in a number of less-complicated ways. The same goes for the operations. Seriously: If you can’t do things like multiplication and addition, you need to brush up on your math skills, not make a Javascript-based CSS framework.

The nested rules is really just a different way to write things, and doesn’t make things any better, save for possibly saving a couple of keystrokes.

The vendor-specific CSS is a non-issue. I can’t think of any good reason to use this to cater for last year’s browser versions. Those who can’t see the rounded corners or dropshadow will just have to see the square corners in stead, and be none the wiser. Graceful degradation at its best.