each() loop w/ & behaves funny

[calvinjuarez]

Given the following, I would expect both loops to render similar output. However, the version where the each() is inside the block and & is used produces strange results. Specifically, the styles immediately under the & are rendered at the top of the loop's generated output. Oddly, a child of the & block is rendered in the expected spot.

Given

@infixes: a, b;

/*! LOOP IN BLOCK */
.amp {
  each(@infixes, #(@_infix, @i) {
    // Each infix actually generates the _next_ infix's block, with the last
    // one generating styles with no infix.
    @infix: e(if(
      ((@i + 1) <= length(@infixes)),
        %('-%s', extract(@infixes, (@i + 1))),
        ''
    ));

    &@{infix} {
      display: block;
      .child {
        display: block;
      }
    }
  });
}

/*! BLOCK IN LOOP */
each(@infixes, #(@_infix, @i) {
    // Each infix actually generates the _next_ infix's block, with the last
    // one generating styles with no infix.
  @infix: e(if(
    ((@i + 1) <= length(@infixes)),
      %('-%s', extract(@infixes, (@i + 1))),
      ''
  ));

  .plain@{infix} {
    display: block;
    .child {
      display: block;
    }
  }
});

Expected

/*! LOOP IN BLOCK */
.amp-b {
  display: block;
}
.amp-b .child {
  display: block;
}
.amp {
  display: block;
}
.amp .child {
  display: block;
}
/*! BLOCK IN LOOP */
.plain-b {
  display: block;
}
.plain-b .child {
  display: block;
}
.plain {
  display: block;
}
.plain .child {
  display: block;
}

Actual

/*! LOOP IN BLOCK */
.amp {
  display: block;
}
.amp-b {
  display: block;
}
.amp-b .child {
  display: block;
}
.amp .child {
  display: block;
}
/*! BLOCK IN LOOP */
.plain-b {
  display: block;
}
.plain-b .child {
  display: block;
}
.plain {
  display: block;
}
.plain .child {
  display: block;
}

Note that .amp is floated to the top.

[calvinjuarez]

Detached rulesets also behave unexpectedly.

@infixes: a, b;

/*! DETACHED RULESET */
.dr {
  each(@infixes, #(@_infix, @i) {
    @infix: e(if(
      ((@i + 1) <= length(@infixes)),
        %('-%s', extract(@infixes, (@i + 1))),
        ''
    ));
    
    @content();
  });
}

@content: {
  &@{infix} {
    display: block;
    .child { display: block; }
  }
};

/*! DETACHED RULESET */
.dr {
  display: block;
}
.dr-b {
  display: block;
}
.dr-b .child {
  display: block;
}
.dr .child {
  display: block;
}

[matthew-dean]

Thanks @calvinjuarez. Do you think you could boil that down to the simplest example that demonstrates the bug? Or are %(), extract(), e() and length() essential to trigger the issue? Right now the example is hard to follow, as to what is doing what.

[calvinjuarez]

@matthew-dean all those functions are just to say, "whatever the current item is, use the next one, unless this is the last one, in which case, use ''". It's important to loop that way to see the bug. Otherwise, the bug is invisible because the un-infixed version is supposed to be at the top. Does that make sense?

So in the loop, when a is the current value, it uses the next value, -b as the actual infix. When b is the current value, since it's the last value, the infix is an empty string (escaped).

So, to answer the question, no, they're not essential to trigger it (I expect it happens always), they're just a way of looping in the wonky way that exposes the issue.

I ran into the issue while fixing the output order in seanCodes/bootstrap-less-port, where the same behavior is accomplished with breakpoint-next() and breakpoint-infix() functions, but the result is the same.

I'll see if there's a less obtuse test case that produces a similar error.

[calvinjuarez]

Here's something a tiny bit more concise, and hopefully easier to read. The key is that, in the CSS, when @infix is an empty value, that output is above output when @infix is a non-empty value, even when the empty value should come afterward. This doesn't happen when the class is inside the loop.

It looks like it has something to do with how & works when the selector ends up matching its parent.

@infixes: a, b;

/*! LOOP IN BLOCK */
.amp {
  each(@infixes, #(@val, @i) {
    @is-last: boolean((@i = length(@infixes)));
    @infix: if(@is-last, ~'', ~'-@{val}');

    &@{infix} { -less-original-value: @val; }
  });
}

/*! LOOP IN BLOCK – CONTROL */
.control {
  each(@infixes, #(@val, @i) {
    @is-last: boolean((@i = length(@infixes)));
    @infix: if(@is-last, ~'-', ~'-@{val}');
    // ^ identical to previous except @infix is non-empty, even when @is-last is true

    &@{infix} { -less-original-value: @val; }
  });
}

/*! LOOP IN BLOCK */
.amp {
  -less-original-value: b;
}
.amp-a {
  -less-original-value: a;
}
/*! LOOP IN BLOCK – CONTROL */
.control-a {
  -less-original-value: a;
}
.control- {
  -less-original-value: b;
}

[calvinjuarez]

