Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

How to customize sass variables in _variables.scss?

See original GitHub issue

When you override the default value af a variable in app.scss like this:

$md-body-font-size-base: rem(1.1);
@import '~@angular/material/core/theming/all-theme';

It has no effect on the font-size like in md-card:

md-card-subtitle {
  @extend %md-card-section-base;
  font-size: $md-body-font-size-base;
}

md-card-content {
  @extend %md-card-section-base;
  font-size: $md-body-font-size-base;
}

Is not better to define a base font-size on the body and use relative font-sizing like in the old-days? (https://developer.mozilla.org/en/docs/Web/CSS/font-size)

Issue Analytics

State:
Created 7 years ago
Reactions:8
Comments:11 (1 by maintainers)

Top GitHub Comments

15reactions

jelbourncommented, May 1, 2017

We don’t consider the variables to be part of the public API for Angular Material at this time. The issue with overriding them is that it would force sass compilation to happen downstream, disallow the components from being able to use styleUrls, and generally make the getting-started workflow more complicated.

Ultimately css custom properties is the way we want to address this, but supporting IE11 makes this not feasible presently.

9reactions

rotan-hanrahancommented, Apr 15, 2017

I’ve observed that the Material Design components support themes where you are essentially only setting the color attributes, but have no support for adjusting things like heights, widths, font sizes and much more. It seems natural to want to control these too. However, if one naively attempts to override via Sass variables then one is in for a disappointment.

The MD components append their styles to the <head>, and these styles are essentially “baked in”. As a trivial example, consider the MD Icon, whose source appears to be node_modules/@angular/material/icon/icon.js and a little over 200 lines into that file you will find this:

styles: [".mat-icon{background-repeat:no-repeat;display:inline-block;fill:currentColor;height:24px;width:24px}"],

In some template of your application, include a <md-icon> and then inspect the DOM of your running application and you will find the following has appeared in the <head>:

<style>.mat-icon{background-repeat:no-repeat;display:inline-block;fill:currentColor;height:24px;width:24px}</style>

In the MD component source files you will see icon.scss, which contains:

$mat-icon-size: 24px !default;

However, this is not involved in the compilation of your app. I assume it was involved in the original compilation of the MD resources. What gets incorporated into your app is what is already in the aforementioned icon.js, and no amount of experimentation with $mat-icon-size in your own Sass files will have any effect on this.

Unfortunately, even if you include some .mat-icon { ... } rule in your Sass file to directly adjust the .mat-icon rule, it won’t work because the MD styles are appended to the children of <head> and they will come after your own CSS rules and therefore have higher precedence.

You have limited options to overcome this. You could use “!important” (which is a sledgehammer best avoided). You could find a way to dynamically move your own <style> or <link> in the head down to the bottom so that it has precedence over the MD injected styles, and you need to make sure you do this after the MD injections have taken place. You could wait weeks or months until MD has theming ability beyond just the palette.

As a temporary hack during HMR I have configured a loader in my webpack config as style-loader?insertInto=#injectedStyle and I have included the following in my HTML template:

<body><span id="injectedStyle"></span>...

This means that the <link> injected during my build will appear in that <span> instead of being in the <head>, and therefore any MD-injected styles will always be before my link-referenced styles. Of course, putting this into the body is “bad”, but it works and is good enough during HMR until I can figure out a more robust approach that will work for a development build, including AoT.

What I would really prefer is that the theme mechanism was expanded to go beyond just the palette, but I’m not familiar enough with the implementation to determine right now what’s involved.

(Actually, what I would really, really prefer is for some guru to point out that all I have to do is [insert magical incantations here] and the problem is solved.)

Top Results From Across the Web

Variables - Sass

Sass variables are all compiled away by Sass. · CSS variables can have different values for different elements, but Sass variables only have...

Sass/SCSS Variables Tutorial - KoderHQ

In this Sass/SCSS tutorial we learn about temporary data storage containers called variables. We cover how to create variables with and without values, ......

Sass Variables - W3Schools

Sass variables are only available at the level of nesting where they are defined. Look at the following example: SCSS Syntax: $myColor: red;...

Unable to set SCSS variable to CSS variable? - Stack Overflow

I found a workaround to mapping the scss variables to css variables. See Terry's answer for better use. Scss: // sass variable map...

Combining SASS variables with CSS custom properties

To convert the SASS variable to a CSS custom property you put curly brackets around it, and a hash in front. If you've...