import a file but override and merge the selectors and properties

[sethaldridge]

We are doing some pretty heavy overwrites to a framework that uses LESS and we've found that in order to customize the library we have to import their code and then add our code to the bottom of it, which allows us to update the base library without overwriting our own changes.

However this adds a lot of extra code we don't need.

What I'm proposing woud be an additional method to how @import works. @extend would allow you to make changes to a specific file and it would overwrite the default options with your changes.

Example:

Updated based on comments to better illustrate usage

myFirstFile.less:

body {
     background:#000;
     color: #fff;
     font: 100% Helvetica, Arial, sans-serif;
}

.container {
     width:940px;
}

.first, .second {
    background: orange;
}

.first {
    color: red;
}

.second {
    color: green;
}

mySecondFile.less

@extend "myFirstFile.less";

body {
     color: #f00;
     font-size:13px;
}

.container {
     color: pink;
     width: 960px;
}

.first {
    color: #000;
    background: red;
}

Output file mySecondFile.css

body {
     background:#000;
     color: #f00;
     font: 13px Helvetica, Arial, sans-serif;
}

.container {
     color: pink;
     width:960px;
}

.first, .second {
    background: orange;
}

.first {
    color: #000;
    background: red;
}

.second {
    color: green;
}

This would make our files much smaller while allowing us to decouple our changes from the main .LESS files.

Sorry if this is not the preferred way to suggest this change.

[mindfullsilence]

Not sure this would work, but might be a temporary work around for what you're trying to do:

firstfile.less
.container() {
    width: 960px;
}

secondfile.less
@import "firstfile.less";

.container() {
    .container();
    width: 940px;
}

callingIt.less

@import "secondfile.less";

selector {
    .container();
}

output.css

selector {
    width: 960px;
    width: 940px;
}

Granted you end up with some duplicate code, but it uses the css cascade so width: 940px would take precedence.

[kamboyer]

I really like the concept of @extend. It seems like it would really help keep your file sizes to a minimum. Mobile sites could benefit from this tremendously.

[ricardovf]

We are extending Twitter Bootstrap a lot too and a lot of code gets duplicated and is not needed. Have you considered changed less behavior so:

.father {
    color: red;
    background: yellow;
}

.father {
    color: blue;
}

Would became:

.father {
  background: yellow;
}
.father {
  color: blue;
}

Instead of:

.father {
  color: red;
  background: yellow;
}
.father {
  color: blue;
}

Note the color: red was removed on the proposed version. This saves the browser from doing it. It does not seem so hard to do, the problem is that i can not go into less internals now.

Would be a really nice thing, what do you think?

[sethaldridge]

We run our LESS scripts through a build process, so I can definitely see how @extend would be better suited for a build based LESS project.

Does your suggestion mean you manually remove the duplicate styles or are you doing it another way?

[ricardovf]

@sethaldridge For now we are just letting the duplicate code as the browser will do the hard work of not using it, but we know its a waste of bytes and processing time. I sugest that there is no need for using @extend as I consider that this duplicate code removal should be a nice default feature. I guess that if implemented as default it would not break any code. If its hard to implement on lessc ill probabily implement it into our build pipeline (we use assemblers and do not use @import).

[matthew-dean]

This sounds good in theory, but CSS inheritence can be quite complex. Consider this

.father {
    color: red;
}
.father, .brother {
    color: yellow;
}
div {
    color: green;
}
div.brother { 
    color: black;
}
.brother {
    color: blue;
}

How are these re-written? Maybe it's easier than it looks, but it seems like there's a lot of opportunity to get it wrong for a very small benefit (or no perceivable performance benefit).

[ricardovf]

@MatthewDL Your point is valid, but i think this optimization should be used only for simple cases like the one we pointed out cause the objective is to extend a library (twitter bootstrap in my case), so most of the cases would be a direct replacement.

Your case illustrates the simple cases: .brother and .father

div.brother should not be touched in this case, unless there was a div.brother rule defined before that would be replaced (the attributes).

.father {         
  color: yellow;
}
div {
    color: green;
}
div.brother {
    color: black;
}
.brother {
    color: blue;
}

[sethaldridge]

I agree with @ricardovf. All replacements would be one to one.

[Synchro]

I don't think that you'd need to introduce a new keyword for this - what you're really asking for is a CSS optimiser, and that would be a great thing to roll into LESS. That said, I've not seen one that goes as far as eliminating overridden properties or repeated definitions.

[ricardovf]

@Synchro Agree. Can you point me to one of this tools that you saw?

[Synchro]

There are quite a few, such as http://www.cleancss.com/ and http://www.codebeautifier.com/ but nearly all seem to use CSSTidy: http://csstidy.sourceforge.net/
CSSTidy is available in C++ and PHP - we could do with a JS implementation.

[ricardobeat]

I think CSSO needs a mention here.

[lukeapage]

We can't eliminate properties because this is quite often used where a browser supports one version of a property but not another.. we don't want to remove that that case.

[lukeapage]

We hope #1210 to solve this use-case when you use that with :extend in order to a) merge selectors b) choose what you want to take out of a library