4 ms·

With your example lower down, what you're describing is entirely possible both with tailwind[1] (depending how you provide your config), and CSS-in-JS toolkits

With your example lower down, what you're describing is entirely possible both with tailwind[1] (depending how you provide your config), and CSS-in-JS toolkits like emotion. These are called themes and they're normally handled with writing a provider that needs to be included higher up in the chain, your CSS function then includes this parent configuration as an argument.[2][3] You can only change so much of the styling without changing markup. https://tailwindcss.com/docs/theme https://tailwindcss.com/docs/theme [1] https://material-ui.com/customization/theming https://material-ui.com/customization/theming [2] https://emotion.sh/docs/theming https://emotion.sh/docs/theming [3]

rglullis 6y ago
Yes, I understand it is possible. What I am saying though is that if we design things with separation of concerns from the start, this would never be a problem in the first place. > You can only change so much of the styling without changing markup. I take that you are not old enough to remember the CSS Zen Garden? Even with craptastic CSS2 implementations of IE7 and no browsers that could fully pass the ACID3 test, the Zen Garden showed how anything could be changed without touching markup. Don't tell me that it's harder in 2020 because it is a whole lot easier.
- r_deckard 6y ago
  I think you might be looking at tailwind the wrong way here. Tailwind does “enforce” separation of concern between styling and content, just in a different way than the separation of html and css. Consider the utility class m-1 and m-2. What they are supposed to say is that element with m-1 class and element with m-2 class should have different margin, with the m-2 element probably have a slightly bigger one, and every element that uses m-2 class should have the same margin. It doesn’t specify styling at all. The concerns of styling are completely separated into the theming system. All that the utility class define is the relation between elements. Eg. which elements should have the same margin/color/typography etc... This would also provides consistency in your designs, unlike pure css which allows you to do whatever you want without defining structure and relationships between elements. I would say tailwind forces you to separate styling concerns out of your content and into your theme. You could probably replicate css zen garden using tailwind theming system.
  - rglullis 6y ago
    If you tell me that there is a way to make all the utility classes completely private and available only for composing styles that can then be @apply'd to your CSS code, I'd not only agree with you but I would preach it as the One True Framework and Adam would be my Pope. But if you are saying that you have different "utility" classes to specify different margins, and if these classes end up in your HTML, you already have styling/presentation definitions that should never be the concern of the document writer.
    - rvense 6y ago
      I no longer think of myself as a "document writer", and there honestly would not be room in my team for someone who only wanted to touch the HTML and not the CSS or vice versa. I was there for the Zen Garden, and it was great at the time and in its context (Flash and image maps!), but now I'm using the web stack for a 3D editing application, and my last job was complex GUI for managing large number of IoT devices. The idea of separating "the content" from "the presentation" does not apply anymore. It's just not a thing. Good software engineering is super important, more-so than ever I'd say, but keeping some parts of the UI in the .css files and some of it in the .ts files does not equal adequate "separation of concerns" in my context. It's just not that simple anymore, and in fact in the previous job it was an impediment, since UI refactors became much harder because of the state of the .css files. In my new project, which was moved over from Bootstrap shortly after I started, Tailwind has made sure that many of the old problems just don't arise anymore.
      - rglullis 6y ago
        The point is not separating people, much less about separating files. It's about separating concerns to allow extensibility of one aspect of the component without having to worry about the other parts of the system. Yes, with vue it is nice to have <template>, <script> and <style> on the same file, but what if I'd like to have multiple styles? Why can't I say "This component has this structure and this behavior and it allows for style A, B, and C" and have the application bundler choose themselves what style they want to use? What if the application bundler thinks "I want to use style C, but I'd like to customize some rules"? How do you do that? > moved over from Bootstrap shortly after I started, Tailwind has made sure that many of the old problems just don't arise anymore. Yes, Tailwind is a step up compared to Bootstrap if you consider how you can define the types and remove the utility classes from your HTML. But my feeling is that people who are so fascinated by the idea of Tailwind custom types are just in the process of reinventing semantic styling, this time with a preprocessor to compensate for the verbosity and some helpful mixins to overcome inconsistencies between browser implementations. So, to repeat the question: What am missing? What do I have to gain from Tailwind if I am using already SASS as the preprocessor and a good library of "utility classes" that can be @imported/@use'd/@apply'd to the document without touching the HTML?

