What you think about LESS CSS?

[C. Ankerstjerne]

Just for the sake of argument:

header('Content-type: text/css');
 
$css = file_get_contents('screen.css');
 
$variable_array = array(
 'font_header' => 'arial, helvetica, sans-serif',
 'font_text' => 'georgia, times, serif',
 'color_header_background' => '#000',
 'color_header_text' => '#fff'
);
 
foreach($variable_array as $key=>$value) {
 $search = '{var:'.$key.'}';
 $css = str_ireplace($search, $value, $css);
}
 
echo $css;

html {
 font-family: {var:font_text};
}
 
h1 {
 background-color: {var:color_header_background};
 color: {var:color_header_text};
 font-family: {var:font_header};
}
 
h2 {
 background-color: {var:color_header_background};
 color: {var:color_header_text};
 font-family: {var:font_header};
}
 
th {
 background-color: {var:color_header_background};
 color: {var:color_header_text};
 font-family: {var:font_header};
}

[L4DD13]

Personally, I love it.
It's perfect for rapid development.
I've saved so much time when prototyping or just toying with ideas.

I'm yet to come across a reason not to use it. However, saying that there are a few issues where the likes of filter: progidXImageT.... causes an output error (at least in the JS version it does). I use the PHP lesscss parser.

Cheers.

[oddz]

Yeah… I mean variables are pretty easily replicated by passing the file through server-side code but mixins, functions and nested rules is not. Granted, I have never needed them I would use them had they been apart of CSS from the start. I'm developing a project with Sencha Touch and it uses SASS, for something like that it seems pretty useful. Had Sencha Touch not been built using SASS it would be much more difficult to customize.

There is a place for this stuff (and no deathshadow the trash is not what I'm referring to). In terms of maintainability I agree. To often than not most people here seem not care about how easy it is to maintain something even if it means fairly small sacrifices. Professionally though maintainability is at the top of my list, considering nothing that I build is ever "complete"… it always gets modified over time. Being able to come back to code and understand what is happening or to easily change something globally with a single key stroke is a big plus for my day to day.

[Michael Morris]

If you think this is a great new tool, then I won't stand in your way. If you can convince me that it is in fact a great new tool, I'll be happy to take it for a spin. But please, do so with constructive arguments, rather than snide remarks, and until then, recognize that it's not necessarily a one size fits all tool.

The source of my derision isn't specific to LESS. It's this idea your floating that using the copy, search and replace functionality is equivalent and better in any language than proper re-factoring and code organization. Without exception every code I've seen written that way is brittle and damn near impossible to work with except perhaps for the original programmer (and sometimes that person has trouble with it).

CSS does not, in and of itself, provide the tools to prevent repetition that variables and mix-ins purport to provide. If Less can provide those tools so much the better. They do have to prove themselves more useful than the cascading nature of the sheets and the ability to mix in by declaring multiple classes on the element. However, multiple class declaration on elements runs contrary to the purpose of CSS to some degree as it is declaring markup in the HTML unless the designer is careful. Still, in principle, variables and functions can help with this situation. They also might not help as their presence in every programming language since near the beginning hasn't prevented Byzantine and unreadable code from being created.

Will all projects need LESS? No, and indeed I'll venture that most won't. But as more and more is asked of CSS, especially the transitions library, those style sheets are going to keep growing. Something's got to give here.

But this idea that copypasta is a good thing is hogwash. I'll stand by that as mean as it to say. Failing to understand the value of code refactoring and DRY (Don't Repeat Yourself) code organization is a fundamental failing. Copypasta has it's place when managers and deadlines loom - but even then the fact its being resorted to is a failing of management and the short term gain will be a longterm loss - unless the project is fire and forget and then why not? Search & Replace against a code base is a weapon of last resort - a powerful weapon to be sure, but a weapon who's use betrays fundamental problems with the code.

[C. Ankerstjerne]

Michael
I never said it was equivilant or better in any language. I was saying that is was just as good for CSS. The PHP I write is almost always object oriented, or at least function based. I use the tool that fit the task. PHP is a programming language, CSS is not, and I treat them accordingly.

I won't rule out that LESS has its uses, but if it does, it's not for the average site (as you write yourself). My concern here is that some developers will start using LESS, when using out of the box CSS is more than enough.

