8 ms·

The ultimate anti-pattern of this philosophy is Tailwind.css (the newest, "coolest" css framework). Not trying to hate on it, but I find it ironic that the whol

The ultimate anti-pattern of this philosophy is Tailwind.css (the newest, "coolest" css framework). Not trying to hate on it, but I find it ironic that the whole point of Tailwind is that you can basically style your entire website within the HTML, without needing to customize it with CSS. For someone who learned CSS during the CSS Zen Garden era where we were told to only use the HTML document for structure and never style, it makes Tailwind cringe-worthy. Yes, I know lots of people customize it and stuff, but the idea still stands that 95% of styles are done within the HTML document through tens of thousands of ultra-specific css classes which basically just tweak a single css property.

adamlett 7y ago
The gospel of separating styling from content comes from an era when most web sites were comprised of collections of hand crafted HTML documents, when it was a pain to make site wide changes to styling because it meant updating each of these documents by hand. These days web sites are mostly comprised of HTML pages rendered on the fly by some type of web app which composes pages from nested templates injected with content from a database. In this scenario separating the styling from the markup gains us little, because to change the styling site wide you only have to update a few templates, not every single page that uses these templates.
Ayesh 7y ago
Totally agree with this. It's faster to prototype with Tailwind though, if you remember the class names well.
- jfengel 7y ago
  Unfortunately, prototypes are rarely thrown away. Prototypes become production code, because code that works is usually more important than code that's clean. Cleanliness comes with refactoring. And that's actually OK, most of the time. In some situations you have to be certain you get it right the first time, but the web encourages you to try, deploy, and fix later. It's messy and has long-term debt, but a lot of that debt rarely comes due. You might just be the one holding it when the bill comes in, and that's no fun, but people do this because on the whole the amortized cost is less. Just don't fool yourself into thinking that this is just the prototype. Unless you have specifically allocated resources to throwing it out and starting over, acknowledge from the beginning that this is going to be production code. That way you make fewer of those "Oh, well, it's a prototype" decisions. Not zero, just fewer.
  - allover 7y ago
    In the context of Tailwind though, the situation isn't really "that". Tailwind allows you to "feel" like you're just quickly prototyping, without afaict compromising maintainability at all. If you're concerned about the ability to reuse an HTML fragment and associated styles (or just a bunch of styles), they have decent docs on that: https://tailwindcss.com/docs/extracting-components/ https://tailwindcss.com/docs/extracting-components/
  - JJMcJ 7y ago
    > prototypes are rarely thrown away Fred Brooks' admonition to plan to throw one away almost never happens. Instead more and more features are force fit onto the prototype. For CSS/HTML, speaking of Fred Brooks, this is an essential complexity, the tension between style and content.
