5 ms·

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 t

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 mistakes and now you don't what you are going to break if you update anything. With tailwind the css is fixed and will never change. So you just change your html and you know what to check/what to test again. For any medium to large project this is a big QA & time boon. "just use code review, naming convention, xxx best practice". This argument is similar to "just don't make mistakes". Mistakes will be made. With semantic css you will suffer.

gherkinnn 3y ago
> "just don't make mistakes". Mistakes will be made. Is kinda what I said.
tipiirai 3y ago
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-practices https://nuejs.org/blog/tailwind-vs-semantic-css/#best-practi...
- sbergot 3y ago
  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 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.
  - tipiirai 3y ago
    So `<div class="gallery">` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.
    - HelloNurse 3y ago
      The coupling is in the right direction: designing possibly very advanced CSS to get a desired appearance from a given good markup, instead of compromising markup to simplify CSS.
      - sbergot 3y ago
        The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.
        HelloNurse 3y ago
        New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant to be displayed inline, in addition to large ones between paragraphs). What kind of fragile markup and problematic CSS global rules are you worrying about?
        skydhash 3y ago
        > What kind of fragile markup and problematic CSS global rules are you worrying about? I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case. As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
- deleted 3y ago
  [deleted]
pas 3y ago
> Rules are scoped globally. Isn't "CSS scoped to components" nowadays a basic feature of frameworks?
- sbergot 3y ago
  The author is advocating for rules like "body > header" in separate css files.
  - tipiirai 3y ago
    Indeed! I'm a freak using CSS as intended :)
    - kaba0 3y ago
      The problem is that CSS’s intended usage is broken, and never lived up to expectations.
      - tipiirai 3y ago
        I think CSS does a good job at separating structure from presentation. Or what do you think was the original intention? Do you think Tailwind fixed the core issue with CSS?
        kaba0 3y ago
        I really recommend you reading the blog post by tailwind’s creator himself: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... Your “semantic” CSS depends on your HTML structure. Tailwind’s HTML depends on a fixed set of CSS styles. None is any more coupled than the other, it’s just that the direction of the dependence is different. Depending on what is expected to change more, both can be a valid approach: e.g. for a blog post that only uses heading, emphasis, link, styling it from CSS alone is definitely the best choice (that’s what it was developed for). But I would argue, most real-world web applications see more HTML-changes, and thus the other direction may make more sense.

gherkinnn 3y ago

> "just don't make mistakes". Mistakes will be made. Is kinda what I said.

tipiirai 3y ago

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-practices https://nuejs.org/blog/tailwind-vs-semantic-css/#best-practi...

sbergot 3y ago
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 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.
- tipiirai 3y ago
  So `<div class="gallery">` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.
  - HelloNurse 3y ago
    The coupling is in the right direction: designing possibly very advanced CSS to get a desired appearance from a given good markup, instead of compromising markup to simplify CSS.
    - sbergot 3y ago
      The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.
      - HelloNurse 3y ago
        New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant to be displayed inline, in addition to large ones between paragraphs). What kind of fragile markup and problematic CSS global rules are you worrying about?
        skydhash 3y ago
        > What kind of fragile markup and problematic CSS global rules are you worrying about? I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case. As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
deleted 3y ago
[deleted]

pas 3y ago

> Rules are scoped globally. Isn't "CSS scoped to components" nowadays a basic feature of frameworks?

sbergot 3y ago
The author is advocating for rules like "body > header" in separate css files.
- tipiirai 3y ago
  Indeed! I'm a freak using CSS as intended :)
  - kaba0 3y ago
    The problem is that CSS’s intended usage is broken, and never lived up to expectations.
    - tipiirai 3y ago
      I think CSS does a good job at separating structure from presentation. Or what do you think was the original intention? Do you think Tailwind fixed the core issue with CSS?
      - kaba0 3y ago
        I really recommend you reading the blog post by tailwind’s creator himself: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... Your “semantic” CSS depends on your HTML structure. Tailwind’s HTML depends on a fixed set of CSS styles. None is any more coupled than the other, it’s just that the direction of the dependence is different. Depending on what is expected to change more, both can be a valid approach: e.g. for a blog post that only uses heading, emphasis, link, styling it from CSS alone is definitely the best choice (that’s what it was developed for). But I would argue, most real-world web applications see more HTML-changes, and thus the other direction may make more sense.