Allow guards to work with undefined variables

[ESchuderer]

.guard () when (@variable) {
  a {
    color: red;
  }
}

Variable isn't defined, therefore no output.

@variable: true;

.guard () when (@variable) {
  a {
    color: red;
  }
}

Variable is definied, therefore output:

a {
  color: red;
}

[hubertgrzeskowiak]

+1
This could also be used to set base colors on libraries.
Imagine the following case:
You have a less file for a specific app, e.g. a website's main menu.
You import this less file in the main less file, where your base colors are defined as variables.
Now if you use those base colors in the main menu's less file, they depend on the main file.
If you could check the variables for existence, you could fall back to module-defined colors.
Here's an example of how i imagine the menu less file:

@menu-base-color: white;
@menu-base-color: @base-color when (@base-color);
...or...
@menu-base-color: @base-color when isset(@base-color);

[jlukic]

+1, we already have istext, isnumber having isdefined and isundefined will help greatly in theming with less.

I.e. use value or userValue if isdefined

I'm running into this issue a lot when trying to set up theming conventions for Semantic UI with LESS.

[SirRawlins]

+1 on this - would be really great.

[micchickenburger]

+1 on this for me too

[seven-phases-max]

Not a big deal to add is-defined function (I expect it to appear in one of the first plugins as soon as v2 is released). Though to be honest the sad thing is that those who want this feature really miss the fact that both use-cases above are solvable (in many cases even with more compact code) w/o any feature like that.

@initart's use-case:

// library.less
@variable: false;

a when (@variable) {
    color: red;
}

// ......................................
// user.less
@import "library.less"
@variable: true;

@Nemesis13's use-case:

// library.less
@base-color: green;
@menu-base-color: @base-color;

.menu {
    background-color: @menu-base-color;
}

// ......................................
// user.less
@import "library.less"
@base-color: white;
// or:
@menu-base-color: black;
// or whatever...

I.e. in summary: instead of testing if a variable is defined just provide a default value for that variable since variable values are freely overridable.

[lukeapage]

Can anyone answer why max's example is not do-able for them? I can only
assume it's because you don't know if the variable is defined above or
below the import ? Or is it something else?
We are not going to consider something that does not have use-cases .
The downside of doing this is people mistyping a variable won't see an
error. We could work around this with a warning but then if you did it on
purpose you wouldn't want a warning.. that's my only problem with this
suggestion.

[JechoJekov]

This is useful especially when defining themes in order to reduce the size of the resulting CSS. When creating themes in general one would like to enable setting a lot of properties. However, users may want to set only some of them leaving the rest of the properties unset. Of course setting them to default values would work in general, however, this bloats the final CSS.

Consider the following base theme (template):

.my-class {
    color: @text-color;
    background-color: @background-color;
    border-color: @border-color;
}

The user of the theme may want to set just the text color leaving the rest of the properties unset. Of course it is possible to set the values to "initial", "transparent", "inherit", etc., however, this increases the size of the final CSS. Themes tend to have hundreds of such properties so this the size may increase considerably.

[seven-phases-max]

@JechoJekov

I think you're missing the point of this feature request, notice that for your use case you still will need to put guard for every of these properties (hence the rationale I suggested two posts above still applies). So I don't think your use-case adds anything new to #1400 (basically it looks like you're suggesting a different feature like "skip property if all of its values are set with undefined variables" or something like that but it's another big story).

[JechoJekov]

@seven-phases-max

Perhaps it would be best if it is possible to set a variable to an "undefined" or "unset" value. Setting a property to such a value would mean that the property is not rendered in the final CSS. This simplifies the syntax and makes it possible to validate that the variable is declared.

[seven-phases-max]

@JechoJekov

Perhaps it would be best if it is possible to set a variable to an "undefined" or "unset" value.

As I mentioned this is another feature that needs its own ticket (with its own discussion).

[matthew-dean]

Just some clarification for roadmap: This is marked "ReadyForImplementation", but there doesn't seem to be consensus in this thread, and it looks like @seven-phases-max suggested a decent alternative. @lukeapage @seven-phases-max, should ready for implementation be removed?

[seven-phases-max]

@matthew-dean No idea. I suppose here "ReadyForImplementation" is still sort of valid, meaning something like "this feature seems to be not really neseccary but if someone comes up with a PR implementing such thing there will be no resistance" or a sort of :)