51–60 of 211 posts
From the examples the tailwindcss one works on android Firefox whereas the semantic one doesn't..
Earlier quoted context omitted.
No this article is flawed. It fails to recognize the fact that css and html are always coupled in one direction or another. With tailwind the css is fixed and the html is designed around it. With semantic the html is first created and then you write your css around it. The fact is that updating css in a big project and a big team is very difficult. Rules are scoped globally. It only takes a junior making a few design…
Author here. You are right: HTML and CSS are always coupled. The major difference is that Tailwind embraces tight coupling and semantic CSS embraces loose coupling. Please check the "Best practises" section: https://nuejs.org/blog/tailwind-vs-semantic-css/#best-practi...
But you don't explain why the tailwind version is tightly coupled and the semantic version is loosely coupled. And you don't do it because it is simply not the case. The coupling between html and css is not tighter or looser. It just goes in a different direction.
> The semantic version, allows you to change the design of the gallery freely. You name the component and style it externally. With Tailwind the style cannot be separated from the structure.
Same with tailwind. You update your component to update its style. With semantic you can update the css rules without touching the html, but you don't know if this css change won't break another part of your design. If you have a simple html structure like a blog with very few components, then semantic works (but so does anything really). If you have lots of components and you need to update them in order to add new features, then semantic will bring more issues.
I just moved our website from semantic to tailwind after I didn’t understand the semantic bits anymore. Main problem was: the semantic css was elegant, but understanding it again after half a year of not editing the page took super long. Tailwind is clear. The code looks uglier but I instantly know what’s going on. No hidden things. And no fear in editing a piece of html that it will break sth else. Huge upside.
Yep ! This is the huge problem with css and «meaningful» selectors, no matter how much you try to make things clear, nuances and details fades and you end up going back end forth between css code, inspector and HTML to figure out what's happening. Utility based css selectors that do one and single thing are clear and explicit, removing most (but not all) that hassle.
Earlier quoted context omitted.
Author here. You are right: HTML and CSS are always coupled. The major difference is that Tailwind embraces tight coupling and semantic CSS embraces loose coupling. Please check the "Best practises" section: https://nuejs.org/blog/tailwind-vs-semantic-css/#best-practi...
This section is what I am talking about. You compare two methods of writing components and then declare that the tailwind version is tightly coupled but the semantic version is loosely coupled. In programming lingo this means tailwind is bad and semantic is good. But you don't explain why the tailwind version is tightly coupled and the semantic version is loosely coupled. And you don't do it because it is simply not…
I don't understand why tailwind would force you to write more divs then CSS. How do selectors solve the problem of how many elements you need to use to achieve the same design?
Extra divs are wrappers that help you style the parent element to add flex layouts for example. Or why do you think the official Tailwind template has so many nested divs with utility classes?
So given the popularity of tailwind I can conclude with confidence, that semantic movement has failed. HTML does not need semantics (because every big site is absolutely filled with divs) and CSS does not need semantics either. Spending time thinking about semantics is wasting time.
Earlier quoted context omitted.
tbf the examples brought up in the blog post omitted semantic attributes such as lang and the whole dom structure (all the divs!) and the other data- attributes just to make it look even worse. OP is severely opinionated.
Sorry, which data- attributes? And what do you mean about the semantic DOM structure?
- There are useless empty elements in the tailwind example - There are so many different breakpoints, paddings and margins in the depths of the tailwind DOM, that can not be achieved with the minified semantic markup as it is simply lacking the DOM structure necessary for it. Substituting just html > body > header > nav > a with html > body > div > div> header > div > div ... just isn't a correct comparison. It's like comparing airplanes to cars. - There are data sttributes such as data-new-gr-c-s-check-loaded or data-headlessui-state. Also, totally unrelated to the semantic markup comparison.
This is just bloated asf.
Do you even know what semantic markup is? Maybe some people are just stubborn and try to find anything against tailwind because they just don't like it.
I've read the article and can't figure out if this is comparing the CSS framework Semantic UI to Tailwind?
If we're comparing CSS to a CSS framework, it seems fairly obvious to me that it's going to be bigger in size, and slower to load, and that the amount of code required to be generic (rather than totally specific) would be larger too.
In my experience, it isn't black or white. I've used tailwind along with components, e.g. .button-primary { @apply rounded-full focus:ring focus:ring-orange-500 ring-offset-4 outline-none px-6 py-3 etc... and it gives you the best of both worlds. You refactor common css code into components and still have the amazing flexibility of utility classes.
By using @apply excessively, now you have to deal with class names and the resulting messy conflicts, and yet you still can't/don't write plain CSS and harness its full power.
@apply is one of Tailwind's worst features, imo.