5 ms·

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party lib

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

dartos 3y ago
I think there are some other benefits of tailwind. Say you have a set of css classes for different components. Then say one component on one page now needs to be styled differently. You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes. All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place. That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable
- 1shooner 3y ago
  Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives. But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence. Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
  - dartos 3y ago
    I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying. Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick. But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier. I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.
    - 1shooner 3y ago
      A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS. >Classes that appear later in a class attribute take precedence over one’s that appear earlier. This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
      - couchand 3y ago
        The Salesforce Lightning Design System makes extensive use of this technique; they call them "styling hooks". https://www.lightningdesignsystem.com/platforms/lightning/styling-hooks/ https://www.lightningdesignsystem.com/platforms/lightning/st...
        1shooner 3y ago
        Is Lightning primarily web components? That would make sense, since css vars penetrate the shadow dom, so with this approach there's no need to mess with loading your css into the component's shadow dom.
mattlondon 3y ago
Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO. There is no harm in a plain CSS file, and applying classes at the element level in the HTML. If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.
- threatofrain 3y ago
  > Just use a single CSS file with sensibly named classes IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.
  - mattlondon 3y ago
    Well the point I was trying to make was to not do what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about the semantic nature of the style, rather than what the style actually is. The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)
    - iudqnolq 3y ago
      The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..." Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css. Without components tailwind is probably a bad choice.
mock-possum 3y ago
It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.
- aniforprez 3y ago
  Only people who haven't used tailwind say this. A lot of tailwind classes aren't singular styles but a composite of style attributes and mostly define behaviours rather than just expose a single CSS attribute. And a lot of that behaviour is applying styles on hover, on media queries, on grouped elements and other extremely common user actions, none of which are possible with inline styles
- wildrhythms 3y ago
  The styles are already coupled to the component anyway, so what's your problem with putting them in the markup? The alternative is making up arbitrary class names and putting the styles in a separate file: now you've added an extra layer of mapping that the developer after you has to grok.
  - ricardobeat 3y ago
    People don’t seem to mind the 7 layers of mapping between their markup and HTML, why are styles different? I find that much more of a problem when it comes to understanding what’s happening for the average dev.

dartos 3y ago

I think there are some other benefits of tailwind. Say you have a set of css classes for different components. Then say one component on one page now needs to be styled differently. You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes. All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place. That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable

1shooner 3y ago
Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives. But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence. Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
- dartos 3y ago
  I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying. Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick. But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier. I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.
  - 1shooner 3y ago
    A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS. >Classes that appear later in a class attribute take precedence over one’s that appear earlier. This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
    - couchand 3y ago
      The Salesforce Lightning Design System makes extensive use of this technique; they call them "styling hooks". https://www.lightningdesignsystem.com/platforms/lightning/styling-hooks/ https://www.lightningdesignsystem.com/platforms/lightning/st...
      - 1shooner 3y ago
        Is Lightning primarily web components? That would make sense, since css vars penetrate the shadow dom, so with this approach there's no need to mess with loading your css into the component's shadow dom.

mattlondon 3y ago

Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO. There is no harm in a plain CSS file, and applying classes at the element level in the HTML. If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.

threatofrain 3y ago
> Just use a single CSS file with sensibly named classes IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.
- mattlondon 3y ago
  Well the point I was trying to make was to not do what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about the semantic nature of the style, rather than what the style actually is. The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)
  - iudqnolq 3y ago
    The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..." Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css. Without components tailwind is probably a bad choice.

mock-possum 3y ago

It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.

aniforprez 3y ago
Only people who haven't used tailwind say this. A lot of tailwind classes aren't singular styles but a composite of style attributes and mostly define behaviours rather than just expose a single CSS attribute. And a lot of that behaviour is applying styles on hover, on media queries, on grouped elements and other extremely common user actions, none of which are possible with inline styles
wildrhythms 3y ago
The styles are already coupled to the component anyway, so what's your problem with putting them in the markup? The alternative is making up arbitrary class names and putting the styles in a separate file: now you've added an extra layer of mapping that the developer after you has to grok.
- ricardobeat 3y ago
  People don’t seem to mind the 7 layers of mapping between their markup and HTML, why are styles different? I find that much more of a problem when it comes to understanding what’s happening for the average dev.