4 ms·
Hmmm... as a non-tailwind user I just took a look. Maybe this shows my age, but it kinda looks like an extension of <b></b> <i></i> - you know, that stuff that
by LouisSayers 5y ago
Hmmm... as a non-tailwind user I just took a look.
Maybe this shows my age, but it kinda looks like an extension of <b></b> <i></i> - you know, that stuff that we moved away from a long time ago...
Isn't this losing the point of CSS - that our "content is separate from its styling"?
I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc.
I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?
- topspin 5y ago> if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class. The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer? > next time a designer decides to give your webapp a makeover? I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
- 1_player 5y agoOne underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.
- LouisSayers 5y agoI think you're discounting the value of naming though. You don't refer to bananas as "the curved sweet yellow food that grows on trees", you simply refer to a banana as a banana. Sure, for one off items it might not make sense to name it but when you create design patterns then it's incredibly useful to be able to name things. Yes it may be hard and require you to think, but just because that is so does not make it bad necessarily.
- topspin 5y ago> "the curved sweet yellow food that grows on trees" You have (some variety of) cavendish bananas in mind. There are red, pink and blue bananas. They're not all sweet. The plants they grow in are not always "trees" but rather large fern like plants. And then that day arrives when you are required to style some variant of 'banana' you are forced to decide: do I break the world by messing with banana or do I make new-banana?
- LouisSayers 5y agoI'm definitely going to have to do some research on bananas after this lol. In CSS land however you wouldn't break the world for a different banana, you'd simply add another class for the variant and style appropriately. .banana { // generic banana styles } .banana.musa-velutina { color: pink; } Of course not all decisions are going to be as straightforward, but I do think that there's a lot of value in keeping a website's items consistent. The work upfront to name things and build out concepts will pay its dividends as you extend a site or build out new ones.
- deergomoo 5y agoIn my experience the “one-off items” are far more common, simply because every one thing I do reuse will typically have several child elements. Why am I naming the styles that represent the title of a contact card if I never use it outside of the contact card—which itself is probably included by referencing a file called “ContactCard.html” or whathaveyou. Of course, there’s no right or wrong answer here, and I suspect it very much depends on what type of web systems you are building. I feel the entire debate is basically a special case of the question “do you make websites or web apps”.