6 ms·

The answer to your question is the actual confusion regarding "separation of concerns" in HTML and CSS. You can do what you've described with Tailwind: check ou

The answer to your question is the actual confusion regarding "separation of concerns" in HTML and CSS. You can do what you've described with Tailwind: check out @apply. But now you still have the issue of coming up with CSS class names. Because CSS on its own doesn't do anything. There is a high dependency between HTML and CSS and it'a up to you to choose the dependency direction. HTML and CSS are not concerns, they're technologies. Components are a better way for separating concerns. That's why CSS-in-JS is so popular and why we're combining pseudo-HTML and JavaScript in React.

rglullis 6y ago
> But now you still have the issue of coming up with CSS class names. Not entirely true. I'd be totally fine with class names that identify what type of widget it is. <div class="card">, <div class="modal"> <button class="secondary-action">, or <span class="clipboard-copy"> are "made up CSS class names" that identify a type of widget and used without making no assumption about presentation concern. <button class="btn btn-small"> and <div class="w-12 rounded-small"> are not. And yes, I understand that tailwind allows you to create types and @apply them. What I am saying is that (1) I'd like to see this separation to be enforced and not just possible and (2) plain SASS also lets you do that already. so I don't understand what I would gain from adding tailwind. > Components are a better way for separating concerns Except when they aren't. Downthread I gave the example of a library project that I want to define the functionality/behavior but leave the looks/styling to the consumer. Desktop GUIs have theme engines for ages, yet frontend web developers want to get excited about frameworks that allow for "night mode"? "Night mode" is just a way to say "you can separate presentation and content however you want, as long you only present in two different styles".
- antris 6y ago
  >Except when they aren't. Downthread I gave the example of a library project that I want to define the functionality/behavior but leave the looks/styling to the consumer. Sounds a lot like an edge case. Most consumer applications do not need theming.
  - rglullis 6y ago
    Most desktop applications also don't need them, or just use the standard style defined by the OS toolkit. My larger point is that when you are developing a web app, it would be much easier if the framework was designed in a way that separated the concerns of presentation and behavior of the components. Just to use Vue as it is what I am using now and had to get a bit more familiar: you have libraries like Vue Bootstrap and Vuetify (for Material Design) which have a lot of duplicate functionality yet are not compatible with one another. If the concerns were separated, you could have components that have a common behavior and only differ in the visuals. Less work for everyone involved, easier for developers to get started, less unnecessary fragmentation and the possibility of positive feedback cycle between different design systems.
- thepratt 6y ago
  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.
- arsey 6y ago
  i think what you're missing is how good removing a layer of abstraction /feels/ when putting things together. it didn't quite click for me until i built something with it. it ends up being a question of "where the work is done" i think, and the work being done within a string in your component just melts away layers of friction