[Stomme poes]

I don't see much difference between your tool to add in a bunch of vendor extensions (as an example) being an editor or that tool being a big thing you install on your server. The fact of the matter is, in CSS, there is no DRY. These tools just do the repeating for you, but it's getting repeated, sorry. Totally different from DRY in programming.

Or maybe I'm confused and DRY really does mean "automation of repetition" but I sure thought it meant "less code that repeats" and that's not what we get.

[deathshadow60]

Totally different from DRY in programming.

... and not that DRY is in fact always good practice in programming -- sometimes it's faster to unroll the loop.

MOV CX,4
:loopBack
MOV AX,DS:[SI]
AND AL,ES:[DI]
OR  AL,AH
STOSB
ADD SI,2
LOOP :loopBack

The loop purges the pre-fetch and adds 30 clocks per iteration.

MOV AX,DS:[SI]
AND AL,ES:[DI]
OR  AL,AH
STOSB
ADD SI,2
MOV AX,DS:[SI]
AND AL,ES:[DI]
OR  AL,AH
STOSB
ADD SI,2
MOV AX,DS:[SI]
AND AL,ES:[DI]
OR  AL,AH
STOSB
ADD SI,2
MOV AX,DS:[SI]
AND AL,ES:[DI]
OR  AL,AH
STOSB
ADD SI,2

More bytes, but executes around 40% faster. Sometimes repeating yourself is a good thing.

Though CSS DOES provide for DRY -- if you bother to use it PROPERLY. To borrow from Chris' example:

html {
 font-family:georgia,times,serif;
}

h1, h2, th {
	font-family:arial,helvetica,sans-serif;
	color:#FFF;
	background:#000;
}

