Note from 2nd March 2020

I know some utility classes can be useful, and #Tailwind helps some devs create pages without (really) knowing #CSS, but is it enough to justify this logorrhea in our HTML?

Tailwind UI utility classes overdose

46 Webmentions

6 likes

1 repost

  1. Rainer Müller avatar

37 replies

  1. Boris avatar Boris
    @nhoizey why not (honest question)?
  2. MIR A Petit Pélican avatar MIR A Petit Pélican
    even more embarrassed that there is no list item (<ul> <li>) and therefore a little bit of ux for assistive technology users. #a11y
  3. Nicolas Hoizey avatar Nicolas Hoizey
    Indeed!
  4. Anthony Ricaud avatar Anthony Ricaud
    What’s the exact issue you’re pointing out?
  5. patrick h. lauke avatar patrick h. lauke
    same as with bootstrap, i strongly suspect it's down to devs demanding a bloody CSS utility class for every single little CSS property. without fail, as soon as you add one, they bleat "why can't we have one for pointer-events:none" or some shit like that...
  6. Nicolas Hoizey avatar Nicolas Hoizey
    Sorry, I though "logorrhea" was strong enough. 😅

    I know repetition is not a real problem with compression, but I guess parsing the uncompressed result is not so nice for low power devices.

    I really fear this is mostly meant for DX and will lead to issues in the future.
  7. Nicolas Hoizey avatar Nicolas Hoizey
    There were also some details in nicolas-hoizey.com/links/2019/06/…
  8. Nicolas Hoizey avatar Nicolas Hoizey
    Exactly.
  9. Steve Workman avatar Steve Workman
    Also, anchor tag with # as the href should be a button

    Many, many things that aren't optimal
  10. Anthony Ricaud avatar Anthony Ricaud
    I’ve never seen that argument anywhere. Honestly, I’ve enjoyed working with TailwindCSS and found it good for performance and UI consistency.
  11. Nicolas Hoizey avatar Nicolas Hoizey
    I agree it helps a lot for consistency, like Bootstrap and other frameworks.

    But if leads to bad code (see https://t.co/qiXqK2xNFE for example), it’s a shame.

    I know you know HTML/CSS enough to not fall in this trap, but I guess many Tailwind users unfortunately don’t.
  12. Anthony Ricaud avatar Anthony Ricaud
    Thinking about this some more, as far as I know, browsers have to parse CSS on every page so the utility approach should be less to parse.
  13. Anthony Ricaud avatar Anthony Ricaud
    I don’t think any CSS framework ever helped writing appropriate HTML.
  14. Nicolas Hoizey avatar Nicolas Hoizey
    Less CSS code, but probably more selectors to match, and more rules to combine.
  15. Anthony Ricaud avatar Anthony Ricaud
    I also had a knee-jerk reaction the first time I saw Tailwind but I’d say give it 5 minutes (signalvnoise.com/posts/3124-giv…).

    Think about the first time you saw something like `<h2 class=“h1”>`. That felt wrong but I think it’s recognised as a good idea nowadays.
  16. Boris avatar Boris
    I look forward to seeing the proof of this statement and the measurement of the impact on performance. From experience, I would say: close to zero.
  17. Nicolas Hoizey avatar Nicolas Hoizey
    Probably close to zero indeed, closeness depending on device type.

    I guess people already made some benchmark, I’ll try to find some.
  18. Boris avatar Boris
    And even if this were the case, there is no indication that fully custom CSS contain less useless code. Still from experience: there are a lot of useless CSS statements everywhere, and it has almost no impact on performance.
  19. Anthony Ricaud avatar Anthony Ricaud
    In my experience, unless you have an outrageously big HTML or CSS file (as in several MB), you can avoid thinking about the performance aspect of the parsing/matching.
  20. Nicolas Hoizey avatar Nicolas Hoizey
    Nice post, thanks for sharing.

    BTW, I don’t like `<h2 class="h1">`…
  21. Boris avatar Boris
    There are edge cases where this is relevant, but in most of the web we know of, the cost of HTML and CSS parsing is far outweighed by the cost of blocking JavaScript.
  22. Nicolas Hoizey avatar Nicolas Hoizey
    If I don’t find any benchmark out there, I might build one and try on my low end devices.
  23. Anthony Ricaud avatar Anthony Ricaud
    There is a very subjective aesthetic aspect to h1.h2 and Tailwind. And it’s OK to not like them based on your tastes. But I’d be careful when arguing that something is bad when you just don’t like it. You know, like tasting food :)
  24. Nicolas Hoizey avatar Nicolas Hoizey
    I agree.

    I don’t (currently) like Tailwind, and maybe more how some use it, but I know it helps some others, as I mention in my first note:
    nho.io/n/2020/03/02/2/
  25. Tim Carry avatar Tim Carry
    While the "previous" way of writing HTML markup first and then applying styling in CSS forced us to think about what the various elements were, and not only how they looked
  26. Anthony Ricaud avatar Anthony Ricaud
    Yes, that's exactly what Tailwind is about. How is that bad?

    Have you read tailwindcss.com/docs/utility-f… and tailwindcss.com/docs/extractin… understand the philosophy?
  27. 0gust1 avatar 0gust1
    Yes, it shocked me at first (note that the average bootstrap site , after 1-2 year is not better).

    Factorizing is possible :
    * leveraging the component level (vue, react etc.)
    * and/or using the theme() function or the "apply" directive

    tailwindcss.com/docs/extractin…
  28. 0gust1 avatar 0gust1
    I tend to agree (but only benchmarks would say)

    also look at dotconferences.com/2019/12/sarah-… (around slide 46)
  29. patrick h. lauke avatar patrick h. lauke
    having a class for every possible CSS prop is only one step above just putting inline style="..." attributes in your markup.

    anyway, purely from my BS experience, i'd rather provide some high level utilities, but then allow authors to define their own separate styles if needed
  30. patrick h. lauke avatar patrick h. lauke
    but i guess it's a matter of taste. "your CSS won't grow" but yes your HTML will. and then devs can still completely mess things up to be completely quirky and non-standard by just littering classes where they shouldn't, losing the power of more high-level classes/components
  31. patrick h. lauke avatar patrick h. lauke
    but hey, each to their own...
  32. Frank Taillandier avatar Frank Taillandier
    RTFM. You don't have to: tailwindcss.com/docs/extractin…
  33. MIR A Petit Pélican avatar MIR A Petit Pélican
    Oh no ! the anchors are internal navigation links, they are links <a>
  34. Nicolas Goutay avatar Nicolas Goutay
    Thanks for the pointer! Yeah I feel you, not leveraging the cascade feels _off_ somehow.
  35. Pierre Burel avatar Pierre Burel
    The problem with the @​apply rule provided by Tailwind is that compiled CSS code is duplicated (last time I checked tho). That’s why they recommend using templates first in their doc. That will output “not-DRY” HTML, but I guess it’s better for performance?
  36. Nicolas Hoizey avatar Nicolas Hoizey
    Good to know, thanks! 👍

    I guess that's why we often see Tailwind combined with uncss.
  37. Nicolas Hoizey avatar Nicolas Hoizey
    Looks like they already use PurgeCSS after all:
    tailwindcss.com/docs/controlli…

2 mentions

  1. Thomas T. avatar Thomas T.
    Agreed.
    Even though I really like Tailwind CSS, I find it absolutely counter-productive to have such an unreadable code. HTML can already be hard to read if it is not your code: no need to make it more complicated.
  2. L'🌒iseau2nuit avatar L'🌒iseau2nuit
    Oooookaaaay ! Ben c'est mort ! J'étais prêt à lui donner une 'tite chance mais là c'est même pas la peine !!! 😱 #Tailwind #CSS