3 ms·

“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a dist

“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.

Retric 3y ago
The primary stated goal is “substantially widen the pool of people who can work on web software codebases.” That’s very different from typical advice for programmers. Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.
1shooner 3y ago
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.
jbverschoor 3y ago
Problems are multidimensional. If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation. In any case, CSS can be seen as aspect oriented programming. The real problem described here is the lack of great tooling across languages / frameworks.
NortySpock 3y ago
(coming from a C# shop with too many interfaces) I think it's a natural counter-reaction to overly abstracted systems. If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer. Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component. https://htmx.org/essays/locality-of-behaviour/#conflict-with-other-development-principles https://htmx.org/essays/locality-of-behaviour/#conflict-with...
usrbinbash 3y ago
> “Locality of behaviour” is such a poorly defined rule. And "separation of concerns" isn't? What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together? The answer is: "It depends". Not separating anything leads to spaghetti. Separating as much as possible, all the time, everywhere, leads to overly abstracted code that is easily as hard to maintain as spaghetti.
- sodapopcan 3y ago
  Yep. I've said this often but whatever: JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.

Retric 3y ago

The primary stated goal is “substantially widen the pool of people who can work on web software codebases.” That’s very different from typical advice for programmers. Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.

1shooner 3y ago

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.

jbverschoor 3y ago

Problems are multidimensional. If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation. In any case, CSS can be seen as aspect oriented programming. The real problem described here is the lack of great tooling across languages / frameworks.

NortySpock 3y ago

(coming from a C# shop with too many interfaces) I think it's a natural counter-reaction to overly abstracted systems. If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer. Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component. https://htmx.org/essays/locality-of-behaviour/#conflict-with-other-development-principles https://htmx.org/essays/locality-of-behaviour/#conflict-with...

usrbinbash 3y ago

> “Locality of behaviour” is such a poorly defined rule. And "separation of concerns" isn't? What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together? The answer is: "It depends". Not separating anything leads to spaghetti. Separating as much as possible, all the time, everywhere, leads to overly abstracted code that is easily as hard to maintain as spaghetti.

sodapopcan 3y ago
Yep. I've said this often but whatever: JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.