simple loop, is it possible?

[ogorzalka]

Hello,

is there a way to create loops?

Exemple of usage :

  @mixin(@intensity: 1) {
      text-shadow:
          for(@i:0, @i <= @intensity, @i++) {
               @i @i 0px #000,
          }
      ;
   }

Thanks for your answer ;)

[cloudhead]

No loops, sorry. I'm trying to keep this language declarative, and don't want it to turn into a programming language. I usually run my .less files through a template engine to set dev/production url paths, nothing's stopping you from say, running it through EJS to do some code-gen. cheers.

[jslegers]

No loops, sorry. I'm trying to keep this language declarative, and don't want it to turn into a programming language.

I hope you've realized now that that particular decision is the main reason everyone has moved or is moving from Less to Sass.

Well, that and Bootstraps moving to Sass. However, the latter is clearly the consequence of the former.

Sass sure has its own issues, but nothing fundamental as the lack of basic control structures like an IF-ELSE statement or FOR-loop.

People want their CSS preprocessor language to behave like a programming language. And if they don't find that in Less, they move on to whichever language does provide this behavior... which usually means Sass!

[seven-phases-max]

@jslegers Wake up. This is 2011 thread. See the documentation and plugins.

[jslegers]

I'm aware of guarded mixins as an alternative to IF-statements and recursive mixins as an alternative to loops in Less. But that's all I've been able to find in the docs about control structures in Less. And those just won't do it for me.

Anyway, I responded in greater detail @ #1293 (comment)

[seven-phases-max]

But that's all I've been able to find in the docs about control structures in Less.

Try harder.

[jslegers]

Try harder.

If people can't find in the documentation what they're looking for, that means that there's something wrong with the documentation.

A basic principle in economics is that the customer (in this case the user) is always right in contexts like these.

[matthew-dean]

A basic principle in economics is that the customer (in this case the user) is always right in contexts like these.

@jslegers If the customer starts by reviving a dead thread and throwing shade at contributors to an open-source language, and also isn't paying any of those people, theeeeen no.

People want their CSS preprocessor language to behave like a programming language. And if they don't find that in Less, they move on to whichever language does provide this behavior... which usually means Sass!

If you like Sass, use Sass. You don't have any contractual obligation here. Some people like imperative structures, some people like declarative structures. Less is a superset of CSS, which is declarative, and thus made the decision to be declarative. Sass made the decision to be a programming language. You actually have a choice here, based on your own personal preferences. And there are many choices beyond that. The opinions as you've shared them are not helpful whatsoever. No one owes you their time, but it's been graciously given. Please learn from this and do better.

[jslegers]

If the customer starts by reviving a dead thread and throwing shade at contributors to an open-source language, and also isn't paying any of those people, theeeeen no.

You call it "throwing shade". I call it "constructive criticism".

Either way, if you care about people using your project you need to listen to their needs... whether they're paying customers or not. If you don't care about people using your project, than I guess it doesn't matter. But in that case, why bother releasing it as an open source project in the first place?

If you like Sass, use Sass.

I wouldn't exactly say that I like Sass. As I said previously, it comes with its own issues.

I guess I could say Sass is the "lesser evil" among CSS preprocessing languages.

You don't have any contractual obligation here.

Sure... but every now and then I look around to see if there's a processor around that is better than Sass, because I'm tired of waiting until they finally provide features like dynamic dependencies. But whenever I do that, I'm reminded of how much worse Less is...

Less is a superset of CSS, which is declarative, and thus made the decision to be declarative.

I guess I somewhat understand where you're coming from. However, anyone trying to so something even remotely complex with Less soon found out that Less simply is ill-suited for anything beyond very basic stuff.

Or to quote @hugogiraudel :
"The point of CSS preprocessors is to easy the CSS development, not to make it harder. So this is the moment I realized LESS wasn’t that good."

You actually have a choice here, based on your own personal preferences. And there are many choices beyond that.

Choices are rather limited between Sass, Less and Stylus. That, and writing my own preprocessor language.
That's not a lot of choice, really...

The opinions as you've shared them are not helpful whatsoever.

As I said, I'm just trying to offer constructive criticism. Sure, they're driven by frustration, which I guess comes off as "throwing shade". But make no mistake : I'm really, really trying to be constructive and helpful here.

No one owes you their time, but it's been graciously given. Please learn from this and do better.

I'm just trying to share my experience with preprocessor languages in the most constructive manner I can think of.

Anyway, I always listen to what my users want, whether they're paying customers of my employer's or people who use one of my open source projects for free. I consider that the most basic courtesy. If you don't believe in that, that's fine. For me, that's just one more reason not to consider using Less.

[seven-phases-max]

"constructive criticism".

