Prevent collisions between utility classes generated by Tailwind #106
Unanswered
ChucKN0risK
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Context
Specify aims to streamline the delivery of design tokens over many sources and destinations. Our approach is to provide maximum flexibility for our users to configure their own pipelines.
TailwindCSS is a utility-first CSS framework that provides a large panel of utility classes to avoid writing your own CSS. Tailwind's configuration allows a deep level of customisation.
Thus, Specify can provide tokens to be included into the Tailwind's default theme. Nevertheless, Tailwind's approach to tokens declaration is opinionated and requires well thought naming conventions.
Let's take an example using our main source: Figma.
Let's consider you define a shape with some border and radius:

By defining such a simple artefact, we already imply various tokens to Tailwind:
border-style: solid
border-width: 3px
border-color: #3760C9
border-radius: 5px
For that matter, Specify uses the name of the shape/layer (
border-primary
in that case) to name border design tokens. This will create a.border-primary
CSS class within a default CSS context.However, Tailwind treats each token as a separated category and apply some magic to generate many utilities classes to ease the development process.
Tailwind "explodes" composite design tokens to create individual design tokens used in utility classes.
Let's have a look at the Tailwind theme configuration generated by the Specify to-tailwind parser:
Which will get parsed by Tailwind as:
🤯 What happened here?
A bit of Tailwind first. The
colors
key used by Tailwind generates 3 types of utility classes:text
for thecolor
CSS propertybg
for thebackground-color
CSS propertyborder
for theborder-color
CSS propertyIn our case, both the
colors
andborderWidth
share the same name:border-primary
. Tailwind interprets it as an intent for factoring those two values within the same scope:.border-border-primary
.Hence, the
border-width
andborder-color
are not accessible independently through CSS classes.Because we're dealing with divergent ways of conceiving how configuration must be generated (Figma) and how it must be implemented for a framework to work (Tailwind), there isn't any one-size-fits-all solution.
Our solution: extend the
to-tailwind
parser configurationIf we can't impact nor on Figma, nor on Tailwind directly, we can still expose a configuration for users to set up their desired overrides.
We would add a
renameKeys
map to provide a pattern replacement feature for each key of the Tailwind theme.Example:
Where {{name}} refers to the name of your design token coming from Specify.
Therefore, the parser would generate:
Which will get parsed by Tailwind as:
Resources
Beta Was this translation helpful? Give feedback.
All reactions