- ivanhoe 6y ago
  > And yes, I understand that tailwind allows you to create types and @apply them. After (a short) twitter discussion with Adam Wathan about this, my impression is that his idea is to basically never use @apply, and instead create micro-components to encapsulate your basic styles. So instead of <div class="modal"> you create a component modal, and then you can put all the utility classes in its html, and still be able to quickly change it if needed.
  - rglullis 6y ago
    That is interesting. But what do you/does him mean by "create a mini-component"? Are we talking about a React component, a Vue one, none of that?
    - roryokane 6y ago
      They mean a normal component in React, Vue, Angular, or whatever other front-end technology you are already working with. I think they’re calling it a “micro-component” just to emphasize that there is no logic in the component beyond the templating.
      - rglullis 6y ago
        Ok. So it is basically that going full-on "CSS dictates HTML" approach, which only makes (some) sense if you have full-control of every aspect of the stack and you just want to have a single repository for your design system. Honestly, the only possible place where this may make sense to me is if you have tooling that can keep a two-say sync between designer tools and programmers tools. I think AirBnB was doing something like that with Sketch? Aside from that, honestly I am still failing to see any benefit. If you are tying yourself to a JS codebase, you can still do that whole "utility classes at the component level" with plain SASS and global variables and mixins and you still don't need to put class definitions in your HTML. Let me see if I can draft a quick Vue example: <template> <button><slot></slot></button> </template> <script> export default { name: "my-button" } </script> <style lang="scss"> @use "my/sass/variables" @use "my/sass/mixins/buttons" button { @include buttons.rounded($variables.radius-button-small) @include buttons.colors($active: $variables.primary, $background: $variables.primary-accent, $disabled: $variables.disabled) } </style> No Tailwind required. Easy to customize. One central place to organize your style and - most importantly to me - no css classes shoved in the HTML! Now, someone might ask for "a large button inside the hero section from the home page." Let's go about that... <template> <div class="hero"> <p>Welcome to the beautiful site</p> <MyButton>Sign up now!</MyButton> </div> </template> <script> import MyButton from './my-button.js' export default { name: "hero", components: {MyButton} } </script> <style scoped lang="scss"> @use "my/sass/variables" div.hero { button { width: $variables.size-button-large-width; height: $variables.size-button-large-height; } } </style> Really, I am yet to understand what I am missing by taking this approach. The example above is contrived, but I don't see why more complex widgets and even whole pages couldn't be done this way. The mixins are the place where you can have all of the abstraction you want, you can even add some logic depending on the values from the variables. So, let's take a look at the benefits: - If next week the frontend team decides to switch from Vue to anything else, the SASS code does not need to be touched at all. - If next week the design team brings a whole new "Design Language", the JS code does not need to be touched at all (unless of course the design system also brings new functionality) - The styling could even be verified on a series of static HTML pages. If the designer does not do any code, they can verify if the implementation matches the designs by opening a reference template, no need to run a whole JS app. Downsides: - If you want the code to be truly portable, your SASS need to follow a standard convention of @mixin names/parameters as well as variables. Honestly though this IS what I would expect from a "CSS framework", so I am not even sure it's a bad thing. - You don't get to put any hip CSS-in-JS framework on your resume.
trevyn 6y ago
>HTML and CSS are not concerns, they're technologies. Components are a better way for separating concerns. This is the clearest concise explanation of this I've seen, thank you. That you frequently have to add <div>s in your HTML in order to get CSS to lay stuff out correctly is enough evidence for me. :)
- rglullis 6y ago
  I gather you haven't used much of display:grid? I'm trying not to make this too much of a dogmatic discussion, but is the cultural norm among developers going to be to just throw their hands in the air and say "styling is hard, let's go shopping for divs"? On the one hand, I get that most people nowadays see HTML and CSS as object code, and is not that important to be abstraction that people think in. However, current web application frameworks can not solve problems that desktop GUIs frameworks have already solved in the 90s and no one is asking themselves "is this really the way to go forward?"
  - seanwilson 6y ago
    > I'm trying not to make this too much of a dogmatic discussion, but is the cultural norm among developers going to be to just throw their hands in the air and say "styling is hard, let's go shopping for divs"? The experiment failed though, we've been trying for over a decade. You can't let one group write the HTML and one group write the CSS (with the pipedream being the designers writing the CSS). The only way to make complex designs is to modify both as you develop. They're too intertwined and CSS alone isn't powerful enough to do everything you want. Keep your actual data like blog post content, blog post meta data, images etc. separated but it's 1) not practically possible and 2) there's no significant benefits to keeping your CSS and HTML separate besides sticking to dogmatism "best practices" that haven't panned out.
    - rglullis 6y ago
      Honestly, I don't buy it. It might be the case if you are trying to target IE9, but "we've been trying it over a decade" is no longer an excuse in 2020 when there are only 2-3 relevant browser engines and all of them are reasonably up to spec. Also, it's not a matter of strictly separating the groups of people doing one task or another. It's a matter of being able to extend in one dimension while keeping the other untouched. > They're too intertwined and CSS alone isn't powerful enough to do everything you want. I'd argue that is precisely backwards. The reason that we don't see any more different designs and more bold experiments is because we are not defining the interaction points between different layers in the development stack. If most developers keep this mentality that all they need to do is to get a system that solves their immediate problems and solves their own unique solution, then all they are going to do is this mushing together of their structure and their presentation layers, and all we are going to get is a pile architectures are going to converge to different local maxima. If instead we don't take the easy way out and make things with flexibility and extensibility in mind, then the likelihood of it becoming the basis of something ground-breaking grows enormously.

