Spacing utilities to px instead of rem by default

[KocsisGabor]

Discussed in #13098

^{Originally posted by KocsisGabor March 6, 2024}
Relevant but closed issue on this topic. #800

I'm honestly surprised, I must assume there's something I don't know because choosing rem for spacing does not make any sense to me.

Apparently rem was chosen because it allows proportional resizing of everything, in other words, it allows us to zoom, exactly like how every browser allows their every user to zoom.
Is there a website which relies on the root font-size to change the zoom? I doubt it, it seems pointless to me.

Why do we have rem units?

If the websites are using rem units for font-sizes, then the users can change the default browser font-size in case they have poor eyesight, which allows them to consume content easier on the internet. This is literally the only reason we have rem units!

Most web developers probably have perfect eyesight because changing the default browser font-size most of the time either has no effect or it zooms the websites. This makes this setting rather useless since pretty much every browser has a dedicated default zoom feature anyway, and the browser zoom can easily be overwritten by the user, for example, with ctrl+wheel.

I don't really understand why most developers use this unit incorrectly. The only change needed when the rem units became supported was to change some font-size to rem instead of pixels. This is pretty much a ~30 line change in CSS for complex websites. Instead, the developers decided to either overwrite the root font-size so they can pointlessly use rem units just because they read somewhere that they should, or they don't overwrite it but use rem everywhere again just to lose its intended functionality.

Why did the Tailwind developers think that it would be a good idea to change the border width on a button, a shadow under a card, or the distance between nav items just because the user has changed the default font-size?

What would be the effect of this change?

Currently, changing the browser default font-size just zooms exactly like how the browser can zoom.

If the spacing units were to change to pixels, nothing would change if the user didn't touch the default font-size. Pretty much every Tailwind website would look exactly the same. However, if the user has changed the default font-size, for example, to 20 pixels, this would mean that most Tailwind websites would show text in 125% size instead of zooming the websites to 125%. This should be the intended effect of changing the default font-size, not a redundant zoom.

Tailwind is popular, so if the spacing units were to change to pixels instead of rem in Tailwind, that would instantly solve this problem on countless websites.

Would this break websites? Maybe, there are surely websites where the root font-size has been overwritten for some reason, but pretty much all of these websites use rem incorrectly. There are probably also websites where they overwrite the root font-size but also allow the user to change it with a button or something. Currently, this button in these websites zooms the content, and after the change, it would have the probably intended effect of changing the font-size (this is a positive effect in my opinion).

The users who decide to change the default font-size would have a better experience on the internet.

What needs to be changed?

The default config should have this theme.spacing property:

spacing: {
	px: '1px',
	0: '0px',
	0.5: '2px',
	1: '4px',
	1.5: '6px',
	2: '8px',
	2.5: '10px',
	3: '12px',
	3.5: '14px',
	4: '16px',
	5: '20px',
	6: '24px',
	7: '28px',
	8: '32px',
	9: '36px',
	10: '40px',
	11: '44px',
	12: '48px',
	14: '56px',
	16: '64px',
	20: '80px',
	24: '96px',
	28: '112px',
	32: '128px',
	36: '144px',
	40: '160px',
	44: '176px',
	48: '192px',
	52: '208px',
	56: '224px',
	60: '240px',
	64: '256px',
	72: '288px',
	80: '320px',
	96: '384px',
}

Most Tailwind users need to change nothing if this change goes live. Those developers who have actually affected website needs to change their Tailwind config to have the rem spacing values.

Conclusion

Even if we assume that for some reason an unreasonable amount of websites need their interface to zoom when a user has changed the default font-size, this change would still be a positive change because the default should be what's best in most cases, not what can be useful in some weird edge cases especially when it takes about ~1 minute to change the pixel values to rem for a developer in their own config file.

Important: This change would not affect font-sizes and some few other properties like max-w-md, which would still use rem units. This change would only affect the spacing properties like margin and some other properties like border-width.

Sorry if this was a bit aggressive, I'm just really frustrated that I needed to make this issue at all.

[znycheporuk]

