101–110 of 185 posts
Earlier quoted context omitted.
This can easily be accomplished with SASS and a methodology like BEM. And it makes the markup a lot easier to read.
after doing a project with tailwind I have completely abandoned the idea of BEM. while it was nice having clean classes, having the styles directly in the html is way easier to reason about.
Lol here we go again. Why does this get people so riled up? I suspect people who immediately dislike this maybe are not using some type of component-based UI. CSS classes are all about code-reuse. If you have the concept of say a "button" in your UI, and you are copying your button markup every where you use that "button" then it certainly makes sense to have a class for your button markup that encapsulates the style…
Most (all?) of the classes apply exactly 1 line of CSS. I see this as an anti-pattern, because to me it looks like inline styles with extra steps. The only thing it avoids is accidental strong specificity. The reason we have CSS is that it's really easy to make HTML unreadable - after all it's essentially a 1D medium(lines of text) trying to describe a 2D space.
Also this is switching things around. Now your html depends on your css classes and not your css depending on your html. No more broken css when a dev modified the html structure and didn’t realize that one of the hundreds of lines of css now doesn’t get applied right.
It's 2018, does CSS supported by modern browsers still lack the basic building blocks of reuse? Why am I being asked to choose between class="resources" (and having to know how to center a div in that resources class) and class="t:center t:wide-margins t:light-bg" (which is basically reintroducing all the harm of style tags). Why can't I, in 2018 and with vanilla CSS, say: .resources { @include .centered @include .wi…
Of course you can say now I mixed style with HTML but if you never intend to change style separately from HTML then why introduce the mental overhead of indirection?
It's 2018, does CSS supported by modern browsers still lack the basic building blocks of reuse? Why am I being asked to choose between class="resources" (and having to know how to center a div in that resources class) and class="t:center t:wide-margins t:light-bg" (which is basically reintroducing all the harm of style tags). Why can't I, in 2018 and with vanilla CSS, say: .resources { @include .centered @include .wi…
Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster fire of styles that is objectively worse than just writing regular CSS.
But it's convenient, right? So who cares! AirBnB, Facebook, Walmart, Github, and Twitter are all probably wrong anyway.
Earlier quoted context omitted.
If you prefer that great, which is why I said that I don't think it makes a huge difference one way or another. .i-dont__find-bem--very-readable.
Sass makes it a lot nicer to write BEM notation. The long class names used to bother me too, but it is actually much nicer than not knowing where a class came from. Is `.right-button` a global button style, or unique to this component?
I treat my name spacing the way I do in most source code. All the code for a unit is in the same file or in files called out from that file.
If you’re not nesting in Sass you’re missing out on some of the better parts.
How would have React adoption looked like if it wasn't backed by a tech giant? React propounds a very controversial idea: to put HTML inside Javascript. Of course, once you get the hang of it, it all makes perfect sense: tight coupling and composability. Tailwind, along the same lines, proposes a contrarian idea and it will only make sense once you start working with it. Here's what I have seen happen frequently: As…
What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms?
Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.
Earlier quoted context omitted.
At that point, why not just write actual CSS?
Because you'll have 29 different margins, 67 different left paddings, etc all over the place. Tailwind allows you to create a consistent design system. CSS was supposed to be "write one class, use it everywhere instead of inlining". Usually it ends up with nobody reusing that class and everyone creating their on in the same codebase. There's an article I don't have a link handy, which explained how ridiculously many…
Earlier quoted context omitted.
So if you have a large number of buttons or other elements with the same class you will be repeating yourself over and over. With elements with a large number of style rules, you add a lot of very long lines to your html. This would be a nightmare to work on/maintain.
> So if you have a large number of buttons or other elements with the same class you will be repeating yourself over and over. In the HTML, sure. But so what? It gets compressed in transport so there won't be significant overhead there (similar to how remote desktop protocols that send images with compression turn out to be just as efficient as those that tried to send intelligent drawing commands), and the browser h…