rglullis 6y ago

Yes, I understand it is possible. What I am saying though is that if we design things with separation of concerns from the start, this would never be a problem in the first place. > You can only change so much of the styling without changing markup. I take that you are not old enough to remember the CSS Zen Garden? Even with craptastic CSS2 implementations of IE7 and no browsers that could fully pass the ACID3 test, the Zen Garden showed how anything could be changed without touching markup. Don't tell me that it's harder in 2020 because it is a whole lot easier.

r_deckard 6y ago
I think you might be looking at tailwind the wrong way here. Tailwind does “enforce” separation of concern between styling and content, just in a different way than the separation of html and css. Consider the utility class m-1 and m-2. What they are supposed to say is that element with m-1 class and element with m-2 class should have different margin, with the m-2 element probably have a slightly bigger one, and every element that uses m-2 class should have the same margin. It doesn’t specify styling at all. The concerns of styling are completely separated into the theming system. All that the utility class define is the relation between elements. Eg. which elements should have the same margin/color/typography etc... This would also provides consistency in your designs, unlike pure css which allows you to do whatever you want without defining structure and relationships between elements. I would say tailwind forces you to separate styling concerns out of your content and into your theme. You could probably replicate css zen garden using tailwind theming system.
- rglullis 6y ago
  If you tell me that there is a way to make all the utility classes completely private and available only for composing styles that can then be @apply'd to your CSS code, I'd not only agree with you but I would preach it as the One True Framework and Adam would be my Pope. But if you are saying that you have different "utility" classes to specify different margins, and if these classes end up in your HTML, you already have styling/presentation definitions that should never be the concern of the document writer.
  - rvense 6y ago
    I no longer think of myself as a "document writer", and there honestly would not be room in my team for someone who only wanted to touch the HTML and not the CSS or vice versa. I was there for the Zen Garden, and it was great at the time and in its context (Flash and image maps!), but now I'm using the web stack for a 3D editing application, and my last job was complex GUI for managing large number of IoT devices. The idea of separating "the content" from "the presentation" does not apply anymore. It's just not a thing. Good software engineering is super important, more-so than ever I'd say, but keeping some parts of the UI in the .css files and some of it in the .ts files does not equal adequate "separation of concerns" in my context. It's just not that simple anymore, and in fact in the previous job it was an impediment, since UI refactors became much harder because of the state of the .css files. In my new project, which was moved over from Bootstrap shortly after I started, Tailwind has made sure that many of the old problems just don't arise anymore.
    - rglullis 6y ago
      The point is not separating people, much less about separating files. It's about separating concerns to allow extensibility of one aspect of the component without having to worry about the other parts of the system. Yes, with vue it is nice to have <template>, <script> and <style> on the same file, but what if I'd like to have multiple styles? Why can't I say "This component has this structure and this behavior and it allows for style A, B, and C" and have the application bundler choose themselves what style they want to use? What if the application bundler thinks "I want to use style C, but I'd like to customize some rules"? How do you do that? > moved over from Bootstrap shortly after I started, Tailwind has made sure that many of the old problems just don't arise anymore. Yes, Tailwind is a step up compared to Bootstrap if you consider how you can define the types and remove the utility classes from your HTML. But my feeling is that people who are so fascinated by the idea of Tailwind custom types are just in the process of reinventing semantic styling, this time with a preprocessor to compensate for the verbosity and some helpful mixins to overcome inconsistencies between browser implementations. So, to repeat the question: What am missing? What do I have to gain from Tailwind if I am using already SASS as the preprocessor and a good library of "utility classes" that can be @imported/@use'd/@apply'd to the document without touching the HTML?