Going back to your article, I stopped using the dot syntax and use the classic declaration div class="…" instead of relying on slim's magic here.
Does this help with the issue you're addressing or am I missing something?
"No" I'm not missing anything, or "No" it doesn't help? 😀
Regarding the key point, nothing is lost that is not worth losing to me. On the contrary, I feel like I regained some lost flexibility.
I still save on all the closing markups + noisy <%=> erb syntax, which is the bulk of the heaviness.
I get to copy/paste classes between projects regardless of whether they use slim or not. Otherwise, you have to turn spaces into dots (and vice-versa).
When you use dom_id(object), it makes more sense to me to have it at the beginning of the line with div id=dom_id(object) class="…" data-… than after a long list of classes and hidden in the middle of other attributes declarations
It makes things a bit more clear and consistent (sometimes you still need a div without any class, or to declare classes with spaces because they are declared in a content_tag or text_field - back to the copy/paste issue).
Slim added support for TailwindCSS oddities in version 4.1
That’s true. Note that I‘ve used tailwind as a stand-in for any similarly structured CSS framework though.
I did!
Going back to your article, I stopped using the dot syntax and use the classic declaration
div class="…"instead of relying on slim's magic here.Does this help with the issue you're addressing or am I missing something?
No, just then a key point on why to use slim at all is lost 😉
"No" I'm not missing anything, or "No" it doesn't help? 😀
Regarding the key point, nothing is lost that is not worth losing to me. On the contrary, I feel like I regained some lost flexibility.
div id=dom_id(object) class="…" data-…than after a long list of classes and hidden in the middle of other attributes declarationsUsing the extractor from tailwindcss.com/docs/controlling-f... did the trick for me.