Note from 2nd March 2020

6 likes

1 repost

37 replies

1. Boris
   @nhoizey why not (honest question)?
   • 2nd March 2020, 13:09
   • Source
2. 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
   • 2nd March 2020, 13:40
   • Source
3. Nicolas Hoizey
   Indeed!
   • 2nd March 2020, 13:53
   • Source
4. Anthony Ricaud
   What’s the exact issue you’re pointing out?
   • 2nd March 2020, 13:57
   • Source
5. 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...
   • 2nd March 2020, 14:02
   • Source
6. 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.
   • 2nd March 2020, 14:05
   • Source
7. Nicolas Hoizey
   There were also some details in nicolas-hoizey.com/links/2019/06/…
   • 2nd March 2020, 14:06
   • Source
8. Nicolas Hoizey
   Exactly.
   • 2nd March 2020, 14:07
   • Source
9. Steve Workman
   Also, anchor tag with # as the href should be a button
   
   Many, many things that aren't optimal
   • 2nd March 2020, 14:08
   • Source
10. 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.
    • 2nd March 2020, 14:30
    • Source
11. 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.
    • 2nd March 2020, 14:40
    • Source
12. 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.
    • 2nd March 2020, 14:44
    • Source
13. Anthony Ricaud
    I don’t think any CSS framework ever helped writing appropriate HTML.
    • 2nd March 2020, 14:45
    • Source
14. Nicolas Hoizey
    Less CSS code, but probably more selectors to match, and more rules to combine.
    • 2nd March 2020, 14:46
    • Source
15. 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.
    • 2nd March 2020, 14:53
    • Source
16. 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.
    • 2nd March 2020, 14:54
    • Source
17. 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.
    • 2nd March 2020, 14:56
    • Source
18. 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.
    • 2nd March 2020, 14:56
    • Source
19. 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.
    • 2nd March 2020, 14:56
    • Source
20. Nicolas Hoizey
    Nice post, thanks for sharing.
    
    BTW, I don’t like `<h2 class="h1">`…
    • 2nd March 2020, 14:58
    • Source
21. 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.
    • 2nd March 2020, 14:58
    • Source
22. Nicolas Hoizey
    If I don’t find any benchmark out there, I might build one and try on my low end devices.
    • 2nd March 2020, 14:58
    • Source
23. 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 :)
    • 2nd March 2020, 15:04
    • Source
24. 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/
    • 2nd March 2020, 15:17
    • Source
25. 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
    • 2nd March 2020, 15:56
    • Source
26. 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?
    • 2nd March 2020, 16:18
    • Source
27. 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…
    • 2nd March 2020, 18:30
    • Source
28. 0gust1
    I tend to agree (but only benchmarks would say)
    
    also look at dotconferences.com/2019/12/sarah-… (around slide 46)
    • 2nd March 2020, 18:36
    • Source
29. 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
    • 2nd March 2020, 19:03
    • Source
30. 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
    • 2nd March 2020, 19:05
    • Source
31. patrick h. lauke
    but hey, each to their own...
    • 2nd March 2020, 19:05
    • Source
32. Frank Taillandier
    RTFM. You don't have to: tailwindcss.com/docs/extractin…
    • 3rd March 2020, 00:14
    • Source
33. MIR A Petit Pélican
    Oh no ! the anchors are internal navigation links, they are links <a>
    • 3rd March 2020, 00:27
    • Source
34. Nicolas Goutay
    Thanks for the pointer! Yeah I feel you, not leveraging the cascade feels _off_ somehow.
    • 24th June 2020, 10:02
    • Source
35. 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?
    • 24th June 2020, 10:51
    • Source
36. Nicolas Hoizey
    Good to know, thanks! 👍
    
    I guess that's why we often see Tailwind combined with uncss.
    • 24th June 2020, 11:01
    • Source
37. Nicolas Hoizey
    Looks like they already use PurgeCSS after all:
    tailwindcss.com/docs/controlli…
    • 24th June 2020, 11:04
    • Source

2 mentions

1. 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.
   • 2nd March 2020, 13:39
   • Source
2. 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
   • 2nd March 2020, 19:21
   • Source