Which configurations should we configure/adopt for tailwind CSS?
For now we only have the default Tailwind CSS configurations configured.
Colors
Customizing the default color palette for your project.
We should add (extend) custom colors (i.e: primary, secondary, primary-hover, success, warning) to stop using hardcoded or arbitrary tailwind values.
Spacing
Customizing the default spacing and sizing scale for your project.
By default, Tailwind includes a generous and comprehensive numeric spacing scale. The values are proportional, so 16 is twice as much spacing as 8 for example. One spacing unit is equal to 0.25rem, which translates to 4px by default in common browsers.
I think that the current scale is hard to reason (ex: p-2 give you 8px padding) but I understand that it can be more accessible by using rem units instead of pixels.
Screens
Customizing the default breakpoints for your project.
I think that for now we don't need to think much about this section.
Plugins
Extending Tailwind with reusable third-party plugins.
We already have the custom debugPlugin plugin that renders outline borders for elements (debug) and childs (debug-childs)
This is a good place to register utility classes for an eventual design system built using tailwind css rules in a CSS file with @apply (eg: [.btn-primary](While you can usually build the bulk of a well-crafted design using a constrained set of design tokens, once in a while you need to break out of those constraints to get things pixel-perfect.
), .btn-secondary).
Arbitrary values
When you find yourself really needing something like top: 117px to get a background image in just the right spot, use Tailwind’s square bracket notation to generate a class on the fly with any arbitrary value:
IMO we should avoid using this feature. Notable cases are for :content and to use dynamic variables.
Which configurations should we configure/adopt for tailwind CSS?
For now we only have the default Tailwind CSS configurations configured.
Colors
We should add (extend) custom colors (i.e: primary, secondary, primary-hover, success, warning) to stop using hardcoded or arbitrary tailwind values.
Spacing
I think that the current scale is hard to reason (ex:
p-2give you8pxpadding) but I understand that it can be more accessible by usingremunits instead of pixels.Screens
I think that for now we don't need to think much about this section.
Plugins
We already have the custom
debugPluginplugin that renders outline borders for elements (debug) and childs (debug-childs)This is a good place to register utility classes for an eventual design system built using tailwind css rules in a CSS file with
@apply(eg: [.btn-primary](While you can usually build the bulk of a well-crafted design using a constrained set of design tokens, once in a while you need to break out of those constraints to get things pixel-perfect.),
.btn-secondary).Arbitrary values
IMO we should avoid using this feature. Notable cases are for
:contentand to use dynamic variables.