skellera 7y ago
Sure you could do everything on the HTML with Tailwind but they do recommend composing component classes for regularly used things. I’m not saying that solves all your concerns but it helps. Abstracting out CSS into utility classes can make it much quicker to get a consistent looking site up while still giving you a little more control over the look and feel. Of course you can misuse this but I think people who don’t understand standard CSS make a much bigger mess of it than if they have something like Tailwind.
rvense 7y ago
I also grew up in the CSS Zen Garden era, and I've become a big Tailwind proponent. To me what is cringe-worthy is hanging on to ideas about what this medium is that just no longer apply. For better or worse, the web stack has been appropriated into an application framework. I am not making documents that have styles applied to them. It's just not a metaphor that works anymore. The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always. Tailwind, to me, solves a bunch of very real ergonomic issues when working with large web applications, and results in far clearer code.
- Benjammer 7y ago
  >The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way This is orthogonal to the issue. It's still possible to separate the functional layers of a website or application, even if the entire stack is JS or whatever. I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.
  - dasil003 7y ago
    SPAs don't invalidate the concept of separating structure and styling, but as with all technical architecture decisions there are tradeoffs. Whenever you add another layer you are paying some base overhead cost with the goal that each individual layer ends up simpler. Whether or not this is a net win depends largely on the interface between the layers (see also: microservice trainwrecks). Content and style is tightly coupled and application-dependent, so abstract principles that sound good may make zero sense in a particular use case depending on a whole slew of technical and operational concerns about how the markup and CSS are generated and served. In the old days, website were primarily documents, and as browser formatting grew more sophisticated the ratio of content to styling markup grew lower and lower, and when you're formatting simple documents the amount of redundant styling is very very high. Because HTML was designed with a small number of elements that provide pretty good coverage over basic documents, and because most documents were created by hand, the original CSS design and philosophy behind CSS Zen Garden was an absolute slam dunk for content creators of the era. The assumption is a small amount of CSS covers styling for a huge library of markup documents, minimizing overall code size. As web apps evolved to be more dynamic, first with bits of AJAX and then graduating into full SPA with more and more functionality ported to client-side APIs, we found the semantics of HTML which were tied to more universal concepts of written documents (heading, paragraph, list, quote, etc) did not cover the semantic needs of describing UI widgets. At this point CSS is still useful but the optimal structure is not as obvious. Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis". This fundamental problem was attacked from many different angles, lots of code generation, web components, OOCSS, BEM, Sass, etc. I consider Nicole Sullivan's work in this area to be seminal, leading to the optimal approaches large web products use at scale, and directly informing the design of React and modern SPA approaches. The reason Webpack processes markup, css and javascript all together is because things are so tightly coupled in practice, that you need tooling to optimize overall code structure and legibility. Purist approaches don't work very well for large projects because HTML & CSS were not designed to build GUIs.
deleted 7y ago
[deleted]
leppr 7y ago
That arbitrary separation never made sense, when HTML always harbored presentation information. From controlling the cascading of styles to spatial layout, your HTML and CSS are tied. The separation of concern that actually makes sense, and on which we ended up, is structured data (JSON) piped into a presentation layer (SPA lib like React). That's what XML tried to do before it became gimped as HTML.
- uk_programmer 7y ago
  Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document. If you look at other document writing system such as LaTeX. You will see that there are Sections, SubSections etc. The link to the CSS simply told the browser how these should be presented. LaTeX has something similar as you can create a document class and Word has different styles you can import. Having a concept of a document structure with a set of styles attached which you can change easily is a good idea. The HTML document should make sense without a style sheet and if you write/generate semantic markup it does work properly.
  - olalonde 7y ago
    > Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document. I disagree. Unlike JSON which is truly presentation agnostic, the position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around. Despite the popular claim to the contrary, HTML was always part of the presentation layer.
    - rglullis 7y ago
      > position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around The results you see on CSS Zen Garden show that this is not true at all. It was hard, but not impossible then and nowadays grid layout and CSS3 fixed a lot of the issues.
iimblack 7y ago
I don't use Tailwind much, but couldn't you still use the Zen Garden style of CSS with Tailwind's @apply?
- ARussell 7y ago
  You absolutely could. But most don't, because, as has already been mentioned in this thread, and explained by Adam Watham himself(1), it's not usually the appropriate thing to do. Components are usually a better abstraction than CSS classes. 1: https://adamwathan.me/css-utility-classes-and-separation-of-concerns https://adamwathan.me/css-utility-classes-and-separation-of-...
keithnz 7y ago
Checkout Adams (tailwinds author) reasoning https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...
ivanhoe 7y ago
Problem with pure CSS is that when you work in teams very quickly you start getting a lot of redundancy. People reinvent already existing styles, copy/paste code all around with just minor differences, color/padding/margins inconsistencies are introduced, you get dead classes that no one dares to delete, etc. The solution is usually to have one person define all the core styles for all components, and then you mandate the rest of team to re-use them as much as possible - which basically boils down to the same thing these frameworks provide, just someone else did a lot of that initial work for you. And if you don't want to use all those utility classes directly in the html, you can use components and @apply to group them into more semantic classes. Still you get the benefits of having ready made utility styles, and also of using the system that a lot of people is familiar with and can quickly onboard the project.
inopinatus 7y ago
I’ve followed a similar path but since become a huge fan of Tailwind’s compositional style. It refactors style at the point of HTML generation, which in this component oriented era makes a ton of sense. CSS was explicitly designed not to be Turing complete. Had DSSSL been the choice twenty years ago, we might not be constantly twisting in the wind for a better paradigm.

