I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.
I think this assertion is where most of the conflict comes from.
There is a fair amount of people that disagree with the premise that it should be separated in that way (Including me).
I personally like this essay by the author of htmx on the topic
https://htmx.org/essays/locality-of-behaviour/
Also just better composition imo.
Practically I think this means components of scoped css, html, js.
People never seem to have the same complaint about mixing or separating app code and sql in the same way?
There’s absolutely no tension between locality of behavior and separation of concerns in CSS: you’re putting styles on the elements in the document. The styles are defined elsewhere.
It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.
Its arguing that that source code that affects the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.
Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path.
Like you would want to init a variable closer to its usage, Or that having a 100 wrapper functions is less understandable than inlining for a single statement, or global mutations are harder to trace then local, and that sometimes its easier to inline a single sql statement then split it out into a different file just because its 2 different languages.
Also, to be clear its possible to write CSS that exhibits less or more LoB. The file thing is more that I don't think HTML, CSS, JS "must" be written as separate files which is what the prevailing best practice used to be, justified as SoC. I just think splitting along the scope/behaviour lines rather than file type is more understandable.
> Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path.
The metaphor remains valid. You can do this all the way down the abstraction stack, back to functions.
I separate those too. Queries get their own file. Sometimes their own framework.
Sorry maybe that wasn’t the best example. It’s not really about separation of files. But how they connect.
In sql your code may be in a seperate file but your app code is still clearly calling the sql. The inlining vs not inlining is just abstraction. You could use a function, or a separate file or not, a different language or not.
But there is a clear single call chain at the points where that behaviour is being applied and a single definition.
With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.
> With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.
There's only one algorithm, the cascade. And it's described here[0].
And just like any code you write, try not to write complex selectors. If you're not sure two styles are equal, it's better to write two different rules. And just like styling works in any system, you go from generic (standard html elements) to very specific ones (the link in the hero section of the about page)
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Casc...
that’s exactly the part that is anti locality of behaviour.
I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.
Call it composition over cascade.
To be clear I think it’s possible to do this without tailwind. And tailwind has other out of the box features/opinions.
But it works well enough without too much friction.
> that’s exactly the part that is anti locality of behaviour.
It is not. Because it fits the concept of "web pages" as documents and forms (which most web apps are, even if they're trying to pass as desktop applications.
> I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.
And you're very welcome to do what you want. But there's no need to bash cascading as it's a good solution for web pages.
End users and even other programs/extensions can load rules to alter your styles. I think thats about as opposite of locality of behaviour as it gets. (no judgment on customization on being good/bad).
With the rest I don't really strongly disagree. I think its just a question of complexity. For simple things its fine, but for complex apps with teams of people :shrug: