guards on css styles

[jfojtl]

I'd like to use guards on concrete CSS like this:

.rule when (@width < 400px) {
  color: red;
}

When @width variable is greater then 400px, the .rule would be hidden in generated CSS. Nowadays I need to do something like:

.rule (@w) when (@w < 400px) {
  color: red;
}

.rule {
  .rule(@width);
}

[souldreamer]

👍

[lukeapage]

Could you explain? Isn't this possible? Or you want @width derived from the element(don't see how this is possible). Could you include a compilable example?

[lukeapage]

Sorry, I understand now. +1 from me.

[matthew-dean]

Since classes get interpreted as mixins anyway, this seems like an obvious win. +1

[matthew-dean]

Note that I've proposed extending this syntax to property / value and inline mixin declarations in #1293.

[lukeapage]

I'm not sure about the additions.. I think we should have 2 bugs and do
them separately. The basics (guards on normal css blocks) is imo more
important and more straight forward extension and syntactic sugar.

[matthew-dean]

Makes sense.

[lukeapage]

Lots of fun on this one

1. If you mixin the styles but it has a guard, does it stop the styles
   being mixed in if the condition evaluates false - I say yes, so it acts
   just like a mixin with a guard, except it is present by default
2. In the case above, is the condition evaluated purely in the context of
   its declaration - I say yes
3. If you extend a guarded class that fails condition, do we output
   extended version or not? I say not
4. Is the guard on the selector or ruleset? If selector you can have 2
   different guards on a block, controlling selector output. I say selector.

Have made good progress on implementing, need another couple of hours.

[extemporalgenome]

@lukeapage can you explain #4 in greater detail (regarding the selector vs ruleset guard distinction)?

[lukeapage]

my unit tests have (something like) this in at the moment...

.light when (lightness(@a) > 50%),
.dark when (lightness(@a) < 50%) {
    color: black;
}
@a: #444;
.i-see {
    .light;
    .dark;
}

extend is per selector because we decided it was unintuitive that it covered all of the selectors.. I think when should be the same.

p.s. probably need a better test since color: black will be removed if output twice but the idea is you would get

.dark {
    color: black;
}
.i-see {
    color: black;
}

[matthew-dean]

Ah, thanks for the example. If I understand correctly, then I'm in agreement with everything you've outlined.

[extemporalgenome]

@lukeapage thanks for the update, though I'm still not clear on the distinction. What would be the output if the guard were on the ruleset instead? And is @a an implicit argument to the selector when mixed into .i-see based on its scope, or is @a always loaded from the scope of the mixin's declaration (I believe you specified that it should be place-of-declaration). In other words, what would happen if everything else where the same, but .i-see were defined as:

.i-see {
    @a: #7f7f7f; // trick question, lightness should be exactly 50%
    .light;
    .dark;
}