`Card`: support more padding options

[jameskoster]

The size options on the Card component often produce unequal horizontal/padding padding values. For example the large size has 24px vertical padding and 32px horizontal padding.

It can sometimes be desirable to create cards with equal padding, or specify per-side padding values on subcomponents like Card.Header. Let's explore how to offer this functionality in a sustainable way (based on presets/tokens) while considering backwards compatibility.

cc @gigitux

[jameskoster]

One idea I had for this is to introduce some new properties: paddingTop, paddingRight, paddingBottom, paddingLeft.

Behavior

• The existing size prop acts as a shorthand defining top, right, bottom, and left padding values.
• When any per-side padding property is set, it overrides the corresponding side derived from size.
• If size is omitted, each padding property applies independently.
• The padding* props accept values from the spacing scale to maintain design consistency.

Backwards compatibility

• All existing uses of size remain fully supported.
• The new properties are additive and non-breaking.

This approach loosely mirrors CSS’s padding shorthand and side-specific properties, offering developers finer control without fragmenting existing patterns or requiring new size presets.

[gigitux]

@jameskoster Instead to add a new prop, what do you think if size looks like this:

export type SizeOptions =
	| 'xSmall'
	| 'small'
	| 'medium'
	| 'large'
	| {
			paddingTop: number;
			paddingRight: number;
			paddingBottom: number;
			paddingLeft: number;
	  };

In this way, Card can be consumed in this way:

<Card size="medium">
  <CardBody>
    <Text>Medium padding (predefined - default)</Text>
  </CardBody>
</Card>

<Card
  size={{
    paddingTop: 8,
    paddingRight: 24,
    paddingBottom: 8,
    paddingLeft: 24,
  }}
>
  <CardBody>
    <Text>Custom horizontal padding (8px vertical, 24px horizontal)</Text>
  </CardBody>
</Card>

[gigitux]

Even in this case, the properties are additive, but the logic would be simpler.

cc @mirka

[jameskoster]

@gigitux with this approach am I correct in thinking that consumers couldn't specify that a card is medium-sized, but override the padding of just one side? Maybe it's okay, I'm not sure to be honest.

It would be neat if accepted values for the padding* values could be tokenised. So consumers could say paddingTop: small, where small references a value from the spacing scale.

[mirka]

Sounds good to me.

export type SizeToken =
	| 'xSmall'
	| 'small'
	| 'medium'
	| 'large';

export type SizeOptions =
	| SizeToken
	| {
			top: SizeToken;
			right: SizeToken;
			bottom: SizeToken;
			left: SizeToken;
	  };

Something like that, maybe. We might not have to support number if we have per-side tokens.