@if("flag") and @unless("flag")

[brigand]

Giving less the power to be built for different configurations, without having separate files is very valuable.

Use Case 1 - Browser Support vs File Size

Consider, we want to keep our file-size down, or increase speed. We can create a gradient, but we may not want to provide optional IE support, using the well known, and very long property. We also may, or may not want browser prefixes to be supported.

@if("prefixes") {
    background: -moz-linear-gradient(top, #ffffff 0%, #000000 100%);
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#ffffff), color-stop(100%,#000000));
    background: -webkit-linear-gradient(top, #ffffff 0%,#000000 100%);
    background: -o-linear-gradient(top, #ffffff 0%,#000000 100%);
    background: -ms-linear-gradient(top, #ffffff 0%,#000000 100%);
}

background: linear-gradient(to bottom, #ffffff 0%,#000000 100%);

@if("ie") {
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#000000',GradientType=0 );
}

Now, when we compile the code, we can pass --use ie or --use prefixes to enable these options. As an alternative, we can use @unless ("noprefixes") to default it to being included.

To avoid conflicts with existing tags, a new tag could be created for this which accepts a comma-separated list of flags to set.

--use ie,prefixes

Use Case 2 - Development vs Production

In production, you may add styles that show information, that you don't want the user to see. Perhaps the styles for a debug toolbar, or creating a theme with both flat and chrome styles. The code can be simplified by wrapping your entire toolbar code in a @if wrapper, or creating a mix-in that does nothing for properties like gradients and box-shadow on the simple version.

linear-gradient(@from, @to) {
    @unless ("flat") {
        background: linear-gradient(to bottom, @from 0%, @to 100%);
    }
}

Unless the user passes --use flat, we get the the gradient.

Why not us separate files?

• LESS focuses on putting related code together. It seems like it goes against its nature to split simple toggles like these into different places.
• You may have things that you want to change, but you also have things you want to be the same, like the padding you changed on .sidebar shouldn't need any copy-paste from file to file. Write LESS CSS.

Command line flag (and possible @if and @unless should probably be renamed.

If the concept is accepted, I'll try to find time to implement it.

[extemporalgenome]

I'd suggest that the '--use' portion be broken out into a separate mechanism, perhaps called --set, with a corresponding new builtin function tentatively called "env". Existing guard expressions would already (mostly) take care of the rest, though it'd be helpful if the grammar were extended to allow guard expressions on arbitrary blocks, for example:

div when (env(ie)) {
    /* ... */
}

env would take a quoted or anonymous type (treating the latter as a string); if the program is called with --set ie, it's equivalent to --set ie=true, though the value portion of a key could be parsed as any valid LESS expression aside from those involving variables.

[lukeapage]

I would suggest

1. Allow variables to be set by command line (we have a bug for this)
2. Allow guards on arbitrary selectors (we have an issue for this)

These 2 features have already been agreed.. is there any advantage to new
functionality/syntax to achieve what you want?

[matthew-dean]

@lukeapage I would add that I think there's a good argument for allowing guards on mixin calls as well, not just definitions, but I've already said that elsewhere. I agree that the amount of new syntax proposed here does not have enough value add for the additional weight.

[seven-phases-max]

I guess this can be closed? This is achievable now via --global-var/--modify-var and mixin/css guards.