> 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 several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group.

Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space.

Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".

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 <button class="btn btn-primary"> you write an atomic component <MyButton> 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 placed anywhere in the application without worrying about inherited styles causing problems.

edit: formatting

I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem (https://viewcomponent.org)

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.

Thanks mate! I've been considering this path and may give it a go.

Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.

I had the same concern at first. I remained skeptical during my first couple days working with Tailwind, but came around pretty soon thereafter.

I realized that all of my semantic CSS classes might as well have been inline CSS for all the good they were doing me on reusability. Utility classes are faster to work with, and, as long as you’re componentizing everything, still going to give you consistent styles across your product.

The usage of utility classes only become an issue if you have unnecessary duplication of components. Say, two buttons that should be the same but are implemented in different places.

IMO one of the interesting parts of functional CSS is that we can apply the same tactics we use for organising code to organising the styling.

Also, with separated CSS, and especially with semantic CSS, there is often a fair amount of duplication that happens in the CSS code itself, which we programmers tend to be very forgiving of. Giving Tailwind more scrutiny than we do for our CSS ends up making our code more consistent, less duplicated and better in general.

My experience with Tailwind + ViewComponent has been great as well. I've also had a lot of success with adding Sorbet typing to the view components. I often use Sorbet enums as view component options. The extra type safety in the view layer is very helpful.

I hadn’t thought about this. That’s a really good idea. Thanks for sharing!

I mentioned downthread about a project called Styletron, which has styled-components-like devexp, but compiles to atomic CSS for the bundle size benefits.

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 <Button>Click me</Button>

There definitely are interesting ways of applying atomic CSS beyond basic Tailwind usage.

Those benefits seem the same as the benefits of styled components or css modules?

Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles

I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.

Yes, @apply exists, but is generally discouraged (and the rationales are given right on that page)

> If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you

Approaching it with moderation is probably worth trying though

It's the same as any DRY or optimised code: taking time and effort to make things overly DRY or optimised up front is a waste, building stuff out and then refactoring when you realise it's going to be repeated is a better workflow. With tailwind, that's simple because you take your string of class names, slap an @apply on it, and then use the new classname instead. No, it's not significantly different from just writing CSS then, but it's the workflow that's changed that reduces the friction between prototyping and then refactoring into a reusable design that makes Tailwind nice to work with in my experience (and I'm using it for a large-scale commercial project, not a landing page or static site).

I'm pretty sure the creator's intention is that you basically don't use @apply at all, except maybe edge-cases where Tailwind simply can't be used (for example, I think before v3.0 you couldn't set print styles, i.e. @media print)

The intended method of not repeating yourself in Tailwind is using a framework, and writing the styles in the template of the component.

We recently started using a combination of tailwind and BEM instead of bootstrap.

It means that we can have our own custom "button button--sm" classes - a single place to change general styling - and on top of that get all flexibility of the tailwind utils for edge cases.

I don't think it's perfect, but it's so far much more flexible than bootstrap, and we don't need to duplicate loads of classes for each similar component.

Why would you need a button class when you can have that button in a component?

> 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.

It doesn't matter, you can have an entire newspaper and perfectly done in functional css with incredible results without having to mastermind any architecture.

http://minid.net/2019/08/12/in-defense-of-functional-css/

The trick with CSS is to write semantic HTML and avoid div, span and css classes. You can of course inline css too (used mostly for optimization to prevent layout shift, but is also fine for elements/classes that are not repeated, such as the top menu, top banner/intro and header/footer)

> The trick with CSS is to write semantic HTML and avoid div, span and css classes

This experiment has failed though. 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. No large website today works otherwise.

HTML is still semantic when it contains styling markup (in the sense that a computer can read and understand the structured data from it) so I'm unclear what benefit is being missed out on. Whether you call a class "home-cta-subheading" or "text-center" so you can apply some styles doesn't make a difference to screen readers, browsers or search crawlers either.

> 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

Totally this. We say we've come a long way from using tables for layout, but for example you still can't use Flexbox without at least some non-semantic .stuff-container and .radio-with-label junk. Decoupled HTML and CSS have failed in the real world, outside of pet projects.

I think grid is that powerful

The example on the Tailwind front page is pretty good semantic wise. Here's my version:

    <figure>
        <img src="/sarah-dayan.jpg">
        
        <blockquote>“Tailwind CSS is the only framework that I've seen scale
        on large teams. It’s easy to customize, adapts to any design,
        and the build size is tiny.”</blockquote>
        
        <figcaption><b>Sarah Dayan</b>Staff Engineer, Algolia</figcaption>
    </figure>

Now without modifying the HTML, how would I get the author's name only to appear on the right of the author image with the other text underneath? And add a line break before the company name? And make the word "tiny" use a small font?

And if you need to modify the HTML, were the extra tags added 100% only for semantic reasons and not for presentation reasons?

It's possible if you substitute "without modifying the HTML" with "without modifying the HTML for styling purposes." That's because the HTML is adversely and unnecessarily bare-bones, missing semantic markup that the CSS could hook into if needed. Specifically:

- There must be a logical reason for wanting to make the word "tiny" use a small font, so that word is missing a tag that represents that prosaic intent. I've used <small>, but depending on how you'd verbalize the word "tiny" (which is what you're representing both with making it use a smaller font and with wrapping it in a semantic tag), you might also wish to use <em> or another tag.

- Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them. This is much like trying to represent two paragraphs of prose with just a couple newlines, rather than actually wrapping each in a <p> tag. To fix this error, I've added tags as necessary to implement the semantic hCard microformat -- independently of styling.

- I've also added the recommended attributes to the image tag, because it was missing. (And for the sake of the Codepen, I replaced the image's src with a placeholder so as not to hotlink from tailwind's site.)

Given those improvements to the semantic structure of the HTML, here's how you can make the author's name appear on the right, with the quote underneath, with a line break before the company name, and "tiny" in a small font: https://codepen.io/Kerrick/pen/KKXgPYw

> There must be a logical reason for wanting to make the word "tiny" use a small font

> - Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them.

Presentation/visuals aren't always tied so closely with logic though. "To make it look nice" is a valid reason. As I said, this experiment has failed. All modern website designs use divs + classes everywhere for styling. I agree extra semantic tags would be useful but at some stage you're going to be forcing yourself to come up with semantic reasons to add a tag when there isn't one.

> I've also added the recommended attributes to the image tag, because it was missing.

Related: alt="" is best practice for when an image tag is for presentation purposes only because images don't have to be there for semantic reasons.

You don't use CSS to move stuff around. If you for example want to place paragraph-1 below paragraph-2 you simply move it in the HTML. And if you want to add a line break you add <br> in the HTML.

If you want to make a word tiny, you can use the <small> HTML element.

Here is the CSS for my example

  body {
   font-family: sans-serif;
   background: #e4e5f8
  }

  figure {
   text-align: center;
   background: #fff;
   border-radius: 1rem;
   padding: 1.5rem;
   max-width: 40rem;
  }

  figure img {
   border-radius: 50%;
   width: 7rem;
   height: 7rem;
   object-fit: cover;
  }

  figure blockquote {
   font-size: 1.125rem;
   margin: 1rem;
  }

  figure b {
   color: #0ea5e9;
   display: block;
  }

The trick is to keep things simple. Then when you have mastered the rules, you can break the rules. eg. when you can style semantic HTML however you want without adding div's and CSS classes, that's when you can start adding a little div and class here and there just to keep things even more simple.

Simple code is most of the time faster to load, and easier to maintain.

I tried it just for the lolz and without changing a single bit of HTML. It's absolutely disgusting and nobody in their right mind should do this EVER! Only tested in Chrome, it might fail in other browsers. And on mobile it will very likely break.

https://codepen.io/BlindPenguin/pen/GRMjjvq

I'm off scrubbing my hands with a wire brush and abrasive cleaner.

I often have trouble writing CSS. Here is how I approached this challenge. https://jsfiddle.net/mwabc719/

Anyone have good advice on a better way?

You modified the HTML. And... I didn't see the output described in the parent in your fiddle. ?

> without modifying the HTML

> Here is how I approached this challenge

...but you modified the HTML?

> ...but you modified the HTML?

The original challenge includes questions that apply only if the resolution involves HTML modifications, which (contrary to the earlier text viewed in isolation) indicates that such modifications are not invalid in response to the challenge.

Yah, maybe I should have been explicit, but I think my HTML change as semantically important. (My interpretation of the last line of the challenge.)

> 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 to get around CSS quirks (search for "wrapper div" for examples).

The discussion is not about the semantic expressiveness of HTML. There are certainly limitations, but these are limitations of HTML. The discussion is about whether or not "tag soup" (excessive HTML elements) is necessary for styling with modern CSS. I cannot think of an example of where it is.

> Can you replace them all with more semantic tags? If not, can you remove them and still style it the same way?

I looked at on the first four examples, but my responses are yes and yes.

Take the figure example. The first div, which groups blockquote and figcaption, is extraneous and unnecessary for the end styling result. The second div is not extraneous because it exists for a purpose. The purpose of the second div is to place emphasis on the name or make it stand out. Thus, it should be changed to em. The third div is extraneous. With the HTML in place, grid it up.

You have the container (figure) with two columns and two rows. The image sits in the first column spanning both rows. The blockquote sits in the second column on the first row. The figcaption sits in the bottom right-hand corner. Then tweak to get your img and other parts as desired (e.g., width, spacing, font-size, etc.).

> You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox) ... to get around CSS quirks (search for "wrapper div" for examples).

Sometimes flexbox is the wrong tool. Sometimes floats are better. Sometimes grid is better. If you find yourself reaching for extra HTML elements first, you should stop and re-evaluate whether your approach to achieving that layout is appropriate.

On quirks, my experience is that "quirks" are rarely actual quirks. They are usually a limited understanding of HTML and CSS.

Can you link to any complex designs you've worked on that only use semantic HTML elements and minimal divs/spans? Are you saying that any modern website that uses wrapper divs is from lack of expertise?

> Are you saying that any modern website that uses wrapper divs is from lack of expertise?

That's a loaded question. CSS frameworks (or tables, or div based designs) are also used because they save time when iterating, not because of a lack of expertise.

This is a quick and dirty example.

https://jsfiddle.net/gx4hk358/

You've never put a number of elements together in a div, and added a class and styles to that div rather than each individual element? You should try it out.

nice, now your aesthetic is coupled to your information hierarchy

style is orthogonal to semantics

I do so for semantics. I don't do it for style.

Just open up the inspector on any major website like Facebook, Twitter, Github, etc. How complex is the UI you typically work with? Once you get to a certain level of complexity, it's literally not possible to not end up with the div soup.

It's definitely possible, but it's not done.

And it's hard to take Facebook serious as an example. They're known to engage in HTML obfuscation on purpose.

https://dev.to/ganderzz/how-facebook-avoids-ad-blockers-4mdc

Not eparating concerns also fails VERY hard, but that bites you in the arse when you least expect or want it (unlike writing good CSS which takes only patience and studying).

There's a reason why inline styles and important! were to be avoided

how are they separated though? if your css rules apply based on hierarchy they are incredibly tightly coupled to your html.

separate files != separate concerns

> "CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs..."

This is untrue by any measure.

This might have been true in the days before flex or grid, but with those additions, there is no need for extraneous styling divs.

> "...and classes that are only there for styling."

That part is confusing. Classes? As in CSS classes? CSS has no other purpose than styling.

Exactly. Also you rely on the development criteria and developers switch jobs and they have different mindsets for architecture. The CSS ends with a soap of architectures and technical debt.

I believe there are accessibility problems with using divs and spans where a more semantic element would suffice.

Yes, you should always be using the elements/tags with the most semantic meaning you can. When you need to add divs, spans and classes for styling reasons though, they're going to be ignored by screen readers so there's no problem here.

Yeah, I guess my concern is that a lot of developers don’t really seem to understand the difference between semantics and style.

I agree. I think the real crux of the issue is that people find CSS hard, and are embarrassed about finding something that's "just a style sheet" hard, so they flock to more complicated alternatives.

I'm really glad I just powered through that point and let myself feel dumb.

what does semantic html has anything to do with css. Doesn't this make the look and feel of the page easily break on any change on the markup structure and content?

Also does this comment even has a point? Like if we do what you suggest then no need of tailwind?