Conditional CSS Code

[valllabh]

How about having something like conditional css code depending upon variable

@has_theme_support: true;

.awesome-class {
    width: 100px;
    height: 200px;
    margin: 0 auto;

    /* Adds theme support if @has_theme_support is 'true'; */
    if( @has_theme_support ){
        background: green;
        color: yellow;
    }
}

[lukeapage]

go to http://www.lesscss.org/ and search for guards.

to avoid having to use mixins, looks at the feature request to allow guards on any css.

[valllabh]

Yes I know that but if we are writing huge LESS we have to write and manage hundreds of .mixins
I don't think mixin solves this issue. Even mixins will get lot of power with this feature.
Less CSS almost have all the feature that some programming language has then why not this ?

.button-maker (@style: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(@style == 'light'){
        /* adds light styling */
    }

    if(@style == 'dark'){
        /* adds dark styling */
    }
}

[pierreis]

I would add a big +1 for this feature I'm really missing. Maintaining guards with a big codebase really is a nightmare. This would really make things a lot easier...

[valllabh]

We can even add switch statement..

[valllabh]

@lukeapage can you please reopen this issue. I think we should discuss this issue/feature

[matthew-dean]

LESS is not a scripting language. The syntax / style resembles CSS.

[Soviut]

LESS is meant to be declarative, meaning it shouldn't be capable complex situations with branching logic, loops, etc.

@pierresforge do you have any examples where guards are insufficient?

[lukeapage]

and where it wouldn't be solved by being able to have guards on any selector?

[lukeapage]

the discussion is open.. if you can persuade me (or another member of the core team) they are necessary then I'll re-open the issue.. but the conversation has been had before and alot of time has been spent on it.

[valllabh]

The sentence from http://lesscss.org/
"LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions."

Yes LESS is not scripting language, but still it has features like variables, functions & operations.
What missing is conditional logic.

I think CSS Media Query is nothing but the conditional logic.

@media all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

If CSS can have conditional logic like guards. so what is the difference. Guards just extending it to mixins.
Guards only allows conditions outside CSS code block and not inside code block.
Please see #1293 (comment) for an instance, guards cant help with such requirement..

Even HTML has conditional logic, yes and its a markup language not scripting language.

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapage thanks..

[Soviut]

Guards are analogous to what media queries do. Notice that in ordinary CSS you can't nest media queries inside selectors; You can only put them at the root of the document.

[pierreis]

Nope, I don't have any example where guards are not sufficient. However, there is plenty where guards are not really best for maintenability.

An example:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(@coreBackgroundColor, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(@coreBackgroundColor, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(@coreBackgroundColor, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

is in my sense more concise and self-explanatory (mostly in the cases where there's no point in making the code re-usable, as the algorithm depends on a lot of factors) than:

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(@coreBackgroundColor, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(@coreBackgroundColor, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(@coreBackgroundColor, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

I agree this is subject to discussion, but this would be a pretty nice addition, if it does not involve a lot of core changes. It allows to wrap together most of the rules to apply to a single element without requiring the addition of mixins.

[Synchro]

This kind of situation is why I wrote the contrast function - it acts as a kind of conditional operation that isn't otherwise available, and it's much neater than using guards, as you say. I guess we could implement some kind of generic function that acts as a kind of selector, rather than going as far as adding syntax for conditions.

[matthew-dean]

@Soviut Devil's advocate - In LESS, you CAN actually place your media query inside of a selector, which is often quite useful.

I've been against ifs, because it starts to make the complexity of your code raise exponentially, and LESS is designed to be simple and straightforward. At this moment in time, there's some push to stabilize the language over adding new features.

However.... devil's advocate again, based on the logic that media queries now appear within selectors, guards could theoretically follow the same principle.

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  @when (green(@coreBackgroundColor) > 50%) {
    background-color: darken(@coreBackgroundColor, 20%);
  }
  @when (red(@coreBackgroundColor) > 30%) {
    background-color: darken(@coreBackgroundColor, 15%);
  }
  @when (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(@coreBackgroundColor, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(@coreBackgroundColor, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(@coreBackgroundColor, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(@coreBackgroundColor, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

More declarative than ifs, closer syntax to existing LESS, and evaluates each statement independently (like LESS / CSS is defined).

Alternatively (or in addition to), similarly, attaching the evaluation of a mixin to the point of evaluation:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(@coreBackgroundColor, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(@coreBackgroundColor, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(@coreBackgroundColor, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

Arguably, statement-level guards are no more/less complex or different logic than mixin-level guards IMO. Probably examples 2 and 3 are less expansive to the language. Just thought I'd throw that in there for thought / discussion.