Which one's more efficient, uses less code, and is easier to perform mass edits with? Only if you're a total {expletive about one's intelligence omitted} redeclaring the same values over again instead of adding them to like targets would any of this 'variables in CSS' nonsense actually be useful. You want to have multiple elements sharing the same value you can edit in one place -- DECLARE THEM TOGETHER!!! DUH!?!

Though admittedly, I see wasteful CSS with people redeclaring the same things over and over again for no good reason all the time -- goes with that nobody seems to bother realizing not every element needs a DIV around it, class on it... much less that presentational classes are zero improvement over just writing HTML 3.2 without CSS.... which is why we still see dumbass coding like: class="red bigfont centered clearfix" -- Net improvement ZERO.

[sdt76]

.
Which one's more efficient, uses less code, and is easier to perform mass edits with?

I think maintainability and ease of use is what LESS addresses. That will be different for everyone. So for your example: yes of course, declaring like values in one selector is always better. But if someone has organized their stylesheet by section with commenting, like /*HEADER AREA */ and then /* FOOTER AREA */ and both have a certain blue color heading, yet different sizes, you can't group them in a selector if they are only relevant to their respective IDs unless you take the #footer and grouped it like this with the header:

#footer h2, #header h2 {color:#bluehexi;}. Then the sizes are controlled in different selectors.

Problem with that is that now you have violated your maintenance set-up by mixing header stuff with footer stuff. Then to change the color, you have scroll all over the place to change footer elements that have the same blue, plus the h2 footer element, somewhere else, that also has that blue. It seems easier to me to have footer styles in the footer section of the CSS, header styles in the header section, then link a variable for the blue color and only change it in ONE PLACE, at the top of the style sheet. Then, you don't have to GUESS as to whether or not you made a human error through copy and paste by forgetting to change a hexi.

But this idea that it supposedly makes for less coding, I don't take to be the real point and benefit. It's just supposed to make it easier to maintain and read. Again though, it depends on how you structure your CSS in the first place. LESS isn't for everyone obviously. Since I have not used it, I cannot say yet whether the benefits are real. But I remember telling myself one time, doing a stylesheet, I wish I could just declare this color in one place.

[deathshadow60]

But if someone has organized their stylesheet by section with commenting, like /*HEADER AREA */ and then /* FOOTER AREA */ and both have a certain blue color heading, yet different sizes, you can't group them in a selector if they are only relevant to their respective IDs unless you take the #footer and grouped it like this with the header

which is something I consider a foolhardy method of sitebuilding -- as it prevents you from doing exactly what I just said... besides if you use MEANINGFUL Id's and class names it should be clear what's in what section and/or what it is for.

But of course with people vomiting up pages with classes like "n","g20" or the all popular "hbk"... I often laugh at the people who put in one line of comment for every element and then use three letter class names... No wonder some people actually see a benefit to minification (which I don't)

[Tebbit]

Just read over the page (note I have only skimmed the responses in this thread)

It just seems...unnecessary. I can't see anyone actually taking the time to learn how to use LESS extensively that would actually result in people writing code faster.

I sort of have to agree with EricWatson on this

[oddz]

Using Sencha Touch with SASS I was able to get 50% of the design complete I am working to achieve for a project, with 10 lines of CSS/SASS. I think that is pretty nifty. There is no way in hell that would be possible without mixins and variables – no way.

In regards to being DRY it is dry – you don't have to repeat yourself – the computer does. Which that is going to happen anyway with the nature of CSS, repeating colors, etc. I mean… it all has to compile down to plane-jane CSS in the end anyway, no getting away from that.

Than again I am referring to SASS with compass (compile SASS files to plane-jane CSS). So you can pretty much write all your SASS than compile down to a compessed plain-jane CSS file and link to that. Which si pretty nice considering SASS is merely use as a tool to aid development.

[sdt76]

which is something I consider a foolhardy method of sitebuilding -- as it prevents you from doing exactly what I just said... besides if you use MEANINGFUL Id's and class names it should be clear what's in what section and/or what it is for.

Well, no matter how you organize your CSS sheet, you are going to run into situations where common elements share the same values within different classes and IDs. When that happens, groupings will occur naturally. So you could do NO division with commenting, which makes the concept of a variable even more useful because you end up with a giant SEA of CSS code without any maintainable breakdown, or you can divide the sections logically, with the same situation. The idea is that you have ONE hexidecimal in ONE place, and you only have to change it once no matter how many elements share the same color all throughout the stylesheet. That's definitely a positive for me.

[oddz]

Man… I must say after diving into SASS loops, nesting, variables and mixins I gotta say it is pretty cool and nice to actually be able to represent hierarchy. Once you get it, which doesn't take to long it heavily improves efficiency and readability for me anyways. It is pretty nice to be able to write 3 lines of SASS to position a spite of 20 frames… just saying.

[Michael Morris]

I won't rule out that LESS has its uses, but if it does, it's not for the average site (as you write yourself). My concern here is that some developers will start using LESS, when using out of the box CSS is more than enough.

This problem is no different in my mind than people learning jQuery, prototype or other JS framework without first coming to terms with what JS itself. It's going to happen - people are going to use chainsaws when scapels are required. But that isn't a reason not to make the chainsaw.

My apologies for being overly harsh in my language up thread.

Or maybe I'm confused and DRY really does mean "automation of repetition" but I sure thought it meant "less code that repeats" and that's not what we get.

DRY (Acronym Don't Repeat Yourself for the designers wondering what we're babbling about) isn't about preventing the computer from repeating itself. It's about you repeating yourself. The computer can repeat itself all it wants.

... and not that DRY is in fact always good practice in programming -- sometimes it's faster to unroll the loop.

<snip assembly>

More bytes, but executes around 40% faster. Sometimes repeating yourself is a good thing.

You're slightly missing the point Jason by taking the acronym too literally. DRY isn't about preventing literal repetition of code. It's about preventing redundant statements about application state, and only defining methods of operation once. Using your own example - the first method, a loop, is what most programmers would write when drafting out the code the first time. When time comes to optimize the second method might get used.

The principle of DRY states the method should be defined only once so that changing once is all that is necessary. Same for application state - the programmer defines it once so that it is changed only once.

Which one's more efficient, uses less code, and is easier to perform mass edits with? Only if you're a total {expletive about one's intelligence omitted} redeclaring the same values over again instead of adding them to like targets would any of this 'variables in CSS' nonsense actually be useful. You want to have multiple elements sharing the same value you can edit in one place -- DECLARE THEM TOGETHER!!! DUH!?!

Counter example.

 
@schoolDark: #009;
@schoolLight: #fff;
 
section {
  color: @schoolDark;
  background: @schoolLight;
}
 
header {
  color: @schoolLight;
  background: @schoolDark;
}

While busy calling designers dumb you are forgetting context switching. Most good designs only really use 2 to 4 colors, but the roles of those colors will change by region and may get swapped. University of Kentucky blue is #009 I think, but say I'm wrong and it's #00A; Without a variable on a site I'd have to use search replace to change this in all the contexts that it was used. A full design will swap these out to box borders and other color elements as well. CSS, even with cascading, cannot address this situation. It has no way of knowing that the color of one element, the border of another and the background of a third should match.

Less' output code can be very repetitive. Who cares? DRY isn't about the state of the final CSS the less compiler shoots out to the browser. Your assembly code example itself is ridiculous because modern compilers will often do what you suggest on their own anyway, as well as other optimization that might not even occur to a human programmer, even one as smart as you.

Though admittedly, I see wasteful CSS with people redeclaring the same things over and over again for no good reason all the time -- goes with that nobody seems to bother realizing not every element needs a DIV around it, class on it... much less that presentational classes are zero improvement over just writing HTML 3.2 without CSS.... which is why we still see dumbass coding like: class="red bigfont centered clearfix" -- Net improvement ZERO.

Even in your own "dumb ass" example, the designer has the ability to determine which shade of red and size of font, so it isn't an entire loss. Sometimes in your arrogance you lose sight of things like that. This said, class chaining like this is what mixins in less are attempting to address.

Misuse can and will occur. Human beings aren't perfect. You cannot design a tool smart enough to prevent its misuse. And it follow that misuse shouldn't usually be the first criteria by which a tool is judged. Unlike you though I give my fellow human beings credit for trying instead of constantly being demeaning (though I lapse on occasion).

[deathshadow60]

Counter example.

See, I would find that confusing in a stylesheet because you aren't saying WHAT you're applying the color to -- it's like recursive constant in Prolog... it ends up being so much effort to backtrace (or in this case forward trace) it offsets the advantage of setting it in just one place.

You'd end up like being back in the days of BASIC programmers using cross-referencing software to build a var list... oh wait, it's called Firebug/Dragonfly

(which I still say if you need to use FB/DF on your own code, there's something horrendously wrong with said code)

[omglookitsagoat]

Well I can't really say I'm much of a programmer (yet). I'm a graphic design major, but I've been learning and using html and css for a few months. Honestly oddz, your opening thread is not confusing to me at all. I understand what you mean by less code, but whether or not you decide to use less or more really depends on the circumstance. (At least as far as I know, but feel free to counter my comment if you have good reasoning to the contrary.)

[oddz]

Well I can't really say I'm much of a programmer (yet). I'm a graphic design major, but I've been learning and using html and css for a few months. Honestly oddz, your opening thread is not confusing to me at all. I understand what you mean by less code, but whether or not you decide to use less or more really depends on the circumstance. (At least as far as I know, but feel free to counter my comment if you have good reasoning to the contrary.)

Fair enough. The only reason I even came back to this thread is that I'm working on a Sencha Touch application. Had I not been introduced to Sencha Touch I would probably have never gave this stuff a second thought. None the less, I think there is much to gain from many of concepts in LESS and SASS having now had used them during a real project. I think SASS is a little more mature than LESS though considering it has loops and some other goodies which are not present in LESS. By far my favorite thing is rule nesting considering it makes the CSS more readable when done properly. At least in terms of the normal practices to mimic rule nesting. I'm not sure if something like compass exists for LESS but it is essentially a command line tool for compiling SASS to plain-jane CSS for deployment. One of the biggest problems I had with this all initially was using JavaScript, which completely sucks and compass eliminates that entirely. Not to mention compass provides a hosts of extra mixins to achieving design goals. I haven't really used many of those, but one the less they are there if you have compass with SASS.

[Stomme poes]

The only reason I even came back to this thread is that I'm working on a Sencha Touch application. Had I not been introduced to Sencha Touch I would probably have never gave this stuff a second thought. None the less, I think there is much to gain from many of concepts in LESS and SASS having now had used them during a real project.

This is a good point... what thing about Sencha Touch made SASS helpful in your work?

[Michael Morris]

See, I would find that confusing in a stylesheet because you aren't saying WHAT you're applying the color to

You aren't that stupid so stop pretending to be. If you truly are that stupid then you fooled the Hell out of me.

(which I still say if you need to use FB/DF on your own code, there's something horrendously wrong with said code)

And yet more trolling. If you don't want to use those tools, fine. Go for it sparky, spend 2 hours figuring out something those tools can make apparent in 2 minutes -- and if you claim that never happens in your code then I say you're lying through your teeth. That or you don't have any experience with javascript files longer than 20 lines.

[deathshadow60]

You aren't that stupid so stop pretending to be. If you truly are that stupid then you fooled the Hell out of me.

Stupid, no... how I percieve things is just different. Remember, I'm the guy who finds color syntax highlighting HARDER to read (I find having the colors all over the place make my eyes refuse to focus on the text), the common use of extra spaces on elements even HARDER to read (I'm not punctuation blind so I try to assume each section spaced apart is a SECTION, not a single statement), and find tabbed editing to be a colossal step BACKWARDS in functionality (especially if the editor doesn't let you drag windows out of the tabs).

And yet more trolling. If you don't want to use those tools, fine.

I do use those tools -- when cleaning up other people's messes... they are great tools for collaboration when the person you're dealing with has little to no common sense much less organizational skills. You know, the type of people who saw nothing wrong with transitional, and are flocking to HTML 5 as if it offers anything USEFUL.

Though this:

That or you don't have any experience with javascript files longer than 20 lines.

Has me scratching my head a bit -- I mean the breakpoint and code tracking tools are useful enough... but I don't really think of Firebug or Dragonfly as tools for working with Javascript... I generally find the error consoles much more informative (Opera user, go figure), I generally have my logic flow worked out before I lay down code.... They're primary use is supposed to be for HTML/CSS debugging... which if you bother to use semantic names on elements, don't try to declare widths the same time as padding/border, don't waste your time declaring widths on EVERYTHING or waste time doing APO on everything and *SHOCK* let flow do it's job... Much less actually practice semantic markup and separation of presentation from content... sectional inheritance to prevent specificity issues...

NOT really sure what purpose either tool would serve when working with my own code.

Go for it sparky, spend 2 hours figuring out something those tools can make apparent in 2 minutes -- and if you claim that never happens in your code then I say you're lying through your teeth.

Generally speaking, I don't see those types of issues -- Though I do often laugh at people struggling to make nonsensical "non-viable for web deployment" crap vomited up by photoshop junkies who know jack about things like accessibility, sustainability, maintainability, or even the concept of hosting costs and practical bandwidth loads.... Probably why most of the time I can take layouts people have "struggled with for weeks" and spit it out in an hour or two... typically in half the markup.

Which I think my posting record here in the CSS area can show in action.

Though it could just be that I've been writing code for three decades -- So I have a little different a viewpoint and get a bit tired of seeing people making the same mistakes and bad choices over and over again.... Stuff we learned our lessons on ages ago but people keep bringing back... either out of ignorance or because somebody that's a "name" in the industry said so.

It's like chiclet keyboards -- they sucked on the Aquarius, they sucked on the Trash 80 Coco, they sucked on the MSX, they sucked on the Sinclair Spectrum, the worst keyboard of all time was the one for the PC Jr.... but slap an Apple logo and a two dollar stamped aluminum shell around it, and it's "trendy" enough for people to ignore that it still sucks. Hell, people will still even pay unicomp scale prices for them when it's unlikely they cost more than five bucks to manufacture.

(and before some "AAH, that's off topic" putz get their panties in a wad... that is a literary device called a "simile")

What's old is new, and that's not always a good thing. You can call it "boot cut", it's still a bell-bottom.

Though to drag myself back on topic, I think a lot of those tools would be a lot less needed if people bothered having code targets -- a limit on how big a page is allowed to be. I still practice 70k ideal / 140k max -- that's HTML + CSS + SCRIPTS + THEME images. (I don't count content images towards that total). If you can't fit a normal website into those limits, you're probably making an annoying, slow crap websites.

To the same end there's the code to content ratio -- how much HTML do you have for the content? If it's more than a 2:1 ratio when you have more than 5k of plaintext, there's probably something disastrously wrong with how the page is written. There's CSS -- if you need more than 48k of CSS there's probably something horrendously wrong/inconsistent/needlessly convoluted with how you applied your style. Then of course there's these idiotic scripting libraries where the library ALONE served COMPRESSED sucks down half my target; where people use a 100k library compressed to 30k to write a 30k script to do what I usually do in 4 to 6k without jquery, mootools or any of the rest of that nonsense. (Or it's animated nonsense that is more annoyance than help when it comes to the page being useful, informative, or would even reach the point of me allowing to load entirely)

See why Mr. "Don't use e-mail clients, use webmail" of the past decade is suddenly switching back to using M2 because of all the annoying, broken, painful to use ajax for nothing BS webmail is being bloated down with... making hotmail, yahoo mail, and gmail effectively useless by comparison. Getting sad when they make Squirrelmail look good. Even more sad when the suits were sold on that scripting as "saving bandwidth" when it in fact typically doubles the traffic load. The joke we used to make about flash applies to 90% of the javascript used on websites these days -- there's a reason it's called "flash" and not "substance".

[omglookitsagoat]

In response to Oddz last post:

Interesting. I'd like to learn more about web design and development. I'll admit you seem to have your reasons and know more about them than I do. You should though since you've been doing it longer than I have.

[Stomme poes]

Off Topic:

It's like chiclet keyboards -- they sucked on the Aquarius, they sucked on the Trash 80 Coco, they sucked on the MSX, they sucked on the Sinclair Spectrum, the worst keyboard of all time was the one for the PC Jr.... but slap an Apple logo and a two dollar stamped aluminum shell around it, and it's "trendy" enough for people to ignore that it still sucks. Hell, people will still even pay unicomp scale prices for them when it's unlikely they cost more than five bucks to manufacture.

oh gawd, I was looking for a new laptop and the only one I could find that didn't have chicklets was the Lenovo Stinkpads... and the only one that would've run Linux was slow and heavy and expensive. (can't run linux on a lot of newer laptops nowadays because they'll have an Intel chip and then an Nvidia graphics card with something called Optimus, which switches between the graphics card and the Intel processor for more power savings etc... Does. Not. Work. In. Non-Windows. Arg. You're either stuck with just the basic Intel if it's changeable in the BIOS, or you get no graphics whatsoever. Nvidia has zero plans to remedy this.)

[TechnoBear]

Even more off topic:

(1) I didn't know that about Linux and laptops - thanks for the warning.

(2) What on earth is a chicklet keyboard?

[xhtmlcoder]

It's the Poes's meow version of a chiclet http://en.wikipedia.org/wiki/Chiclet_keyboard the cat's paws like breaking them and stuff so she needs a rugged keyboard.

[deathshadow60]

Off Topic:

Even more off topic:
(2) What on earth is a chicklet keyboard?

Click for Larger

Chiclet is the one on top... it refers to the keys looking like the candy... Top is from an original Coco, bottom is from a Coco 2.

http://www.digibarn.com/collections/...rd/Image09.jpg
That's the PC Jr. one, usually comes up as the worst piece of computer hardware ever developed.

... and it is a good comparison in terms of things that we should know better by now, but always comes back because it's cheaper to make. See why most of the public suffers by on what were once called "melted" keys (what today is a 'low profile' or laptop style keyboard) or rubber domes. You see the same thing with HTML/CSS/Scripting and web development as a whole -- the same stuff we learned pre-dotcom bust being repeated by people either too young to know it or with too short term a memory to recognize it...

See "advertising can pay for everything", "popups don't annoy users" and "who cares about accessibility". What's next? "Does it work in IE, who cares about the rest"

Oh wait, we have that last one with FF/Chrome instead of IE.... IE? Who still uses that? Opera, what's Opera?!? -- which is when the "percenters" come out of the woodwork not realizing that saying "oh this group is only xxx% and this group is only xxx% and this group is only xxx%" until there's no percent of audience left.

Off Topic:


Oh, and @sp, I'd kill for a laptop with full travel cherry switches or even better, buckling springs. Someday I'm gonna build my own laptop starting with a Model M and just bolting crap onto it.