Html specs corrections 6

[TeyaVes]

targets: https://github.com/telerik/kendo-themes-private/issues/246

This PR targets the following items from the related issue:

Splitter

• some suites (Angular, React) are having k-touch-action-none/ touch-action: none; class/style on the splitbar, do we want to add that class in the reference rendering, or add a style in the themes? -
  the touch-action: none style is added to the themes and the utility class is no longer needed. It needs to be removed from the styles.

Gantt

• simplify templates, remove tasks
• check if k-selectable can be removed
• TreeList does not have k-grid-aria-root

PivotGrid/Checkbox

• missing k-sr-only on the empty-cell
• the class on the chip list should be k-column-fields, instead of k-filter-fields
• k-pivotgrid-content cell value wrapper, do we need this, check if it can be removed.
  I think that we should leave this wrapper with the class- in this way we can target the text inside the cell, without affecting the toggle icon which might be present. Similarly, we have a wrapper for the text inside pivotGrid headers- .k-pivotgrid-header-title

Inputs

• should opened inputs be k-focused?
  The purpose of the templates are to give guidelines for the static reference rendering of the componets. Adding states to inputs under certain conditions should not be in the scope of the specs. Thus, the inputs when a dropdown is opened will currently remain unchanged.

AI Prompt

• some products use k-white-space-pre-line utility in the card body. Is this okay, should we consider adding those util styles in the component. -  
  I think that we should not add such a class as a part of the rendering or a style in the component, as it imposes certain styles to the card body content and we do not want that- the client should be responsible for that
• The toolbar buttons does not have k-toolbar-button classes. Should they be added for consistency with other components?

[epetrow]

LGTM

[inikolova]

Looks OK :) Just one suggestion from me - simplify Gantt templates - should be chore commit;

[TeyaVes]

Looks OK :) Just one suggestion from me - simplify Gantt templates - should be chore commit;

I've updated the commit message to chore() instead of fix()

[zhpenkov]

To summarize, currently we have three fields: rows, columns, and filters.

and we provide 3 different classes for each field:

kendo-themes/packages/default/scss/pivotgrid/_layout.scss

Lines 245 to 250 in 7e81c25

	.k-row-fields,
	.k-column-fields,
	.k-filter-fields {
	margin-top: $kendo-pivotgrid-configurator-fields-margin-y;
	flex-wrap: wrap;
	}

I am uncertain if the k-filter-fields class on the "Values" chip list should be replaced with k-column-fields.
If this is the case k-filder-fields becomes redundant and should be removed from styles.

I also question whether three different classes are necessary for each of the fields.

All these classes share the same styles, so from a styling perspective, it doesn't matter which class is used.
If there isn't a specific need for a different class for each field, we can simplify the approach by using one generic class to handle those field styles. This would reduce confusion and ensure consistency across all fields.

[TeyaVes]

You are absolutely correct, in the general case the correct classes are- fields, rows and columns. However, in the jQuery old PivotGrid implementation (PivotGrid v.1) the styles differ a bit from the PivotGrid v.2 used in the rest of the suites. Updating the classes would impact the styles of the PivotGrid configurator by removing the grey border around the chiplist. Thus, let's leave all classes k-column-fields in the jQuery configurator.

The point you are raising whether we need these different classes is valid since they all share the same styles. I have logged the issue under the Discussion section in the Templates&Spec fixes issue just to make sure that we are not missing something - I am not certain why the fields were named with 3 different class names in the first place.