One of possible use cases for rem — scaling ui on huge screens.
A lot of sites look half empty on 2k+ screens, and it can easily be fixed by using rem + dynamic root font size

:root {
    font-size: max(calc(12px + 1vmin), 18px);
}

depends on design and other stuff, but sometimes it makes site more usable

[avarayr]

This issue has exactly nil chance of being resolved purely because it will be an enormous breaking change. Because Tailwind supports arbitrary values (w-[1rem]), this will cause a breaking change in codebases where arbitrary and preset values are mixed.

Even though I don't agree with some of your points, I can understand why you're frustrated about it. My suggestion would be to use a custom config that suits your needs. All tools are built based on the authors' preferences, and the beauty of open source is that if you don't like it - you can always change it locally.

[KocsisGabor]

@znycheporuk

One of possible use cases for rem — scaling ui on huge screens. A lot of sites look half empty on 2k+ screens, and it can easily be fixed by using rem + dynamic root font size

If the user has a huge screen, they should probably change the scale of everything either in some display settings in their operating system or as a default zoom in the browser. if you really need to use font-size based zoom on your website, you can revert back to rem spacing units in ~2 minutes.

We're talking about the defaults, so the point is, that if you find 100 random websites which use Tailwind, my proposed change is going to improve at least 99 of them without the need to touch anything (other than a tailwind update of course).

[KocsisGabor]

@avarayr

This issue has exactly nil chance of being resolved purely because it will be an enormous breaking change. Because Tailwind supports arbitrary values (w-[1rem]), this will cause a breaking change in codebases where arbitrary and preset values are mixed.

I don't think it would be a breaking change at all. Using w-[1rem] would yield the same result as the current setup, with only slight changes in the size of other elements.
Let's say you have a button which only has an icon in it. You set up the icon to be w-[1rem] and the button padding to be p-2.

• Currently If you didn't touch the default browser font-size: the icon button is 8 + 16 + 8 (32px) in size.
• Currently If you've changed the default browser font-size to 20px: the icon button is 10 + 20 + 10 (40px) in size.
• After the change, If you didn't touch the default browser font-size (most user): the icon button is still 8 + 16 + 8 (32px) in size.
• After the change, If you've changed the default browser font-size to 20px: the icon button is 8 + 20 + 8 (36px) in size.

I doubt this 2px padding difference can be considered a breaking change. Also this is what users should expect to happen when they change the default font-size. And this is what developers who know what rem units were invented for should expect to happen with tailwind. And if you're really bothered by this change, you can revert back to rem spacing units in about 2 minutes or better yet, just change p-2 to p-[0.5rem].

Edit: forgot to reply to this part

My suggestion would be to use a custom config that suits your needs

I use a custom config of course but this is not the point. The point is, that there is an important accessibility setting in all browsers, the default font-size, but because most webdevelopers misuse the rem units this setting is pretty much useless and users don't even change it because of it.
If a few popular css frameworks like Tailwind would improve their handling of rem units this would improve the internet for everyone who have less than perfect eyesight because it would allow them to see websites in an actually more readable way and not just zoomed in.

If you plan to use rem units for scaling elements other than font-sizes, you should be the one who has to change the default config.

Edit 2:

Also your w-[1rem] example is weird, because currently you would just use w-4 instead. This is exactly my problem, why would I want an element's width to depend on the default font-size...

If we stay with the icon button example, the correct way to create it is to either use an svg inside with a width and height of 1em, or to use an icon font. In both cases the size of the icon will depend on its parent's font-size which hopefuly is using rem units.
If you also set up w-4 on this icon, you're just making a mistake and in this case my proposed change could actually cause problems (because the w-4 would become 16px but the icon inside might change based on the browser's defult font-size). This is probably the only realistic breaking change we could expect to see and only because the developer has made a mistake.

[adamwathan]

Lots of good feedback here and I appreciate it! This is something I've thought about a lot and I worry it's just pretty complicated to come up with a universal approach that's going to work for everyone.

I really liked this post on the topic:

https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/

