Fix iOS end-snap drift in filters carousel by using vi instead of cqw

[Austin1serb]

Summary

On the homepage Backdrop filters carousel, the last card (e.g., sepia) ends up horizontally offset to the right on real iOS devices (Safari and Chrome). Chrome DevTools mobile emulation does not reproduce it. I noticed this while working on the tooltip PR.

Proof

Repro

1. Open https://tailwindcss.com/ on an iPhone (iOS 17+).
2. Scroll to the filters carousel.
3. Let auto-scroll advance to the last item.
4. Observe the card sits offset to the right.

Minimal Fix (tested hotfix)

- w-[calc(50cqw-(var(--size)/2)-(var(--gap)))]
+ w-[calc(50vi-(var(--size)/2)-(var(--gap)))]

Rationale: In this full-bleed section, 50cqw ≈ 50vi. Swapping to vi avoids the container-unit code path that exhibits end-snap bias on iOS while keeping identical layout intent.

Explanation

• The section uses container query units (cqw) for spacer math at the ends; cqw = 1% of the query container’s width. MDN Web Docs
• When the container is effectively full-bleed on mobile, 50cqw ≈ 50vi (viewport inline size). vi is the writing-mode-aware "viewport width" (LTR pages: vi === vw).
• Defining the snap "center" via scroll-padding (or scroll-padding-inline) is spec-intended and used during scroll snap and scroll-into-view operations. MDN Web Docs
• Switching the spacer calc from cqw→vi removed the offset on real devices (no other changes). This suggests the issue is tied to container-unit rounding + end snap behavior, not content layout.

Follow-up (separate PR if desired; not included here)

• Remove end spacer nodes and define center with
  scroll-padding-inline: calc(50vi - var(--size)/2);
• Use programmatic centering that honors scroll-padding:
  node.scrollIntoView({ inline: 'center', block: 'nearest' });

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
tailwindcss-com	Ready	Preview	Comment	Sep 24, 2025 4:28am

[thecrypticace]

Oh huh. This is a problem with smaller viewport resolutions. This is reproducible in responsive design mode in Safari on desktop. Interestingly though not on Chrome at the same or smaller resolutions so this could also be a Safari bug (in which case I'll want to file a webkit bug).

Also tested against (and reproduced on):

• iPhone SE
• iPhone 14
• iPhone 15
• iPhone 16

[thecrypticace]

btw the vi units also exhibit this problem just at a slightly smaller viewport size. Though this might be a good enough workaround for now.

[Austin1serb]

Also tested against (and reproduced on):

You are correct, I just tested in responsive design mode as well.

btw the vi units also exhibit this problem just at a slightly smaller viewport size. Though this might be a good enough workaround for now.

That is what I was thinking also, maybe just ship this as a patch for now, and look into root cause in the meantime. I'd be happy to look further into it, and see what I can find.