rglullis 6y ago

> But now you still have the issue of coming up with CSS class names. Not entirely true. I'd be totally fine with class names that identify what type of widget it is. <div class="card">, <div class="modal"> <button class="secondary-action">, or <span class="clipboard-copy"> are "made up CSS class names" that identify a type of widget and used without making no assumption about presentation concern. <button class="btn btn-small"> and <div class="w-12 rounded-small"> are not. And yes, I understand that tailwind allows you to create types and @apply them. What I am saying is that (1) I'd like to see this separation to be enforced and not just possible and (2) plain SASS also lets you do that already. so I don't understand what I would gain from adding tailwind. > Components are a better way for separating concerns Except when they aren't. Downthread I gave the example of a library project that I want to define the functionality/behavior but leave the looks/styling to the consumer. Desktop GUIs have theme engines for ages, yet frontend web developers want to get excited about frameworks that allow for "night mode"? "Night mode" is just a way to say "you can separate presentation and content however you want, as long you only present in two different styles".

antris 6y ago
>Except when they aren't. Downthread I gave the example of a library project that I want to define the functionality/behavior but leave the looks/styling to the consumer. Sounds a lot like an edge case. Most consumer applications do not need theming.
- rglullis 6y ago
  Most desktop applications also don't need them, or just use the standard style defined by the OS toolkit. My larger point is that when you are developing a web app, it would be much easier if the framework was designed in a way that separated the concerns of presentation and behavior of the components. Just to use Vue as it is what I am using now and had to get a bit more familiar: you have libraries like Vue Bootstrap and Vuetify (for Material Design) which have a lot of duplicate functionality yet are not compatible with one another. If the concerns were separated, you could have components that have a common behavior and only differ in the visuals. Less work for everyone involved, easier for developers to get started, less unnecessary fragmentation and the possibility of positive feedback cycle between different design systems.
thepratt 6y ago
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.
arsey 6y ago
i think what you're missing is how good removing a layer of abstraction /feels/ when putting things together. it didn't quite click for me until i built something with it. it ends up being a question of "where the work is done" i think, and the work being done within a string in your component just melts away layers of friction
ivanhoe 6y ago
> And yes, I understand that tailwind allows you to create types and @apply them. After (a short) twitter discussion with Adam Wathan about this, my impression is that his idea is to basically never use @apply, and instead create micro-components to encapsulate your basic styles. So instead of <div class="modal"> you create a component modal, and then you can put all the utility classes in its html, and still be able to quickly change it if needed.
- rglullis 6y ago
  That is interesting. But what do you/does him mean by "create a mini-component"? Are we talking about a React component, a Vue one, none of that?
  - roryokane 6y ago
    They mean a normal component in React, Vue, Angular, or whatever other front-end technology you are already working with. I think they’re calling it a “micro-component” just to emphasize that there is no logic in the component beyond the templating.
    - rglullis 6y ago
      Ok. So it is basically that going full-on "CSS dictates HTML" approach, which only makes (some) sense if you have full-control of every aspect of the stack and you just want to have a single repository for your design system. Honestly, the only possible place where this may make sense to me is if you have tooling that can keep a two-say sync between designer tools and programmers tools. I think AirBnB was doing something like that with Sketch? Aside from that, honestly I am still failing to see any benefit. If you are tying yourself to a JS codebase, you can still do that whole "utility classes at the component level" with plain SASS and global variables and mixins and you still don't need to put class definitions in your HTML. Let me see if I can draft a quick Vue example: <template> <button><slot></slot></button> </template> <script> export default { name: "my-button" } </script> <style lang="scss"> @use "my/sass/variables" @use "my/sass/mixins/buttons" button { @include buttons.rounded($variables.radius-button-small) @include buttons.colors($active: $variables.primary, $background: $variables.primary-accent, $disabled: $variables.disabled) } </style> No Tailwind required. Easy to customize. One central place to organize your style and - most importantly to me - no css classes shoved in the HTML! Now, someone might ask for "a large button inside the hero section from the home page." Let's go about that... <template> <div class="hero"> <p>Welcome to the beautiful site</p> <MyButton>Sign up now!</MyButton> </div> </template> <script> import MyButton from './my-button.js' export default { name: "hero", components: {MyButton} } </script> <style scoped lang="scss"> @use "my/sass/variables" div.hero { button { width: $variables.size-button-large-width; height: $variables.size-button-large-height; } } </style> Really, I am yet to understand what I am missing by taking this approach. The example above is contrived, but I don't see why more complex widgets and even whole pages couldn't be done this way. The mixins are the place where you can have all of the abstraction you want, you can even add some logic depending on the values from the variables. So, let's take a look at the benefits: - If next week the frontend team decides to switch from Vue to anything else, the SASS code does not need to be touched at all. - If next week the design team brings a whole new "Design Language", the JS code does not need to be touched at all (unless of course the design system also brings new functionality) - The styling could even be verified on a series of static HTML pages. If the designer does not do any code, they can verify if the implementation matches the designs by opening a reference template, no need to run a whole JS app. Downsides: - If you want the code to be truly portable, your SASS need to follow a standard convention of @mixin names/parameters as well as variables. Honestly though this IS what I would expect from a "CSS framework", so I am not even sure it's a bad thing. - You don't get to put any hip CSS-in-JS framework on your resume.

