RFC: Component sizes, colors and shapes

[joneff]

Quick preface

As of 2020, Kendo UI components are quite monolithic in terms of themes e.g. a component always has a given set of visual properties for a single theme and there are no modifiers. Yes, developers can customize the themes, but they still end up with the same rigid and monolithic components.

A button, for instance, is always has a certain rounded border; a certain set of dimensions; a certain font size ... The only exception is that our image buttons are square and our primary buttons are with a different color. We did try to make things a bit more flexible with our look property that added some much needed variations, but that was not enough and couldn't be applied to all components.

And thus we reach the current discussion...

In order to customize components better we can break up our monolithic approach to a more granular one: instead of a single class applying everything, let's go with k-button for kendo-button, we can have modifiers that apply very few properties. We've grouped characteristics / modifiers in the following categories:

• shape: customizes ... well shape of a component. That usually translates to border radius
• size: customizes font size, line-height, padding and border of a component as well as spacing between child elements
• theme color: customizes the main (predominant) color of a component
• fill mode: specifies how the main color of a component is applied

And I will go into more details.

Shape

While many shapes are quite possible with CSS, not all of them are applicable, usable or make sense. Do we really need a triangle button, or star shaped grid?

As of now, shape, to us, specifies the roundness (border radius) of a component and the ratio between width and height:

• rectangle: no rounding applied; no fixed size; grows with content;
• rounded: default border radius (depends on size); no fixed size; grows with content
• pill: applies 50% rounding to the start and end of the component; no fixed size; grows with content;
  • note: if the circumstances are correct, this may look like circle
• square: no rounding applied; width and height are specified; content is either clipped or overflows
• circle: 50% rounding applied; width and height are specified; content is either clipped or overflows
• dot: 50% rounding applied; width and height are specified; there is not content and the dot is smaller
• leaf: 50% rounding applied on the top left and bottom right corner; no fixed size; crows with content

As of 2020 element aspect ratio is not supported so square and circle shapes have hard-coded dimensions. If a component has any other shape it may grow horizontally and / or vertically.

Important: Not all shapes make sense to be present in all components!

Note: A badge component may take advantage of nice decorations like n-star or ribbon like appearance.
Note: We may need a rounded square shape.

Size

The dimensions of a component are the sum of border width, padding and content. Any naming may do, but we've boiled them to the following:

• extra small: significantly smaller than medium
• small: slightly smaller than medium
• medium: the default size. that would be the current size of our components
• large: slightly larger than medium
• extra large: significantly larger than medium

Apart from border width, padding, font size and line-height, sizes also control border-radius.

Important: Not all sizes make sense to be present in all components. Initially, we'll go with small, medium, large.

Note: Size should not be confused with typographic density, which is another similar, but distinct concept

Theme color

Brings the color factor in the components. Looking at our themes we've decided to have our main theme colors, plus our important colors as options:

• primary: Applies coloring based on primary theme color.
• secondary: Applies coloring based on secondary theme color.
• tertiary: Applies coloring based on tertiary theme color.
• info: Applies coloring based on info theme color.
• success: Applies coloring based on success theme color.
• warning: Applies coloring based on warning theme color.
• error: Applies coloring based on error theme color.

There are also three special options:

• dark: Applies coloring based on dark theme color.
• light: Applies coloring based on light theme color.
• inverse: Depending on luminosity of themes is dark in light themes and light in dark themes

There are two other cases we should consider

• inherit: should inherit?
• auto: apply no coloring and leave customization to developers, say via css variables.

Fill

Imagine the following:

• a white button with red text.
• a red button with white text.

They are both red, right! Fill mode specifies how a color is applied to a component:

• solid: theme color is used mostly for background
• outline: theme color is used mostly for text and border
• flat: theme color is used for text color with some additional styling on hover
• clear: theme color is used for text color with no additional styling on hover

Rendering

Each modifier should be applied via a class that has the component name e.g.:

• k-textbox-lg denotes a large textbox component
• k-badge-inverse denotes a badge with inverse theme color

There is one issue with this approach though, considering that all props are in fact either enums or string, there will be no visual difference between a button with size primary and theme color small and a button with size small and theme color primary.

One way we could tackle this is to use compound class names:

• k-component-shape-size: k-button-rounded-sm, k-input-sqare-lg ...
• k-component-fill-color: k-input-solid-primary, k-button-outline-inverse ...

That in terms leaves another question: what if we want a value to be "auto" i.e. not specified and left for customization? What if two values are "auto"?

[eeasss]

What would be the output of the research RFC? What are the criteria that can guide you in making this decision?

[joneff]

I've converted the issue to a discussion shared my findings as a RFC