The thing that stood out to me was the point that the margin between paragraphs should likely be rem because it's still related to the readability of the type, even if you are using px for all of the padding around everything.

But in other cases margin makes more sense to be px. So there's not really one "right" unit to use for a utility like mt-4 because I agree it's sort of context-dependent.

Similarly sometimes width might make sense to be px, but other times rem if it's important that it can fit the text that's inside of it.

There are also situations where you have a sidebar built with width, but then need to add a matching padding-left on the body to accommodate the sidebar, and now it's important that both of those use the same unit, so you can't always make width use rem and padding use px.

So I dunno, I don't know how to wave a magic wand here and make it easy for every user to always do the best thing without being deliberate about it themselves. That combined with the fact that this would be a breaking change leaves me inclined to just leave things as they are by default, and let the people who are inclined to really go deep with this stuff handle that themselves in their own projects. Everything in the framework is customizable so you can totally switch to pixels if you want by changing your spacing scale.

Again I agree with all your points generally and value the feedback, I just don't think it's as simple of a change to get right on a framework level as it sounds on the surface.

[KocsisGabor]

Upon rereading the thread, I noticed a mistake: you mentioned that with some sidebar, the unit change could cause a problem. That's not true because with my suggested change, both the width and padding would simply change to pixels; they would still retain the same unit type just a different one. The only issue I can think of that might arise is with paragraph and other text margins. But those would only appear different for users who adjust their browser font size, and it still wouldn't disrupt anything huge, it would just slightly reduce the white space.

[HarleySalas]

Eh, I see the point in this example, but I've never actually had an issue where something like that caused this effect. Not sure if it's just my coding style, or what, but for the past 5 years or so, in a freelance and then agency environment, I have operating under the strict requirements: no usage of px allowed, ever, for any reason. all media queries in em, everything else in rem. The result has been consistent designs at any zoom level (tested for every site released) and never once has there been an issue.

I think if you build websites in this manner, you will rarely have a scenario where you need px and so, I believe the default should be rem.

[KocsisGabor]

I suspect there is a small misunderstanding: I don't have any problem with rem at any zoom level. My problem is with the default browser font size setting; that's what rem was invented for.

Did you test any of your websites with different default browser font size settings? Please do so you can see what I mean. I'm fairly certain that if you change the default browser font size to, let's say, 24px, you will see every website zoomed in. But what a person with poor eyesight would want is to see the text bigger, not the whole website zoomed in. This is what I'm trying to fix with my suggestion.

In this example website, I've used rem for everything except for the spacing units. You can try it out with a 24px default font size and see that it looks perfectly fine, but it's not zoomed in. For example, the navbar didn't get bigger like it would with zoom.

[HarleySalas]

I test multiple browsers, with zoom level, as well as default font size.

I disagree that the user would only want larger text. The only way to know that your website looks 100% the same on literally every device at every zoom level is by using rem and scaling everything proportionately. Larger text can have other elements around it to behave differently. When people are zooming in, it should behave as if they are on a smaller device. Same with when they change their default font size, in my opinion.

In your example, you may have expected each navigation item to remain on one line. When setting the default font size to "very large" in google chrome, it causes a couple nav items to wrap to 2 lines. What if your header didn't respect that? Do you really want and/or think it's necessary to have to test for every zoom amount and default font size? You're also using px for media queries, which I think is all around a bad idea.

I stand behind em for all media queries and rem for everything else. The alternative creates more work, requires more testing and inconsistent user experiences.

[KocsisGabor]

If the user wants zoomed-in websites, then they should use the zoom feature, which is already built into every browser.

The default font size clearly has a different purpose; the option's name is default font-size, not default zoom...
So by using rem for everything (media queries are irrelevant to this discussion), you're not respecting the user's choice to change the default font size. This is my whole point, and I don't really see room for disagreement here.

What if your header didn't respect that? (the wrapping of the nav items)

Then I made a mistake, and I should fix it. With some experience, making a website correctly is not that hard. There's no need to test for every default font size if the website is made correctly. The navigation items wrap to two lines in that example, but that's just the expected behavior.