[RFC] Make unit scales consistent

[madeleineostoja]

Carrying on from #32, with a probable v3 breaking change coming it could be a good opportunity to rethink some fundamentals that Pollen blindly inherited from Tailwind. Namely, inconsistent unit scales.

We currently use:

• Numerical (eg: --size-2)
• Sizes (eg: width-xs)
• Descriptive (eg: tracking-tight).

If Pollen was to standardise on a scale I feel like it should be numeric, since that's the most obvious, extensible, and easiest to understand.

Great discussion on Tailwind that was abandoned due to breaking change friction on a large project: tailwindlabs/tailwindcss#1277

[madeleineostoja]

Here's where I am so far:

• Abandon size (sm, lg, etc) scales for numerical scales. Effects width and radius.
• Either use descriptive units (loose, wide) or size (sm, lg) for tracking, leading, and measure

Feels consistent enough while adding semantic value where it could be useful. Other than the font size scale we already have descriptive values for typography (font weights, measures, etc) and it feels natural to continue that for line heights and letter spacing, where you don't have an extensive scale like with --size etc but a few key values you'd probably customise for your own design system. Doing that for something like --leading-3 vs --leading-normal or --leading-sm feels unintuitive.

In places with more that 4-5 values, a scale from xs → 7xl or whatever scale is semantically the same as a numerical scale but more cumbersome for no reason.

[crhallberg]

I agree that for line-height and border-radius making the values consistent is great. With the widths however, I feel that meaning is lost and incorrect meaning is implied (such that width-2 is half of width-4).

I think it would be better to have an alias for or otherwise emphasize commonly used breakpoints (768px, 544px, 1200px) such as width-tablet, -mobile, -screen-sm. Maybe then the numbered units can be tied to something more immediately understandable. Best example for now: width-1 could be 10rem.

[madeleineostoja]

Hmm good point. I don't know that tying it to devices/breakpoints would be best, because you can't use CSS variables in media queries anyway, and there are 10 values for widths so you'd run out of device names pretty quick. The width scale is for setting max widths of containers on a page (for example).

There are other places in Pollen where a numerical scale doesn't have the same proportional relationship as the Size scale, but I agree that widths are pretty closely tied to sizes, semantically, that it could be a gotcha.

The only alternative I see is sticking to the original xs → 7xl scale, but it feels a bit odd

[crhallberg]

Yeah, I'm also not a fan of the #xl scales. It just feels arbitrary. I see a lot of value in tying the widths to common screen sizes, even if it can't be used for media devices, but it would not fit any numerical scale nor would it fill 10 slots.

If you think the 10 values you have are the ones you want, width-1 thru width-10 would be the clearest, but maybe some semantics can be gleaned from how you got to those values (similar to the previous --measure values trying to target x number of characters).

I did a little research into other systems but no inspiration struck yet.

[madeleineostoja]

yeah it's tricky. I guess we could reduce the width scale, I only ever use a few myself in the prod sites I've used Pollen on, and even then measure is usually a better tool for things like article max widths, and if anything it'd be worth expanding that scale. The current width scale was just lifted straight from Tailwind.