components
components copied to clipboard
angular
Support theming with CSS Custom Properties
feature request
Use CSS custom properties for at least color selection.
What is the expected behaviour?
To be able to alter the color-scheme during runtime on supported browsers, and fall-back to predefined SASS defined colors on others
Here is a sample (by Cris Coyier) of how CSS custom properties might work
Is there anything else we should know?
Here is a simple sass mixin that might help:
@mixin variable($property, $variable, $fallback) {
#{$property}: $fallback;
#{$property}: var($variable);
}
By using something like that mixin, support for browsers that have no CSS variables support, stay's the same way as its now, while supported browsers gain a way more flexible way to use colors.
We do actually plan on doing this eventually but don't have it as scheduled work at the moment.
TIL about PostCSS. I taught I would share it here. The reason for that is that it enables to use standard CSS (Including custom CSS properties!), and then compile it down for old browsers. This is a huge win over sass, as you need to compile that for old and new browsers alike. This is the plugin(cssnext) that makes this possible. Among other nice to have things.
It will likely be early 2020 (when Microsoft plans to end support for IE11)
It will likely be early 2020 (when Microsoft plans to end support for IE11)
How about an opt-in option to consume CSS Custom Properties for those of us lucky enough to ditch Internet Explorer 11?
someone seemed to solve it with css variables and IE 11 fallback. https://github.com/datorama/themify
StencilJS, created by the Ionic team, has a conditionally loaded CSS variable polyfill, if the Angular Material team talks with them and includes the polyfill Material would be able to switch to CSS Variables. Thank you for your time, have a great day!
Here is a CSS Properties ponyfill https://github.com/jhildenbiddle/css-vars-ponyfill
I believe that this functionality would bring enormous benefits to the creation of themes for the material, since with native variables you will not have to load files with css of themes as the documentation itself does. That brings more perfomance.
I really don't understand why they don't simply use the polyfill and just switch to css variables now. This is GREAT downside right now.
I agree that this is huge downside to not use CSS variables.
Anyway it should be nice to at least remove all fade-out and other SASS functions dependent on Color so at least colors can be defined as CSS variables as a start. This will allow people to use CSS variables in theme definition and not change how theming works now.
We have customers who want to switch to Ionic 4 just because of CSS variables: this is starting to be a serious issue for those who want to achieve a modern and pleasant to work with custom theming.
@jelbourn
It will likely be early 2020 (when Microsoft plans to end support for IE11)
Where did you get this date from? EOL of Windows 8.1 is 2023. https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet
IMHO there are only two parts necessary
- A style sheet with custom properties
- For older browsers a script that replaces the property references with fixed values. Simple text replace should be enough.
Where did you get this date from? EOL of Windows 8.1 is 2023.
You can use IE11 in Windows 10 as well, so that means October 14, 2025 AT LEAST. If the Material team doesn't decide to fix this now more and more people will start migrating to something else.
Give up with old browsers and just use a polyfill to support them: https://github.com/jhildenbiddle/css-vars-ponyfill
@darkbasic
You can use IE11 in Windows 10 as well, so that means October 14, 2025 AT LEAST.
If you also count Windows 10, the Enterprise LTSC support is currently running until 2028 😉 But there you have Edge as an alternative making it a lesser problem.
@darkbasic Edge is an default browser for Windows 10 so defiantly IE11 is not an issue on Windows 10. You will use Edge or install Chrome when using Windows 10.
@manklu This stylesheet can be user defined so that user can decide to use CSS variables or not. But in order for this to happen functions over colors like: fade-out, darken, lighten must be removed from SASS code in order for project to compile.
@darkbasic Corporate policies may prohibit that.
@vasicvuk I know that this is a big bunch of work. But i don't think it's necessary to maintain two separate sets of style sheets.
Jan. 2020 is end-of-life for Windows 7, which is the most recent major Windows OS version on which Edge can't be installed.
@manklu of course you cannot really give up with IE11, but I still don't understand what's wrong with a polyfill
@jelbourn In 2020 there will be something new probably better then CSS variables that we have now, so there is no point in waiting for technology that is already here.
I agree with @darkbasic. For browsers without updates polyfill should be used.
@jelbourn
According to Microsofts FAQ, Edge can't be installed on Windows 8.1 https://docs.microsoft.com/en-us/microsoft-edge/deploy/microsoft-edge-faq
Q: Will Windows 7 or Windows 8.1 users get Microsoft Edge or the new Microsoft EdgeHTML rendering engine?
A: No. Microsoft Edge has been designed and built to showcase Windows 10 features like Cortana, and is built on top of the Universal Windows Platform.
I had a bit of a go of getting things building by removing the usage of functions that required a color at build time. Patch is below if anyone is interested. The challenge is finding dynamic equivalents to the functions that were originally in use, as noted by the todo's
Patch to _theming.scss
1273a1274,1275
> // MODIFICATION TODO read input opacity...
>
1275c1277
< $opacity: if($opacity == null, opacity($color), $opacity);
---
> $opacity: if($opacity == null, 1, $opacity);
1277c1279
< @return rgba($color, $opacity);
---
> @return unquote('rgba(' + $color + ', ' + $opacity + ')');
2384c2386,2387
< background-color: fade-out(mat-color($palette), $mat-datepicker-selected-fade-amount);
---
> // MODIFICATION
> background-color: mat-color($palette, $mat-datepicker-selected-fade-amount);
2445c2448,2449
< border-color: fade-out(mat-color($foreground, hint-text), $mat-datepicker-today-fade-amount);
---
> // MODIFICATION
> border-color: mat-color($foreground, hint-text, $mat-datepicker-today-fade-amount);
3218c3222,3223
< $drawer-backdrop-color: invert(mat-color($background, card, 0.6)) !default;
---
> // MODIFICATION TODO put invert back somehow...
> $drawer-backdrop-color: mat-color($background, card, 0.6) !default;
3562c3567,3568
< color: mix($table-background, rgba($text-color, 1), (1 - $text-opacity) * 100%);
---
> // MODIFICATION TODO mix somehow...
> // color: mix($table-background, rgba($text-color, 1), (1 - $text-opacity) * 100%);
Example Usage:
:root {
--color-50: 227, 242, 253;
--color-100: 187, 222, 251;
--color-200: 144, 202, 249;
....
}
$dynamic-mat-theme: (
default: var(--color-500),
lighter: var(--color-100),
darker: var(--color-700),
default-contrast: var(--color-contrast-500),
lighter-contrast: var(--color-contrast-100),
darker-contrast: var(--color-contrast-700),
50: var(--color-50),
100: var(--color-100),
...
}
In terms of IE11 support, has anyone evaluated the suitability of this polyfill: https://github.com/jhildenbiddle/css-vars-ponyfill
I have created a small repo where I used it and it worked pretty well: https://github.com/bene-starzengruber/dynamic-theming
with the recent announcement by the edge team of moving your browser to Chromium I think this is a good time to support this feature request and abandon internet explorer support
@Rodrigo54 Edge has had CSS Custom Properties support for more than a year.
@LayZeeDK part of Edge moving to Chrommium is that they are going to be supporting Windows 7 and 8, so IE11 can finally be replaced
That sounds nice. But it could be another year before it lands. So probably 2020 anyways. How about Windows Server, will it get Edge Chromium?
We will evolve the Microsoft Edge app architecture, enabling distribution to all supported versions of Windows including Windows 7 and Windows 8, as well as Windows 10. We will also bring Microsoft Edge to other desktop platforms, such as macOS. Improving the web experience for end users (better compatibility) and developers (less fragmentation) requires a consistent web-platform as widely available as possible. To accomplish this, we will use Chromium’s cross-platform app-technology along with a change in our distribution model, so that the Microsoft Edge experience and web-platform become available across all supported operating systems.
@LayZeeDK according to this section of the document it is probable that yes
I think it is an exaggeration to wait until 2020 for a feature like this, I believe that offering a polyfill to keep support for IE11 is sufficient, just make it explicit in the documentation.
@Rodrigo54 It depends on how you interpret all supported versions of Windows since Windows Server LTSB does not support Microsoft Edge.
@LayZeeDK Well, The edge version based on chromium will land ~q1 2019. That will work there. I would love to see this feature ASAP. Runtime theming then becomes a snap!
it seems that pull request #15140 has opened doors to use css vars in angular material projects
Yes with #15140 + overriding the mat-color function with a custom one, theming with css variables works like a charm :) See here: https://stackoverflow.com/a/55306685/2416833
Yes with #15140 + overriding the mat-color function with a custom one, theming with css variables works like a charm :)
But not in a backward compatible fashion. Only browsers that support CSS custom properties can benefit from this solution.
@kevinbeal Yes, but at least for projects that dont have to support these browsers (like ours), this solves the problem.
I took a look at the following
Here is a CSS Properties ponyfill https://github.com/jhildenbiddle/css-vars-ponyfill
It has some performance issues with Angular where a few people are helping the author test performance updates. It looks like it's getting close to being included in their 2.0 release. Until then, I doubt that it can be considered for official support with Angular Material. (though there are certainly some people already using it)
The Ponyfill also has some limitations related to defining variables in :root {} declarations and does not support media queries. They plan to address the media query issue once the Angular performance issues are resolved.
someone seemed to solve it with css variables and IE 11 fallback. https://github.com/datorama/themify
I tracked down what they are doing and it's certainly a non-trivial amount of code that isn't as easy as dropping in a conditional polyfill.
StencilJS, created by the Ionic team, has a conditionally loaded CSS variable polyfill
@arjunyel I haven't had time to dig into this yet, but it would be helpful if you could research it a little bit and post some GitHub links where we can look at how this is done.
I've been using the css-vars-ponyfill module with mixed results. Defining variables in :root as lists of rgb values and then defining a custom theme in sass with them.
:root { --primary-500: 127, 163, 133; }
$primary-palette: (
...
500: rgba(var(--primary-500), 1),
...
)
I recall having to redefine some styles in which an rgba color in Angular Material's was used with an alpha channel value other than 1.
Defining your variables in :root {} worked well enough for me, but changing the values of css variables in child elements had no effect in older browsers regardless of the options passed to the ponyfill.
:root { --primary-500: 127, 163, 133; }
.child-theme {
--primary-500: 133, 163, 127; // no effect
}
I did not measure for performance. For now, this solution is working for my project.
IE11 support should ALWAYS be taken into account, regardless of when Microsoft says they're phasing out anything. There are many, many companies out there with older versions of Windows that couldn't care less about keeping up to date, and enterprise products would need to have IE11 far into the future to remain competitive.
Just wanted to let you know, that I created a little library to add support for this feature: https://github.com/johannesjo/angular-material-css-vars
It's freshly build, so please let me know what you think or when you have any suggestions for improvement!
Status update on this: it's still something we're thinking about, but we're still at a point where we can't drop IE11 just yet; we don't want to require apps to Polyfill CSS variables, since the polyfills are imperfect. Once we can drop IE11, we'll be able to explore how to incorporate CSS variables into the theming system, though we expect everything to still function primarily through a Sass API.
Thank you for the update, @jelbourn.
This is still a major pain in 2020. So much redundant CSS. High negative impact on the developer experience of customizing Angular Material styles.
Internet Explorer 11 lives on at least until October 2025 because of Windows 10.
What date/year are you aiming for in terms of dropping Internet Explorer 11 support?
Ionic just announced they're dropping IE 11 support https://twitter.com/maxlynch/status/1252341822413664256?s=19
I don't have anything beyond "As soon as we feel like we can". We base our browser support on what we hear from Angular customers (especially larger enterprises) , and so far IE11 is still hanging in there. Personally, I'm going to buy a cake when we finally get to drop it.
I'm also going to buy you a cake when you drop Internet Explorer support and migrate to CSS Custom Properties 🎂
we don't want to require apps to Polyfill CSS variables, since the polyfills are imperfect
May I ask you to clarify the meaning of "imperfect" in this context? Because on one hand we have "imperfect" IE11 support (which almost nobody uses), dry code and an awesome developer experience, while on the other hand we have "perfect" IE11 support but also tons of redundant CSS and a high negative impact on the developer experience. If it was me I wouldn't hesitate to choose the first path, even if it means delegating IE11 to its own legacy bundle stuffed with polyfills.
Would it be an option to maintain two parallel versions of sass file? One w/ and one w/o css variables? This is the approach jQuery came to when they made v2 many years ago. They succeeded with that quite well and btw won a lot of performance by cutting off old browsers.
So, this would solve this particular issue and potentially would give performance benefits to the modern browsers because of smaller CSS bundles and simply better approaches.
Yes, more work to be done and more tests to be written. But this is a price for ie11. Still I hope it is possible to have the common sass codebase meanwhile.
I'm for whatever needs to be done ALSO providing a pathway for ensuring IE11 still functions correctly.
I respect (and envy) LinkedIn's announcement that IE11 support is being left behind, but that's a decision they make as a product, not as a framework which countless products across a range of use cases depend on.
P.S If you're mad at the fact that in 2020, IE11 is still being used in many large companies around the world, be mad at the reality that old and slow change management process are common in larger organizations, not at the employees who deserve the best experience that product creators can provide. But to think IE11 isn't important anymore because it has a small market share would be to discount the reality that enterprise SaSS providers have to deal with. Nobody should be left behind :)
@jpike88 By stills supporting IE11 we (the total developer community) are enabling/allowing a known insecure browser to still exists. While I do get the leave none behind sentiment, I strongly believe that this is allowing bad practices to pertain. It is not a service to end-users. Heck, Linked-In is part of Microsoft, and they drop support. That should be telling.
Has anyone tried my polyfill? https://github.com/nuxodin/ie11CustomProperties
Could we have an update on this? It's been more than 6 months since the last update.
- Angular version 12 deprecates (not removes) support for Internet Explorer 11. This is the last browser officially supported by Angular which doesn't support CSS Custom Properties.
- Angular Material is migrating to MDC Web internally. MDC Web uses CSS Custom Properties.
- Angular version 12 deprecates (not removes) support for Internet Explorer 11. This is the last browser officially supported by Angular which doesn't support CSS Custom Properties.
- Angular Material is migrating to MDC Web internally. MDC Web uses CSS Custom Properties.
So when can we expect that migration, in Angular 12 or Angular 13+?
We do indeed plan on deprecating support for IE11 in Angular v12. It's still to be determined in which version we'll fully drop IE11 support, but that would be the prereq for us moving to a CSS variable based theming system.
The switch over the using MDC Web under the hood is going to make this much easier for us at that point, but I don't have an ETA. We're actively rolling out the new versions to teams inside Google and using their feedback to fix bugs and make improvements before we lock into a stable API on npm.
Thanks for confirming, @jelbourn.
Do the MDC-based variants in Angular Material Experimental have feature parity? Are you looking for external feedback or contributions?
The MDC-based components in experimental should have feature parity with the existing components. Except for chips, they should all also be API compatible (i.e., the exact same APIs). The caveats are:
- List is not done because MDC just rewrote it recently
- MDC also rewrote their chips recently and we need to update ours
- Our mdc-based slider is in progress (but it will have range support)
- Toggle buttons are planned by MDC but haven't been finished yet
We're happy to get any feedback, though we haven't put out any public docs yet on adopting the new versions, so there might be some bumps in that regard. When we do eventually move them into stable, there will be automated tooling to assist (which we've been using and refining inside Google so far).
@jelbourn That sounds great. Thanks for the update, looking forward to see how this comes together 🙌 I think CSS Custom Properties will make a lot of issues go away. Interesting to see which future this opens up for Angular Components.
We do indeed plan on deprecating support for IE11 in Angular v12. It's still to be determined in which version we'll fully drop IE11 support, but that would be the prereq for us moving to a CSS variable based theming system.
According to the Angular v12 relase post, IE11 will be dropped in v13. I guess that makes it possible to move forward with this issue. Though I guess it still takes some thought with the effort to rewrite the components to use MDC.
Yeah, we're formally dropping IE11 in v13. Updating our theming system to use CSS variables is near the top of my list of things to focus on next. One thing we're waiting on, though, is for MDC to finish updating their own theming APIs to better align with ours. You can see an example of this in https://github.com/angular/components/pull/23143, which covers the slide-toggle