Is it? To be constructive you should at least stop reading and quoting an ancient blog-post and become a bit more concrete.
So for instance getting back to the subject. What exactly "won't do it for you" in recursive mixin loops? (Counting it's just the same thing except being just-one-line more verbose... And not counting that if you can't stand a non-C-like syntax even in HTML you were able to use various loop-helping mixin mini-libs (since 2014) and plugins (since 2017)).

Arguing with a 5 years old misinformation (yet again mostly based on personal preferences and poor language knowledge even in its 2012 state) would be a waste of time.
In contrast, when it comes to concrete use-cases (here or at the SO), personally I almost always suggest a proper Less-style pattern or snippet or at least a workaround (and quite often it's actually a more compact and/or more generic implementation if compared to initially asked blind-another-language-copy-paste conversion.. There're a few examples in #1293 already but there're tens more spread all over the issue tracker and SO).

[jslegers]

So for instance getting back to the subject. What exactly "won't do it for you" in recursive mixin loops?

My main issue with recursive mixins - and Less in general - is the syntax!

With SCSS, I can just do this :

@for $index from 10 through 1 {
  .my-element:nth-child(#{$index}) {
    animation-name: "loading-#{$index}";
  }
}

The Less equivalent of this same code would be something like this :

#myResursiveMixin(@index) when (@index > 0) {
  .my-element:nth-child(@{index}) {
    animation-name: "loading-@{index}";
  }
  #myResursiveMixin(@index - 1);
}

#myResursiveMixin(10);

This means I would need one mixin declarations and two mixin calls in Less to emulate the behavior of what I can do with a basic for-loop in Sass. That's just... wrong.

Well, it may be just good enough if you're only using Less to create a basic homepage, but if you're creating a CSS framework that's supposed to be configurable and modular, this kind of coding style becomes very messy very very fast!

It also doesn't help that mixin calls and declarations look a lot like class selectors or ID selectors.

And not counting that if you can't stand a non-C-like syntax even in HTML you were able to use various loop-helping mixin mini-libs (since 2014) and plugins (since 2017)).

Having to extend a language with libraries or plugins for something as basic as loops is a good reason to avoid that language IMO.

Arguing with a 5 years old misinformation would be a waste of time.

I'm not basing anything on 5 years old "misinformation".

In contrast, when it comes to concrete use-cases (here or at the SO), personally I almost always suggest a proper Less-style pattern or snippet or at least a workaround (and quite often it's actually a more compact and/or more generic implementation if compared to initially asked blind-another-language-copy-paste conversion.

My concrete use case is refactoring an existing CSS framework that is currently written in plain CSS.
I'm looking for a preprocessor language that's easy to read and easy to write, and which allows me to easily add, remove and configure components with on as little as possible configuration.
Sass is lacking a few language features (like dynamic mixins) to do everything I had in mind, which is why I'm looking for an alternative. But then I look at what Less has to offer, and Sass doesn't seem so bad anymore.

[seven-phases-max]

You really should consider putting more efforts into reading and searching instead of writing these global useless slogans. You're knocking into open door. And no, you don't make me post a direct links to things I already mentioned above.

[jslegers]

You really should consider putting more efforts into reading and searching instead of writing these global useless slogans.

You really should consider putting more efforts into documenting your language instead of telling people they're using it wrong without helping them any further.

[seven-phases-max]

into documenting your language

It is as my (or ours) as yours. Simple misunderstanding of how these things (i.e. opensource development) work seems to be your very problem (though you've been already told that - so I'll stop right here).

[jslegers]

Simple misunderstanding of how these things work seems to be your very problem

If users still don't understand how your language works after both going through the documentation and interacting with you, blaming those users is never an acceptable response.

It probably means either that there's something wrong with your API, with your documentation or both.

[aminland]

Wow dude. Instead of arguing, did you ever think to look up who you're arguing with? Maybe checkout their github account, to see a plethora of plugins / helpers that let you do exactly what you're insisting is not possible with less?
So rude...

https://github.com/seven-phases-max/less-plugin-lists

[matthew-dean]

@jslegers

So my dude... there's been plenty of discussion in other threads and PRs about possible ways to do control structures in Less that makes sense in the syntax. You're arguing with people who do not necessarily disagree with your positions; you're just kinda being a bit unkind about it. If you hadn't started with snark and been combative, you might have discovered that there's been recognition of both the annoyances of the verbosity of recursive mixins, and some desire to address that with some simpler syntax solutions.

A lot of discussion was here: #2270

That thread was auto-closed due to lack of activity, but I re-opened it because it's a good thread, and if there's a solution that makes sense for people, I'm sure that could go somewhere. Feel free to contribute, and if there's consensus and something is ready to implement, feel free to make a PR.

[matthew-dean]

I also made a PR for an each() function here, but closed it due to lack of consensus: #2786

As well, like @aminland mentioned, @seven-phases-max has done quite a lot of work with list plugins for Less.