181–190 of 246 posts
This pretty much resolved my objections towards this approach. I think it makes a lot of sense with react.
Earlier quoted context omitted.
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, what the hell is that thing described by all those styles? versus: 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 s…
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;…
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.
Earlier quoted context omitted.
I see the downvotes already coming. Cascading is bad, it makes it hard or impossible to restructure things and move markup around. And then you have to fight specificity. An example from my work where someone put a bunch of tags under `.new-style` like `.new-style h1` and applies to every container which needs those new styles. Now if I add my component to that container, it completely breaks encapsulation because `.…
In other words, improperly used cascading is bad? (didn't downvote you FWIW)
In my experience working on a web app that sees +80k DAU, the most difficult updates to our UI are ALWAYS in the cases where somebody wasnt cogniscent of the cascade. Or was, and used it when they shouldn’t have.
IMO, theres a lot of pushback to this technique and not a lot of questions into its benefits, but plenty of questions as to why its “just like this” so “why should I use it.”
I encourage you to consider the benefits of an isolated approach to UI, or perhaps try building something with it and see how the method compares to your current approach.
Or, we can all go on assuming that Airbnb, Facebook, IG, et al, have all opted into this approach for no reason
Keep your CSS as absolutely shallow, declarative, and "noun-based" as possible. Stay away from utility classes and "adjective-based" classes. Preferably everything should be within it's own component (React/Vue/Web component/etc.).
Earlier quoted context omitted.
First line of the first example you get in "what is Tailwind": Just accept the fact your HTML contains your styling and go with: There was a time when people thought CSS could be used to style some logical HTML: So the day you want to change the color of your card-wrapper from white to green you can change a line in some CSS and not have to go around all your HTML or end with a with a green background. CSS frameworks…
> CSS frameworks feel like a "let's get all the shit CSS was meant to help remove and just put it in divs". You just made me realize this is why I always have a hard time every time I try a CSS frameworks. It always goes the same way. I'm first amaze by all what they offer, how simple and quick a great UI can be made. Then when I try to use it, there's always something wrong and I hate how it goes and I always stop a…
If it's popeprly designed functional CSS would be exaclty what it actually looks like - garbage.
Functional CSS is a terrific approach. Tailwind in particular is exemplary. Absent this approach, in web projects of nearly any size, the CSS inevitably grows and becomes increasingly difficult to maintain. It takes very very few cases of "I'll just write a bit more CSS" as the default solution to bug fixes or changing requirements, before the best-intentioned design system becomes a brittle nightmare. Whereas functi…
In web apps (as opposed to web pages), this problem is better solved by breaking up and grouping CSS with its associated components. Re-use the components, not the CSS classes.
Regarding how to keep CSS modular, just give each component a unique name and apply styles to child elements using nested selectors:
.exampleComponent .exampleItem {
border: 1px solid #aaa;
/* etc */
}
.exampleComponent {
/* put all the component's styles in here */
.exampleItem {
border: 1px solid #aaa;
}
}For web apps, I contend that modularity ought to be the goal for HTML, JS, and CSS. In the project I'm working on now, each widget/component has its HTML, JS, and CSS together in a single folder. When a widget/component is first loaded, its CSS is added to the DOM. Each component has a unique parent class name, and all its markup and styles are nested under it.
Having cross-cutting styles that are re-used throughout the app sounds decidedly un-modular. Why not re-use components/widgets instead?
Take ten minutes and learn. Here's some tips:
Attribute selector:
button[disabled]
background-color: gray
button.large, a.button.large
font-size: 2rem
profile-card > h2
font-size: 1rem
margin: 0
Semantic elements:
profile-card
display: block
profile-card.active
background-color: green
Pro-tip:tm: try learning CSS before creating or adopting a CSS "framework" to solve problems that CSS already solves.
Hope this brief rant saves a life or two. Hang in there people.