4 ms·

so i'm on board with your central concern here. my issue with functional css is that your markup has no semantics. you can't just look at it and know what thi

by jonahx 8y ago

so i'm on board with your central concern here. my issue with functional css is that your markup has no semantics. you can't just look at it and know what things are by their names. ie, <div class="m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"> what the hell is that thing described by all those styles? versus: <div class="profile-card"> and i know immediately what it is, and can instantly map the markup to what i see on the page. you just lose too much by not having that imo. i really like composing styles out of small little semantic utility classes as in the first example above, but you can do that and still have semantically named classes easily enough with a preprocessor. i'd be curious to hear your thoughts on that. when i've discussed this concern with functional CSS purists they usually just shrug and say something like "you get used to it" or "you just don't need those semantic class names" but i find that response unsatisfactory. clean, readable markup is so much more pleasant to work with.

darekkay 8y ago
One possible solution is in the article - nothing prevents you from using: <div class="profile-card m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"> with "profile-card" being use just for identifying the component. Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for.
- jonahx 8y ago
  yeah that's better than nothing, but your markup is still super noisy and hard to scan. > Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for. I do all the time. I'd much prefer to work in my text editor, without being obliged to use chrome tools to extract semantic meaning from my code.
- gyrgtyn 8y ago
  var profileCard = "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"
camgunz 8y ago
From the other perspective, I know what "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" will look like and I can immediately change it. I have no idea what "profile-card" does, and if it's ultimately something I don't like I have to go through the whole asset pipeline to change it. I'm not saying you're wrong, I think I'm more or less against functional CSS, but just saying there's at least one more way to look at it.
- jonahx 8y ago
  Yes, this is valid to point out as a tradeoff. I weight clean markup and "knowing immediately where i am by looking at the code" more heavily in this particular balance scale, though -- it's a higher-level concern in some sense. Practically speaking, I'd typically have the markup open side by side with the SASS (or other source CSS) file where "profile-card" was defined in vim, so the lookup process is just moving my eyes across the page.
newsbinator 8y ago
classes like m-5 or p-2 can be semantic enough. But using classes named with colors is silly. It's as silly as naming a function based on the content of a string it's manipulating. const str = "cat"; function reverseCat(str){ return str.split("").reverse().join(""); }
chrisweekly 8y ago
There's another active post right now [1] where Tailwind's creator has been addressing these understandable initial reactions. TLDR: Tailwind is utility-FIRST not utility-ONLY, and its `@apply` directive and approach to composition means you can exercise a lot of control without every element requiring so much "noise". Don't get me wrong, I'm not saying there's only one good way to do things and this is obviously it; rather, it's worth overcoming one's initial revulsion to look at what's possible, bc it is in fact quite elegant. [1] https://news.ycombinator.com/item?id=18084013 https://news.ycombinator.com/item?id=18084013
- jonahx 8y ago
  I'm sold on building up your UI through the composition of utility classes. I just don't want them in my html. It's really not resistance that's at work here. I just think you should name your abstractions. Note this does not imply coupling. If you're so worried about that give every element a different name for all I care, put a number at the end of the names, but at least make them meaningful. I still want to be able to read my markup. It's odd to me that functional-css seems to have gotten bound up with "inline everything." The two concepts are orthogonal. And it seems that the big benefit of having everything in line is... you only have to have one file open? I mean, I guess that's simpler than two files side by side, but it's such a tiny benefit compared with readable markup imo.
chrisweekly 8y ago
"... your markup has no semantics. you can't just look at it and know what things are, by their names." Huh? I think you've got it exactly backwards. My React components all have semantic names. In contrast, you're apparently using raw HTML "div" elements and relying solely on your style classes' names for semantics. You can certainly do that (with or without functional css) but it's orthogonal to the things that make Tailwind and functional css great, and your complaint makes me wonder about your setup; it's almost as if you're hand-writing and maintaining static HTML identical to what you see with "view source". Are we both talking about styling web applications?
- jonahx 8y ago
  > but it's orthogonal to the things that make Tailwind and functional css great exactly. that's what i've been saying, and why i don't understand why "inline css" and "functional css" have been conflated. i'm not sure why you're bringing up react -- i'm talking about the general case of writing markup. obviously you sometimes might write it directly by hand, and sometimes it might be generated for you by react components or server-side components or whatever.