adamlett 7y ago

The gospel of separating styling from content comes from an era when most web sites were comprised of collections of hand crafted HTML documents, when it was a pain to make site wide changes to styling because it meant updating each of these documents by hand. These days web sites are mostly comprised of HTML pages rendered on the fly by some type of web app which composes pages from nested templates injected with content from a database. In this scenario separating the styling from the markup gains us little, because to change the styling site wide you only have to update a few templates, not every single page that uses these templates.

Ayesh 7y ago

Totally agree with this. It's faster to prototype with Tailwind though, if you remember the class names well.

jfengel 7y ago
Unfortunately, prototypes are rarely thrown away. Prototypes become production code, because code that works is usually more important than code that's clean. Cleanliness comes with refactoring. And that's actually OK, most of the time. In some situations you have to be certain you get it right the first time, but the web encourages you to try, deploy, and fix later. It's messy and has long-term debt, but a lot of that debt rarely comes due. You might just be the one holding it when the bill comes in, and that's no fun, but people do this because on the whole the amortized cost is less. Just don't fool yourself into thinking that this is just the prototype. Unless you have specifically allocated resources to throwing it out and starting over, acknowledge from the beginning that this is going to be production code. That way you make fewer of those "Oh, well, it's a prototype" decisions. Not zero, just fewer.
- allover 7y ago
  In the context of Tailwind though, the situation isn't really "that". Tailwind allows you to "feel" like you're just quickly prototyping, without afaict compromising maintainability at all. If you're concerned about the ability to reuse an HTML fragment and associated styles (or just a bunch of styles), they have decent docs on that: https://tailwindcss.com/docs/extracting-components/ https://tailwindcss.com/docs/extracting-components/
- JJMcJ 7y ago
  > prototypes are rarely thrown away Fred Brooks' admonition to plan to throw one away almost never happens. Instead more and more features are force fit onto the prototype. For CSS/HTML, speaking of Fred Brooks, this is an essential complexity, the tension between style and content.

skellera 7y ago

Sure you could do everything on the HTML with Tailwind but they do recommend composing component classes for regularly used things. I’m not saying that solves all your concerns but it helps. Abstracting out CSS into utility classes can make it much quicker to get a consistent looking site up while still giving you a little more control over the look and feel. Of course you can misuse this but I think people who don’t understand standard CSS make a much bigger mess of it than if they have something like Tailwind.

rvense 7y ago

I also grew up in the CSS Zen Garden era, and I've become a big Tailwind proponent. To me what is cringe-worthy is hanging on to ideas about what this medium is that just no longer apply. For better or worse, the web stack has been appropriated into an application framework. I am not making documents that have styles applied to them. It's just not a metaphor that works anymore. The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always. Tailwind, to me, solves a bunch of very real ergonomic issues when working with large web applications, and results in far clearer code.

