-
Notifications
You must be signed in to change notification settings - Fork 6.7k
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support theming with CSS Custom Properties #4352
Comments
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. |
Is there a timeline on this yet? |
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. |
Before, the material font-family could only be set at application build-time. Now, developers can modify the material font-family at runtime by setting the --mat-font-family css variable. This will greatly improve the application's ability to be themed dynamically at runtime and with WYSIWYG material theme editors. This commit partially addresses this feature request: angular#4352
Before, the material font-family could only be set at application build-time. Now, developers can modify the material font-family at runtime by setting the --mat-font-family css variable. This will greatly improve the application's ability to be themed dynamically at runtime and with WYSIWYG material theme editors. This commit partially addresses this feature request: angular#4352
Before, the material font-family could only be set at application build-time. Now, developers can modify the material font-family at runtime by setting the --mat-font-family css variable. This will greatly improve the application's ability to be themed dynamically at runtime and with WYSIWYG material theme editors. This commit partially addresses this feature request: angular#4352
Before, the material font-family could only be set at application build-time. Now, developers can modify the material font-family at runtime by setting the --mat-font-family css variable. This will greatly improve the application's ability to be themed dynamically at runtime and with WYSIWYG material theme editors. This commit partially addresses this feature request: angular#4352
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. |
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
|
This comment has been minimized.
This comment has been minimized.
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. |
Nobody prevents you from installing Chrome on Windows 8 as well ;) |
@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. |
This comment has been minimized.
This comment has been minimized.
@darkbasic Please keep your language professional. |
@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. |
According to Microsofts FAQ, Edge can't be installed on Windows 8.1
|
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. |
Has anyone tried my polyfill? |
Could we have an update on this? It's been more than 6 months since the last update. |
|
So when can we expect that migration, in Angular 12 or Angular 13+? |
I don't know. It's been ongoing for years. |
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:
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 |
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 #23143, which covers the slide-toggle |
Hey @jelbourn, |
I was wondering if there are any updates on this? |
Looks like Angular Material transitions to MDC-based components in Angular Material version 15: https://github.com/angular/components/pulls?q=is%3Apr+sort%3Aupdated-desc+%22use+mdc%22 |
We migrated our project to Angular Material 15, but it seems MDC-based componets doesn't solve the problem. We have exactly two issues that block us from defining the primary, accent and warn colors as CSS variables. mat.define-palette((
...
500: var(--primary-color-500),
...
)) The first issue is in _progress-bar-theme.scss on the line 16: track-color: color.adjust(mdc-theme-color.prop-value($color), $alpha: -0.75), Calling the function color.adjust causes this error: The second issue is in _mdc-helpers.scss inside the mixin using-mdc-theme: mdc-theme-color.$on-primary:
if(mdc-theme-color.contrast-tone(mdc-theme-color.$primary) == 'dark', #000, #fff); Calling the function mdc-theme-color.contrast-tone causes this warning: Without these two issues, the colors defined as CSS properties would work fine. |
@suchar-intens, yes this is tracked in #25981 |
Any news would be very appreciated! |
Any news on this? |
In a new project, I tried to use CSS custom properteis to theme my own components. I never really liked theming my own components using SCSS because:
What I now did is to define all available theming properties as css properties under
Defining an additional dark theme looks like this:
This way you can simply use it in your
In my opinion this is a lot simpler and will hopefully become the default for theming your own components. |
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:
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.
The text was updated successfully, but these errors were encountered: