So, we're just going a full circle back now. Interesting.
Yep. Every 7 years.
Moving away from Tailwind, and learning to structure my CSS
151–160 of 435 posts
Re: Moving away from Tailwind, and learning to structure my CSS
#152> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…
> Tailwind instead pushes the dev into a CSS-first approach. You think about the Tailwind classes you want, and then throw yet-another-div into the DOM just to have an element to hang your classes on. I wholeheartedly disagree. That mindset is not caused by Tailwind, but by being ignorant. You can perfectly create an HTML document with semantic meaning and the add Tailwind just as any other CSS framework or pure CSS…
The HTML spec says divs are the element of last resort. This issue isn’t that they’re bad. The issue is they are reached for far too quickly.
Also if you think massive numbers of nested divs don’t have a performance impact in the DOM when reusable components are nested (because “styling”), you’re wrong.
Re: Moving away from Tailwind, and learning to structure my CSS
#153> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…
> HTML is marking up the meaning of the document. You should start there. Then style with CSS. If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first). > Tailwind instead pushes the dev into a CSS-first approach. You're putting the cart before the horse. Or forgetting either the cart or the horse. Tailwind doesn't force anything…
> Oh no! And what are the opening examples on any of the "proper pure-as-god-intended CSS" sites?
The first example on https://developer.mozilla.org/en-US/docs/Learn_web_developme...:
Instructions for life:
Eat
Sleep
Repeat
p {
font-family: sans-serif;
color: red;
}
li {
background-color: greenyellow;
border: 1px solid black;
margin-bottom: 5px;
}
Re: Moving away from Tailwind, and learning to structure my CSS
#154Earlier quoted context omitted.
Global styles are like global state in software: They're best avoided.
Global state is bad because it’s mutable. Global styles are not mutable.
No.. that's not the only reason.
Global state is bad because it makes it hard to reason about your system. The global state can affect any part of it, or, focusing on the inverse which is probably better applied to global styles, any part of your system can depend on the global state.
It's also weird to say "global styles are not mutable" - you're right, they're (generally) not mutable, at runtime. But they are mutable in the sense that your developers (you, or your colleagues, or someone in 3 years maintaining your code) can mutate them, and if large parts of your system are implicitly dependent on the CSS cascading properly and so on, then those changes can have unintended consequences.
Of course, that can also apply to tailwind, to some extent. A developer can change a class (custom or otherwise) or the configuration - but at least it is very clear what is being changed and what parts will be affected (just grep).
Re: Moving away from Tailwind, and learning to structure my CSS
#155> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…
It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer.
The summary: write your CSS in specificity order [1]:
/scss/
├── 1-settings. Re: Moving away from Tailwind, and learning to structure my CSS
#156Earlier quoted context omitted.
> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for . Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY,…
There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few. Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there. > Sure, sure. except for the inline styles everywhere. And the fact that e…
> Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
Erm...what now? That's so off-the-wall that I can't even wrap my head around your meaning.
Are you trying to argue that because, say, a conventional CSS file has "border:1px" in multiple places, this is somehow equivalent to the Tailwind approach of making a "b1p" class that captures the same thing [1], and plastering it across your templates?
Because a non-abusive application of CSS would actually just put that border property in a semantic class like ".widget" or something, and sure, you'd have multiple "border:1px" declarations across all of your CSS files, but that's irrelevant, because you're not trying to reconstitute every style inline from pseudo-properties.
[1] I am making this example up for illustrative purposes.
Re: Moving away from Tailwind, and learning to structure my CSS
#157Earlier quoted context omitted.
> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for . Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY,…
There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few. Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there. > Sure, sure. except for the inline styles everywhere. And the fact that e…
> Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
It’s like the difference between
app_name = "Foobar"
print(f"Welcome to {app_name}")
print(f"Learn how to use {app_name}")
print(f"Welcome to Foobar")
print(f"Learn how to use Foobar")
Re: Moving away from Tailwind, and learning to structure my CSS
#158Earlier quoted context omitted.
I use Tailwind and have all kinds of "screen reader" directives in my templates. Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them. It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".
It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.
People always forget they're one unlucky event from losing their sight, hearing, dexterity, or more. Hell, like you say, even aging's enough to do it. Accessibility suddenly becomes a lot more important when you're on the other side of the "not a priority" talk.
Re: Moving away from Tailwind, and learning to structure my CSS
#159Earlier quoted context omitted.
> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for . Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY,…
> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hu…
> And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.
The client still has to decompress it and waste processing power parsing all the repeated text.
Re: Moving away from Tailwind, and learning to structure my CSS
#160I just want to point out that you can use Tailwind inside your CSS with the `@apply` directive (not to be confused with the since abandoned CSS `@apply` rule). You write your CSS and mix in Tailwind instructions where it makes sense. Example:
@import 'tailwindcss';
p {
@apply text-justify;
@apply bg-slate-300 dark:bg-slate-800; /* Second rule just for colors */
display: block; /* regular CSS */
}