So it is basically, because you’re using tailwind anyway for styling, using it for layout is nice for consistency sake. I get that.
For (2) however I usually use CSS custom properties to reach for preset values, e.g. setting "column gap" to "var(--margin-inline-wide)", and "row-gap" to "var(--margin-block-short)" etc.
Creator of Tailwind here — what you're seeing here actually is a best effort attempt to be consistent and predictable.
Keys in the config file generally correspond with the CSS property they refer to, and we use the singular form to make it match the CSS property.
There are 3 exceptions, which are "colors", "spacing", and "screens", and these are sort of special keys that don't map to anything in CSS. The "colors" and "spacing" keys are more like reusable variables that are consumed by the property-specific keys like "backgroundColor", "fill", and "borderColor" in the case of "colors", and "width", "height", "gap", and others in the case of "spacing".
The "screens" key is a list of breakpoints for your project, which also doesn't map to an underlying CSS property.
Originally we tried to keep things really abstract and group things together under concepts like "spacing", "typography", whatever, but ultimately found it was more flexible and predictable to make it possible to customize every CSS property using the exact property name, while only providing a couple high-level things like "spacing" and "colors" that you can use to update other dependent keys at once.
Getting complex config files right is unfortunately hard and it's not perfect for sure. At this stage in the project it's a delicate balance between improving things and maintaining backwards compatibility. Totally appreciate what you're saying, just wanted to do my best to clarify though as I'm equally picky about this sort of consistency.
(1) Tailwind uses utility classes that feel like syntactic sugar over full CSS, so I don't feel like I'm "using Tailwind for layouts" as much as "using useful CSS grid presets"
(2) Much like with margins and paddings, text sizes, and colors, Tailwind helps me "pare down" the number of different values available to me. Much like having preset "m-1", "m-2", etc. values helps me be more consistent, having preset grid columns and gap spacing helps me stay consistent and not go too crazy.
(3) Because I'm using something closer to CSS-wrapped-in-classes rather than a set of components built by someone else, and because tailwind gives both a naming convention and an easy mechanism for adding my own classes that fit right in to Tailwind's, if Tailwind doesn't give me the exact values I want for grid spacing, then I can modify theirs. If I need to add a couple new presets in addition to Tailwind's, then I can do so easily.
(4) Early on when CSS Grid was new, I got bit by some bad layout bugs that were very hard to find, and impossible to fix (they were browser bugs). So, while I'm sure the bugs I encountered have since been fixed, I'm a bit gun shy on grids. I occasionally use Grid when it makes sense (via Tailwind), but more often than not I find it easier, more flexible, and safer to just use nested flexbox cols and rows. For which I also use Tailwind, if the project is of suitable size.
OK, but my assumption was that this syntax was proposed as an incentive to use Tailwind, rather than trying to cram custom properties into style attributes.
If I’m going to use custom properties it would be in a way that plays to CSS’s strengths.
This is why I have a hard time getting on the Tailwind bandwagon. It feels like a pipeline equivalent to "margin: 1px 0 0 4px;" and other element-specific stylings _everywhere_.
CSS brought some opportunity for structure. At least it started out as "define a common style for a thing", and then if you really wanted to make a small deviation you could inherit and override something from the class.
Could be that since I'm not a frontender I just don't get it, but to me it feels like "global variables everywhere".
That's the thing that speaks for tailwind with the swatch-like config, but applying this principle here would lead to utter chaos.
If i need a little more spacing on alk my medium margins, i would end up with something like .m-8 { margin: 10px; } if i start editing these compiled styles
I'm not using Tailwind, but that comparison is wrong. Something like mt-2 still doesn't map to a fixed style, and it also has another specificity than inline styles which makes it easier to override.
If you need to globally change the margin that mt-2 adds, you only need to change that class instead of all HTML inline styles.
It's not the same thing, though. Tailwind applies rules from your design system, not plain CSS values. Assuming you're updating your corporate design to use border-radius 2 vs 4 everywhere, with Tailwind it's a matter of reconfiguring your design system configuration; with styled components (and other approaches) you're going on a string hunt.
I think you might be looking at tailwind the wrong way here.
Tailwind does “enforce” separation of concern between styling and content, just in a different way than the separation of html and css.
Consider the utility class m-1 and m-2. What they are supposed to say is that element with m-1 class and element with m-2 class should have different margin, with the m-2 element probably have a slightly bigger one, and every element that uses m-2 class should have the same margin. It doesn’t specify styling at all. The concerns of styling are completely separated into the theming system.
All that the utility class define is the relation between elements. Eg. which elements should have the same margin/color/typography etc... This would also provides consistency in your designs, unlike pure css which allows you to do whatever you want without defining structure and relationships between elements.
I would say tailwind forces you to separate styling concerns out of your content and into your theme. You could probably replicate css zen garden using tailwind theming system.
I believe the primary reason that sets TailwindCSS apart is its inclusion of pre-defined margins, paddings, and colors. Starting with these built-in defaults is much simpler than having to consider all these design elements from scratch.
There are a few important limitations, Tailwind can't fully support logical properties for example because `mb-8` could mean margin bottom or block. Any use case that requires styling one element based on another gets a bit hairy too.
Both of these can be technically worked around. Config may be able to disable existing margin/padding classes and replace them with a custom set, and the groups feature helps especially for simple cases of referencing other elements.
In my experience though, as soon as config is meaningful modified or you elan on the more obscure features for groups, pseudo selectors, etc. the learning curve has just been moved from the dev who doesn't know CSS to the dev who doesn't know Tailwind.
Exactly. Tailwind's utility classes correspond 1-1 with CSS attributes more or less. Then you have variants to help you target things like hover and focus states as well as pseudo elements like before and after. But Tailwind does nothing to hide away CSS in that you still have to understand flex and grid layouts, padding, z-indexing, margins, etc.
What Tailwind does give you is a way to build on top of a design system. The Tailwind config gives you a pretty good default design system in terms of spacings (padding and margins), colours (palettes and shades), etc. And you are free to modify or make your own design system, but once you do your design is much more likely to be consistent.
You can of course achieve the same design system with css custom properties (aka variables), but you have to be much more cognisant of using them. With Tailwind the design system is the default and you have to go out of your way to use custom values.
Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites.
Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of these utility classes for a single class. Including Tailwind UI itself.
Given that the relationship of class to property is one to one, why not cut out the middle person and just use CSS directly? There seems no real advantage. You've basically indepedently re-invented CSS, while adding a strange layer of additional abstraction on top. It is nice and fast to write it in the HTML I'll grant, but, the speed advantage is not so great that it is worth it compared to the mental overhead of other aspects of working with Tailwind (e.g. having to trim all the classes with automated scripts and so on).
I was going to say this. Tailwind always appeared to be as an alternate way of writing inline styles. I focus mostly on the back end and CSS is always a source of frustration when dabbling in front end, so perhaps I am not the right target anyway.
that's ridiculous, why not just write padding: 2px 5px; display: flex; align-items: center; color: #fff; You are basically just creating a set of attributes that just mimic standard css properties, I find this approach of tailwind absolutely counter productive, and I am surprised that it gets so much popularity.
Using tailwind is mostly like using css. It is just a selection of recommended properties and values that hides almost nothing about the nature of css.
The abstraction is very thin and its main goal is to limit the "power" of css (complex selectors, arbitrary color or spacing values) to help developers implement best practices.
For (2) however I usually use CSS custom properties to reach for preset values, e.g. setting "column gap" to "var(--margin-inline-wide)", and "row-gap" to "var(--margin-block-short)" etc.
reply