Benjammer 7y ago
>The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way This is orthogonal to the issue. It's still possible to separate the functional layers of a website or application, even if the entire stack is JS or whatever. I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.
- dasil003 7y ago
  SPAs don't invalidate the concept of separating structure and styling, but as with all technical architecture decisions there are tradeoffs. Whenever you add another layer you are paying some base overhead cost with the goal that each individual layer ends up simpler. Whether or not this is a net win depends largely on the interface between the layers (see also: microservice trainwrecks). Content and style is tightly coupled and application-dependent, so abstract principles that sound good may make zero sense in a particular use case depending on a whole slew of technical and operational concerns about how the markup and CSS are generated and served. In the old days, website were primarily documents, and as browser formatting grew more sophisticated the ratio of content to styling markup grew lower and lower, and when you're formatting simple documents the amount of redundant styling is very very high. Because HTML was designed with a small number of elements that provide pretty good coverage over basic documents, and because most documents were created by hand, the original CSS design and philosophy behind CSS Zen Garden was an absolute slam dunk for content creators of the era. The assumption is a small amount of CSS covers styling for a huge library of markup documents, minimizing overall code size. As web apps evolved to be more dynamic, first with bits of AJAX and then graduating into full SPA with more and more functionality ported to client-side APIs, we found the semantics of HTML which were tied to more universal concepts of written documents (heading, paragraph, list, quote, etc) did not cover the semantic needs of describing UI widgets. At this point CSS is still useful but the optimal structure is not as obvious. Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis". This fundamental problem was attacked from many different angles, lots of code generation, web components, OOCSS, BEM, Sass, etc. I consider Nicole Sullivan's work in this area to be seminal, leading to the optimal approaches large web products use at scale, and directly informing the design of React and modern SPA approaches. The reason Webpack processes markup, css and javascript all together is because things are so tightly coupled in practice, that you need tooling to optimize overall code structure and legibility. Purist approaches don't work very well for large projects because HTML & CSS were not designed to build GUIs.

deleted 7y ago

[deleted]

leppr 7y ago

That arbitrary separation never made sense, when HTML always harbored presentation information. From controlling the cascading of styles to spatial layout, your HTML and CSS are tied. The separation of concern that actually makes sense, and on which we ended up, is structured data (JSON) piped into a presentation layer (SPA lib like React). That's what XML tried to do before it became gimped as HTML.

uk_programmer 7y ago
Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document. If you look at other document writing system such as LaTeX. You will see that there are Sections, SubSections etc. The link to the CSS simply told the browser how these should be presented. LaTeX has something similar as you can create a document class and Word has different styles you can import. Having a concept of a document structure with a set of styles attached which you can change easily is a good idea. The HTML document should make sense without a style sheet and if you write/generate semantic markup it does work properly.
- olalonde 7y ago
  > Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document. I disagree. Unlike JSON which is truly presentation agnostic, the position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around. Despite the popular claim to the contrary, HTML was always part of the presentation layer.
  - rglullis 7y ago
    > position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around The results you see on CSS Zen Garden show that this is not true at all. It was hard, but not impossible then and nowadays grid layout and CSS3 fixed a lot of the issues.

iimblack 7y ago

I don't use Tailwind much, but couldn't you still use the Zen Garden style of CSS with Tailwind's @apply?

ARussell 7y ago
You absolutely could. But most don't, because, as has already been mentioned in this thread, and explained by Adam Watham himself(1), it's not usually the appropriate thing to do. Components are usually a better abstraction than CSS classes. 1: https://adamwathan.me/css-utility-classes-and-separation-of-concerns https://adamwathan.me/css-utility-classes-and-separation-of-...

keithnz 7y ago

Checkout Adams (tailwinds author) reasoning https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...

ivanhoe 7y ago

Problem with pure CSS is that when you work in teams very quickly you start getting a lot of redundancy. People reinvent already existing styles, copy/paste code all around with just minor differences, color/padding/margins inconsistencies are introduced, you get dead classes that no one dares to delete, etc. The solution is usually to have one person define all the core styles for all components, and then you mandate the rest of team to re-use them as much as possible - which basically boils down to the same thing these frameworks provide, just someone else did a lot of that initial work for you. And if you don't want to use all those utility classes directly in the html, you can use components and @apply to group them into more semantic classes. Still you get the benefits of having ready made utility styles, and also of using the system that a lot of people is familiar with and can quickly onboard the project.

inopinatus 7y ago

I’ve followed a similar path but since become a huge fan of Tailwind’s compositional style. It refactors style at the point of HTML generation, which in this component oriented era makes a ton of sense. CSS was explicitly designed not to be Turing complete. Had DSSSL been the choice twenty years ago, we might not be constantly twisting in the wind for a better paradigm.