Add !default to more scss variables to allow overriding values

Bug, feature request, or proposal:

Feature Request

What is the expected behavior?

Custom theme should be able to override most colors/styles used in material theme (assuming they are SCSS variables). This override should be possible at time of theme generation and not by overriding CSS after the fact. The variables are already there but some are marked as !default while others (that could also be) are not.

What is the current behavior?

Certain variables ($light-primary-text, entire $mat-grey palette) are used directly in SCSS and not via theme setup ($mat-light-theme-foreground). These should have !default flag to allow customization at theme generation time.

What is the use-case or motivation for changing an existing behavior?

To cleanly override some of these colors, I currently make a copy of _theming.scss and update this file manually so I don’t have to override CSS after it has been generated; thus maintain brittle CSS that might change in future material updates.

Is there anything else we should know?

This suggestion simply implies adding !default to a few more variables, I realize current behavior is likely deliberate to prevent users from shooting themselves in the foot, but this also has a side effect; if someone is going to override these variables it’s on them, no different than rest of styling.

There seems to be a slight syntax variant in how to override maps that’s different than standard variables i.e.

$grays: () !default; $grays: map-merge(( "100": $gray-100, "200": $gray-200, "300": $gray-300, etc... ), $grays);

[tomgruszowski]

Thanks for linking to these issues @jelbourn but there is clearly a desire for this from the community, it seems too easily dismissed, especially since level of effort here appears reasonable (unless I’m missing something). We’re already compiling downstream when theming with SCSS what harm can there be from exposing the variables? CSS variables are not some magic bullet, SCSS variables will make sense for years to come. It’s disappointing that the material team takes such a restricted stance on styling while being extremely strong on the component architecture. Again, apologies if I don’t understand the details well enough, but it doesn’t strike me as anyone is trying to solve this.

[jelbourn]

The fundamental issue here is twofold.

Issue number one is that making this possible would make the Sass surface a public API. The existing public API surface area for Angular CDK + Material is already huge; the more we open this up, the harder it becomes to make any changes at all.

Issue number two is the build graph. Any given component uses styleUrls to reference a CSS file. When we publish the library, that CSS file has to exist, so the compilation has to happen before publishing. Angular doesn’t have a way to hot-swap style files that would enable leaf applications to affect the CSS that’s associated with the component.

CSS variables really do make this problem much easier to address. Because we’re so close to using them, it’s ultimately going to be the most effective use of the team’s time to revisit the theming system just once.