Skip to content
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

Detach kendo-theme-bootstrap from twbs/bootstrap #4176

Closed
4 of 12 tasks
joneff opened this issue Dec 16, 2022 · 3 comments
Closed
4 of 12 tasks

Detach kendo-theme-bootstrap from twbs/bootstrap #4176

joneff opened this issue Dec 16, 2022 · 3 comments
Labels
Breaking Change Item which is introducing a breaking change. Enhancement New feature of an existing functionality or an improvement of an existing functionality. Epic A non-trivial issue that resolves large-scale problems SEV:Critical T:Bootstrap Kendo Theme Bootstrap
Milestone

Comments

@joneff
Copy link
Contributor

joneff commented Dec 16, 2022

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 dependency

A list of issue to check if are still relevant after the detaching:

cc @telerik/kendo-front-end @telerik/web-components-lt

@joneff joneff added Enhancement New feature of an existing functionality or an improvement of an existing functionality. T:Bootstrap Kendo Theme Bootstrap SEV:Critical Breaking Change Item which is introducing a breaking change. labels Dec 16, 2022
@joneff joneff added this to the 2023.1 milestone Dec 16, 2022
@joneff joneff pinned this issue Dec 16, 2022
@Juveniel Juveniel modified the milestones: 2023.1, 2023.2 Jan 11, 2023
@Juveniel
Copy link
Contributor

@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 ?

@Juveniel Juveniel removed this from the 2023.2 milestone May 22, 2023
@joneff joneff added the Epic A non-trivial issue that resolves large-scale problems label Jun 13, 2023
@joneff
Copy link
Contributor Author

joneff commented Jun 13, 2023

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.

@inikolova
Copy link
Contributor

Effective with the R4 2024 release (v10.0.0), twbs/bootstrap is removed as a dependency of the Telerik and Kendo UI Bootstrap theme:
8c1f9c8

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 *;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Item which is introducing a breaking change. Enhancement New feature of an existing functionality or an improvement of an existing functionality. Epic A non-trivial issue that resolves large-scale problems SEV:Critical T:Bootstrap Kendo Theme Bootstrap
Projects
None yet
Development

No branches or pull requests

3 participants