Skip to content

Individual transforms can't get converted to compatible syntax by lightningcss #14094

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ottomated opened this issue Jul 31, 2024 · 3 comments
Closed

Comments

@ottomated
Copy link
Contributor

What version of Tailwind CSS are you using?

4.0.0-alpha.18

What build tool (or framework if it abstracts the build tool) are you using?

[email protected]

What version of Node.js are you using?

v20.16.0

What browser are you using?

Chrome 103.0.5060.134 (OBS CEF)

What operating system are you using?

Linux

Reproduction URL

LightningCSS

Describe your issue

The translate property (and other individual transforms) is only supported in newer browsers.

Per parcel-bundler/lightningcss#247, lightningcss does support converting translate: ...; into transform: translate(...);. However, it seems to have a few caveats - it needs a transform property in the same class, and it also doesn't seem to work when vars are used to define the parameters.

The v3 docs say:

While most of the features in Tailwind CSS will work in all modern browsers, Tailwind also includes APIs for several bleeding-edge features that aren’t yet supported by all browsers, for example the :focus-visible pseudo-class and backdrop-filter utilities.

In my opinion, a common utility such as transform should be supported in all browsers - the lack of support blocks me from using v4 in any production applications.

@adamwathan
Copy link
Member

Hey! Yeah so for v4 we are targeting fairly modern browsers, aiming for Safari 16.4+ so we can use features like @property (Safari 16.4/Chrome 88), color-mix() (Safari 16.2/Chrome 111), and @layer (Safari 15.4/Chrome 99).

Independent transforms were added in Chrome 104 which was released two years ago. If we have to support Chrome 103 then we also can't use @layer which is a really important part of the v4 architecture, so I don't think there's any benefit to changing this unfortunately since you'd still have problems with other features if you need to support old Chrome versions.

Appreciate the feedback either way, helpful to keep track of in case it does make sense to change our plans.

@ottomated
Copy link
Contributor Author

I understand. Looks like that adds up to 84.4% on browserslist, which is unfortunately a dealbreaker for me. What do you think is the feasibility of an official or community-supported pulgin for "legacy" compat? I don't see it on the roadmap, and I think it's a mistake to advertise backwards compatibility if v4 only supports bleeding-edge css.

@ottomated
Copy link
Contributor Author

opening a new issue for visibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants