5 ms·

I really don't see the benefit. Sure, you don't write "CSS", but you write a lot of classes that look like CSS. If you write class="bg-white no-underline" you c

by SunboX 8y ago

I really don't see the benefit. Sure, you don't write "CSS", but you write a lot of classes that look like CSS. If you write class="bg-white no-underline" you could easily write style="background: white; text-decoration: none;" and every frontend guy will understand it. I don't get the point.

davidwparker 8y ago
Did you read the article? There's a header titled "why is this different from inline styles?" that addresses your specific question.
mattferderer 8y ago
If this article didn't make it click for you, that's understandable. It took me a long time of hearing about this & thinking it was stupid before it made sense. When that happens to me, it's usually a sign of something good. The author of Tailwind suggested I read his best effort at explaining why this makes sense.: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... Towards the end of the article it started clicking for me.
- paulsutter 8y ago
  Easier just to quote the reason he gives: “With inline styles, there are no constraints on what values you choose... Utilities force you to choose... You can't just pick any value want; you have to choose from a curated list. Instead of 380 text colors, you end up with 10 or 12.”
  - ealhad 8y ago
    And of course, those colors are fully customizable.
  - jacamat 8y ago
    in what way is that consistent tho?
    - neurotrace 8y ago
      In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.
      - jacamat 8y ago
        But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray? these inconsistencies compound, especially across teams.
        neurotrace 8y ago
        Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.
- akvadrako 8y ago
  I admit, after the middle of that article anything would look good. It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet. However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.

by SunboX 8y ago

davidwparker 8y ago

Did you read the article? There's a header titled "why is this different from inline styles?" that addresses your specific question.

mattferderer 8y ago

If this article didn't make it click for you, that's understandable. It took me a long time of hearing about this & thinking it was stupid before it made sense. When that happens to me, it's usually a sign of something good. The author of Tailwind suggested I read his best effort at explaining why this makes sense.: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... Towards the end of the article it started clicking for me.

paulsutter 8y ago
Easier just to quote the reason he gives: “With inline styles, there are no constraints on what values you choose... Utilities force you to choose... You can't just pick any value want; you have to choose from a curated list. Instead of 380 text colors, you end up with 10 or 12.”
- ealhad 8y ago
  And of course, those colors are fully customizable.
- jacamat 8y ago
  in what way is that consistent tho?
  - neurotrace 8y ago
    In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.
    - jacamat 8y ago
      But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray? these inconsistencies compound, especially across teams.
      - neurotrace 8y ago
        Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.
akvadrako 8y ago
I admit, after the middle of that article anything would look good. It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet. However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.