[Solved] V12.3 to V13.0 changes to k-button

[Rob]

It seems changes made to CSS in V13 has triggered a code effort to "correct" as per article here:

https://www.telerik.com/blazor-ui/documentation/upgrade/rendering-changes/13-0-0

Not sure why this was done, but it's left us with dropdownlist and grids and many buttons much larger than before and as such as increased the row heights causing a BIG mess.

I can go thru the Developer mode for Edge and trying to locate all the offending changes, but that's time consuming.  Can I get a more comprehensive list of what exactly was changed and what CSS k classes I'll need to address to get this back to what was working in v12.3?

Rob.

[Rob]

I adjusted as follows (to recover spacing):

.k-grid.k-grid-sm .k-table .k-edit-cell, .k-grid.k-grid-sm .k-table .k-command-cell, .k-grid.k-grid-sm .k-table .k-grid-edit-row td, .k-grid.k-grid-sm .k-table .k-grid-edit-row .k-table-td, .k-grid .k-grid.k-grid-sm .k-table .k-edit-cell, .k-grid .k-grid.k-grid-sm .k-table .k-command-cell, .k-grid .k-grid.k-grid-sm .k-table .k-grid-edit-row td, .k-grid .k-grid.k-grid-sm .k-table .k-grid-edit-row .k-table-td {
    padding-block: var(--kendo-spacing-1, 0.25rem);
    padding-inline: var(--kendo-spacing-1, 0.25rem);
}

I'm not sure why you folks like to default to massive empty space in your CSS, it's never something end users really want and for lower resolution displays or scaling on desktop computer it's a huge waste of space.   For mobile devices we're operating a very different UI anyway, so I don't really understand some of you default choices when it comes to margins and padding.

[Dimo]

Hello Rob,

The change in our theming mechanism has the following benefits:

• Appearance related component parameters (like ThemeColor, Size, Rounded, FillMode) must no longer have hard-coded default values in the components. The default values now depend entirely on the theme.
• The themes are now more flexible to control the above appearance settings directly, including:
  • When nesting components. For example, a component may use different appearance settings when used standalone and when nested in a specific parent.
  • Across different themes. For example, a component may use different appearance settings with the Bootstrap or Material themes, which have their own unique design language.
• Fewer rendered CSS classes and smaller HTML footprint.

The theming change could impact apps that used custom CSS code with CSS classes that are no longer rendered. Is this your use case? If yes, then you can replace the non-rendered CSS classes with rendered ones, for example, use .k-button instead of .k-button-md. This will spare you the need to set Medium Size explicitly to restore the functionality of the custom CSS code.

Another thing that you can do to make our components more compact is to override the spacing-related variables:

• Example with Blazor components
• List of all spacing variables

Overriding theme variable values affects all components that use them, so you don't have to implement and maintain multiple CSS rules that target separate components or elements.

Regards,
Dimo
Progress Telerik

[Rob]

Hi Dimo,

Yes, the CSS classes that are no longer rendered (as in .k-button-md).  Is there a list so we can go thru our custom CSS code and see if we need to make adjustments?

 

Rob.

[Dimo]

Hi Rob,

Please check the updated article Rendering Changes in Version 13.0.0. I didn't list all possible CSS classes, as they are too many, and moreover, components with non-default settings will still look the same anyway. I described the appearance CSS classes' naming convention and I hope this will be enough to proceed. You will mostly need to look for -md and -solid.