Are these additions necessary? It looks like SizeableProps is already included through BaseSubComponentProps.

Fixed with 832e1b1

Should we move the cardPaddings stuff directly into this file? They're not used anywhere else. While you're at it, could you also move all the card padding values out of the config-values file? We want to get rid of that file eventually. I think this get-padding-by-size.ts file can be the canonical source of card padding sizes.

Fixed with f5d8c47

Could we remove the exact pixel values from this story description and from the code comments? We don't want to commit to pixel values in documentation, since they could be changed at some point.

Fixed with c4af856

The padding shorthand property is not a logical one, so it's not going to respect our logical values. We have to set each property separately (padding-block-start, etc).

Sorry! I completely forgot to update it! I fixed it!

Not sure what I think about the "fall back to 0" behavior, given that 0 is not an explicitly allowed value and the object shape marks all properties as optional. I can see it becoming a weird loophole with consumers who want to set a 0 padding.

	| {
			blockStart?: SizeToken;
			blockEnd?: SizeToken;
			inlineStart?: SizeToken;
			inlineEnd?: SizeToken;
	  };

I can think of two ways to address this:

1. Mark all sides as required in the object case, and fall back to medium for undefined or invalid sides.
2. Officially support none as a size token.

No strong option here — 2 is probably fine? I'll also note that there's already a CardMedia subcomponent that can be used for full-bleed content.

Mark all sides as required in the object case, and fall back to medium for undefined or invalid sides.

I took this approach given that it is simple.

One quirk of this approach is that if I specify size={ { blockStart: 'medium' } }, I'd get space( 6 ) for the top padding, but if I specify size="medium", I get space( 4 ) for the top padding.

We could maybe have some convoluted logic for mapping sizes based on vertical or horizontal properties, but I do quite like keeping this simpler with each step mapping to 2, 4, 6, and 8.

Just to clarify, do you expect some changes here, or is it just a note?

Not necessarily expecting any changes, just flagging a potential point of confusion or inconsistency of expectations. Unless you have concerns about it, I'm personally happy to try this as-is.

I agree that it could cause some confusion, but I’m not sure how to fix it without introducing breaking changes.

The idea is that with size={{ blockStart: 'medium', blockEnd: 'medium', inlineStart: 'medium', inlineEnd: 'medium' }}, we can define consistent padding across all properties.

Is the typeof here check redundant? I can appreciate the explicitness, and only mention it because checking object-ness is pretty fraught (see also isPlainObject in various utility libraries), e.g. typeof null === 'object'

Addressed with 767da77

Nit: I'd probably avoid the top, etc. naming because the idea of logical properties is to avoid associating with specific directions like this, even if it's more familiar due to historical usage.

Addressed with 767da77

cardPaddings is already essentially acting like a constant, so internally referencing CONFIG seems like unnecessary indirection over just inlining the values.

Fixed with 5c873be