by jonahx 8y ago

darekkay 8y ago

One possible solution is in the article - nothing prevents you from using: <div class="profile-card m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"> with "profile-card" being use just for identifying the component. Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for.

jonahx 8y ago
yeah that's better than nothing, but your markup is still super noisy and hard to scan. > Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for. I do all the time. I'd much prefer to work in my text editor, without being obliged to use chrome tools to extract semantic meaning from my code.
gyrgtyn 8y ago
var profileCard = "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"

camgunz 8y ago

From the other perspective, I know what "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" will look like and I can immediately change it. I have no idea what "profile-card" does, and if it's ultimately something I don't like I have to go through the whole asset pipeline to change it. I'm not saying you're wrong, I think I'm more or less against functional CSS, but just saying there's at least one more way to look at it.

jonahx 8y ago
Yes, this is valid to point out as a tradeoff. I weight clean markup and "knowing immediately where i am by looking at the code" more heavily in this particular balance scale, though -- it's a higher-level concern in some sense. Practically speaking, I'd typically have the markup open side by side with the SASS (or other source CSS) file where "profile-card" was defined in vim, so the lookup process is just moving my eyes across the page.

newsbinator 8y ago

classes like m-5 or p-2 can be semantic enough. But using classes named with colors is silly. It's as silly as naming a function based on the content of a string it's manipulating. const str = "cat"; function reverseCat(str){ return str.split("").reverse().join(""); }

chrisweekly 8y ago

There's another active post right now [1] where Tailwind's creator has been addressing these understandable initial reactions. TLDR: Tailwind is utility-FIRST not utility-ONLY, and its `@apply` directive and approach to composition means you can exercise a lot of control without every element requiring so much "noise". Don't get me wrong, I'm not saying there's only one good way to do things and this is obviously it; rather, it's worth overcoming one's initial revulsion to look at what's possible, bc it is in fact quite elegant. [1] https://news.ycombinator.com/item?id=18084013 https://news.ycombinator.com/item?id=18084013

jonahx 8y ago
I'm sold on building up your UI through the composition of utility classes. I just don't want them in my html. It's really not resistance that's at work here. I just think you should name your abstractions. Note this does not imply coupling. If you're so worried about that give every element a different name for all I care, put a number at the end of the names, but at least make them meaningful. I still want to be able to read my markup. It's odd to me that functional-css seems to have gotten bound up with "inline everything." The two concepts are orthogonal. And it seems that the big benefit of having everything in line is... you only have to have one file open? I mean, I guess that's simpler than two files side by side, but it's such a tiny benefit compared with readable markup imo.

chrisweekly 8y ago

"... your markup has no semantics. you can't just look at it and know what things are, by their names." Huh? I think you've got it exactly backwards. My React components all have semantic names. In contrast, you're apparently using raw HTML "div" elements and relying solely on your style classes' names for semantics. You can certainly do that (with or without functional css) but it's orthogonal to the things that make Tailwind and functional css great, and your complaint makes me wonder about your setup; it's almost as if you're hand-writing and maintaining static HTML identical to what you see with "view source". Are we both talking about styling web applications?

jonahx 8y ago
> but it's orthogonal to the things that make Tailwind and functional css great exactly. that's what i've been saying, and why i don't understand why "inline css" and "functional css" have been conflated. i'm not sure why you're bringing up react -- i'm talking about the general case of writing markup. obviously you sometimes might write it directly by hand, and sometimes it might be generated for you by react components or server-side components or whatever.