Add classes to grid to allow hoverable behaviour, alterinating rows and borders

[joneff]

The gist of it is that sometimes customers want a different looking grid and it's kinda hard to do it the way things are now.

Describe the solution you would like to see implemented By adding classes to rendering we can enable a myriad of features to the grid, the same way bootstrap does:

• will rows be hovered when pointed with mouse?
• will rows have alternating background?
• what kind of borders the grid has, if at all?

$("#grid").kendoGrid({
    // Controls wether hovering mouse over rows will appearance
    hoverable: (true|false), // defaults to true, to keep current look
    // Controls wether grid renders alternating row styles
    striped: (true|false), // defaults to true, to keep current look; will "break" material
    // Show grid outer border
    border: (true|false), // defaults to false, to keep current look
    // Show borders between columns
    columnLines: (true|false), // defaults to true, to keep current look; will "break" material
    // Show borders between rows
    rowLines: (true|false) // defaults to false, to keep current look; will "break" material
})

Semanticly speaking, grid borders have a handful more values "just left borders of cells", "just bottom border of rows borders", "borders between groups (thead / tbody)" etc. We don't need to implement all possible cases -- just those that make sense. Clearly, we don't need "just left / right borders between cells"; a single columnLines would do.

In short, assigning a given property value would result in a class name: .k-grid-hoverable, k-grid-striped, k-grid-no-border etc.

Describe the alternatives you have considered An alternative would be to complicate the grid styles further, which is not really an alternative

Additional context Although not strictly speaking part of this particular issue, grid density / row height (compact, cosy, comfortably) falls within this same concept of configuration. See telerik/kendo-ux-private#27

And yeah... that's still doable with plain old markup and deprecated attributes: https://dojo.telerik.com/@joneff/AduSUYUg.

/cc @eeasss @bergenhem @hadjieva @tsvetomir @tapopov @Raisolution @Xizario @lkarakoleva @telerik/kendo-front-end

The question here is: do you find this useful?

Regarding implementation, if we just write the styles, all grids will look default until the corresponding properties are implemented.

EDIT: updated the example. added clarification.

[tsvetomir]

These all seem like customizations that should be done either with CSS or through events/callbacks. Covering all possible combinations with settings objects would escalate pretty quickly - e.g. make only header cells hoverable and set border on data cells.

On the upside, we'll be the first to pioneer CSS-in-JSON 😉

/cc @dtopalov for specific references to customer requests.

[joneff]

We don't want all scenarios to be covered. just those that make sense. For instance, it does make sense to be able to choose which borders you want to see in a given table.

Hoverable does not concernt header -- it's strictly related to rows.

On the upside, we'll be the first to pioneer CSS-in-JSON 😉

I was merely giving json representation for kendo-jquery -- I am not suggesting we should use json notation. The angular equivalent, should be something like:

<kendo-grid ... [hoverable]="true" [striped]="true" [border]="true" [columnLines]="true">
...
</kendo-grid>

Or if spaces aren't good enough of a separator, let it be an on object of type GridBorders[], the same way kendo-popup needs an object of type Align.

As you can see, it's not such a configuration madness. It's 3 properties.

More importantly, the motivation behind the property is the same one behind the property for grid density, which in terms requires inputs and buttons to have sizes -- 1) it bestows enormous flexibility in the components, 2) actually reduces the complexity of the themes.

Finally, there are properties striped, border, columnLines, rowLines in Sencha Angular Grid, which control the alternating lines, the border of the grid, borders between cells and rows respectively. Yes, that will increase the number of properties a little, but make them easier.

on a side note, within Sencha rowLines actually controls borders between any type of vertically repeating items and yes, you could disable the border of a given column header, but let's not go there yet.

Edit: updated example.

[tsvetomir]

Two issues would remain even if we come up with an intuitive API:

• Defaults are defined by the theme.
• It's not possible to customize the settings through themes. (so it's a bit of a conundrum)

Customers would have to copy/paste settings or use framework-specific solutions to apply styles across the application. The trade-off would be worth it if we assume that grid instances are likely to use unique settings. So the question is what is important to customers. Do we have specific feedback that we want to address?

[joneff]

Two issues would remain even if we come up with an intuitive API:

* Defaults are defined by the theme.

Not really. The theme will, in the case of the grid, will have no defaults. It will be a borderless table (apart from outer border), with no hover effects, no alternating row, like so:

* It's not possible to customize the settings through themes.

Quite the opposite, background color of the grid header, alternating rows, hover effed; text color of grid, grid header, alternating rows etc will be customizable by theme. Customization of the grid in the direction of do you want given thing to be in the grid, say horizontal borders, or alternating rows will be activated / deactivated by properties. Customization that cannot be generalized will be controllable by themes, like the exact color you want to use for the grid borders or the exact background color (or text) you want for alternating rows.

Customers would have to copy/paste settings or use framework-specific solutions to apply styles across the application. The trade-off would be worth it if we assume that grid instances are likely to use unique settings. So the question is what is important to customers. Do we have specific feedback that we want to address?

Only customers, who are not happy with the our default settings. Then again, those same customers will need to customize the themes in order to achieve mostly the same thing. In that respect, the number of customers who need to customize something will probably not change.

Yes, there is framework specific code -- in kendo-jquery that means a-la JSON settings; in kendo-mvc that's attributes; in kendo-angular that's attributes; in kendo-react that's attributes and finally in blazor-ui that's also attributes.

We've already had requests to be able to turn hovering and alternating rows on and off. Turning alternating rows off for default-theme or bootstrap-theme will result in data tables that are simply uncomfortable to read. To tackle this, we need to be able to turn horizontal borders on and off. And that begs the question, why not turn vertical borders on and off too?

[dtopalov]

The most notable customer requests, related to the potential customizations discussed in this thread, are the following:

1. Customize the row height and/or cell paddings
2. Customize the icons (mostly expand/collapse and group expand/collapse icons) but also the filtering and sorting related ones
3. Add/customize horizontal row borders (less frequently - cell left/right borders)
4. Customize the master-detail layout, mostly in terms of hiding the expand/collapse column altogether, and variations based on this (removing the padding of the detail cell etc)
5. Customize the layout of a grouped grid, mostly in terms of controlling the offset of each nested level

[bergenhem]

I think there's merit to trying to include these configuration options for our components - especially the Grid. If we can ride that line of having the right amount of configuration options without completely replacing CSS knowledge we're in a good spot. We see an overall desire to do most things through default switches rather than using your own CSS or hooking in to an event and applying some style so these kind of options are a step in that direction.

A note of where I'm coming with my line of thinking: there's a group of users which have made up their mind that any time a template, custom rendering functions, or any kind of event hook is needed then they are using a "workaround" and it's not a part of the component. This mostly affects the traditional jQuery audience, but there are folks in Angular and React that look back at the simplicity of WebForms and jQuery (not our components, but the ecosystem) and want that applied to their new frameworks as well - even when the framework itself is what is causing the change in approach.

All that being said, the above discussions around what is available or not in the theme are a little out of my comfort zone to discuss so I'll leave it up to the experts :)

[eeasss]

Why not enable those features in the themes, by adding the respective classes but then leave the product teams to implement it in the best way for the platform?

Generally speaking I like the idea of separating those behaviors in a separate activator classes.

[tsvetomir]

So far we've looked into simplified use cases that involve a single component. Configuration settings are applied directly and it's all rainbows and unicorns from there.

But the Grid embeds all sorts of different controls and most of them can be replaced by templates. The same goes for the Scheduler, Spreadsheet and complex components.

A simple configuration settings is no longer simple—it has to map to the configuration settings of embedded components. The filter row for example must support a compact appearance. It gets even worse for templates. The user is responsible to match the appearance of the parent control.

Consider a typical use case—Master/Detail Grids. Say that I remove the borders from the parent grid and set it to "compact". How should the detail grid look in that case?

• If it looks like the parent we're breaking the rule of encapsulation. The component is no longer self-contained.
• If it uses the default settings, then the user must copy the settings from the parent grid. That definitely goes into the "workaround" category.

This all goes to say the configuration settings are not a cure-all. They just shift the "cascading" part of CSS to the code, but do not eliminate it.

[tsvetomir]

I'd like to add some notes regarding this issue that came up from an offline discussion:

• @joneff noted that implementing this modular approach implies a breaking change. Older versions of the components would not look the same with the updated themes.
• @Xizario suggested a dedicated "compact" theme, possibly based on Material, as a solution to the Grid "density" problem. I like this idea a lot—the generous spacing of Material has often been cited by customers as an issue when it comes to business applications.

[bergenhem]

Whenever I see breaking changes mentioned I always want to jut add this in: I'd prefer to avoid this if possible unless we feel strongly that this is the right move.

As for the "compact" theme, this has been something on a short list of potential themes (along with a full accessibility theme) that I'd love to see if we can dive in to. I know we don't want to add too many themes, but a compact theme certainly is worth the effort if you ask me.

[joneff]

How about this:

• we implement the classes for, say grid-hoverable, grid-compact etc, but we do not enforce them by default
• since there is imminent vNext of the themes (for instance, when we extract the font icons from the themes), we'll then remove the current appearance styles with it. Meaning that customers will have to manually migrate the version of the themes. That should take care of older components.

[tsvetomir]

No, that would just defer the breaking change.

This is a completely new way to add styling features to the components, not just an incremental improvement. The themes had been out "in the wild" for quite some time now. People, including us, have set expectations on how to use and customize them.

Such change warrants a fresh start—a new, modular, theme. That would give us more freedom to experiment without risking breaking changes to existing users. We'd be able to choose just one design language instead of having to consider all three at once. Most importantly, it would be a separate entity with its own features, documentation and learning curve.