Consistency in naming: Width / Width Scale / Height Scale

[macandcheese]

Description

There are a few instances where we use "heightScale", "widthScale" to determine sizes for components, usually accepting s/m/l. There are also instances of "width" used frequently.

We should look at consolidating these patterns / naming...

heightScale - calcite-flow-item, calcite-panel, calcite-shell-center-row
detachedHeightScale - calcite-shell-panel
widthScale - -calcite-shell-panel, calcite-flow-item, calcite-panel

Many other components use width - some are s/m/l choice, others use full / auto / half etc.

Acceptance Criteria

A consistent naming and usage pattern is defined and implemented. I do think we should continue with the proposed changes to panel to remove height / width settings in general and have it behave as a block level element that fills the container it is placed in (most of the time, this would be shell panel, and its defined width / height scale or explicit value)

Relevant Info

No response

Which Component

Above

Example Use Case

No response

Esri team

Calcite (design)

[ashetland]

Agree, this would be a good one to dig into.

[geospatialem]

For 2024 we should work towards prop deprecation, and for the 2025 breaking change consider removal of any of the deprecated components.

[Elijbet]

I scanned through components and made a list of what each uses. The majority (50+) of components only use scale. Some of the components use width/widthScale in addition:

Dialog
Dropdown
Modal

/** Specifies the size of the component. */	
@Prop({ reflect: true }) scale: Scale = "m";

/** Specifies the width of the component. */
@Prop({ reflect: true }) widthScale: Scale = "m";

Notice
Segmented-control
Select
Split-button

/** Specifies the size of the component. */	
@Prop({ reflect: true }) scale: Scale = "m";

/** Specifies the width of the component. */
@Prop({ reflect: true }) width: Width = "auto";

Button
Tile-select

@Prop({ reflect: true }) width: Width = "auto";

Shell-Panel

@Prop({ reflect: true }) widthScale: Scale = "m";

Sheet

/**
* When `position` is `"inline-start"` or `"inline-end"`, specifies the width of the component.
*/
@Prop({ reflect: true }) widthScale: Scale = "m";
/**
* When `position` is `"block-start"` or `"block-end"`, specifies the height of the component.
*/
@Prop({ reflect: true }) heightScale: Scale = "m";

Shell-center-row

/**
* Specifies the maximum height of the component.
*/
  @Prop({ reflect: true }) heightScale: Scale = "s";

Shell-pane

/**
* When `displayMode` is `float-content` or `float`, specifies the maximum height of the component.
*
* @deprecated Use `heightScale` instead.
*/
@Prop({ reflect: true }) detachedHeightScale: Scale;
/**
* When `layout` is `horizontal`, specifies the maximum height of the component.
*/
@Prop({ reflect: true }) heightScale: Scale;
/**
* When `layout` is `vertical`, specifies the width of the component.
*/
@Prop({ reflect: true }) widthScale: Scale = "m";

[Elijbet]

Related issues to consider:
Epic: Audit scale across components#7082
Includes adding scales to components:
Block
Block-section
Panel
Flow-item
List
Menu
Menu-item

[Design] Consistent width-scale , height-scale values across components #7616

[Elijbet]

Currently:

• widthScale has been used when the width has a set of defaults, that use s/m/l as values
• width has been used when the width has a set of defaults, but are not s/m/l - instead are auto / half / full.



The discussion width vs widthScale is leaning towards single prop width with s / m / l / auto / full  as options, since they are used in a mutually exclusive manner. The values width accepts would still depend on the component.

There is no great use case for using half value outside of two adjacent elements each taking up 50% of the container, in which case we’ll just set them to full.

[github-actions]

cc @geospatialem, @brittneytewks

[github-actions]

Installed and assigned for verification.

[DitwanP]

🍡 Verified locally