You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem with the above code is that @import statements work only on the root level (cannot be nested in selectors), and that theme variables are defined globally with the first import.
What is the motivation or use case for changing the behavior?
Resolving this problem allows customers to have different component themes defined in the same file.
Implementation suggestion
This functionality can be accomplished by using mixins instead of outputting CSS directly from SASS modules:
// include mixin API@import"~@progress/kendo-theme-default/scss/api";
// theme definitions$light-theme: (
'dropdown-bg': '#eee',
'dropdown-hover-bg': '#ccc'
);
$dark-theme: (
'dropdown-bg': '#444',
'dropdown-hover-bg': '#666'
);
// single file with multiple kendo themes.light {
@includekendo-dropdownlist($light-theme)
}
.dark {
@includekendo-dropdownlist($dark-theme)
}
// access theme variable (instead of relying on global variables$kendo-dropdownlist-bg: map-get($dark-theme, 'dropdownlist-bg');
Note that the suggested approach can be implemented and used as a new backbone for the themes. Once ready, the global variables can be removed in a new major version. This resolves name clashes between the theme and other frameworks, too.
The text was updated successfully, but these errors were encountered:
Hello, I would be great if we can have multiple theme for the same application. In my case I want to use the default theme for all the controls except for datetimepicker, datepicker, text boxes that I want to use material theme
I'm submitting a...
Current behavior
A component can import only one theme. If you need light and dark dropdowns on the same page, they need to be compiled in different CSS files.
Expected behavior
Allow compilation of scoped themes, e.g.
The problem with the above code is that
@import
statements work only on the root level (cannot be nested in selectors), and that theme variables are defined globally with the first import.What is the motivation or use case for changing the behavior?
Resolving this problem allows customers to have different component themes defined in the same file.
Implementation suggestion
This functionality can be accomplished by using mixins instead of outputting CSS directly from SASS modules:
Note that the suggested approach can be implemented and used as a new backbone for the themes. Once ready, the global variables can be removed in a new major version. This resolves name clashes between the theme and other frameworks, too.
The text was updated successfully, but these errors were encountered: