Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

no support for break or continue in loops #378

heygrady opened this Issue May 4, 2012 · 26 comments


None yet

heygrady commented May 4, 2012

I might be missing something but I was surprised yesterday when I couldn't find an documentation and experiments failed for using @continue or @break inside of a for, each or while loop.


@for $i from 1 through 10 {
  // skip even numbers
  @if ($i % 2 == 0) {

  // on odd numbers, do something
  // ...

$list: rgba(#000, 0.5) 3px 3px 2px #F00 ;
$color: inherit;

// find the first color in the list
@each $value in $list {
  @if (type-of($value) == color) {
    $color: $value;
@debug $color; // outputs red



nex3 commented May 5, 2012

Sass is not a full-fledged programming language, so it doesn't support all aspects of all control structures. You can work around this using @if if you need to.

@nex3 nex3 closed this May 5, 2012

@nex3 While it is understood Sass isn't a "full-fledged programming language", and that it is targeted at both developers and designers alike, control structures/directives such as @break and @continue would alleviate the need for deeply nested @if blocks. Furthermore, it is understood that this adds complexity, for both the developers (you folks) and consumers (me folks) of the language, but no matter how you slice it, Sass has become a programming language (full-fledged or not). The programming-savvy will reap the benefits from such features, and the rest won't be hindered in any way.

+1 — even if SASS is not a full language, those a relatively basics and required when loops are involved.


nex3 commented Feb 2, 2013

I'm still pretty skeptical of this. The issue is that the more seldom-used control structures exist in Sass, the harder it is for something with only passing familiarity with the language to read stylesheets that use those control structures. That's why it started out with the bare minimum set of structures needed to do anything: because in many cases it makes sense to skew towards a smaller surface area of the language rather than optimal semantics for writing complex code.

@chriseppstein, what do you think about this proposal?

In my opinion, as Sass evolves, people tend to build larger frameworks upon it. It's a natural progression.
If you're offering "lists" and loops, then continue and break would be great additions to that.


If you're going to offer loops, then there should be @break and @continue directives. Otherwise all that happens is people are forced to write bloated code to work around this lack. Surely clarity is the most important thing. It's pretty clear than people aren't going to stop writing complex loops because there is no @break or @continue directive so why not make things easier for them to write and clearer for everyone else to read.


chriseppstein commented Sep 11, 2014

I think @break makes sense as it can be used to avoid a lot of work. Continue just doesn't provide enough value over @if.

@chriseppstein chriseppstein reopened this Sep 11, 2014

lolmaus commented Sep 11, 2014

Please provide @continue too.

It lets reduce nesting. Compare:

@each $item in $items {
  @if length($item > 2) { @continue; }

  .foo-#{$item} {
    bar: baz;
@each $item in $items {
  @if length($item <= 2) {
    .foo-#{$item} {
      bar: baz;

When code gets long, it becomes difficult to track the context. Our JS guideline explicitly tells to use the first way.


nex3 commented Sep 12, 2014

I think if we provide @break we should provide @continue as well.

IEfucker commented Jan 7, 2015

@function getAnimationTime($arrayTime, $index){
$index: if(($index <= 0), 1, $index);
@each $elAniTime in $arrayTime {
//no break, continue or index of loop is supported, bad luck

$animationTime: $this_duration $this_delay;
@return $animationTime;

break, continue, even index of loop is great.

I’m just going to revive this thread and say +1

+1 also - developers will never "not use" break/continue/etc. just because it's not available - we will find hacky, inefficient ways to implement it. I'd rather stay away from hacky.

donatj commented May 5, 2015


Very needed!


nex3 commented Nov 6, 2015

I'm willing to bend on this.

@nex3 nex3 added Planned and removed Under Consideration labels Nov 6, 2015

@nex3 nex3 removed their assignment Nov 6, 2015

👍 Yay!


ghost commented Jan 7, 2016

Nice! +1, very useful.

@chriseppstein chriseppstein added this to the 4.0 milestone Jan 7, 2016

So did this just not happen in the end? lol.

screen shot 2016-04-22 at 13 26 33

@entozoon I think that pretty much summarizes it :).

@kevin-smets And sass in general.. :( lol


chriseppstein commented Apr 22, 2016

@entozoon @kevin-smets

Hi, thanks for your very constructive comments. Please allow me to let you know what we've been up to lately since you are probably unaware of our current priorities and roadmap.

For the last year, Sass has been under a "feature freeze" while we've been helping libSass reach feature parity. During that time, we've been releasing regular bug patch releases and non-breaking CSS compatibility enhancements. We are currently gearing up to release Sass 3.5 which has a number of new features specifically to support changes in CSS which required us to issue deprecation warnings because of how the feature needs to be supported.

Since we are now doing simultaneous development and releases of two implementations (ruby & C++) we have a common test suite called sass-spec which is where tests cases are shared to ensure that a common language standard is used by everyone no matter which compiler implementation they use. We have also been spec'ing out new features for 4.0 in a more formal way so that the libSass core team can understand the features and the algorithms used without having to reverse engineer them from our code. For the last three weeks, I've been working every day to improve this test suite and make it integrated into ruby sass's tests and make sure the tests can be ran correctly while doing parallel development of no less than three active branches of development (stable, 3.x and 4.x).

This feature, is not actually very hard to add, but since it has work arounds it's also not super high on our list of priorities with limited development resources.

Please let me know what resources and/or documentation you need but could not find when you tried to implement this feature (which I'm sure you must have tried and failed at before coming here to complain that our team of volunteers hasn't had time to implement yet).

Given such a verbose reply I feel I ought to apologise.
That said, I did actually look through the source to try and implement it myself but having limited ruby skills I couldn't manage it.
And moreover, it is a user's prerogative to request features and complain without the ability to implement it themselves.
Perhaps not enjoyable for yourself to read, but fair. That's the nature of feedback.


chriseppstein commented Apr 25, 2016

That's the nature of feedback.

There is constructive feedback and then there's what you did. This is my feedback to you. If you want us to actually care about your feedback, don't be a jerk as you deliver it.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment