These types of examples basically never match real-world experience, it is never as easy as it sounds. Are you telling me the giant text in headers and small text inside buttons and condensed text in tables and indented text in lists and plain body text all share the same margin size? What happens with text adjacent to an image that itself has a margin applied to it? Or text next to an icon (which technically may be an icon font text glyph).
>> all the CSS rules for mobile in the inline class names.
most of the time, this works great. desktop and mobile can share, for example, font family, color, weight, background color, and use different font-size and padding, to account for the smaller dimensions on mobile. As a developer, having multiple styles inline are a constant reminder to be responsive-minded before making any style changes that might look fine on a dev machine with a huge screen.
you're correct there is no perfect way and projects differ -- but Tailwind's approach is often superior to alternatives
You cannot do this in inline styles:
<div class="md-display--none xl-display--block">…</div>
It's a false premise to say this is "inline CSS". Inline styles are one subset of the entire CSS world and functional classes can hold dozens of advantadges inline CSS doesn't have.
All that said, 100% agreed with your closing sentence! :)
Yep. I like utility classes (F.K.A. OOCSS, Atomic CSS, and Functional CSS) and use them all the time. But it's one tool amongst many. It's not reason to give up small namespaced components (e.g., BEM) or using inheritance when you're doing so clearly and deliberately (Zen Garden Method).
This debate, which is something like 25 years old at this point, always seems to assume a need for absolute purity. But one of the best things about CSS is, depending on what you're trying to build, these techniques can work really well together.
Yes it is.
I personally don't like the end result, where by "separating the concerns" you end up hardcoding your style in the HTML markup. For me the utility classes are just exposing the CSS rules to the HTML markup, which I think is actually the opposite of separation of concerns because I when I think of "separate" I think the most of writing code in two different files.
> The amazing thing about this is that before you know it, you can build entirely new UI components without writing any new CSS.
So, if you want a responsive/mobile version you would have to either serve a different HTML for mobile or also have all the CSS rules for mobile in the inline class names. Before you know, you have a list of 30 cryptic CSS classes written inside the HTML markup for an element.
> How many times have you needed to style some HTML and thought, "this text needs to be a little darker," then reached for the darken() function to tweak some base $text-color?
Well, why not just use $text-color--darker? Define your swatches globally beforehand and do not allow the creation of new colors anyhwere else in the code. I guess his solution is similar, but with using another CSS class instead of a variable.
Also, what if at some point you decide to redesign your site and change the margin of all text? So you would have to replace all "mar-6" with "mar-12", but only where the margin is for text. This looks like a complex update invloving a lot of bug-prone search and replace. If it was written as ".text-margin { margin: 6px; }" then it was just a matter of changing one number and you know it would only affect the text-related margin. Sharing style across components is not always a good thing, it makes changing things much harder. I guess with this approach you should never change the initial values, as the entire design might be affected in weird ways.
I am not saying this is completely bad, I am just saying there's no perfect way of doing things and everyone and every project is different.