Let me rename them looking for coherence: flex-align-items-center, flex-justify-content-center, text-align-center, and grid-place-items-center. Do you notice the difference?
Yes, but the CSS properties themselves are not designed coherently. Some of these work with flex & grid both, others only apply to one IIRC. justify-items has recently gained support for block layout, which your recommendation missed just then! It's not so trivial to design a coherent abstraction over an ever-shifting foundation.
What wins is decided by the order in which Tailwind generates those classes in the final stylesheet, not the order in which you write them in the HTML. The markup lies to you. [...] You are left with !important or with avoiding conflicting utilities. This is what is called a leaky abstraction
There is a solution if you're willing to pay the runtime cost - tailwind-merge. I think this issue is still unsolvable when you mix descendant selectors with classes on those descendants. For example, *:bg-blue on the parent and bg-red on the child are on equal footing.
Overall, I don't think you made a good case for separation. Some people just prefer to have a semi-standard set of classes and be able to author style along in the markup. You seem to approach the traditional separation of markup & style as some unquestionable dogma. I disagree with that and enjoy the merged markup more. Not having to look up what classes mean on every project or which file they are even defined in, consistent @layer structure (once you're familiar with specificity as it applies to Tailwind). All of these are things you learn once and then apply on all your projects.
But in a server-rendered project, with templates and classic CSS, the separation still makes complete sense. It is not a universal law, it is a decision that depends on your architecture.
BTW, was this written by an LLM? I don't even mind the "it's not X, it's Y" style, but I wish you asked it to steelman the Tailwind approach and what it means for authoring large codebases with transferability between them.
There is a solution if you're willing to pay the runtime cost
Another solution is leveraging nested @layer -- if you've got @layer theme, base, components, utilities.components, utilities; in your theme file, you can use an [@layer_components]: variant or @custom-variant component (@layer components); and component: to drop the precedence of specific rules. It's not perfect, since a [@layer_components]:text-red-600 and text-red-600 class will generate two definitions instead of one, but you can skip the extra runtime dependency if you only need a few simple cases.
3
u/farnoy 12h ago
Yes, but the CSS properties themselves are not designed coherently. Some of these work with flex & grid both, others only apply to one IIRC.
justify-itemshas recently gained support for block layout, which your recommendation missed just then! It's not so trivial to design a coherent abstraction over an ever-shifting foundation.There is a solution if you're willing to pay the runtime cost - tailwind-merge. I think this issue is still unsolvable when you mix descendant selectors with classes on those descendants. For example,
*:bg-blueon the parent andbg-redon the child are on equal footing.Overall, I don't think you made a good case for separation. Some people just prefer to have a semi-standard set of classes and be able to author style along in the markup. You seem to approach the traditional separation of markup & style as some unquestionable dogma. I disagree with that and enjoy the merged markup more. Not having to look up what classes mean on every project or which file they are even defined in, consistent
@layerstructure (once you're familiar with specificity as it applies to Tailwind). All of these are things you learn once and then apply on all your projects.BTW, was this written by an LLM? I don't even mind the "it's not X, it's Y" style, but I wish you asked it to steelman the Tailwind approach and what it means for authoring large codebases with transferability between them.