7 ms·

I used the JIT version recently on a new landing page with code completion for class names in my IDE and found it great. The distance between what I'm picturing

I used the JIT version recently on a new landing page with code completion for class names in my IDE and found it great. The distance between what I'm picturing in my head and what I have to type to see that on the screen felt so much shorter and less fatiguing than the standard CSS approach. With the regular way, to style something that's probably not going to appear elsewhere, I'm having to: come up with class names, annotate the HTML with them, repeat some of this annotating in a CSS file, jump back and forth between files to tweak the styles, use the web inspector to figure out which CSS class is overriding another then jump to the right CSS file to fix it etc. Tailwind classes are also faster to type and flip between when you're experimenting (e.g. editing "mt-5" to "pb-3" vs "margin-top: 4.25em" to "padding-bottom: 2.75em") and you get less distracted because it has sensible defaults and helpful guardrails (you rarely need all the possible attributes and range of parameter values CSS has available). I also rarely had the super irritating and common CSS scenario where you edit a style and it doesn't change and you have to go investigate to find out why e.g. something is overriding something, your selector is wrong, and even after all that maybe you undo the edit because it doesn't look good. Plus you no longer have the fear that tweaking a shared class to going to break some completely different page. I feel that beyond some building blocks, trying to create reusable CSS classes with cascading styles has similarities to using excessive abstraction and deep OOP class hierarchies in regular programming languages to avoid a little duplication. I also don't have a problem with styling stuff appearing in my HTML files either as long as the right HTML tags are used around the data. HTML files are already full of class annotations and divs that are only there for styling yet this doesn't cause a problem to e.g. browsers, screen readers or crawlers.

z3t4 5y ago
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)
- seanwilson 5y ago
  > 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.
  - meerita 5y ago
    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.
  - jolux 5y ago
    I believe there are accessibility problems with using divs and spans where a more semantic element would suffice.
    - seanwilson 5y ago
      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.
      - jolux 5y ago
        Yeah, I guess my concern is that a lot of developers don’t really seem to understand the difference between semantics and style.
  - z3t4 5y ago
    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>
lhorie 5y ago
> 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".
- dqv 5y ago
  Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles 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.
  - lhorie 5y ago
    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

z3t4 5y ago

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)

seanwilson 5y ago
> 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.
- meerita 5y ago
  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.
- jolux 5y ago
  I believe there are accessibility problems with using divs and spans where a more semantic element would suffice.
  - seanwilson 5y ago
    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.
    - jolux 5y ago
      Yeah, I guess my concern is that a lot of developers don’t really seem to understand the difference between semantics and style.
- z3t4 5y ago
  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>

lhorie 5y ago

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

dqv 5y ago
Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles 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.
- lhorie 5y ago
  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