-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Description
Feature Description
System level CSS variables are awesome. They give full control over theming:
- Theme variable values are available at runtime.
- Theme variable values can be adjusted at runtime.
- Changing the entire theme is just a matter of supplying different values for the
sys-variables. - Using any theme variable anywhere in the app can be done using the CSS variables. No need for importing any SASS logic from
@angular/material.
Defining and using a theme is as simple as:
@use "@angular/material" as mat;
$theme: mat.define-theme(
(
color: (
theme-type: light,
primary: mat.$cyan-palette,
tertiary: mat.$magenta-palette,
use-system-variables: true,
),
typography: (
use-system-variables: true,
),
)
);
html {
@include mat.system-level-colors($theme);
@include mat.system-level-typography($theme);
}With this one can easily define a bunch of such defined themes, and then load one based on user settings. Alternatively a backend endpoint could render the CSS file with the sys- variables.
The issue
Everything in Angular Material nicely supports system-level themes, except the component theming mixins.
We still are still required to do something like:
html {
@include mat.all-component-themes($theme);
}This is not nice, because we now have generic styling code that needs to use a specific theme.
A solution would be to allow passing something like this:
html {
@include mat.all-component-themes((use-system-variables: true));
// Or available on mat.
@include mat.all-component-themes(mat.$system-variables-theme);
// Or allow passing no theme
@include mat.all-component-themes();
}Workaround
Create your own $system-variables-theme, and use it:
html {
$system-variables-theme: mat.define-theme(
(
color: (
use-system-variables: true,
),
typography: (
use-system-variables: true,
),
)
);
@include mat.all-component-themes($system-variables-theme);
}Use Case
Easy and clean theming, with minimal theme files.
I'm not sure whether the current workaround is 'ergonomic' enough. If it is, it should at least be added to the documentation.