I saw many answers but one thing is common to all of them - No one actually use LESS so I think that this fact pretty much tells enough about it.
That doesn’t really tell anything about it. Three could be many reasons for that. For me it is because it is new and so I haven’t gotten a chance to try it. I plan to try it out on my next project.
I’ve been waiting on a PHP implementation myself. My impression of it is that it is a very flexible tool - as such it can be easy to misuse. The criticisms I’ve seen in the thread seem to me to be about that misuse - not about what less can or cannot do itself.
In and of itself it encourages DRY markup. CSS is very, very repetitive - and the moment someone says you can change something with “search & replace” I just…
I’ll flat out state that if you think copypasta code and having to use the search/replace tool is a good thing you’re a moron. Doesn’t matter if you’re dealing with HTML/CSS/PHP/JS/C or whatever, you’re a moron if you resort to those tools - a moron that is only and will only ever be capable of “fire and forget” projects that aren’t maintained over time.
Well, this moron has quite a few websites with many years on their back. The oldest one is about ten years old. Not sure that counts as a fire and forget project.
I’d be interested in knowing why search-replacing one colour for another is apparently so very, very bad, while installing a framework to do the exact same thing for you is not.
Less isn’t a framework. It’s a an extension to CSS to allow for more programmatic behavior with the stated goal of reducing repetition. I’ve not looked at any frameworks based on it - and the horror stories of them I’ve seen in this thread dissuade me from taking a look. But that is a seperate issue from less.
From what I can see, it’s an advanced CSS generator, retaining some CSS syntax, rather than an extension of CSS itself.
See post 34
You then said "Yes, well, but you can prepend it with stuff like /* main home color /".
Sure, you could, but what if someone types /* home main color **/ , or too many spaces, or mian instead of main, or, or, or …
Point is, search replace the way you do it is not semantic, the search/replace can only look for raw text without having any clue what it’s actually looking at, and you can never be 100% guaranteed that the end effect will actually be what you wanted it to be.
Whereas with LESS, when you change the value of the variable all instances of that variable will be replaced, so you can be 100% sure it hits everything you want to hit, and nothing else.
It’s completely different from search/replace in any way.
Of course it’s different. I just don’t see why it’s bad. And surely, a misspelled comment is just as likely as a misspelled variable?
If after ten years you don’t see it I hardly see how anything on a message board, from pithy comment up to enlightened thorough example, will help.
On the contrary: If you can show me a good reason to use LESS, I’ll be more than happy to give it another look. I just haven’t seen anything thus far that compels me to reconsider. The variable functionality is nifty, but I really don’t believe it would save me significant amounts of time, if any at all. Besides, if I really wanted to be able to use variables in my CSS, it wouldn’t take me long to write a PHP script allowing me to do just that. I don’t use vendor-specific CSS, mainly for idealistic reasons, so this is certainly not a selling point for me.
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.
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};
}
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: progid:DXImageT… causes an output error (at least in the JS version it does). I use the PHP lesscss parser.
Cheers.
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.
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.
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.
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.
… 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.
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.
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)
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 