I always thought this was funny. This was the embodiment of the original CSS philosophy, which was to "label your html elements semantically with what they ARE, and then worry about styling those in the CSS." The whole point was to get anything style related out of the HTML altogether, the HTML would just be semantic/content related.
But then Bootstrap and other CSS libraries came out, and completely inverted the philosophy back to what HTML originally looked like pre-CSS, which is that you had all of these rules you could place directly in the HTML that would directly control how the element was styled. In CSS Zen era you could look at my HTML and have no idea how I intended it to LOOK, whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.
Now people just make components and will maybe use style variables/tokens. Just funny how things change.
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.
Because it was "the whole point" doesn't mean that it was a "good idea", especially when the web changed so much since then.
It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes?
I find the approach by Bootstrap (or better, Tailwind) much easier to work with: compose utility classes to make up higher-level components. It still require some encapsulation of these higher-order components (with a Web Component, React Component or even just a class with @apply), but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. Ultimately I code faster with less bugs and easier maintainance: I take it as a subjectively better approach.
If you look at some talks on ideas behind oocss you can understand that a lot of elements share similar styles. It's all boxes in the end. There is this one talk about refactoring a huge pile of css into a small number of reusable visual styles, I think it was for facebook. The semantics of an element might be a comment box, but visually it's a box with a shadow and a chat box or sidebar might share the same look, thereby it would make sense to assign them the same class (classes are intended for extracting common visual styles). Doing styles the zen garden way was usually done via long selectors to target the elements and you would end up with css code that is tightly coupled to your markup. Moving html sections would cause the styles to break. Using strictly visual styles (ie functional classes) makes it easier to distinguish the style aspect from the content and HTML is already a presentational medium.
> ...in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.
Part of the blame for this has to fall onto the lap of CSS itself.
Up until CSS-grid it has been too damn hard to get layout to "just freaking work" with CSS.
To be fair, it was even more of a dumpster fire back in the early naughts when almost everyone just used HTML tables to do their layouts. The folks behind CSS should have caught on at that time and focused on making layout better and eliminate thousands of person-years of frontend people grinding their gears... BUT NO, not until 2018-ish did we get CSS-grid.
I've long thought about this too. Eventually I've come to the conclusion that CSS Zen Garden was more about "Hey you can do all of this with pure CSS" than it was "You should do it this way". At the time that I discovered Zen Garden, CSS was in it's more early, primitive days. As a front-end developer, it was easy to say "I can't achieve this design without changing the HTML Structure". Zen Garden showed us that this was just an excuse, (just about) any design could be achieved without a requirement to fundamentally change the HTML of the page. It was eye-opening to see some of the ways theme authors rearranged content, broke down those box boundaries, and used design tricks that stretched the limits of CSS and HTML in that era.
It was awfully inspiring, and I think the point was never - "this is the way you should encode pages" it was more about taking excuses away.
People are far too concerned with these things anyway, IMO. All ways work well enough and perhaps I'm just ignorant, but in the past 25 years I haven't seen a single good example of a situation where someone won against the competition because of better presentation or better choice of frontend framework. That excludes those who shot themselves in the foot with Flash though.
IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.
I think this reversal is sad, actually. Even sadder, that one of the driving reasons was people just giving up on CSS ("too complex/weird") and going for spaghetti and a wall approach. Then trying to use tools to plug the knowledge hole.
For awhile now I've felt that the CSS libraries like Bootstrap, Semantic UI, etc are never the "right" way to organize your markup and CSS for a large project. They're great for getting out something quick and dirty that looks decent. But once your project passes a certain scale (in size or time spent maintaining it), the balance shifts in favor of semantic markup and style in CSS using BEM or something similar as an organizational paradigm. The latter just doesn't seem conducive to off-the-shelf styles because semantic organization is different for every project.
Another way of thinking about it is that CSS libraries build infrastructure for universal reusable widgets. In the beginning of a project it makes sense to build your app by putting together these building blocks. But as time goes by and the app grows, you start to develop a layer of higher level UI abstractions that are specific to the domain of your app. And when that happens it is often in conjunction with some kind of a re-styling and the old universal building blocks are no longer what you want. I've seen multiple large frontend projects go through these phases, and am starting to see them as a natural evolution of frontend projects.
> whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.
say what you will about utility classes, but the grid classes are absolutely necessary, especially when many elements might need specific behavior for different screen sizes and must interact gracefully. without the grid classes your css would be an absolute nightmare of a thousand often-nonsensical "semantic" classnames littered with a crapload of fragile media queries.
Bootstrap still gives me an eye twitch. It didn’t handle color customization properly until at least 3.0 (oh you could color many things, but you want light text on a dark background and you’ll have to override a ton of stuff).
I was ordered to use a version that didn’t even handle responsive design properly. Right after we had agreed to make the app responsive.
Personally, I find the mixes of class names like with Tailwind really confusing and need to keep looking it up when using it. Doesn't really make things easier imho
It's a failed experiment. We've had over a decade of people trying to use CSS to style websites and ending up with worse results than if they'd just changed the HTML.
This approach is extremely seductive because on the surface it sounds so "pure" and "clean" but the reality is that on large projects it leads to some of the most horrific, hard to maintain CSS you'll ever see, no matter how hard you try to keep things in good shape. CSS is just inherently more difficult to maintain than HTML, and choosing a workflow that encourages editing CSS instead of HTML just makes things harder and harder over time.
Choosing an approach where CSS is treated like a third-party dependency that is _consumed_ by your HTML ends up being much more practical, maintainable, and scalable because editing and maintaining HTML is _easy_ — every time you change a class on an HTML element your changes are local and predictable.
Always thought this article by Nicolas Gallagher did the best job arguing this point:
CSS Zen Garden is from a time when people still used tables and font tags to design their pages, and as such it was a pretty powerfull way to convince people there are better and more efficient ways to do things.
I think the important part here is "efficient". It is more efficient to go to a style sheet and change a color instead of 1000 font tags, but in other ways it's just more efficient and easier to adjust your template-generated html and be done with it. Or write it from scratch.
The thing that I think doesn't work very well with this way is reusability. Rarely do you have this one thing you've made, and that you can use in the completely same way in another place. So you end up adjusting the style through CSS for a specific case, which eventually results in having rules like .foo > .bar:not(.baz) :first-child and making a change there results in playing whack-a-mole: you change something, break it in another place, fix it there, now it breaks in the third place etc. This is even worse if you have multiple people doing quick fixes.
There are other reasons too, but in general all of that is fine if you want to do a one-off thing to see if it could be done. Especially if you're a designer writing the code yourself. But getting a finished design from somebody who doesn't care about code is different because you cannot really predict what people will think of -- and I've actually never seen anybody do a redesign like this.
But can you do what CSS Zen Garden does only by changing HTML? If you can't, it means you failed at separating concerns.
Additionally, applications that you need to customize/theme usually makes it hard for us to edit the HTML. The only option is to edit the CSS. In this case, you whole argument breaks down.
p.s.:
In your case, I believe Tailwind should be pushing more for the use of @apply, instead of making those god-awful markups :(
I recently brought this up with my team. As an "old-school" web developer, I buy in to the whole CSS as design thing, while the front-end engineers @ work switched to using styled react components. As we look to make substantive design changes, now we have multiple places to make the CSS changes, only now it's the SASS project and all of the React components / projects. I must be missing something about how hip and cool styled components are, but they'll never be as cool as the CSS Zen Garden :)
I think different parts of the page need to be treated differently.
In a typical webpage, you'll have lots of "chrome" (menubars, sidebars, footers, logos, etc.) and "content well" of some sort. For the content well, the content is probably going to come in through some sort of CMS with Rich Text Editor that can handle bold, italics, links, headers, blockquotes, etc. by outputting plain HTML.
The content well should be designed to work without classes on the items. It should be able to take the <a href> and <em> tags and make it look correct. The tags themselves have a semantic meaning, and you can imagine this same content surviving through multiple redesigns of the site.
But for the chrome HTML, the tags are only there as part of the current design. When you redesign the site, there's no reason to expect the same tags to be used. It may or may not be possible depending on the goals of the redesign, but either way, it's not a goal, the way that reusing the content well HTML is.
I think this is what leads to the disconnect. If you're new school web dev making CSS-in-JS components or whatever, you're expecting your components to be thrown out when a new design comes along in five years. If you're designing the content well, you expect the HTML to live essentially forever or at least as long as the business.
I also started coding when CSS Zen Garden was the best thing ever but sorry, CSS in JS is better.
With classes and a separate stylesheets, there are no statically analyzable connections between them. You typo a class name? Too bad. You're no longer using that class anywhere? No compiler will tell you it's dead code. You want to increase the padding in this one place? There's no way to be confident what else it will affect.
And all the "benefits" that stylesheets tout are also offered by components. No one is adding <font> tags on all on all of their headings. With components, you just set the font once on the heading component.
CSS Zen Garden was a treasure back in the day, one of the most inspirational CSS sites showing the power and flexibility that can be achieved with CSS over semantic HTML.
I still remember the original design from Dave Shea fondly:
I remember this blowing my <table>-addled brain in 2003. This site was what convinced me to really dig into CSS, and not just use a few inline styles as hacks. This also opened my mind to JavaScript at the same time (as I looked into "DHTML"). It was a pretty different web back then!
It looks great. Nice job. I miss the web from this era. Sites looked so much more unique. People posted to their own sites and syndicated content. Feed readers were useful. Sigh.
Some time ago I made https://github.com/fiatjaf/classless, a framework for making themes for simple websites (like blogs) using the same basic HTML structure.
The idea is: you write HTML that conforms to the structure, then you can reuse any of the themes by just including a CSS file (and sometimes a JS file) in your <head>.
Turns out I wasn't the best person indicated to push this, as my design skills weren't marvelous, but I still think it was a good idea. There are 17 themes available, mostly ported from other places. A playground where you can see the themes (and test your own, if you are feeling like building one) is available at https://classless.alhur.es/
I wrote my blog's HTML[0] semantically, and I'm glad I did. I have a different style when someone fires up a new instance. I was already going for a retro "vaporwave" aesthetic there, and that recent Windows 93 post[2] pushed me over the edge. I apply those styles to my main site as an Easter egg when you view it in the Japanese locale.[1]
Dave Shea (CSS Zen Garden), Eric Meyer, Jeffrey Zeldman (A List Apart), Jeremy Keith (DOM Scripting), and others who escape me provided the foundation for the CS classes I taught 15 years ago. Thanks guys!
Honestly, these designs are so refreshing. There is no place for ads. No popups asking to subscribe to their newsletter. No breaking because I have Javascript disabled.
Looking through some of the designs made me happy... and a bit nostalgic. :)
Good memories from 10 years ago (the site looks practically unchanged since then). Incredibly how the frontend nonsense of recent years allowed us to go backward. Same result but slower and more complex without any good reason.
Separation of html and css can still be a useful paradigm and does not have to be incompatible with separating your code into components.
For medium-sized projects, I have found it useful to have general (or "base" and "cosmetic" a la MCSS) styling in a central place with all my variables. For my components, I strive to balance the "structure-" and "container-" -like (similar to OOCS) styling they need while not trying to make them so general that they are over-engineered. To that end, I am comfortable enough using the central variables within my components and even some central classes, recognizing that when I do want to re-use my components across projects there is occasionally ad-hoc refactoring/customization.
Also, Css in JS is only one way of building components. You can keep your component-specific css separate from the rest without using JS.
Cool. XML, by way of HTML was always designed to be layered. As in, a layer for a different use case. At the lowest layer, is the data. Each layer used to decorate the layer below it enables using it for different use cases. CSS is just another decoration to create another layer used for another use case (styling the data for the rendering in a browser use case). While keeping the underlying data still usable for a totally different use case. CSS Zen Garden is such a fantastic showcase of that layering architecture of HTML.
Regarding Javascript applications, I consider it just another case where we're using the design of the web for something it's inventors could never foresee. Well, they did foresee "apps", but I'm just not sure React, Angular, Ember, etc. apps was what they were imagining.
I see a lot of people bickering here in the comments about what's better and why, but does it really matter? I mean I don't care if you like to wear rain boots when it's sunny or flip flops when it's raining, as long as you have some footwear on.
There's many ways a webpage could be programmed/designed/developed/styled but the only thing that really matters is that it's usable and visible to the end-user. No programmer likes every other programmers code when they have to work with it and we all know there's ten different ways to solve the same problem so just let people do it the way they know how as long as you can use/view it with no major issues who cares.
It might seem dated, but the ideas of using images and flowing layout shaped that era, and the simplicity can still be applied today (although we can make it look a lot better and cleaner thanks to CSS grid, flexboxes and other new tech that's now available in most browsers).
There's a lot of good nostalgia here if you go through their older designs.
[+] [-] ralusek|6 years ago|reply
But then Bootstrap and other CSS libraries came out, and completely inverted the philosophy back to what HTML originally looked like pre-CSS, which is that you had all of these rules you could place directly in the HTML that would directly control how the element was styled. In CSS Zen era you could look at my HTML and have no idea how I intended it to LOOK, whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.
Now people just make components and will maybe use style variables/tokens. Just funny how things change.
[+] [-] jacurtis|6 years ago|reply
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.
[+] [-] williamdclt|6 years ago|reply
It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes?
I find the approach by Bootstrap (or better, Tailwind) much easier to work with: compose utility classes to make up higher-level components. It still require some encapsulation of these higher-order components (with a Web Component, React Component or even just a class with @apply), but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. Ultimately I code faster with less bugs and easier maintainance: I take it as a subjectively better approach.
[+] [-] dsego|6 years ago|reply
[+] [-] crispyambulance|6 years ago|reply
Part of the blame for this has to fall onto the lap of CSS itself.
Up until CSS-grid it has been too damn hard to get layout to "just freaking work" with CSS.
To be fair, it was even more of a dumpster fire back in the early naughts when almost everyone just used HTML tables to do their layouts. The folks behind CSS should have caught on at that time and focused on making layout better and eliminate thousands of person-years of frontend people grinding their gears... BUT NO, not until 2018-ish did we get CSS-grid.
[+] [-] thomascgalvin|6 years ago|reply
[+] [-] jguffey|6 years ago|reply
It was awfully inspiring, and I think the point was never - "this is the way you should encode pages" it was more about taking excuses away.
[+] [-] lazyjones|6 years ago|reply
IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.
[+] [-] rimliu|6 years ago|reply
[+] [-] mightybyte|6 years ago|reply
Another way of thinking about it is that CSS libraries build infrastructure for universal reusable widgets. In the beginning of a project it makes sense to build your app by putting together these building blocks. But as time goes by and the app grows, you start to develop a layer of higher level UI abstractions that are specific to the domain of your app. And when that happens it is often in conjunction with some kind of a re-styling and the old universal building blocks are no longer what you want. I've seen multiple large frontend projects go through these phases, and am starting to see them as a natural evolution of frontend projects.
[+] [-] bromuro|6 years ago|reply
[+] [-] leeoniya|6 years ago|reply
say what you will about utility classes, but the grid classes are absolutely necessary, especially when many elements might need specific behavior for different screen sizes and must interact gracefully. without the grid classes your css would be an absolute nightmare of a thousand often-nonsensical "semantic" classnames littered with a crapload of fragile media queries.
[+] [-] hinkley|6 years ago|reply
I was ordered to use a version that didn’t even handle responsive design properly. Right after we had agreed to make the app responsive.
[+] [-] hcarvalhoalves|6 years ago|reply
[+] [-] wdb|6 years ago|reply
[+] [-] tylerjwilk00|6 years ago|reply
[+] [-] arvinsim|6 years ago|reply
[+] [-] jakearmitage|6 years ago|reply
[+] [-] arkh|6 years ago|reply
[+] [-] lmm|6 years ago|reply
Let it die.
[+] [-] gridlockd|6 years ago|reply
Things have simply moved towards what's actually manageable in a production environment, not what some ivory tower designer thought was good practice.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] adamwathan|6 years ago|reply
Choosing an approach where CSS is treated like a third-party dependency that is _consumed_ by your HTML ends up being much more practical, maintainable, and scalable because editing and maintaining HTML is _easy_ — every time you change a class on an HTML element your changes are local and predictable.
Always thought this article by Nicolas Gallagher did the best job arguing this point:
http://nicolasgallagher.com/about-html-semantics-front-end-a...
[+] [-] locallost|6 years ago|reply
I think the important part here is "efficient". It is more efficient to go to a style sheet and change a color instead of 1000 font tags, but in other ways it's just more efficient and easier to adjust your template-generated html and be done with it. Or write it from scratch.
The thing that I think doesn't work very well with this way is reusability. Rarely do you have this one thing you've made, and that you can use in the completely same way in another place. So you end up adjusting the style through CSS for a specific case, which eventually results in having rules like .foo > .bar:not(.baz) :first-child and making a change there results in playing whack-a-mole: you change something, break it in another place, fix it there, now it breaks in the third place etc. This is even worse if you have multiple people doing quick fixes.
There are other reasons too, but in general all of that is fine if you want to do a one-off thing to see if it could be done. Especially if you're a designer writing the code yourself. But getting a finished design from somebody who doesn't care about code is different because you cannot really predict what people will think of -- and I've actually never seen anybody do a redesign like this.
[+] [-] wtetzner|6 years ago|reply
[+] [-] andre-lima|6 years ago|reply
Additionally, applications that you need to customize/theme usually makes it hard for us to edit the HTML. The only option is to edit the CSS. In this case, you whole argument breaks down.
p.s.: In your case, I believe Tailwind should be pushing more for the use of @apply, instead of making those god-awful markups :(
[+] [-] crad|6 years ago|reply
[+] [-] earthboundkid|6 years ago|reply
In a typical webpage, you'll have lots of "chrome" (menubars, sidebars, footers, logos, etc.) and "content well" of some sort. For the content well, the content is probably going to come in through some sort of CMS with Rich Text Editor that can handle bold, italics, links, headers, blockquotes, etc. by outputting plain HTML.
The content well should be designed to work without classes on the items. It should be able to take the <a href> and <em> tags and make it look correct. The tags themselves have a semantic meaning, and you can imagine this same content surviving through multiple redesigns of the site.
But for the chrome HTML, the tags are only there as part of the current design. When you redesign the site, there's no reason to expect the same tags to be used. It may or may not be possible depending on the goals of the redesign, but either way, it's not a goal, the way that reusing the content well HTML is.
I think this is what leads to the disconnect. If you're new school web dev making CSS-in-JS components or whatever, you're expecting your components to be thrown out when a new design comes along in five years. If you're designing the content well, you expect the HTML to live essentially forever or at least as long as the business.
[+] [-] exclipy|6 years ago|reply
With classes and a separate stylesheets, there are no statically analyzable connections between them. You typo a class name? Too bad. You're no longer using that class anywhere? No compiler will tell you it's dead code. You want to increase the padding in this one place? There's no way to be confident what else it will affect.
And all the "benefits" that stylesheets tout are also offered by components. No one is adding <font> tags on all on all of their headings. With components, you just set the font once on the heading component.
[+] [-] mythz|6 years ago|reply
I still remember the original design from Dave Shea fondly:
http://www.csszengarden.com/001/
[+] [-] klenwell|6 years ago|reply
Ha, I found the blog I was keeping:
http://myspacecivilized.blogspot.com/2006/09/css-moshi-garde...
It includes a small screenshot.
[+] [-] jklinger410|6 years ago|reply
[+] [-] sbergot|6 years ago|reply
[+] [-] GavinAnderegg|6 years ago|reply
[+] [-] omegote|6 years ago|reply
Incredible, I had never thought of how long it's been...
[+] [-] austincheney|6 years ago|reply
This is my Zen Garden attempt. According to the HTTP headers it is from 20 October 2008.
You can see how font rendering has changed over the years. When I wrote this all columns were the same height and alignment cross browser.
[+] [-] bendotero|6 years ago|reply
[+] [-] wiremine|6 years ago|reply
If you're not familiar with the project, I suggest checking out the Wikipedia article:
https://en.wikipedia.org/wiki/CSS_Zen_Garden
[+] [-] cromulent|6 years ago|reply
http://www.csszengarden.com/099/
Dave Shea mentioned that it was no longer relevant back in 2013.
https://www.awwwards.com/why-the-web-doesn-t-need-another-cs...
[+] [-] fiatjaf|6 years ago|reply
The idea is: you write HTML that conforms to the structure, then you can reuse any of the themes by just including a CSS file (and sometimes a JS file) in your <head>.
Turns out I wasn't the best person indicated to push this, as my design skills weren't marvelous, but I still think it was a good idea. There are 17 themes available, mostly ported from other places. A playground where you can see the themes (and test your own, if you are feeling like building one) is available at https://classless.alhur.es/
[+] [-] theandrewbailey|6 years ago|reply
[0] https://theandrewbailey.com/
[1] https://theandrewbailey.com/?lang=ja
[2] https://news.ycombinator.com/item?id=22463415
[+] [-] RyanOD|6 years ago|reply
[+] [-] coreyp_1|6 years ago|reply
Looking through some of the designs made me happy... and a bit nostalgic. :)
[+] [-] antirez|6 years ago|reply
[+] [-] andre-lima|6 years ago|reply
[+] [-] piinbinary|6 years ago|reply
I'm happy that this is still online.
[+] [-] TiredGuy|6 years ago|reply
For medium-sized projects, I have found it useful to have general (or "base" and "cosmetic" a la MCSS) styling in a central place with all my variables. For my components, I strive to balance the "structure-" and "container-" -like (similar to OOCS) styling they need while not trying to make them so general that they are over-engineered. To that end, I am comfortable enough using the central variables within my components and even some central classes, recognizing that when I do want to re-use my components across projects there is occasionally ad-hoc refactoring/customization.
Also, Css in JS is only one way of building components. You can keep your component-specific css separate from the rest without using JS.
[+] [-] joeyguerra|6 years ago|reply
Regarding Javascript applications, I consider it just another case where we're using the design of the web for something it's inventors could never foresee. Well, they did foresee "apps", but I'm just not sure React, Angular, Ember, etc. apps was what they were imagining.
[+] [-] subless|6 years ago|reply
There's many ways a webpage could be programmed/designed/developed/styled but the only thing that really matters is that it's usable and visible to the end-user. No programmer likes every other programmers code when they have to work with it and we all know there's ten different ways to solve the same problem so just let people do it the way they know how as long as you can use/view it with no major issues who cares.
[+] [-] djsumdog|6 years ago|reply
https://battlepenguin.com/tech/a-history-of-personal-and-pro...
It might seem dated, but the ideas of using images and flowing layout shaped that era, and the simplicity can still be applied today (although we can make it look a lot better and cleaner thanks to CSS grid, flexboxes and other new tech that's now available in most browsers).
There's a lot of good nostalgia here if you go through their older designs.