I find it funny whenever Tailwind people tout that you "don't have to name things." You still have to name your JS-framework-of-choice components, and you still have names for each of the parts of a single component that get smattered with class names; it's just that the name is implicit in your head now instead of explicit in the CSS
Tailwind CSS v3.0
401–410 of 448 posts
Re: Tailwind CSS v3.0
#402Earlier quoted context omitted.
As an example, I'd say this isn't semantic HTML: heading bob is a person This is better: heading bob is a person This is less clean but has the same level of semantic detail in the HTML: heading bob is a person Am I missing something? I think people conflate semantic class names (read by programmers and maybe ad-hoc web scrapers) with semantic HTML (read by screen readers, SEO bots). Semantic HTML is HTML that uses t…
> This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML. Which I also think is weird, because the hierarchy of HTML is inherently styling/presentation. If HTML was truly decoupled from styling, you'd just throw all the tags that you want into an HTML file and then arrange them around with CSS. That's why w…
> That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor.
Yep, trying to keep data and presentation separated like this comes with a lot of pain. Why bother? I don't see the practical benefits in real-life projects as long as you're still using semantic HTML tags.
There's this other pipedream that the HTML is generated/written by people that aren't concerned with the presentation and then the CSS can be swapped in to style it however you want. You can and should do this in a sense that you keep your data/articles/posts in Markdown, SQL databases, behind APIs etc. - I think trying to split this further at the HTML/CSS level isn't gaining anything.
Re: Tailwind CSS v3.0
#403Earlier quoted context omitted.
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 + Vi…
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!
Re: Tailwind CSS v3.0
#404I tried Tailwind (and a similar project Windi) on a few projects now and have some findings. Tailwind aggressively speeds up development time of components by allowing me to stay in the same cobtext when styling things. The brevity of class names also dramatically shortens the time spent writing styles. While working on the projects I'd setup with Tailwind, I felt far more productive. However, those were new projects…
I'm very surprised that people actually like tailwinds.
I wrote HTML in a time when you used inline HTML attributes for styling. Changing one bit of the style meant visiting every single page to update everything (then making sure to test because you definitely forgot at least one place).
CSS was an amazing idea for making just one place to put all your styling. You could now change one style and everything else would automatically update.
Tailwinds feels like it's just a trip right back to the old inline styling right down to searching bunches of pages if you're making a styling update.
Re: Tailwind CSS v3.0
#405Earlier quoted context omitted.
One underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.
I think you're discounting the value of naming though. You don't refer to bananas as "the curved sweet yellow food that grows on trees", you simply refer to a banana as a banana. Sure, for one off items it might not make sense to name it but when you create design patterns then it's incredibly useful to be able to name things. Yes it may be hard and require you to think, but just because that is so does not make it b…
> "the curved sweet yellow food that grows on trees"
You have (some variety of) cavendish bananas in mind. There are red, pink and blue bananas. They're not all sweet. The plants they grow in are not always "trees" but rather large fern like plants.
And then that day arrives when you are required to style some variant of 'banana' you are forced to decide: do I break the world by messing with banana or do I make new-banana?
Re: Tailwind CSS v3.0
#406I tried Tailwind (and a similar project Windi) on a few projects now and have some findings. Tailwind aggressively speeds up development time of components by allowing me to stay in the same cobtext when styling things. The brevity of class names also dramatically shortens the time spent writing styles. While working on the projects I'd setup with Tailwind, I felt far more productive. However, those were new projects…
I'm very surprised that people actually like tailwinds. I wrote HTML in a time when you used inline HTML attributes for styling. Changing one bit of the style meant visiting every single page to update everything (then making sure to test because you definitely forgot at least one place). CSS was an amazing idea for making just one place to put all your styling. You could now change one style and everything else woul…
Tailwind is best used with components. If you're repeating yourself, it should probably be a component.
Re: Tailwind CSS v3.0
#407I’ve never understood CSS frameworks. CSS is the most lightweight thing I touch in the front end. It’s predictable, there are a billion ways to accomplish things, and it’s super easy to namespace yourself to safety. SASS I understand. It makes writing CSS faster. Tailwind feels like you have to learn CSS, but you’ll never have to actually write CSS. Reminds me of CoffeeScript in that way. You always had to understand…
For Tailwind in particular, it’s easier to understand the benefit if you consider the three main problems it solves:
1. Naming things “semantically” is a giant pain. Sure “user-card” is easy enough, but when you have to start giving names to all the little bits of the user card it quickly becomes absurd. Yeah you can use child selectors and stuff to ease that a little but then you’re basically re-writing your HTML in CSS. Tailwind’s approach is to say “have a UserCard.{html,vue,js} component and move on”.
2. Most codebases have multiple people working on them, and those people are often not CSS experts. It is very common to end up with giant stylesheets that only grow with time, because people are too scared to ever remove or change things in case it breaks something seemingly unrelated. Utility frameworks (and other modern approaches like styled components) keep the styles directly attached to the HTML being styled. You can make any change you like, safe in the knowledge that you are only affecting the thing in front of you.
3. It pushes you into a design system. Sure this is achievable through Sass/CSS variables, but for Tailwind it’s right there with a sensible default out of the box, and easily configured if you need something different.
I think the important thing is, Tailwind doesn’t enable you to do anything you can’t do by writing well structured CSS, because ultimately it is just CSS. However, people aren’t perfect, and I believe that Tailwind does a genuinely good job of helping people avoid common footguns.
If your team is largely composed of CSS wizards who are fine to carry on as normal, that’s great, you probably won’t get much out of Tailwind. But for a lot of us, the price of remembering some (very consistent, to be fair) shorthand class names is well worth not wasting hours battling the cascade and suchlike.
Re: Tailwind CSS v3.0
#408just got parachuted into a tailwind project. have to say I don't fully get it. the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. For example, say I want to do something basic like "display:flex; justify-content: start". In tailwind you would type "flex justify-start" instead. Which doesn't really follow any rules as far as how to get from A to B, so it'…
You have to learn the more verbose CSS properties in the first place, and the vast majority of tailwind's class names include the unique keywords of those anyway.
Re: Tailwind CSS v3.0
#409Earlier quoted context omitted.
> 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.)
Re: Tailwind CSS v3.0
#410Earlier quoted context omitted.
Alright. Now add a media query to change the button size based on the device size. Or maybe use a different color on hover. You can’t do that with inline styles.
You shouldn't need to do any of this in the first place if you followed the original recommendations for the WWW.
Use cases and expectations have changed somewhat in the last few decades.