trevyn 6y ago

>HTML and CSS are not concerns, they're technologies. Components are a better way for separating concerns. This is the clearest concise explanation of this I've seen, thank you. That you frequently have to add <div>s in your HTML in order to get CSS to lay stuff out correctly is enough evidence for me. :)

rglullis 6y ago
I gather you haven't used much of display:grid? I'm trying not to make this too much of a dogmatic discussion, but is the cultural norm among developers going to be to just throw their hands in the air and say "styling is hard, let's go shopping for divs"? On the one hand, I get that most people nowadays see HTML and CSS as object code, and is not that important to be abstraction that people think in. However, current web application frameworks can not solve problems that desktop GUIs frameworks have already solved in the 90s and no one is asking themselves "is this really the way to go forward?"
- seanwilson 6y ago
  > I'm trying not to make this too much of a dogmatic discussion, but is the cultural norm among developers going to be to just throw their hands in the air and say "styling is hard, let's go shopping for divs"? The experiment failed though, we've been trying for over a decade. You can't let one group write the HTML and one group write the CSS (with the pipedream being the designers writing the CSS). The only way to make complex designs is to modify both as you develop. They're too intertwined and CSS alone isn't powerful enough to do everything you want. Keep your actual data like blog post content, blog post meta data, images etc. separated but it's 1) not practically possible and 2) there's no significant benefits to keeping your CSS and HTML separate besides sticking to dogmatism "best practices" that haven't panned out.
  - rglullis 6y ago
    Honestly, I don't buy it. It might be the case if you are trying to target IE9, but "we've been trying it over a decade" is no longer an excuse in 2020 when there are only 2-3 relevant browser engines and all of them are reasonably up to spec. Also, it's not a matter of strictly separating the groups of people doing one task or another. It's a matter of being able to extend in one dimension while keeping the other untouched. > They're too intertwined and CSS alone isn't powerful enough to do everything you want. I'd argue that is precisely backwards. The reason that we don't see any more different designs and more bold experiments is because we are not defining the interaction points between different layers in the development stack. If most developers keep this mentality that all they need to do is to get a system that solves their immediate problems and solves their own unique solution, then all they are going to do is this mushing together of their structure and their presentation layers, and all we are going to get is a pile architectures are going to converge to different local maxima. If instead we don't take the easy way out and make things with flexibility and extensibility in mind, then the likelihood of it becoming the basis of something ground-breaking grows enormously.