61–70 of 76 posts
Earlier quoted context omitted.
Or, like, off-green. And after midnight, green with all the blue taken out.
Yes of course. But not red.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
As someone who has consulted on more enterprise level websites than I can count, this has not been my experience at all.
Can you point me to an enterprise level website that uses semantic classes?
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.
Remember when serverless got invented even though CGI already existed?
Back in the day we made fun of this nonsense, now we freakin glorify it with libraries like Tailwind & friends...
Earlier quoted context omitted.
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 f…
Then you can do things like `color1` (or `primary1` or `secondary2`) etc, keeping them generic. With this setup you can then re-theme any area instantly, no dark-x or light-x, no green-x. You can inverse an area to be light on dark, you can change the color out if need be.
We even go one step further (as an optional feature) where you can avoid the `color1` for many cases and instead use `color`, `colorHover` etc, which allows for having themes that change contrast or the strength of their various alternate states, but that's another story.
The site itself shows off some of this, but it's really quite nice. Now your "Notice" box can be alert style, or success style, with just a single ``.
Earlier quoted context omitted.
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 f…
The biggest thing I've learned in making Tamagui is that the ideal setup is not to really have specific colors at all (unless you really really are just doing a one-off single color thing), but instead to let themes handle this (essentially a classname that changes out a set of CSS variables). Then you can do things like `color1` (or `primary1` or `secondary2`) etc, keeping them generic. With this setup you can then…
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!
Nope. Green should give you green.
I will always argue against this. Keep your layout in one file and your styling in another. I've done more CSS than most in heavy web production and I never once had a reason to think something like this would be faster or more efficient.
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.