Switch from px to rem for responsive variants?

[MichaelAllenWarner]

Using pixel-values instead of rem-values for media queries often results in a poor experience for people who use text-only zoom (in violation of WCAG Success Criterion 1.4.4). To see an example of what I mean, visit https://tailwindui.com/pricing in Firefox, select "Zoom Text Only" from the View -> Zoom menu, and start zooming in. Here is a screenshot at 150% text-only zoom:

The entire item on the right side is cut off; in fact, it's unreachable because of an ancestor-div with .overflow-hidden. Changing the breakpoints' min-width values to their rem-equivalents fixes this.

Should the default screens media-queries be changed to rem values? I believe some developers recommend using pixels to sidestep a bug in Safari where normal-zoom doesn't work well with rem-based breakpoints, but A) that was maybe bad advice in the first place, since it comes at the expense of accessibility for all users who zoom text-only (regardless of browser), and B) if I'm not mistaken, that bug has been fixed.

[MichaelAllenWarner]

Or maybe ems would be better than rems even? https://danburzo.ro/media-query-units/

[adamwathan]

So I looked into this a lot originally when building Tailwind and at the time, Safari didn’t handle em values properly. I wrote a blog post about it here:

https://adamwathan.me/dont-use-em-for-media-queries/

If that’s all fixed now then we could definitely consider switching for Tailwind CSS v4 some day down the road.

If you happen to do some thorough testing I’d definitely be interested in seeing the results 👍🏻

[MichaelAllenWarner]

Nice write-up there, though I'd personally come to the opposite conclusion (because the problem that text-only-zoomers encounter with pixel-valued breakpoints results in content that's completely inaccessible, whereas the "switches to wider-breakpoint too late" problem that Safari-zoomers encounter with em-valued breakpoints typically doesn't).

Anyway, I did recently switch to rem-valued media queries in my setup, and on normal-zoom in Safari 15 I'm seeing breakpoints kick in exactly where they should. Haven't dived any deeper than that, but it looks fixed. Perhaps I should switch from rems to ems, though, to sidestep the infinite-loop problem that can arise in Safari <= 14 (described in the post I linked in my previous message).

[MichaelAllenWarner]

Worth noting that if the media-query values were switched to ems by default, then container max-widths and utilities like max-w-screen-lg should be expressed in rems (not ems).

[adamwathan]

Good news, just did some testing and it seems like the bug in Safari is fixed in 15 👍🏻

Here's a demo from Safari 14 (used Browserstack to go back and test):

safari-14.mov

...and here's the same thing in Safari 15:

safari-15.mov

So I think we can probably change the defaults to em for v4 👍🏻 Will still want to test on mobile Safari I think to make sure there's no unexpected behavior but will definitely be awesome if we can switch to relative units for this with no downside going forward.

[thiemeljiri]

There are people who need smaller font sizes (because of limited field of vision) and people who need extremely large font sizes and/or zoom. Respecting users preference of font size is something that is now finally being more widely adopted. But it has its consequences. Using px based breakpoints and respecting user's font size preference at the same time is not safe. You need to test everything with different font size settings to make sure it works. (And the site will very likely be broken if you really need very large font size.) And you need to do that repeatedly throughout whole the development process and after any subsequent change to the UI.

As responsive websites are now standard, there's an easy way to make sure that they look OK with any user font size preference. When you use em based breakpoints it will work like "default zoom". It saves huge amount of time to developers, it will work in more scenarios and most of all you don't even have to know about it. Which should be a huge concern for any major frameworks. It should have reasonable defaults that do as much to increase the accessibility of the final product as much as possible.

🙏 So, please, make the breakpoints use ems in v4 by default. 🙏

I'd also like to add the following personal story and some more information:

I actually stopped using ems for media queries for few years and overriding the users font size preference (as having just one is dangerous as I described above) and I was sad about it all the time. I stopped not because of Safari (the observed issue was with rems), but I myself experienced an issue on some notebook with larger pixel density and a touch screen. When using max-width breakpoints two breakpoints overlapped or there was 1 CSS pixel gap and content could easily gone missing or layout could broke completely. There was no value that worked safely as upper boundary of exclusive interval (like XX.9em, XX.99em, XX.9375em...) - there always was some issue, at least few years ago. And the possibility of having max-width breakpoints was something me or other team members didn't want to strip ourselves of.

But then I learned how complicated it can be for some users to zoom the site. And by design it¨s per site settings, there is no way how to set a default zoom the browser will use for newly accessed sites. And even if it is acceptable by WCAG that you use px for everything and just zooming works (it would only be an issue with non-responsive site), it's far from optimal. I have no idea if the issue with the max-width breakpoints with em unit still exists, but as it took me several years to actually discover it I probably would never use it this anyway. I don't think there is any safe subtrahend for max-width breakpoints unless wide research proves it. But It's possible that CSS Media Queries Level 4 will be a thing sooner.

In the meantime we have two options.

1. Either to use min-with based media queries only. Using max-width breakpoints with Tailwind seems a bit redundant and even maybe a bit anti-pattern. I can imagine it being stripped in the next major version in the default settings.
2. Or use completely different approach for max-with breakpoints, if it's really necessary for them to be part of the framework. I came up with this idea earlier this year. It should be safe by the design. I tested it in many browsers with different various font size preferences and I feel confident enough to share this link https://codepen.io/ThiemelJiri/pen/GRXLRBG

Also it should be explained on the breakpoints docs page.

Keep Up The Good Work!

[Hurtak]

Is there a difference between using em and rem in the media queries?

[MichaelAllenWarner]

I believe not, except for the bug in Safari < 15 mentioned earlier in the thread (which is why I still choose em).

[grace-snow]

Do you need someone to open a PR for this change for v4? When is v4 likely to come out?

The fact that Tailwind uses px media queries as a default means every site built using the default config could be inaccessible, potentially with critical usability failures (not to mention legal compliance failures) so it needs to be a priority. Let's lead by example and help developers build accessible sites.

[barvian]

Merged! #13469

[grace-snow]

That article is pretty old and is missing the point a bit. The exact pixel point a layout switches isn’t as relevant. That’s micromanaging. Whereas using px for media queries means layouts won’t scale correctly for the many people who change their default font size settings. More info here: https://fedmentor.dev/posts/responsive-meaning/ And here: https://fedmentor.dev/posts/font-size-px/ You can test it out yourself in browser too. See what happens to layouts when you use px media queries and change font size in browser to 32px or even 64px then change viewport size.

…

On Sat, 11 Jan 2025 at 16:58, Ifeora Okechukwu ***@***.***> wrote: Hello @adamwathan <https://github.com/adamwathan> , have you taken a look at this article ? https://zellwk.com/blog/media-query-units/ — Reply to this email directly, view it on GitHub <#8378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACRDWNZOWK7C3EQKBIW4I232KFEVDAVCNFSM6AAAAABVAEGHZGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBQG42DOOI> . You are receiving this because you commented.Message ID: ***@***.*** com>