Using Mixins in CSS: Developer Abuse and Misuse

When it comes to the various CSS preprocessors that are available today, I think one of the dangers that we – as developers – face is using certain features that were not previously possible in vanilla CSS as a sort of crutch.

By that, I mean that I think that we have a tendency to fall back on things that we’re used to in our server-side environments as opposed to practices that are more preferential on the client side.

For example, I there are things that we used to do – or should be doing – with class names as opposed to mixins, but may not end up falling back to using mixins as opposed to more general classnames.

Confused?

Using Mixins in CSS

To make my point clear, it’s important to understand what mixins are, as they relate to CSS preprocessors.

Both LESS and Sass support them, and they are defined as follows (from the LESS CSS website):

Mixins allow you to embed all the properties of a class into another class by simply including the class name as one of its properties. It’s just like variables, but for whole classes. Mixins can also behave like functions, and take arguments, as seen in the example below.

The emphasis added is mine, and that’s because I where find differentiating between when to use element class attributes and styles, and when to use mixins for styling can become a bit middled.

The Purpose of Class Names

Remember from way back when – or not so way back when ;) – preprocessors didn’t exist, HTML elements afforded two methods by which we could identify them:

  • class attributes
  • id attributes

And remember that IDs should be unique to a given element whereas a class attributes are applied to a more general collection of related elements.

For example, on a blog, you may have a one comment form – perhaps identified by #commentform – but multiple fields for users to fill out – such as .comment-inputs for the name, website, email, and so on.

At this point, the #commentform should be styled using a unique set of a styles, whereas .comment-inputs can be given styles that will apply to general elements.

How Do Mixins Impact This?

From a developer’s standpoint, I’m finding that it’s becoming increasingly easy to use mixins as a crutch for replacing what should be relegated to classes – we end up taking elements that have a variety of ID’s and then styling them using a set of mixin.

For example, using mixins to style a collection of unique elements may look like this:

But isn’t that something should should be applied to markup through the use of classnames?

When Are Mixins Appropriate?

There are generally two cases that I believe mixins are appropriate:

  • When you need to perform some type of calculation on a set of styles before applying (that is, parametric mixins)
  • When you have a subset of styles that you want to apply to elements regardless of their class or ID attributes

So, practically speaking, let’s say that you want to apply something such as border-radius to a number of different elements. In this case, the code may look like this:

Of course, this can be taken even further by having the mixin accept a parameter and letting the radius be calculated based on the parameter.

Don’t Mix Up Mixins

This is a short and potentially less complete post than it should be, but the point should be clear enough: Just because we have the ability do things with mixins that were once accomplished using proper semantic naming doesn’t mean that we should avoid the initial strategy.

So here’s the rule of thumb: If you need to style a collection of elements with something similar, then use the class attribute. If you have a set of individual, yet unique elements – perhaps text-shadow – that may be applied to certain paragraphs or spans, but that don’t necessarily need to be semantically defined in the context of the markup.

Mixins should enhance what’s already in place.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.