Learning Material Design Lite: Customizing

Up until now we have been looking into how to implement MDL components. The question remains: how do we customize these components so that they fit within the context of our design and brand?

For many of you, the answer to this question might seem obvious: we create a new stylesheet then write the style rules to override the defaults. However, doing this is not always the best way when dealing with a framework of this caliber.

A Better Approach

So as to not bloat the website with styles that may eventually be overridden, we first need to determine which parts of our components we are going to customize; the color, the sizes, the shapes, or perhaps the positions? This will lead us to understand how we can begin customizing.


Right at the beginning of the series, we learned that you can customize the color scheme through the Customize tool. You can select the primary and the secondary color that will be applied to the MDL UI components, either by the default or by adding a Modifier class like mdl-button--colored.

MDL customizer

However it is often the case that two colors aren’t sufficient to produce the desired result, or perhaps the secondary color applied in a particular UI element does not match with the overall design of the website.

Material Design comes with specification for a wide palette of colors that include red, blue, pink, purple, and yellow. If your required color—background or text color—falls within the range of these colors, you won’t have to write custom style rules to override the originals. You can add the following classes instead:

  • mdl-color--{color-name}-{shade}: overrides the element background color as specified in the {color-name} and {shade}.
  • mdl-color-text--{color-name}-{shade}: overrides text color as specified in the {color-name} and {shade}

The following is an MDL card component from an earlier tutorial, displaying a blog post with the post title, the post excerpt, and a couple of buttons. This time the buttons are in their default color.

Assuming we want to change the like as well as the share button to light gray, while the title and Read More button are given a light blue, we could add the mdl-color-text--blue-grey-300 class to the button, and add the mdl-color-text--light-blue-900 to the title.

This results in:

Once again, please refer to the Material Design color specification for the supporting colors and shades.

Drop Shadow

Another thing we can adjust by adding a “modifier class” is the shadow. Add the following classes to apply drop shadows to a UI element:

  • mdl-shadow--2dp
  • mdl-shadow--3dp
  • mdl-shadow--4dp
  • mdl-shadow--6dp
  • mdl-shadow--8dp
  • mdl-shadow--16dp

The larger the number, the strongest the shadow depth and spread, accentuating the raised effect to the element in question. With our previous card, we may add the mdl-shadow--16dp to levitate the card further.

This results in:

Component Modifier

At the end of the documentation for each component, Google provides a list of classes that can be applied. Before writing any customized style rules, examine each component for these classes to find whether it has actually been covered. The navigation component, for example, comes with an abundance of modifier classes, such as:

  • mdl-layout--large-screen-only; to show the element only in the large viewport size and hide it when it goes to table- or phone-sized viewport.
  • mdl-layout--fixed-header; makes the navbar sticky so it’s always visible in the viewport as the user scrolls.
  • mdl-layout__header--scroll; makes the header unstick and scroll along with the content.
  • mdl-layout__header--transparent; makes the header transparent so we can add, for example, a background image.
  • mdl-layout--fixed-drawer; makes the off-canvas navigation always visible.

Applying these classes avoids lines of unnecessary customization code.

Go Further!

If your required customization goes beyond what’s in the specification, we’ve no choice but to start a custom stylesheet and write our customized style rules. We can create a new .css file, link to it in the document below the MDL stylesheet (or compile everything together using a build tool), and run over the file with our own style rules.

But, as easy as it might sound, you will sooner or later encounter specificity issues. Since the component might be used multiple times in several levels of DOM hierarchy, your style may end up something like the following:

So, instead of targeting the MDL native selector directly, we’d be better separating the custom style rules into a custom selector as well. That means assigning a new class for the element you are going to customize and writing the styles under the new selector:

Doing this enables us to keep our style specificity low. It also allows us to identify which element is applied with custom styles. In case you want to disable the custom styles, you could remove the new class.

And the following is an example of doing so to customize our previous card:

Hint: check the CSS tab.

Raw Source

Another way of doing complete customization over the MDL default styles is through the source code. MDL is available through multiple channels: Github, NPM, and Bower.

Run the following git command to download MDL from Github, using it as a Git Module which enables us to pull down commits and updates:

Run the following command to get MDL from NPM and deploy it, perhaps, as a NodeJS application:

Run this command to deploy MDL in your website as a dependency with Bower:

In all cases, this gives us the src folder that contains the MDL source codes.

By having the raw files—uncompiled code—we are able to customize the MDL components to the finest detail. We could compile a lighter main stylesheet by excluding superfluous components. We could also change and reuse the variables and the mixins to write the custom styles.

Modifying the source files is the way to go for those who demand total control over the output. In the final part of this series “Quick Tip: Pick ‘n’ Mix MDL Components with Gulp” we’ll examine the process of taking only the MDL parts we want in our build.


In this tutorial, we have seen various ways to customize MDL components. And as we have discovered, the approach largely depends on the output we envision. Sometimes it could be as direct as adding a modifier class, yet sometimes you may also need to pull down and edit the whole source files.