I'm getting the feeling this is expected behavior out of &, actually. Consider:

.control-2 {
  each(@infixes, #(@val, @i) {
    @infix: ~''; // @infix is always empty

    &@{infix} { -less-original-value: @val; }
  });
}

.control-2 {
  -less-original-value: a;
  -less-original-value: b;
}

That's probably expected. This looks like it'd be a hairy one to sort out...unless we're okay making this output as 2 rules with the same selector. :/

[seven-phases-max]

At quick glance I suppose .amp is floated to the top because it is at the top. E.g. consider:

.amp {
    /* 0 */
    a {/* 1 */}
    & {/* 2 */}
    b {/* 3 */}
}

this should result in:

.amp {
    /* 0 */
    /* 2 */
}

.amp a {/* 1 */}
.amp b {/* 3 */}

And the same order is expected if you remove /* 0 */.
I.e. it's two instances of .amp that simply collapse into the first of them (the surrounding "block" itself) which is always there and always at the top even if empty (like in the initial example).

[matthew-dean]

Yeah, I never really thought about placement order of nested blocks. But it definitely seems like Less doesn't try to keep things in order. To expand on @seven-phases-max's example:

.amp {
  is: one;
  .a { is: two }
  & { is: three }
  .b { is: four }
  is: five;
}

Outputs:

.amp {
  is: one;
  is: three;
  is: five;
}
.amp .a {
  is: two;
}
.amp .b {
  is: four;
}

Sass's output is slightly different, opting to keep nested selectors in order, even if one is just &

.amp {
  is: one;
  is: five;
}
.amp .a {
  is: two;
}
.amp {
  is: three;
}
.amp .b {
  is: four;
}

Oddly, Sass doesn't treat the is: five declaration as coming "after" the other nested declarations. But I guess that does allow you to "force" subsequent declarations to come in a certain order by wrapping them in &{}.

So, if you're migrating Bootstrap and comparing output, you're likely seeing that Less collapses & as being part of the parent ruleset, and Sass treats it as a new selector and generates a sequence of rules to follow the parent.

The each() function doesn't do anything special in terms of rulesets. It basically generates a sequence of anonymous rulesets (injecting @value, @key etc variables at the top of each one) which then get evaluated.

As far as which behavior makes more sense? 🤷‍♂️ I really don't know how to answer that. They're just different. I think the rationale in Less's behavior is to create fewer selectors. But Sass's rationale is probably to keep nested selector order intact, but it probably comes down to the merging algorithms are just different.

Now, I were to put my CSS hat on, and thinking about things like the @nest proposal, probably BOTH Less and Sass have this wrong (with Sass maybe being "more" wrong, because it places three as the "final" value in the .amp class?). What the output probably SHOULD be to reflect the way it was written is this:

.amp {
  is: one;
}
.amp .a {
  is: two;
}
.amp {
  is: three;
}
.amp .b {
  is: four;
}
.amp {
  is: five;
}

That is, declarations should maintain their order in the stylesheet, if they're broken up by other nested selectors. If nesting were ever added to CSS natively, that's likely what it would mean. It's more verbose, but it seems more accurate.

[calvinjuarez]

Yeah, I think we're all seeing eye-to-eye. What we've got is reliable and expected in nearly all cases (the examples shared in the previous 2 comments, for instance). You kind of have to work to find how to "break" it. Even in those situations, though, the workaround doesn't suck, since each() can run at the root level without anything in the way, so it's probably usually gonna be easy to write out the need for the "naked" & entirely.

Given all that, I'm closing this for now (won't fix, intended behavior). If we really wanted to allow forcing output the way sass does, it would need to be a new feature, and it'd need a SUPER compelling use case.

And for posterity:

Workaround

Refactor so that & doesn't appear alone (even conditionally) at the root of the loop's iterator mixin.

.amp {
  each(a b, #(@val, @i) {
    @is-last: boolean((@i = length(@infixes)));
    @infix: if(@is-last, ~'', ~'-@{val}');

    &@{infix} {
      -less-original-value: @val;
    }
  });
}

BECOMES

each(a b, #(@val, @i) {
  @is-last: boolean((@i = length(@infixes)));
  @infix: if(@is-last, ~'', ~'-@{val}');

  .amp@{infix} {
    -less-original-value: @val;
  }
});

[matthew-dean]

@calvinjuarez Btw, you can simplify your code slightly like this:

@infixes: a b;
each(@infixes, #(@val, @i) {
  @is-last: boolean(@i = length(@infixes));
  @infix: if(not(@is-last), ~'-@{val}');

  .amp@{infix} {
    -less-original-value: @val;
  }
});

That is, boolean and if no longer require outer parens around first argument (as of 3.6...?), and an if() statement doesn't necessarily need an else condition.

[calvinjuarez]

Interesting. I tried dropping the parens, but it didn't compile for me at the time. I'll double-check. The bootstrap-less-port handles that logic with plugin functions (to be more familiar to folks coming from the Sass stuff), but I'll have to keep that in mind in case we decide to go native-er with it at some point.