Live data from Hacker News

Styling with Classy CSS (2006)

thedailywtf.com

51–60 of 76 posts

Re: Styling with Classy CSS (2006)

#51
post #39

Earlier quoted context omitted.

It's funny how the solution (use CSS as it was intended) is now being transformed into JS-powered component solutions. But yeah take say a dashboard layout with a lot of cards of different sizes. They're going to have the same underlying design, padding, rounded edges, background colors, etc -- and usually only vary on maybe size and breakpoints. This is all very well solved in semantic web, but it feels to me like t…

> This is all very well solved in semantic web If it was solved with "semantic web" (whatever that means), we wouldn't have people attempting to solve this again, and again, and again.

That's patently false. The webdev community does nothing but reinvent/rediscover the wheel e.g. SSR.

Re: Styling with Classy CSS (2006)

#53
post #18

It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability. Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!

Or just use var(), which of course didn't exist when the article was written.

That way you can define your company's --brand-colour at the top of the file.

Re: Styling with Classy CSS (2006)

#54
post #31
post #21

Earlier quoted context omitted.

Now that you're familiar with BEM you can use the perfect css approach `.page__inner__title-f-green {color:#0f0;}` imagine the portability!

Or you can call the login box “.login” and style it.

Or you can have fun

Re: Styling with Classy CSS (2006)

#55
post #18

It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability. Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!

This was the only bit in tailwind we modified a lot in our Config. You really need to remove the default colors and define them as [Primary, Secondary, Neutral, Warning, Error, Success] and then add variants of each. Then it really works. I honestly think this should be a default config change/setup option in TW. Nobody with a Design System/Brand guidelines should be including the default colors in their app.

I agree that you don't need the default colours, and in fairness this is one of the things that Tailwind fairly explicitly encourages. That said, I also used to use "primary"/"secondary"/etc names for the colours, but since using Tailwind, I've been using colour names directly (e.g. "blue" or for fancier design systems "mirage-blue" or whatever their name for their specific custom blue is).

I find it's helped for a few reasons, but the big one is just that it's easier to keep the colours in my head - I'm not thinking in terms of "tertiary-alt-3" or something, I'm looking at a design and going "that's green, which green? This green". I have more discussions talking about colours in terms of the standard English colour names than I do in terms of those colours' purposes in the design system, so the colour names seem more practical.

That said, I agree that spending some time switching the colours to whatever design system you're using us very useful. Another trick I've found is starting off a project just using raw CSS values (the `p-[8px]` syntax), and then when the basic designs are done based on whatever the designer has sent, getting a list of all the custom classes you've got and using this to define what the standard units are. This is helpful when the design guide isn't specific on these details, and the designer is being more freeform.

Re: Styling with Classy CSS (2006)

#57
post #2

Back in the day we made fun of this nonsense, now we freakin glorify it with libraries like Tailwind & friends...

Yeah. It's essentially a less verbose form of per-element style="..." attributes. It's weird to me that this is considered the state of the art today.

Re: Styling with Classy CSS (2006)

#58
post #20

Earlier quoted context omitted.

Perhaps I'm just old-fashioned but I prefer semantic classes. I completely rewrote the CSS for my website and I did not need to touch the templates. An .error is an error and a . collapsible is a collapsible. Their exact style is not dictated by the markup. I also like that it keeps the markup small and easy to read, because it's not peppered with CSS. It also avoids situations where two widgets look different becaus…

Semantic classes make sense for small and brochure-style websites. For any moderately complex website or web application, your class semantics quickly become a challenge. Naming things is exceptionally hard, especially when each "component" can have multiple variants each with their own modifier classes e.g. `alert alert-danger alert-with-icon alert-collapsible alert-expandable alert-hidable`. Multiply this by hundre…

As someone who has consulted on more enterprise level websites than I can count, this has not been my experience at all.

Re: Styling with Classy CSS (2006)

#59

Yep, Tailwind didn't invent style tokens or composable classes! After learning Foundation, Tachyons, Material UI, Chakra...I was happy to see we finally settled on Bootstrap. Oh, we didn't? Well, time to learn a new syntax. (Was it ` dark:md:hover: text-slate-400` or ` hover:md:dark: text-slate-400` again?) At least Tailwind arguably has more benefits than its predecessors.

I think Tachyons struck the balance to be honest. Tailwind's "functions" and combinations seem to allow a higher level of complexity where it becomes difficult to quickly inspect a class block after some time has passed.
Post reply on HN