Open joneff opened 5 years ago
In our company we are very interested in this feature. It would allow us to change Theme at run-time, based on logged in user.
Choosing custom theme is a must nowadays. Every serious web application supports it. And a lot of desktop applications support it to. At least light and dark.
I had another idea, which may be easier/quicker to implement: I am building Angular application and I am using Kendo UI for Angular and SASS. It would be awesome if SASS variable could accept CSS variable (for example):
$primary: #73B3A2
$primary: var(--my-app-primary-color)
I think this would work, but we need theme without processing colors like this:
//File: node_modules\@progress\kendo-theme-material\modules\@progress\kendo-theme-default\scss\mixins\_colors.scss
@function true-mix($color1, $color2, $weight: 50%) {
@return mix(rgba($color1, 1), rgba($color2, 1), $weight);
}
What do you think @joneff ? Any timeline?
I've got the same error. :( I'm really waiting for this feature.
Is it possible to implement, @joneff?
Colleagues, maybe you can help with the answer about the timeline? @veselints @vladimirivanoviliev @Dimitar-Goshev @elena-gancheva
I've prepared a small PR (#1677) and while parts of the discussions should be there, here are a couple of key points:
null
value and do not generate output when there is no need, which is not the case with css variables;null
value will fallback to prop: initial
null
, so should we provide a fallback to normal state?prop: k-var( --kendo-css-var, $kendo-sass-var )
and have a $use-css-variables
switch...Apart from that, it looks like it would be doable to have e theme that's based on css variables but can also benefit from sass toolchain.
@bundyo your feedback will be appreciated
The first patch of @progress/kendo-theme-nouvelle is published. It contains only a fragment of the button styles just so we can check how it works.
v0.1.0-dev.a9a94db3 is out. It adds border radius variable (previously left out) and two basic input components, input and autocomplete, to test how linked variables will behave.
Note: the autocomplete is missing the dropdown part. That will come with the next dev version and will include more or less complete button and input styles.
@progress/kendo-theme-nouvelle@0.2.0-dev.d9fa428d version is out (#1764)
Notes:
Loose "roadmap" ahead:
This looks nice joneff. Can we get also "loose" dates. I am only interested when all components are supported. But I am happy to see that work is putting on this issue.
A theme, depending on the complexity takes about a year to create. Depending on the theme and whether or not it's based on external (third party) designs (Bootstrap, Material) will then need a couple of more months to polish, because during that year the designs have changed.
For 2020 R3, which is about three weeks away, we want to deliver v 0.2.0 (all inputs) for kendo-theme-nouvelle. And while I am saying inputs, one of those includes a calendar, which by itself is pretty complex piece of component (and themes).
For any further versions, sadly, I can not comment. As much as we want to deliver a basic grid, and I do mean basic -- something like https://demos.telerik.com/kendo-ui/grid/from-table -- that will require some negotiation. Here is what I mean by that:
For everything else beyond that basic, first we need to cover many more components: a grid may have popup editing (that implies window or dialog); a grid may use forms (that implies the form layout); a grid may have a toolbar; a grid may have a pager ...
Considering this is not the even he first version, I guess we could "get away", initially, with not delivering those essential parts of the grid to showcase what the grid could be. But after that, we'll need to catch up with the said requirements.
I know the above answer is, to put it mildly, vague. But we don't want to disappoint when we deliver v 0.2, 0.3 ... all the way to v1.
Thanks for the heads up @joneff. We will continue to use the new features brought by the nouvelle theme along with bootstrap theme to cover missing elements. Appreciate your work on this topic!
As an enterprise Kendo Angular user, I am glad to discover that a theme built with CSS custom properties is in the works!
Due to how our versioning works, we did release v0.2.0, but it doesn't contain the styles, yet. Still, we are making progress:
@progress/kendo-font-icons
After the second one is done, or to be precise, when the inputs are refactored, we'll review the styles in nouvelle and ship the next minor version.
+1 - we need this for upcoming project and must have css variables support because we must support run-time dynamic themes in angular app.
Can you share an updated timeline on when the entire library / theme will support css variables?
Could we have an update on this? This could be a deal breaker for us adopting kendo ui. Thank you
We've paused the development slightly before we figure out few key aspects:
:pseudo
selectors explosion -- that's a bit tricky. in essence, we want:// write
.k-button:hover { ... }
// get
.k-button:hover,
.k-button.k-hover {}
// and the tricky part
.k-button:focus {}
to
.k-button:focus,
.k-button.k-focus { .. }
.k-button:focus-within { ... }
Those are needed.
Here is a ... sort of tentative timeline:
Most components can be delivered within the 2021 R3 timeframe. The grid, however, should take more time. (For what is worth, even the scheduler is a less complicated component than the grid.)
How does it sound?
Hi @joneff,
I don't quite understand the example you gave (:hover vs .k-hover, etc).
The earlier the release date is, the better 😄
We have started to use this theme along with the bootstrap theme since the early alpha you provided. The real issue for us, as of now, is to deal with two different themes (nouvelle theme overrides bootstrap theme wherever possible) and to only partially use CSS variables.
We had to disable encapsulation on many components that are using Kendo UI components, due to the impossibility of styling them properly with CSS variables only. We have a lot of TODO marks all over our CSS files, like "remove this selector once Kendo UI support CSS variables for component xyz".
We are still available to share our progress or experience if that can be of any help.
Regards
@CheetahDev I will elaborate on :hover -> .k-hover
Examine at https://github.com/telerik/kendo-themes/blob/develop/packages/default/scss/button/_theme.scss#L58
As per spec, only buttons, forms etc, can have disabled attribute, hence <span class="k-button" disabled></span>
will not be matched. That's why we have k-state-PSEUDO
class names like k-state-hover
or k-state-disabled
-- so we can apply those programmatically.
When we give the Nouvelle theme a long overdue update, I will ping you in the PR if we are going in the right direction.
Hi @joneff,
Sorry for my late reply, forgot to answer. Thanks for the example, got it!
I see that you released a 4.40.x version of the nouvelle theme. Is it just a version bump or is there a changelog we can read?
We still have to manage both theme at the same time: nouvelle to leverage CSS props wherever we can, and bootstrap with selector overrides as a fallback.
As we have made some important UI progress since the last time we spoke on a call, we can maybe arrange a new one in the upcoming weeks if that can be of any help.
Regards
@CheetahDev indeed it was just a version bump to align all themes. Sort of -- make it easier for developers to know easily which the latest version is and to manage dependencies easier.
That out of the way, here is a long overdue update on nouvelle theme:
From the start, nouvelle was (and still is, to an extent) a technological preview -- what we could do if we were not bound by any restrictions i.e. how would front end developers create a theme for Kendo UI components, framework limitations and browser support aside.
As you can imagine, that's not always possible and the theme has been in development limbo for a while...
... HOWEVER ...
Starting right after September 6th, development will resume on the next major version of the themes, nouvelle included. There will be a technology preview channel which will see 3 intermediate releases (alpha, beta, rc) every 6 weeks, one "dev" release every week, and one final in 2022 R1. That 6 weeks schedule is something we established and it seems to be working and provides predictable updates.
So what would be the things we would work on? How would it reflect in nouvelle?
Our goal is to have sizing options (component sizes) and shape customization (read border-radius) in all inputs and buttons for all themes, like I said, nouvelle included. When I say inputs, I mean all the various pickers and editors, as well as child components like calendar (for datepicker), slider for color picker ...
Major spoiler: those improvements will require changes in rendering, which would be handled by component API (properties) so themes will not be usable directly against productions code... with the exception of nouvelle, which will see some backporting of features.
By backporting I mean ... say we have different sizes for buttons -- k-button-sm|md|lg
. Obviously, with no component actually having the API, developers will need to set the classname themselves and it will work only in nouvelle.
Regarding styling and css variables -- we are going to continue to use them, albeit with a slightly different approach: sass variables, unlike css variable, can have a null
value, which when processed removes the rule. When used in combination with css variable, it keeps the rule, which invalidates and resets the value of the property in question to "initial"... To avoid that, we are going to, probably, use an intermediate function, something like color: k-var(button-text, $button-text), which will check for
null` value.
Also, in recent months, variable ownership has become ... well it's a thing. It's often that we have reports about $primary
being a map or a boolean in customer code bases and our themes being hard to compile for that reason. To avoid this, all css variables will be prefixed with --kendo-
, which is one more reason to use intermediate function. But then we have trends... some folks already use --color
and --background-color
similarly named css variables and we have requests for that too...
The final outcome of all those might look like:
// Layout
.k-button {
color: var(--color);
background-color: var(--background-color);
border-color: var(--border-color);
}
// Theme
.k-button {
--color: var(--kendo-button-text, $kendo-button-text);
--background-color: var(--kendo-button-bg, $kendo-button-bg);
--border-color: var(--kendo-button-border, $kendo-button-border);
}
.k-button:hover {
--color: var(--kendo-button-hover-text, $kendo-button-hover-text);
--background-color: var(--kendo-button-hover-bg, $kendo-button-hover-bg);
--border-color: var(--kendo-button-hover-border, $kendo-button-hover-border);
}
Intrestingly enough, the selector for button hover state, while with specificity 0 2 0
, can be overriden with 0 1 0
selector, if it targets the actual properties rather than the custom properties...
So this is all for now! Be on the lookout for the first v5-dev
version on the 13th.
IMPORTANT: it goes without saying that "dev", "alpha", "beta" and "candidate" versions are not suited for production. We intend to use them to showcase what we are working on and to collect feedback on what we did good, what can be improved and what we did utterly wrong.
Thanks for this update @joneff ! Looking forward to give it a try.
By the way, we just finished our v1 theme. It relies at 100% on CSS props. It enables our customers to customize the look and feel of our components.
The customization pattern is as follow (from customer facing to internal stuff):
Only the first level (app properties) is intended to be modified by our customers or consultants. The second level (framework properties) is maintained by our core framework team. Sub levels (third-party properties) depend on providers such as you (Kendo UI) or others (ex: Ionic)
Don't hesitate to reach out if you want to see how we managed this.
J.
From #2826:
Note: this introduces backwards incompatible behaviour for nouvelle, but the theme hasn't had its "v1" release yet (which will be v5...)
Two major changes: :where
styles and new modules system
:where
styles
We began using the selector for component styles. Considering this is a selector that doesn't increase specificity, any selector would override it. That means utility classnames, both from our themes or third parties, should, in theory, work by overriding our styles. A highly-enough requested feature to be able to apply third party classnames to kendo components.
Note: each and every developer is responsible for what third party class names do to Kendo UI components! Bootstrap's form-component
will, in all certainty, break the layout of every Kendo UI form component.
new module system (WIP)
That's the more important bit: our current module system employs some very unsavoury practices, like loading all required components. It may sound like a good idea, but at the end, the button styles get loaded like a gazillion of themes, which leads to exponential build times in the magnitude of ... well a lot. We also employ some other practices to plugin to node-sass / dart-sass and speed up our build process and bring time down to just over a second for a theme.
That being said, not everyone uses those (even though our "shortcuts" are available as @progress/kendo-theme-tasks
) and build time is generally slow.
The new module system, which, I cannot stress enough, is still work in progress, should solve those issues. Build time should be as linear as it gets.
Where as previously, if somebody wants a custom build of Kendo UI themes, they would have to import all components they need (which leads to the aforementioned exponentially slow build time), this time around, everything is imported once and a single configuration is provided. When we are done, it should something like:
// For all components
@import "~@progress/kendo-theme-NAME/dist/all.scss";
// For some components
$kendo-theme-config: (
components: (
"grid",
"scheduler",
)
);
@import "~@progress/kendo-theme-NAME/dist/all.scss";
Hi @joneff
I just tried to upgrade my dependencies but it went not as smooth as expected.
New stuff from buttons (all new classes added after k-button) break many things. All CSS properties brought by nouvelle theme are properly added on our end, but these new classes overwrite most of them (cause background etc are directly set on one of the new class).
Since the early tests with nouvelle theme, we are using both bootstrap theme and nouvelle theme (nouvelle is set after bootstrap in the angular.json config file). I'm wondering if this is still the way to go, as more components are being available in nouvelle theme... and this time the update of bootstrap lead to many UI glitches.
Any idea?
Edit: Ok, seems that most issues come from :where change. As we define both themes, classes from bootstrap theme override the :where selector from nouvelle. I'm wondering what would be the best option... generating a custom CSS file in which we only pick style for components that are not yet available in nouvelle?
Thanks
Similar issue here, we are using default version with just color updates using KendoVariables and recently we adopted CSS variables that is passed from :root
and we had errors because initially variables are populated and it causes CSS functions used inside Kendo to error.
Example
// _kendo-variables.scss
// My variables
$default-border: var(--colorsBorderGrey, $color-neutral-60);
// Kendo Stuff
$input-border: $default-border;
What is status on this?
https://www.npmjs.com/package/@progress/kendo-theme-nouvelle says a new release was done 9 days ago, but usage links are pretty broken and it still says it needs to be configured via SCSS builds.
Could it include some default css variable setup to match some of the existing layouts as much as possible (such as default and default-dark, etc... IE similar to https://github.com/telerik/kendo-themes/tree/develop/packages/default/lib/swatches just in css)
I am sure I commented this somewhere: for 2023 R1 nouvelle theme will be ready without the bigger components, such as grid. In the meantime, we also have the Fluent theme, which can also be customized with css variables.
We are ironing out some quirks related to css variables and their usage; the complexity of customization and so on and so forth.
Hi @joneff and happy new year!
2023 R1 should be out next week and I don't see the nouvelle theme in the post: https://www.telerik.com/campaigns/kendo-ui-r1-2023-release-webinar
Is it still scheduled for this release?
We'll not talk about the nouvelle theme in webinars until it's completely completed -- all components with all the features etc.
In the meantime, improvements are ongoing, albeit a bit off schedule due to unforeseen ... well other stuff got in the way.
I will keep you updated.
Update: @CheetahDev Likes I said, a bit off schedule, but still -- #4222.
I'm evaluating using Kendo React for a large greenfield project in our organization. Is there a resource someone here could point our team toward that indicate how far out Nouvelle is?
I like the idea of utilizing CSS variables for theming the application, but Fluent isn't for us.
Hello @paynecodes, we are moving towards CSS variables for the other kendo themes as well and this will happen after https://github.com/telerik/kendo-themes/issues/4104 issue. Could you share your thoughts what would you like differently in the Fluent theme?
Hello @paynecodes, we are moving towards CSS variables for the other kendo themes as well and this will happen after #4104 issue. Could you share your thoughts what would you like differently in the Fluent theme?
Hello @elena-gancheva,
Will you still keep the nouvelle theme along the others?
Hi @joneff @elena-gancheva,
We will soon update our platform from Kendo UI Angular R1 2022 to the latest version. Lots of changes have been introduced since R1 2022, especially on theming stuff. Before we start the upgrade, we'd like to have some update both on :
Thanks!
What is the status of this currently, as applied to the Bootstrap theme?
I have a multi-tenant app and want to be able to apply CSS customization on a per-tenant basis at runtime by having JavaScript set a minimal number of variables with values that are sourced in the database.
Thanks!
Rationale
Our themes, as of now, are based on explicit values and that comes with it's short comings. CSS variables might be able to solve some of those, especially nesting selectors and customization.
Consider the following for button and toolbar button:
That will enable us not to override the complete selector and in terms increase complexity. It may also be possible to solve #450 (Allow multiple themes for the same component on the same page).
Solution
The new theme, as of July 2020, we'll be called kendo-theme-nouvelle and we'll try to keep it as close as possible to kendo-theme-default in terms of appearance. Until we reach reaches v1 (in semantic terms), the theme will be experimental:
:focus-within
selectorsWe'll start with the basics: buttons, inputs and build on top. As such, components like the grid will come last.
Update (01/07/2020)