bug(@angular/material-experimental): breaks theme secondary color

[Fulll3]

Is this a regression?

• [X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

git+ssh://[email protected]/angular/material-experimental-builds.git#bed96e28e7a35fc5a9357b738497dfd51907f76d

Description

Hi,

latest version is missing support for secondary color Latest version: git+ssh://[email protected]/angular/material-experimental-builds.git#95f8ae1dd5bda218024ce6d75bb92a913ade8472 . Previous version: git+ssh://[email protected]/angular/material-experimental-builds.git#bed96e28e7a35fc5a9357b738497dfd51907f76d

vs

Reproduction

StackBlitz link: I have large repo hard to repodruce in StackBlitz Steps to reproduce: 1. 2.

Expected Behavior

Support of secondary color in theme definition.

Actual Behavior

Secondary color is not supported and throws error during compilation.

Environment

• Angular: 17.1.0
• CDK/Material:17.2.0-next.0
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): Windows

[crisbeto]

cc @mmalerba

[SeraphCoding]

I can second that - not that I am too familar with the experimental code, but also happens on define-colors:

Edit - I cannot test any other functionalities using a non-demo app because even the built-in themes will not work when using material-experimental for the same reason.

[Fulll3]

@SeraphCoding for just testing purposes I made it work with workaround. I have manually replaced commit version in package-lock.json.

In node_modules/@angular/material-experimental > resolved you can change the value to git+ssh://[email protected]/angular/material-experimental-builds.git#bed96e28e7a35fc5a9357b738497dfd51907f76d .

This is older build that was used in provided demo.

[SeraphCoding]

@SeraphCoding for just testing purposes I made it work with workaround. I have manually replaced commit version in package-lock.json.

In node_modules/@angular/material-experimental > resolved you can change the value to git+ssh://[email protected]/angular/material-experimental-builds.git#bed96e28e7a35fc5a9357b738497dfd51907f76d .

This is older build that was used in provided demo.

Yeah it's resolved in the latest commit. I just grabbed the latest build to avoid the issue.

[mmalerba]

We changed define-theme to always derive the secondary palette from the secondary palette. This is because the M3 spec itself seems to assume that the secondary color is basically a more muted version of primary (but same general hue). If we just allow people to combine an arbitrary primary and secondary hue, I think it would result in some of the components not looking great.

The current state of things is that:

• The M2 concept of "primary" roughly maps to M3's "primary" or sometimes "secondary"
• The M2 concept of "accent" roughly maps to M3's "tertiary"
• The M2 concept of "warn" roughly maps to M3's "error"

And in fact we have a back-compat mixin that can be included to actually apply those mapping to the .mat-{primary/accent/warn} classes. (Though in general I would suggest people use the new @include mat.xxx-color($theme, $color-variant: primary/secondary/tertiary/error) API in M3 as it doesn't generate as much boilerplate CSS as the predefined classes

[gabynevada]

@mmalerba Is the new api intended so that we apply the css globally for each of the colors we need per component?

Just want some direction on that area to plan accordingly to migrate our project.

For example if we need mat-icon in accent and error colors, the way forward is to create a selector per each of the colors in the global css? Also is the color options in the material components not recommended for future use?

@use '@angular/material' as mat;
@use '@angular/material-experimental' as matx;

$theme: matx.define-theme();

.primary-icon {
  @include mat.icon-color($theme, $color-variant: primary);
}

.error-icon {
  @include mat.icon-color($theme, $color-variant: error);
}

[mmalerba]

@gabynevada Yes exactly, rather than automatically getting the CSS for every color variant of every component (as we got with M2, or by using the color-variants-back-compat mixin), it is preferable to just apply the color variants you need as you showed in your example.

The [color]="..." API that is available on many of the components isn't deprecated. It still applies the .mat-primary, etc classes, but there are no styles targeted at those classes by default in M3. However, I would recommend applying the styles to your own classes rather than the ones added by the [color]="..." API since it offers you more flexibility and control.

[awat-lango]

I'd like to strongly support the possibility of providing a custom secondary colour:

In my team we deliver a white label application that is branded using the colours of our customers' brand. As their brand guide usually is not based on Material, their "secondary" colour is usually not derived from their "primary" colour. In addition, they may have three brand colours, and it would therefore be helpful if we were able to map them to the Material primary, secondary and tertiary colours.

In regards to the arguments made by @mmalerba above:

This is because the M3 spec itself seems to assume that the secondary color is basically a more muted version of primary (but same general hue).

The way I interpret the spec, there are three ways to define the colour scheme to be used by Material:

1. By feeding Material Color Utilities (MCU) a source colour that is user generated to generate primary, secondary and tertiary colour schemes.
2. By feeding MCU a content-based colour (e.g. an album image) to generate primary, secondary and tertiary colour schemes.
3. Feed brand colours - primary, secondary and tertiary - into MCU to create a custom colour scheme that matches the brand.

I'd also like to point out that all of MDC-Android, Jetpack Compose, Flutter and Web allows the adopters to set their desired secondary (as well as all other) colours. I do not see any reason why Angular Material shouldn't also give their adopters this option.

Source: https://m3.material.io/styles/color/system/how-the-system-works#75d38b0f-75e2-4e5e-b2a9-b05514c420d1

If we just allow people to combine an arbitrary primary and secondary hue, I think it would result in some of the components not looking great.

Should Angular Material be this opinionated though? Should it not be up to each team that adopts the library to define what "looking great" means?