Closed joneff closed 2 weeks ago
@joneff I suggest to try and move for this breaking change with the R1 release, so that we can polish and fix all related issues ?
Considering Bootstrap 5.3 is out and it's for all intents and purposes it's a major (breaking) release masked as a minor that's the timeframe we are looking at.
Effective with the R4 2024 release (v10.0.0), twbs/bootstrap is removed as a dependency of the Telerik and Kendo UI Bootstrap theme: https://github.com/telerik/kendo-themes/pull/5165/commits/8c1f9c835cced5f8b588a4072a47d84b66221345
This means that customising twbs/bootstrap scss variables will no longer have an effect on the Telerik and Kendo UI Bootstrap theme. However, we will provide mostly the same look and feel through variables that have the same values as those in twbs/bootstrap.
To continue using twbs/bootstrap with the Telerik and Kendo UI Bootstrap theme, ensure that you add it as a dependency in your project by following the official documentation, and use it in your project:
@use '@progress/kendo-theme-bootstrap/scss/all.scss' as *;
@use 'bootstrap/scss/bootstrap' as *;
Looking at the latest changes in twbs/bootstrap, it has become apparent, that it will be harder and harder to have a theme based, as in depends, on bootstrap. Bootstrap is moving ahead with implementing styling trough custom properties (CSS variables) at a pace of their own that's, at the very least, not predictable. While there is nothing inherently wrong with using custom properties, it does present to major challenges, and I will elaborate:
1) we can no longer rely that a sass variable are resolvable during compile-time 2) rogue custom properties from a page can affect us in unpredictable way
Sass variables are no longer resolvable during compile-time
When doing any compile-time calculation, be it math, color manipulation, string manipulation, we rely that variables we receive are resolvable i.e. we work with pointers to either sass values or css property values. Receiving another type of value i.e. custom property will break that logic and in terms will fail the compilation. We've seen this behaviour enough times in the likes of
$color is not a color
.Rogue custom properties
While the first behaviour would break compilation and inform the respective user that there is an issue, the second problem happens in the browser: a custom property can propagate and customize our components in unpredictable ways. It could event be an unintentional side effect of simply having bootstrap on the page!
Ugly design aside, this could result in unreadable content. Say we have a component with resolved white background and text that uses custom property. Along comes dark mode and we have white on white.
What it means to developers?
The biggest and notable difference will be that customizing bootstrap scss variables will no longer have effect on our components, as the theme will be detached i.e. not depending upon. Of course, we'll provide mostly the same look and feel trough variables that have the same values. We'll update the variables on every minor release.
I say mostly, because we do have some components that predate bootstraps own components. On the top of my head, I can think of breadcrumb and panelbar (accordion).
As soon as Bootstrap enters a stable state, of sorts, we can provide our won custom property map that is based on theirs. That part will surely take some time, though.
What it means to us?
It means remove bootstrap as dependency and ensure the theme compiles and looks the same:
1) create a list of components that we have parity with bootstrap 2) prefix our scss variables with
kendo-
for those components 3) link those variables to existing variables in our themes, or create new ones 3.1) We'll need to touch the sizing map to allow for half sizes 4) Document 5) remove bootstrap as a dependencyA list of issue to check if are still relevant after the detaching:
cc @telerik/kendo-front-end @telerik/web-components-lt