css - LESS: Better to use inheritance or multiple classes

Question

I have a LESS file with an inputbase(){} class. I use it on a lot but not every input type. When I compile I have a lot of repeated styles in the outputted CSS file.

I took a look out how bootstrap use LESS for their grid and they use the same approach; where column 1 etc would inherit from a column base class. Again this seems to generate a lot of CSS.

Should I be using .inputbase .specificClass in every <input /> instead of using LESS inheritance?

question from:https://stackoverflow.com/questions/19977493/less-better-to-use-inheritance-or-multiple-classes

Answer 1

Various Options, No Set Answer

It's going to depend a lot upon your code, your goals, etc., how you get styles to the various elements. Here are some possibilities, each with strengths and weaknesses.

1. Mixin (what you currently do)

LESS

.inputbase() {
  /* your base code */
}

.someInput {
  .inputbase;
  /*some input special code */
}

.someOtherInput {
  .inputbase;
  /*some other input special code */
}

.andAnotherInput {
  .inputbase;
  /*and another input special code */
}

CSS Output

.someInput {
  /* your base code */

  /*some input special code */  
}
.someOtherInput {
  /* your base code */

  /*some other input special code */    
}
.andAnotherInput {
  /* your base code */

  /*and another input special code */    
}

If there is more than a line or two of code in .inputbase(), and if it is mixed in more than just a couple of instances, this will be generating a lot of extra code. This is the issue you find yourself facing.

2. Extend a Class

It appears LESS is just about ready to allow for extending mixins, but at present (LESS 1.5) this requires just a class definition, so this:

LESS

.inputbase {
  /* your base code */
}

.someInput {
  &:extend(.inputbase);
  /*some input special code */
}

.someOtherInput {
  &:extend(.inputbase);
  /*some other input special code */
}

.andAnotherInput {
  &:extend(.inputbase);
  /*and another input special code */
}

CSS Output

.inputbase, /* this is gone once mixin extending allows .inputbase() extension */
.someInput,
.someOtherInput,
.andAnotherInput {
  /* your base code */   
}
.someInput {
  /*some input special code */    
}
.someOtherInput {
  /*some other input special code */   
}
.andAnotherInput {
  /*and another input special code */   
}

The advantage is all the base code is not repeated, but what is repeated is the selectors, as they are first grouped together with the base code, then again are output for the individual code. If one likes to keep their code grouped in one selector definition, then this would not be the way to go. Otherwise, this offers a nice way to reduce CSS output.

3. Two Classes (extra html markup you propose)

This one solution you proposed, having two classes (this is because you stated that you do not always want .inputbase applied to an input element).

LESS and CSS Output*

.inputbase {
  /* your base code */
}

.someInput {
  /*some input special code */
}

.someOtherInput {
  /*some other input special code */
}

.andAnotherInput {
  /*and another input special code */
}

This does have the least amount of CSS, but it has the disadvantage that it also requires the extra HTML markup of the two classes, <input class="inputbase someInput" /> etc.

4. One Class with Override of Base

This may be better than the above.

LESS and CSS Output

input {
  /* your base code */
}

.someInput {
  /*some input special code */
  /*override input base code if needed */
}

.someOtherInput {
  /*some other input special code */
  /*no override if not needed */
}

.andAnotherInput {
  /*and another input special code */
  /*no override if not needed */
}

If most inputs will have the baseinput code, you can simply define your base input code within the input element definition, then just override the properties you don't want in your special css code. This allows for less html with just the single class applied <input class="someInput" />. This will keep both the CSS and the HTML less cluttered, but has the disadvantage of remembering what the base code is and being able to override it if needed.

Summary

What will be best depends too much on the particular circumstances you face. But perhaps the two additional options will help you think through your case. I personally would in most cases opt for #2 or #4, but again, there are applications for #1 and #3 as well.