Hello Christian,

I accept and value your feedback about our workflow with the feature request. We will think about how to indicate potential risk and that research stage would determine the outcome of the request. Still, I hope you understand that during implementation there would be still a change of facing challenges that might interfere the release of a feature.

We have reviewed the offerrings on the market and there is noone (to our knowledge) that offers min and max width functionality of columns when the rendering of the element is table. So, I believe that no opportunity for implementation has been missed during our research. Still, I would like to point out that research for changing the rendering of the Grid in all our suites is something that will be evaluated.

Regarding the virtual scrolling, indeed we have observed some improvements in terms of configuration and scope that we started to evaluate. We will definitely include more complementary features and easier configuration. Apart from that, when looking into any vendor's features or components we should look into the limitations as well in addition to the offerring. 

Once again thank you for sharing all your feedback. If you have more feedback regarding our components it will be beneficial if you could open a support ticket and we could discuss it further.

Regards,
Joana
Progress Telerik

Hi all,

My name is Joana Ivanova and I am the Team Lead of the Telerik Blazor team.

I do understand your disappointment of seeing this feature declined, and I would like to bring some clarification around our processes and the limitations that we hit that are outside of our control at the moment.

First, I would like to start by giving you more context about our workflow with feature requests. The first stage of working on a feature request is research. We perform thorough research on the market, the state of html, css, Blazor and overall all dependencies that impact the implementation of a certain feature. The output of the research is always consulted with our front-end and solution architects. We value every request, and in no way it is easy for us to decline any of them. Thus, we insist on the research stage to be able to give firm arguments and provide our customers confidence that all possible outcomes have been revised.

Implementation of Min and Max Width on table cells

The current rendering of the Grid relies on table html elements with `fixed table-layout` that makes it impossible to implement minimum and maximum width of its cells. By specification, the table columns are inline boxes that support only border, background, visibility and width. Since width functions as minimum width in table layout, it is possible that you could rely on the Width column parameter.

What we could do next?

We follow the evolution of the standard behavior for tables, and as soon as there is progress around the table cell sizing we will implement the feature. You could also observe the communication around css-tables and planned tasks in the taskboard:

https://github.com/w3c/csswg-drafts/issues/2802 (example issue around max-width attribute)

Another action point on this request is our evaluation of global changes in the rendering of the grid. Internally, we will look into pros and cons of replacing the table rendering that will allow us to implement better column and rows sizing. However, we do not typically share such plans as we cannot give statement whether, or when such huge change would come.

Alternatives for our customers

My colleague Radko pointed out several approaches that I would like to mention again:

- Usage of Width parameter of the columns. I am not aware of the exact use cases of the Grid, however, I believe that in many cases this parameter is sufficient to assure minimum width of the columns. A good example of the default behavior of table sizing could be this demo where Product Name column extends on larger screens, and shrinks to 300px (configured width) on smaller screens.

- Adding MediaQuery integration where you could dynamically update the width of the columns based on the screen.

- Introducing Minimum and Maximum Resizable Widths to constrain the resizing. However, I could see that this one is not something that you are interested in.

Regarding the other linked requests

- API method for fitting to width columns - it is included in our short-term planning and we will start working on it soon

- More configuration option of default filtering elements - it is on our radar for planning as well, and we do track the demand there

I hope that the above information makes sense and gives more clarity of the table limitations that we cannot fight even though we try.

Regards,
Joana
Progress Telerik

Hello all,

It appears we got the wrong impressions of what the desired behavior for this feature was. After looking into this request in detail, we have to decline it, as the described behavior by Robert is not possible, or partially achievable at best. Here is why.

There are certain constraints and specifics when working with HTML tables. We can define rules for the width of each column, however, CSS styles such as min-width & max-width are not supported as described here - Visual formatting model details. It might be plausible to "simulate" a min and max behavior on individual columns, by subscribing to the OnResize event and recalculating the width on each change, reassigning the value (essentially trying to override the default HTML table behavior). However, there are far more cases to consider besides OnResize, and such an approach will be very difficult to implement robustly.

If you find it beneficial, you can vote for this feature request - Columns - Min & Max Resizable Width, which will introduce parameters for setting the min and max resizable width. Note this feature will not make the Grid react to browser resizing in a different way than a standard HTML table but will allow providing values that will serve as constraints when resizing a column by dragging (Resizable needs to be enabled for this to work).

Having said this, there are still certain things one might do in order to achieve better responsiveness.

• It would be beneficial to get familiar with the Grid Column Width Behavior article first if you have not already. Besides a tutorial on what CSS units you can use for the Width parameter, there you will find various scenarios and the expected outcome of each one of them. For example, setting the width explicitly on some columns and given the available Grid width exceeds the combined width of said columns, the remaining width will be distributed evenly between the rest of the columns(without the width parameter). The width of the columns with set values will be respected.
• Using the MediaQuery component, you can react to the size of the browser. The MediaQuery - Grid Integration demo showcases such an approach, where the Visible parameter of columns is changed based on the current resolution.

Regards, Radko Stanev Progress Telerik

Hello Vladislav,

Perhaps this is what you need: https://feedback.telerik.com/blazor/1434744-hide-column-only-on-small-device or this https://feedback.telerik.com/blazor/1450105-column-chooser? A MinWidth would have effect for column resizing and to ensure text visibility when you have many columns, but not so much when you have to choose which columns you want to see. If one of those items is what you need, just click the Vote and Follow buttons on their pages.

Regards,
Marin Bratanov
Progress Telerik