Canonicalize dimensions #19101
Merged
Canonicalize dimensions #19101
+250
−140
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We will normalize units to their canonical form, this is an initial step for allowing `rem` to `px` conversion as well. in, cm, mm, q, pc, pt → px grad, rad, turn → deg ms → s khz → hz Already provided the option to pass in a `rem` value. Once passed in, we will convert `rem` to `px` as well.
+ Expose a `CanonicalizeOptions`
This allows us to migrate `rem` to `px` when provided
The `SignatureOptions` will contain the `DesignSystem` in addition to other potential options. Already added the `rem` option (naming up for debate) to canonicalize `rem` to `px` values if provided.
Instead of a top-level `DesignSystem`, we can use the `SignatureOptions`. We can create `CanonicalizeOptions` or similar in the future that contains `SignatureOptions` _if_ we need values while canonicalizing values but aren't needed when creating a signature. Just didn't want to add this as long as we don't need it. This also changes the APIs for utility and variant canonicalization steps. The APIs look like this: ```ts type VariantCanonicalizationFunction = (variant: Variant, options: SignatureOptions) => Variant | Variant[] type UtilityCanonicalizationFunction = (candidate: Candidate, options: SignatureOptions) => Candidate ```
Oops.
RobinMalfait
force-pushed
the
feat/canonicalize-dimensions
branch
from
619ccdc to
edd6b21
Compare
thecrypticace
approved these changes
Oct 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR further improves the canonicalization of units in Tailwind CSS to increase the amount of similar candidates that can be converted to their canonical form.
This also introduces a
remoption to thecanonicalizeCandidates([…], { rem: 16 }). If this is passed with a pixel value, thenremunits will be converted topxvalues. This is not enabled by default while running upgrades, but this can be used (e.g.: in intellisense).This allows us to migrate
mt-[16px]tomt-4(assuming--spacing: 0.25remis defined). Rem to px value migrations are not safe by default (because it depends on the root font size), but Intellisense can use them to provide a suggestion because in most cases that is what you want.Internally this required a refactor because we now need the
remvalue as well. This introduced aSignatureOptionsinterface to make sure that we have a single stable object that can be passed around and that all the caches exist perSignatureOptionsobject. This means that you can callcanonicalizeCandidateswith differentremvalues without influencing other options.As a user, you don't have to worry about making this second object stable, that will happen internally already.
Usage example:
Test plan
remvalueremvalue or a different value after the previous calls don't touch shared caches.