Declined
Last Updated: 08 Jul 2024 09:08 by ADMIN
Michael D
Created on: 14 Jun 2022 06:26
Category: Kendo UI for jQuery
Type: Bug Report
0
Input controls do not override button's border radius

In the latest version of Kendo UI, various input controls like the NumericTextBox or the ColorPicker now consist of an input field and a button control (used for increasing/decreasing the value or opening the dropdown).

The border-radius for those widgets can be controlled by setting the "rounded" option. At the same time, when using SASS themes, a button's default border-radius might be set using the $kendo-button-border-radius variable. The buttons inside e.g. a NumericTextBox do not override the theme's border-radius which leads to an outcome like this:

Widgets that use Buttons internally (and therefore offer no way of overriding the button's border-radius by setting its "rounded" option manually) should override the default styles.

Unfortunately, I could not reproduce the behavior in a DOJO, because I cannot transpile SASS themes there.

11 comments
ADMIN
Georgi Denchev
Posted on: 08 Jul 2024 09:08

Hi, Michael,

I apologize, however I do not see this is a valid request, at least as far as I can understand it.

The following statement is not correct in my opinion(unless we are talking about breaking the functionality itself, not the styling):

If some global styling may break a widget, the widget must prevent that itself

If a developer wishes to set a certain style, to a certain element, the style must be applied. Dismissing styles applied by the developer would be a bad practice as there will be no way to tell who expects what result. If applying a custom style leads to some undesired visual effect then it is the job of the developer to remedy the problem and update the appearance to their liking.

The NumericTextBox functions normally with or without the rounding:

https://dojo.telerik.com/@gdenchev/ecAwOREt 

As I mentioned in my previous reply, if the goal is to apply rounding to all buttons except the spinners, then the selectors must be updated.

Best Regards,
Georgi Denchev
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Kendo family, check out our getting started resources
Michael D
Posted on: 01 Jul 2024 10:19

I fully understand that configuring all details of internally used widgets is neither feasible nor a good idea. But this is not what I wanted to address with this bug report.
I would rather say that the main issue is that by setting global variables (like $kendo-button-border-radius) one could destroy the layout of unrelated widgets (like the NumericTextBox).

If I want to apply some specific border-radius to all buttons, the easiest and most straight-forward solution is to set $kendo-button-border-radius. However, any border-radius other than 0 does not work with the spinner buttons in the NumericTextBox or you get the weird results shown in the original post. Currently, when setting $kendo-button-border-radius, I have to take care of "reparing" the textBox due to rendering issues of some internals - fixing internals, however, is the job of the creators of Kendo-UI as they know best which internals are used and how they interact. If some global styling may break a widget, the widget must prevent that itself (e.g. by setting a border-radius that fits its current style and therefore overriding the global $kendo-button-border-radius value).

I hope this clears things up a bit.

ADMIN
Georgi Denchev
Posted on: 29 Apr 2024 14:03

Hi, Michael,

Just to summarize what has been said so far, the main issue behind this thread is that there is no built-in way to change the more granular elements of a component, is that correct?

For example the numerictextbox consists of an input and two buttons. The `rounded` style is applied to the component as a whole, not to its individual parts.

More granular styles have to be applied manually as there is no way to cover all cases for all widgets.

Taking the numerictexbox as an example, if we want to change the spinner buttons without affecting any other button in the application, then we would target their respective classes:

.k-spinner-increase,.k-spinner-decrease {
border-radius: 10px;
}

If we want to target every single button in a particular component, then again, we would use the appropriate selectors:

/* k-grid, .k-numerictextbox, k-dropdownlist, etc. */
.k-widgetname .k-button {
 border-radius: 10px;
}

If we want to target all buttons, except the ones in the numeric:

      .k-button:not(.k-spinner-increase,.k-spinner-decrease) {
        border-radius: 10px;
      }

The possibilities are countless and they can vary depending on the needs of the application/design. That is why the more optimal way would be to use customized CSS.

If every single case was covered in the component options, then the object will probably reach hundreds of lines of code just for its styling. This is something that should be handled in the themes themselves, either by modifying the existing Kendo SASS themes or with plain CSS.

Let me know in case I misunderstood the report.

Best Regards,
Georgi Denchev
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Kendo family, check out our getting started resources
Michael D
Posted on: 23 Apr 2024 06:39

I'll try to clarify the issue some more. Imagine the following scenario:

  1. On a page, there is a NumericTextBox widget that internally creates two spinner buttons that allow the user to increase/decrease the value step by step.
  2. We also want to render a rounded button. To have full control over the amount of border-radius applied, we have adapted the $kendo-button-border-radius variable that SASS-based themes offer.

Sadly, setting $kendo-button-border-radius also influences the border-radius of the spinner buttons inside the NumericTextBox. This DOJO demonstrates the described scenario. Note that, as in previous posts, I had to "fake" setting the SASS variable to be able to put all this into a DOJO.

Why do developers have to adapt internal stylings of an (at first sight) unrelated widget when changing the appearance of a different one?


ADMIN
Martin
Posted on: 18 Mar 2024 08:13

Hello, Michael,

If there were no actions after our last discussion on the matter in later releases, our front-end team have decided that no changes are required. Still, if you think that the thread should be reviewed, kindly summarize all the information that would be useful for our front-ends. If the issue can be demonstrated in a Dojo example, that should ease their work.

Thank you in advance for your cooperation. Looking forward to your reply.

Regards,
Martin
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Kendo family, check out our getting started resources
Michael D
Posted on: 11 Mar 2024 14:23
While doing our regular housekeeping tasks, I have stumbled over this issue again. Are there any news on this?
ADMIN
Martin
Posted on: 27 Jul 2022 06:43

Hello, Michael,

Thanks again for your feedback on the matter. I will pass it along to the team.

Regards,
Martin
Progress Telerik

The Premier Dev Conference is back! 

Coming to you live from Progress360 in-person or on your own time, DevReach for all. Register Today.


Michael D
Posted on: 20 Jul 2022 06:58

Hi Martin!

Sorry for the late reply.

I fully understand your concerns regarding the reusability and maintainability of widgets. However, if a widget like the NumericTextBox uses a widget like the button, the NumericTextBox is responsible for handling the button and not anything that wraps the two of them - the wrapper should not even know that there's a button to deal with in the first place.

This principle should not only be applied for behavior, but also for the appearance of widgets. In other words: It should not matter if settings come via a JS configuration option or a SASS variable. Buttons can be styled via the $kendo-button-border-radius variable and the NumericTextBox has to deal with it. If it cannot prevent rounded corners via configuration, it has to disable them in CSS.

I am not saying that the solution you suggested is wrong, but rather that it should be part of the NumericTextBox widget and the NumericTextBox widget only.

Maybe a last addition: At least in version 2022.2.510, .k-button applies the border-radius regardless of the presence of a .k-rounded class (see ./scss/button/_layout.scss)

ADMIN
Martin
Posted on: 28 Jun 2022 12:08

Hello, Michael,

The k-button class is the base class for the Button and there is no way for us to ignore it when integrating the Button in other widgets. We are re-using the styles in order to achieve effectiveness and better maintenance. When it comes to styling the Kendo widgets, one must keep in mind the child components used and that global styles are expected to affect them.  When custom CSS rules should be applied, we normally leave it up to the developers to take care for such cases due to the specifics of their requirement.

I hope that clears things up. Let me know if you have any further questions.

Regards,
Martin
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Michael D
Posted on: 21 Jun 2022 12:23

Thank you for your solution. This is the way we are currently fixing the problem. However, this means that a developer using a widget - in the previous example the NumericTextBox - has to know about its internals - the buttons - and how to style them.

Since the way a NumericTextBox is built and the elements it consists of may change, this fix may easily break with a future update. Also, we have no control over the internals of a widget, so only the widget itself should manipulate them (Open/Closed Principle).

Also, there is no situation where a NumericTextBox should look like in the provided image - no matter if it has rounded corners or not. This is why (in my opinion) the described behavior is a bug of the NumericTextBox widget.

ADMIN
Martin
Posted on: 20 Jun 2022 12:40

Hello, Michael,

If you wish to avoid setting a custom border-radius for the buttons in the NumericTextBox widget, you can use the CSS below.

.k-rounded-md .k-button,
       .k-rounded-sm .k-button,
       .k-rounded-lg .k-button {
         border-radius: 0px;
       }

Here is a small example for reference. You can see that the k-button rule will set a custom border radius for the buttons, but the rules applied for the .k-rounded-{size} .k-button selector will prevent the 10px border radius applying for the inner NumericTextBox buttons.

Let me know if that would resolve the issue, or if I am missing something.

Regards,
Martin
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.