This comes at particularly nice timing with Rails 7 releasing at the end of the month. I can't wait to pair the two and see how well the new features of each work together.
Tailwind CSS v3.0
271–280 of 448 posts
Re: Tailwind CSS v3.0
#272Earlier quoted context omitted.
Sounds a bit like a glorified ... ?
Yes, or now with Tailwind v3.0 you can write that as ... I wish I were being hyperbolic, but alas, no: https://tailwindcss.com/blog/tailwindcss-v3#arbitrary-proper...
FWIW, I also hated using header files in C++ and also wrote a Ruby library for inlining all my tests immediately following the functions they test. I like having more context when looking at code without having to flip around from file to file to piece a bigger picture together.
Re: Tailwind CSS v3.0
#273I love Tailwind! It elegantly solves most pain points in writing CSS. However, it does this at the cost of readability, and you can easily end up with HTML that looks like this: Yikes! I would love to have a transpiler that produces the line above from a code like this: Yeah!
https://windicss.org/ does it It also seems that the major speed improvement in Tailwind is inspired by windi
It's exactly what I was looking for, Thanks!
Re: Tailwind CSS v3.0
#274Earlier quoted context omitted.
> I used the JIT version recently on a new landing page Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with…
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something you write an atomic component which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be…
Another variation I've seen is a combination of atomic CSS and Mithril.js' hyperscript selector syntax, which lets you do stuff like this:
const Button = 'button.bg-gray-900.px-6.text-white';
// JSX
return Click me
There definitely are interesting ways of applying atomic CSS beyond basic Tailwind usage.Re: Tailwind CSS v3.0
#275Earlier quoted context omitted.
> CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs and classes that are only there for styling. Can you provide an example? I've never found this to be the case, particularly with modern CSS. Happy to be wrong though.
Take a look at the https://tailwindcss.com/ page and search for "div". Can you replace them all with more semantic tags? If not, can you remove them and still style it the same way? You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox), to target content for styling (e.g. putting a div around the name of the author to make it blue when you otherwise wouldn't tag it) and t…
Re: Tailwind CSS v3.0
#276I love Tailwind! It elegantly solves most pain points in writing CSS. However, it does this at the cost of readability, and you can easily end up with HTML that looks like this: Yikes! I would love to have a transpiler that produces the line above from a code like this: Yeah!
Re: Tailwind CSS v3.0
#277Earlier quoted context omitted.
> I used the JIT version recently on a new landing page Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with…
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something you write an atomic component which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be…
Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes.
I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + ViewComponent has basically revolutionized the way I build user interfaces in Rails.
Re: Tailwind CSS v3.0
#278Earlier quoted context omitted.
> CSS modules still seem to solve every problem Tailwind solves, and better. I don't understand Tailwind either; but I find myself struggling with CSS modules when I need to override a CSS rule of a child from a parent. Like, say, my button should always be green, except in this context I want it to be purple, its font-size larger and its padding a bit different. With CSS modules, the parent component is unaware of t…
.button is the default .button-context is the context version className={isContext ? ".button--context" : ".button"} ---- alternatively if you want many unrelated base rules that aren't color/padding as a baseline: .button contains base rules .button--default default color/padding .button--context contextful color/padding className={`.button ${isContext ? ".button--context" : ".button--default"}`}
import classNames from 'classnames';
...
className = classNames(styles.buttton, props.className);
But this leaves me at the mercy of the order in which webpack builds stylesheets (sometimes props.className will be defined after styles.button and my plan would work; other times it will get defined before styles.button, and styles.button will override the CSS rules of props.className).Really wanted the extension of the base rules to work out; but I guess you are right: the className from the props should override entirely one of the classNames of the component.
Re: Tailwind CSS v3.0
#279I love Tailwind! It elegantly solves most pain points in writing CSS. However, it does this at the cost of readability, and you can easily end up with HTML that looks like this: Yikes! I would love to have a transpiler that produces the line above from a code like this: Yeah!
Even spread out in attributes it’s hard to read
Re: Tailwind CSS v3.0
#280Earlier quoted context omitted.
If you're talking about Tailwind UI[1] — I use Tailwind extensively and have basically never looked at Tailwind UI. It's just useful snippets of HTML styled with Tailwind. It is by no means required to get value out of Tailwind. I'm not sure what you mean by proprietary culture! Based on the fact that I've pretty much never seen anyone talk about it, I would guess (total guess, no real knowledge) that no more than 1%…
You have to do literally everything from scratch with Tailwind though, for example I never realised how much work is involved in a simple avatar dropdown / logout component (hidden full-screen button). Tailwind is much closer to raw CSS than Bootstrap. That's not a criticism, it's just a different value proposition.
* https://blocks.wickedtemplates.com
* https://tailwindcomponents.com/
* https://www.tailwind-kit.com/
* https://www.tailwindtoolbox.com/
Most of the sites I put together this year used an amalgamation of components from those sites for basic structure, and then just get customized to the brand and site function. I hate writing raw CSS and I would also hate writing raw Tailwind.