CSS Zen Garden(csszengarden.com)
csszengarden.com
CSS Zen Garden
https://csszengarden.com/
175 comments
Not to mention that early on, CSS was very lacking compared to today. We didn't even have `border-radius` until something like 2011! Consider that this relatively simple site design[1] takes about 420 lines of modern CSS[2]. And that's even using nesting, and liberal use of :has, which is a game changer. I remember having to restructure both my CSS and my HTML to achieve appearances which were otherwise impossible to create in the intuitive way, all because of inherent limitations to CSS at the time.
[1] https://90s.dev/
[2] https://90s.dev/style.css
[1] https://90s.dev/
[2] https://90s.dev/style.css
Re border radius… The coveted rounded corner, the mark of a really slick design before that property made it easy :D
I think media queries/responsive is what did in the last bastion of CSS resistors.
I think media queries/responsive is what did in the last bastion of CSS resistors.
CSS rounded corners often looked a bit pixelated in the early days, and I remember doing image-based corners well after border-radius was widely supported.
By the time CSS rounded corners became really smooth a lot of designers had moved on to the boxy flat look, and square corners were fashionable again.
By the time CSS rounded corners became really smooth a lot of designers had moved on to the boxy flat look, and square corners were fashionable again.
Modern CSS makes me long for Hi5 to make a comback. My profile would be killer.
The reason we used tables was because getting things right in CSS in the early days across all of the browsers was a nightmare. An expensive nightmare. Which was fine if you were a well funded startup and could afford to rebuild your HTML regularly.
CSS at the time was still a leaky abstraction: in order to get things working, you had to include extraneous DIVs in the HTML code as anchors for the CSS rules.
The standard body has attempted to address this issue with pseudo-elements and pseudo-classes as well as other features I may not be aware of.
At least though, these extra DIVs weren't disrupting the page layout (eg. when disabling the CSS - something that was still possible at the time), which was beneficial for accessibility.
At least though, these extra DIVs weren't disrupting the page layout (eg. when disabling the CSS - something that was still possible at the time), which was beneficial for accessibility.
The “across all browsers” problem was such a huge pain. Not just for CSS but JS too.
I still remember the campaign for sites to drop support for IE6 in protest.
I still remember the campaign for sites to drop support for IE6 in protest.
Yeah fun times.
I kept our internal reporting site running for 3-4 years, I used CSS for layout.. it required regular maintenance but I had enough time to do it as my main job was as a Database Admin / Data Engineer (I'd have been called "devops engineer" nowadays as I had quite a broad set of responsibilities).
I kept our internal reporting site running for 3-4 years, I used CSS for layout.. it required regular maintenance but I had enough time to do it as my main job was as a Database Admin / Data Engineer (I'd have been called "devops engineer" nowadays as I had quite a broad set of responsibilities).
I remember a time when using <div> tags was considered a sign of "expensive" to some.
It always felt like a fun challenge. For me, it was a crucial part of my love of the web (and eventually, programming): the hackability and the way that there was no canonical correct way to solve a given problem. I miss those days.
I'm fuzzy on the timeline, but there was a time where the emerging CSS wasn't up to the task of creating more complex layouts (no flexbox, not to speak of the grid). CSS Zen Garden was just there to show what could be done by that point.
Things have certainly gotten easier, but even back then CSS had things like pseudo-elements and display: table-cell. The main problem was Internet Explorer 6 holding everybody back so floats were the main way of laying things out, and those go back to CSS 1 (1996).
floats and clearfix were plenty powerful even before flexbox, despite not being intended for the purpose.
But then, neither were tables.
But then, neither were tables.
Ahhh yes, floats were everything.
> layouts were implemented by abusing table elements to create a grid.
Never understood what was actually wrong with it, apart from the whole "semantic html" yadda yadda that is meaningful for a small subset of applications.
Never understood what was actually wrong with it, apart from the whole "semantic html" yadda yadda that is meaningful for a small subset of applications.
On the contrary, semantics are very important from accessibility point of view.
The main problem with table layouts was that a site re-design meant rebuilding all the pages/templates from scratch, where as in theory CSS-based layouts meant changing just a single CSS file.
In practice though we always had to clean up and modify the HTML anyway. Sometimes just to remove all the old table cruft, but often adding and removing page elements. But pages did become cleaner and easier to maintain without table layouts, so it was a net improvement.
In practice though we always had to clean up and modify the HTML anyway. Sometimes just to remove all the old table cruft, but often adding and removing page elements. But pages did become cleaner and easier to maintain without table layouts, so it was a net improvement.
Yeah me neither, I think the CSS being cool and hard to use was the real reason. People like being ”elite”, and tables were just dead simple.
I am surprised people here still hold on to that era of CSS. There are even people in the comments being proud of clearfix
But I should probably be thankful for CSS for getting me out of webdev early :)
I am surprised people here still hold on to that era of CSS. There are even people in the comments being proud of clearfix
But I should probably be thankful for CSS for getting me out of webdev early :)
Tables were easy to build, but hard to maintain, Especially when looking at someone else's undocumented code.
>> layouts were implemented by abusing table elements to create a grid.
> Never understood what was actually wrong with it
Separation of concerns?
> Never understood what was actually wrong with it
Separation of concerns?
I don't remember pushback against CSS, but I do recall it was common for websites to dabble in CSS for styling fonts but still use table layouts. That's not pushback, just practicality.
If you wanted a solid predictable grid, you used table layouts. Particularly for tight and complex layouts. It wasn't uncommon for the navigation section to be a table layout even if other parts weren't. "Pixel perfect" was the name of the game. There emerged some pushback against the elimination of pixel-perfect design, not CSS.
Around 2000, remember spacer elements?
Until flexbox went mainstream in 2014, CSS float layouts were an exercise in balancing spinning plates. Empty divs didn't behave the same as divs containing content, and it sucked. We'll never get those hours back, but at least we were paid.
The idea that early CSS gave us wonderful "zen garden" layouts doesn't align with my experience. Then again, I was making information media sites not fun arty sites.
If you wanted a solid predictable grid, you used table layouts. Particularly for tight and complex layouts. It wasn't uncommon for the navigation section to be a table layout even if other parts weren't. "Pixel perfect" was the name of the game. There emerged some pushback against the elimination of pixel-perfect design, not CSS.
Around 2000, remember spacer elements?
<spacer width="332" height="1" type="block"></spacer>
Until flexbox went mainstream in 2014, CSS float layouts were an exercise in balancing spinning plates. Empty divs didn't behave the same as divs containing content, and it sucked. We'll never get those hours back, but at least we were paid.
The idea that early CSS gave us wonderful "zen garden" layouts doesn't align with my experience. Then again, I was making information media sites not fun arty sites.
Creating a grid is exactly the purpose of a table, not an abuse.
> Tables have existed as part of web standards since the HTML 3.2 standard (January 1997). The standard referenced an earlier RFC and was intended to be compliant with the table tags Netscape had already added to their browser, but this was their official addition to the HTML standard.
> The standard pointed out that tables could be used for tabular data or layout purposes, but cautioned that using them for layout would impact accessibility.
> In HTML 4 (April 1998), this warning was strengthened to "Tables should not be used purely as a means to layout document content", and we were pointed to the addition of CSS1 to help accommodate this. It was noted, however, that using deprecated features was expected to continue for a little while [heh] in order to support older browsers (browser listed above).
https://www.tiernok.com/posts/history-of-html-table-layouts....
> The standard pointed out that tables could be used for tabular data or layout purposes, but cautioned that using them for layout would impact accessibility.
> In HTML 4 (April 1998), this warning was strengthened to "Tables should not be used purely as a means to layout document content", and we were pointed to the addition of CSS1 to help accommodate this. It was noted, however, that using deprecated features was expected to continue for a little while [heh] in order to support older browsers (browser listed above).
https://www.tiernok.com/posts/history-of-html-table-layouts....
Semantically speaking, tables are supposed to contain tabular data, not to be used solely for their layout capabilities. That's why it's called an abuse.
An HTML table describes data that is related across multiple axes. A grid is a typical presentation for that data. That does not mean that creating a grid is the purpose of a table, and it doesn’t mean that any instance of a grid should be a table.
I remember being at Uni and having to build a css zen garden theme as a project, this really dug up some memories for me!
What an excellent summary.
[deleted]
With all due respect to Dave, no. Please stop rewriting history without the relevant details.
CSS Zen Garden is a project that demonstrated that "progressive enhancement" and "semantic HTML" were nonsense. The only reason something like CSS Zen Garden worked at all is because all the markup is fixed, all the content is static, and the designs are not really responsive.
There is no CMS with a theming system that offers the flexibility that CSS Zen Garden claims one can have with a single .css, independent of the HTML. And this is because web developers were huffing the HTML/CSS gospel too much, fussing over not having extra divs in their source and what not, and celebrating "semantic HTML" without ever running their website through a screen reader.
The reason people stopped using table layout when they were doing CSS is because CSS1 did not support the _most common way of doing layout at the time_, and IE6 held the web hostage for a decade. This is a remarkable thing because it means everyone hopped on this bandwagon despite it being very obviously ill-informed and not ready for production. The CSS Zen Garden era designs can be expected to be full of float/clear tricks, requiring careful layout dependency between elements so everything gets pushed down just far enough. And it looks exactly like the table-based layouts they were replacing, except they will scale improperly or not at all.
The "status quo" attitude has also not vanished, as witnessed by CSS variables, custom properties and all the other epicycles that keep getting added on to CSS instead of actually just scrapping the parts that are dumb. None of these CSS experts have the vision or depth of experience to really know what it takes to implement what they spec, or what is even still relevant today and what isn't.
I actually implemented my own web layout system for Use.GPU from scratch, with flexbox and blackjack and hookers, and it's remarkable how much of HTML/CSS you don't need, and also, how many parts of it are still laughably inadequate (like text-ellipsis).
Dave did not win the argument. The people who celebrated CSS Zen Garden were cargo culters who confused a pretty design for a structurally sound layout, and who honestly just wanted something they could feel good about while dealing with pre-Firebug / pre-Dev Tools CSS development.
There is a really easy way to test this too, and I would challenge Dave to do it: translate all the content to another language. See how many of those beautiful CSS-only designs fall apart.
CSS Zen Garden is a project that demonstrated that "progressive enhancement" and "semantic HTML" were nonsense. The only reason something like CSS Zen Garden worked at all is because all the markup is fixed, all the content is static, and the designs are not really responsive.
There is no CMS with a theming system that offers the flexibility that CSS Zen Garden claims one can have with a single .css, independent of the HTML. And this is because web developers were huffing the HTML/CSS gospel too much, fussing over not having extra divs in their source and what not, and celebrating "semantic HTML" without ever running their website through a screen reader.
The reason people stopped using table layout when they were doing CSS is because CSS1 did not support the _most common way of doing layout at the time_, and IE6 held the web hostage for a decade. This is a remarkable thing because it means everyone hopped on this bandwagon despite it being very obviously ill-informed and not ready for production. The CSS Zen Garden era designs can be expected to be full of float/clear tricks, requiring careful layout dependency between elements so everything gets pushed down just far enough. And it looks exactly like the table-based layouts they were replacing, except they will scale improperly or not at all.
The "status quo" attitude has also not vanished, as witnessed by CSS variables, custom properties and all the other epicycles that keep getting added on to CSS instead of actually just scrapping the parts that are dumb. None of these CSS experts have the vision or depth of experience to really know what it takes to implement what they spec, or what is even still relevant today and what isn't.
I actually implemented my own web layout system for Use.GPU from scratch, with flexbox and blackjack and hookers, and it's remarkable how much of HTML/CSS you don't need, and also, how many parts of it are still laughably inadequate (like text-ellipsis).
Dave did not win the argument. The people who celebrated CSS Zen Garden were cargo culters who confused a pretty design for a structurally sound layout, and who honestly just wanted something they could feel good about while dealing with pre-Firebug / pre-Dev Tools CSS development.
There is a really easy way to test this too, and I would challenge Dave to do it: translate all the content to another language. See how many of those beautiful CSS-only designs fall apart.
This sounds less like you want to correct something I have said that was inaccurate and more like you have a fundamental disagreement with the design of CSS.
Where in your comment did you mention the IE angle? The effect of lack of dev tools? Where did you mention the boondoggle of CSS2 tables and how everyone had to learn a whole new way of making floats behave? Where did you mention the laundry lists of named hacks that people used to get around browser parser differentials?
You didn't. You wrote the story as it is being told instead of how it happened.
You just don't know what you're talking about.
You didn't. You wrote the story as it is being told instead of how it happened.
You just don't know what you're talking about.
I didn’t mention any of that because none of it is relevant to the point I was making about design.
> You wrote the story as it is being told instead of how it happened.
I did the opposite of that. I was very clearly and specifically recounting an aspect of the situation that is not being told today. When was the last time you heard somebody talk about how CSS could only create “boring, boxy” designs? It’s got to be about twenty years for me. It’s practically forgotten. Pointing that out was the whole purpose of my comment.
Both of your replies to me in this thread are about that chip on your shoulder, not about what I am saying. You should post your own thoughts as a top-level comment like I did, not get angry with me for not talking about what you want to talk about.
> You wrote the story as it is being told instead of how it happened.
I did the opposite of that. I was very clearly and specifically recounting an aspect of the situation that is not being told today. When was the last time you heard somebody talk about how CSS could only create “boring, boxy” designs? It’s got to be about twenty years for me. It’s practically forgotten. Pointing that out was the whole purpose of my comment.
Both of your replies to me in this thread are about that chip on your shoulder, not about what I am saying. You should post your own thoughts as a top-level comment like I did, not get angry with me for not talking about what you want to talk about.
If that's how your feel about CSS, what do you think about XSLT?
You could easily make float/clear layout for dynamic content.
Pop quiz: make a 3 columns layout with fixed width header and sidebars, with a sticky footer at the bottom of the page, and which reaches full height even if the main content is shorter than the sidebar, or vice versa... even if the whole page is shorter than the browser. It must work in IE6-8.
Spoiler: you can't.
Spoiler: you can't.
> [IE] held the web hostage for a decade.
I wonder whether we'll ever get to reach this point with Safari. Especially with regards to PWAs and the insane state of "native" apps.
I wonder whether we'll ever get to reach this point with Safari. Especially with regards to PWAs and the insane state of "native" apps.
[deleted]
This site is old, and I mean it in a good way.
This site was a "culture" shock for me, back in 200x and made me walk away from Microsoft ASP.NET and start building apps on linux, realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
It was Alex Russell (creator of Dojo JS) who showed that side in one of the conferences, and I was shocked how much information I was missing while getting my technical news through Microsoft channels.
For many years, my toolkit was simply Web.py, HTML, JS and CSS.
We then got jQuery, and Backbone, and Underscore, till the React and then TS made new "Full stack" dumber again.
This site was a "culture" shock for me, back in 200x and made me walk away from Microsoft ASP.NET and start building apps on linux, realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
It was Alex Russell (creator of Dojo JS) who showed that side in one of the conferences, and I was shocked how much information I was missing while getting my technical news through Microsoft channels.
For many years, my toolkit was simply Web.py, HTML, JS and CSS.
We then got jQuery, and Backbone, and Underscore, till the React and then TS made new "Full stack" dumber again.
> This site was a "culture" shock for me, back in 200x and made me walk away from Microsoft ASP.NET and start building apps on linux
What stopped you from building such apps on Asp.net? It didn’t prevent you from building anything like that. You could stop creates style sheets and separate JS files.
> realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
Ironically what’s old is new again because we have literally gone full circle even down to nextjs? Recreating view state… and tailwind with inline styling and shadcn with react components.
What stopped you from building such apps on Asp.net? It didn’t prevent you from building anything like that. You could stop creates style sheets and separate JS files.
> realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
Ironically what’s old is new again because we have literally gone full circle even down to nextjs? Recreating view state… and tailwind with inline styling and shadcn with react components.
Indeed.
The famous asp.net "__VIEWSTATE" is now back to life...
Svelte now exists; it's a bit of a "clever" fullstack
> made me walk away from Microsoft ASP.NET and start building apps on linux, realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
That's still online, although as an outdated relict: https://www.ajaxtoolkit.net/. There was no enterprise software without drag panel!
For a moment semantic markup and CSS had taken the lead but nowadays I don't even care enough to check what the trends are. Stopped caring around the moment of "HTML inside JavaScript" (JSX).
That's still online, although as an outdated relict: https://www.ajaxtoolkit.net/. There was no enterprise software without drag panel!
For a moment semantic markup and CSS had taken the lead but nowadays I don't even care enough to check what the trends are. Stopped caring around the moment of "HTML inside JavaScript" (JSX).
I started writing ASP & PHP, the whole ASP.Net thing was about helping Visual Studio developers make crappy web apps, it wasn't fit for purpose for the web writ large.
You didn't need to switch to Linux either; I built everything under Windows (IT didn't allow Linux desktops) and deployed it to both Windows and Linux servers.
You didn't need to switch to Linux either; I built everything under Windows (IT didn't allow Linux desktops) and deployed it to both Windows and Linux servers.
I feel like the main point of css zen garden was how, by maximizing your use of semantic HTML, you could separate the presentation from the content and operate on them completely independently.
While you can still do this to the extent zen garden does, it's really operating within the limits of css (i.e. css can do this, therefore I can create this type of design, not I want this type of design, therefore I need to write this css).
There are lots of style choices that require modifying the DOM directly to effect, and can't be done purely with CSS. I've seen discussions on W3C where it was like "Well if you add another div around this you can achieve this effect, so why do we need a new CSS property?". Stuff like inserting or swapping an image is simple, but swapping a styleable SVG is impossible because the SVG nodes need to be directly embedded in the html.
So you're forced to mix presentation and content structuring decisions at the HTML and Javascript levels and even some simple design changes require modifications throughout the stack.
While you can still do this to the extent zen garden does, it's really operating within the limits of css (i.e. css can do this, therefore I can create this type of design, not I want this type of design, therefore I need to write this css).
There are lots of style choices that require modifying the DOM directly to effect, and can't be done purely with CSS. I've seen discussions on W3C where it was like "Well if you add another div around this you can achieve this effect, so why do we need a new CSS property?". Stuff like inserting or swapping an image is simple, but swapping a styleable SVG is impossible because the SVG nodes need to be directly embedded in the html.
So you're forced to mix presentation and content structuring decisions at the HTML and Javascript levels and even some simple design changes require modifications throughout the stack.
The CSS community's promise was always that structure and presentation can be separated.
After my 30 years of writing GUIs, I'm now convinced that this is the wrong place to draw a dividing line.
Instead, we should be isolating intent. This is what Composites do in my project. I'm so excited to announce it next week!
After my 30 years of writing GUIs, I'm now convinced that this is the wrong place to draw a dividing line.
Instead, we should be isolating intent. This is what Composites do in my project. I'm so excited to announce it next week!
Enter stage: XSLT
On the other hand CSS is very capable these days and many designs, that actually are not flying air castles and take the medium into account, can be implemented flawlessly using only CSS and HTML.
Agreed. A lot of modern web design problems come from trying to force a medium to do something it was never meant for. If you work with the grain of HTML and CSS instead of against it, you can still build really flexible and beautiful layouts without needing to hack the DOM or pile on JS. zen garden was a reminder of that and it still holds up.
As someone who learned CSS from Zen Garden and the likes of Eric Meyer, modern css tools like Tailwind looks like an anti pattern
Absolutely! There are so many problems with Tailwind.
The HTML is littered with styling information. Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header". But... you might argue that people do not read HTML anymore. Yes, people don't read HTML anymore. Who would when the devs using this framework turn the HTML into a horrible mess! If you litter your HTML with so many framework classes, there is more noise than content in HTML. Is it a surprise that reading HTML has fallen out of fashion? And since nobody reads HTML anymore, devs are totally unhinged with cluttering it with more and more classes and styles. It's a self perpetuating cycle.
Webdevs do style duplication rampantly. Instead of something like ".button", you'd find stuff like "text-white rounded bg-gray-aaa" littered throughout hundreds of places. I'm not sure if this is a Tailwind problem or dev problem but the problem definitely is there. A large project would soon reach a situation where if you want to make a style change across all similar UI elements it's a whack-a-mole game to find out which inline styles in which elements you need to look at.
The HTML is littered with styling information. Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header". But... you might argue that people do not read HTML anymore. Yes, people don't read HTML anymore. Who would when the devs using this framework turn the HTML into a horrible mess! If you litter your HTML with so many framework classes, there is more noise than content in HTML. Is it a surprise that reading HTML has fallen out of fashion? And since nobody reads HTML anymore, devs are totally unhinged with cluttering it with more and more classes and styles. It's a self perpetuating cycle.
Webdevs do style duplication rampantly. Instead of something like ".button", you'd find stuff like "text-white rounded bg-gray-aaa" littered throughout hundreds of places. I'm not sure if this is a Tailwind problem or dev problem but the problem definitely is there. A large project would soon reach a situation where if you want to make a style change across all similar UI elements it's a whack-a-mole game to find out which inline styles in which elements you need to look at.
I have a fairly strong grasp on CSS, at one point having what I felt was as close to as knowledgeable as I'd care to be about it, but one thing always stuck out as a neverending battle; style organization. I think Tailwind does have all those problems to some extent, but CSS alone didn't find cultural consensus around how best to implement it, always leaning on whichever flavour of the month conceptual framework that was often just one more system to try to manage. There's some virtue in writing the stuff you do cleanly, but sometimes it's just not as valuable to someone who's primarily doing what could be described as complex software development. Sometimes the marginal benefit to a clean implementation and a slightly messy redundant one of the same interactive caliber just isn't that important relatively, especially when the negative qualities are somewhat mitigated by component re-use and scoping.
I think it's the complex specificity rules that prompted things like TW to come about. Sure it's useful and powerful but it's utterly baffling to reason about, especially when everyone's conventions work at a different level of specificity. Trying to tame specificity gave us cumbersome structures like BEM, and TW came about as an act of rebellion against such things.
Conversations about CSS complexity always remind of this quip: "Two CSS selectors walk into a bar. A bar stool on the other side of town falls over."
Conversations about CSS complexity always remind of this quip: "Two CSS selectors walk into a bar. A bar stool on the other side of town falls over."
yeah, and then one day you want .button, but with a variation. GREAT. but oh no, now there's this other button that has a little bit of a change but not enough to create a separate class. maybe we'll just inline it... but no, i need a mobile selector here or i have some complex hover style. i know, let's create a basic utility class to help me out here. hmm, starting to look suspiciously like tailwind...
now multiply this problem by more people working on an app, with different isolated components that they never even dreamed of during css zen garden's time and this is how something arose. we've tried creating centralized css sheets and it just doesn't work at scale.
so yeah, a necessary evil, but i wouldn't call it an anti-pattern. it grew out of real needs. we had bootstrap and all these css frameworks attempting to make "order" about of something that honestly after decades of working with i don't think can be ever be fully "clean". people just gotta move past it.
now multiply this problem by more people working on an app, with different isolated components that they never even dreamed of during css zen garden's time and this is how something arose. we've tried creating centralized css sheets and it just doesn't work at scale.
so yeah, a necessary evil, but i wouldn't call it an anti-pattern. it grew out of real needs. we had bootstrap and all these css frameworks attempting to make "order" about of something that honestly after decades of working with i don't think can be ever be fully "clean". people just gotta move past it.
> Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header".
Unlike vanilla CSS where you need to look at browser dev tools and computed styles to figure out why something is styled this way. Because of course it's not styled just by the `.jus-one__more--modifier`.
And Tailwind is mostly there for people developing sites/apps, not reading final HTML. So all that is usually contained in the specific component.
Unlike vanilla CSS where you need to look at browser dev tools and computed styles to figure out why something is styled this way. Because of course it's not styled just by the `.jus-one__more--modifier`.
And Tailwind is mostly there for people developing sites/apps, not reading final HTML. So all that is usually contained in the specific component.
It's a culture problem with Tailwind devs: for a long time there was a crusade against `@apply` in favor of inlining every class. I think the reason was solely because TW's tree-shaking wasn't very capable then and did even worse with @apply, but the air was thick with specious "philosophical" justifications flying around for inlining all the things. The most typical was "it should always be done through a component toolkit", which of course just buries the problem in javascript -- not to mention doing it dynamically is incompatible with tree shaking, so you end up having to predeclare everything you use...
Nowadays the anti-@apply contingent seems to have gone quiet, so it is possible to not only use TW and similar toolkits sanely (which has always been the case) but to even see people publicly advocating for sanity.
Nowadays the anti-@apply contingent seems to have gone quiet, so it is possible to not only use TW and similar toolkits sanely (which has always been the case) but to even see people publicly advocating for sanity.
I think CSS tools like that appeal to people who learned web development in a kind of ad-hoc way. When I first started, I just wanted to make designs I had in my head. I kind of went from "header, text, and image on the page" to, "how do I center this?", "how do I change this color?", "how do I space these elements out?" It wasn't long before I had developed a toolkit of CSS ideas, but once you do that, you lose out on a lot of the finer details that make CSS work well. I knew how to work around weird issues using position: absolute and transform, but I wasn't familiar with block formatting contexts, or the intricacies of the box model. When all of your CSS knowledge is just band-aids placed on your other shoddy CSS knowledge, you're working on fumes. At that point, you could imagine the appeal of grabbing a prebuilt toolkit of composable styles that takes away your access a lot of the available CSS footguns.
What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up. It introduced everything from first principles, and had an approach where they explained why things were the way they were. They didn't just give you their "top 10 ways to center a div" and ask you to leave. I read the whole thing in an afternoon and it changed the way I think about web development. For the life of me, I can't remember what the book was called. If anyone's read something similar I'd love a reference, it was a while ago now and I'd still like to reference it. I specifically remember them saying "display: block is like a word document, and display: flex is like how you'd expect things to work," which illuminated a lot for me, not just about the display property, but generally about the way HTML & CSS were designed.
What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up. It introduced everything from first principles, and had an approach where they explained why things were the way they were. They didn't just give you their "top 10 ways to center a div" and ask you to leave. I read the whole thing in an afternoon and it changed the way I think about web development. For the life of me, I can't remember what the book was called. If anyone's read something similar I'd love a reference, it was a while ago now and I'd still like to reference it. I specifically remember them saying "display: block is like a word document, and display: flex is like how you'd expect things to work," which illuminated a lot for me, not just about the display property, but generally about the way HTML & CSS were designed.
> What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up.
Do you remember which one? Your experience sounds a lot like mine and I’d love to learn CSS from first principles.
Do you remember which one? Your experience sounds a lot like mine and I’d love to learn CSS from first principles.
Unfortunately, no :( I was hoping someone would recognize the book and reply...
Tailwind code is ugly as fuck. I hate it. I was working on some big sites when it came out, and the idea of adding hundred of style attributes each to thousands of pages (instead of just a single class name and few lines in a CSS file) seemed a huge backwards step that undid half the advantages of CSS.
I think it works well and is a good standard for companies with hundreds of people. Want to style everything one-off in a landing page go ahead.
A bit of light in the dark ages of Tailwind and CSS-in-JS.
It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.
It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.
CSS-in-JS (like how Styled Components and Emotion do it) is primarily a solution to code organization. It doesn't fundamentally change how CSS works.
But it's a performance killer
https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-...
Edit:
See also this thread on Bluesky
https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-...
Edit:
See also this thread on Bluesky
https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
It can be, depending on how it's used. But most of the modern tools I've seen are specifically designed to compile away the dynamic aspects of CSS-in-JS, meaning it essentially becomes a different way of writing normal CSS.
It made me fall in love CSS for sure. But it didn’t prevent me from understanding the appeal of Tailwind for large scale projects.
Please enlighten me of the benefits of using tailwind in large projects as opposed to using inline styles.
Not having to name a myriad of things! Sure, things like BEM can help you at least avoid naming conflicts, but you still have to decide a few thousand times what something is called semantically correct, in a way that you and your French colleagues and the intern of next year are going to understand it.
When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant.
With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions.
It’s a truly elegant solution for authoring web pages.
When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant.
With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions.
It’s a truly elegant solution for authoring web pages.
How do you cope with page URLs, with JavaScript classes, variables, methods, Git branches, CSS filenames, image filenames, directory structure, etc.?
I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it.
If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs?
I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?
I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it.
If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs?
I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?
I don't do front end these days and don't really have a dog in this fight, but most code is nouns and verbs, while design choices are adjectives and adverbs. When the business decides that we need to run, not walk, you can just change the name of the function from walk to run instead while changing the code, if that seems appropriate. With CSS selectors, when the business decides we need to change the "feel" of the page from "spiky" to "gentle," you might only want to change some subset of the design that was built up around the "spiky" concept, while leaving others as they are. There is not a comprehensiveness and absoluteness to the changes, and it's a lot harder to reason about "pure functions".
Add to this that CSS is like a codebase built on try/catch and throwing errors for its primary control flow mechanism, where the only thing that tames this is the naming conventions employed, and you've got a situation where the names really matter in a way that they don't when we're doing other programming, because the names are the only connective tissue to help you reason about the "control flow" once your css starts getting complex.
Add to this that CSS is like a codebase built on try/catch and throwing errors for its primary control flow mechanism, where the only thing that tames this is the naming conventions employed, and you've got a situation where the names really matter in a way that they don't when we're doing other programming, because the names are the only connective tissue to help you reason about the "control flow" once your css starts getting complex.
Naming things involves creating an ontology that makes sense. In the context of URLs, that’s an hierarchical structure of things that’s self-describing; in the context of code, it’s a direct model of the domain logic underlying the problem, at least for the most part: There’s lots of code involving "managers" and "containers" and "controllers" and "factories". That’s where it starts to get murky. Meanwhile, CSS classes require creating an ontology of things that’s both reusable, and at the same time referring to small or partial aspects of a thing, sometimes a thing that shows up in other parts of the code, sometimes as a variation, or just a one-off occurrence. If you do it properly, that means you’ll need to find a shared vocabulary for button attachments, centered max width wrappers, field hints, list items, and so on. It’s draining, because it’s not productive. The end result is just hopefully maintainable style sheets.
It's draining because you're over-complicating things. CSS is for styling HTML. So however you structure your HTML, CSS closely follows (hierarchy of components/partials). Then you consider variants. After that, parents influencing children styles. Then on top of that, you add a reset (because small browser incompatibilities) and maybe a grid utility.
[deleted]
Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.
I still don't understand how not naming things is a benefit over inline styles? With inline styles, instead of class="bg-blue" you'd write style="background-color:blue" and then you could remove an entire build step and an entire dependency because the browser already supports this.
You can override bg-blue with a more specific selector or a user stylesheet, which you cannot do with inline styles.
So you write a rule to say that blue buttons are actually yellow?
Then someone sees the code for a button which is clearly marked as blue and will be surprised it's yellow.
Then someone sees the code for a button which is clearly marked as blue and will be surprised it's yellow.
Try to imagine that was an example. There was even another response mentioning different shades of blue. Imagine one might override it locally, just for one widget. Imagine one had a style (something other than color, even) that wasn't designed to reference a CSS variable ahead of time. Imagine there's no heaven.
That; and also adjacent selectors, pseudo elements, media queries, variants, dark mode handling, state handling (hover, focus, etc.), and much more.
So you make the bg-blue style make things yellow?
No, but your designers have decided instead of cornflower blue, they want it to be aqua instead. Have fun searching for all variants of the color in your stylesheets—including CSS varsity, hex codes and rgba variants. In Tailwind, all you need to do is update the config file, and it'll apply to backgrounds, text, shadows, anything.
Well that's why we use CSS variables and any change would apply everywhere and also give us semantic information with naming like color-primary or color-surface.
[deleted]
Do you treat your JS and TS the same way, eschewing semantic clarity?
Why do you assume there's no semantic clarity?
Tailwind is made for the age of apps and components. The semantics are on component level.
Tailwind is made for the age of apps and components. The semantics are on component level.
So you can name a component, but you cannot name the styles attached to that component?
It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app.
It’s not about not being able to name all these things, it’s that it’s pointless to do so.
It’s not about not being able to name all these things, it’s that it’s pointless to do so.
You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components.
My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.
Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.
Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
> If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.
That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.
> Tailwind [is] a path to ruin.
Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.
For me, styling on the web is solved.
That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.
> Tailwind [is] a path to ruin.
Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.
For me, styling on the web is solved.
I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance.
Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
> style bundling an issue unheard of
But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
> style bundling an issue unheard of
But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
> Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
> Isnt that what scoping is for?
The one that hasn't been available in CSS until 2023?
> So you name you conponent and use selectors for styling sub components.
So how can you do that with CSS?
The one that hasn't been available in CSS until 2023?
> So you name you conponent and use selectors for styling sub components.
So how can you do that with CSS?
> So how can you do that with CSS?
The old:
That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
The old:
.card > .card-header
That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
> .card > .card-header
And we know that it never worked well. That's why BEM and many other naming strategies exist: to try and replicate scoping purely through naming discipline.
> That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
Nesting partly solves the naming and the "keep all of a component's style close together".
The other partial solution is CSS Scoping: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
And this still doesn't solve the issue of repetition where every component has to spell out the margins, the paddings, the borders, the...
And we know that it never worked well. That's why BEM and many other naming strategies exist: to try and replicate scoping purely through naming discipline.
> That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
Nesting partly solves the naming and the "keep all of a component's style close together".
The other partial solution is CSS Scoping: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
And this still doesn't solve the issue of repetition where every component has to spell out the margins, the paddings, the borders, the...
Because you honestly don't need to, and shouldn't need to.
CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years.
What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952
Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/
CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years.
What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952
Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/
What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors.
CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating.
Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating.
Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
> Also nesting is syntactic sugar, nice, but orthogonal to these discussions.
What is it with you and nesting? We were talking about scoping styles to a component.
> CSS isn’t an imperative language. It’s a declarative one.
So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years.
> Which is what Tailwind is replicating.
I fail to see the logic or, indeed, the meaning of your assertion.
What is it with you and nesting? We were talking about scoping styles to a component.
> CSS isn’t an imperative language. It’s a declarative one.
So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years.
> Which is what Tailwind is replicating.
I fail to see the logic or, indeed, the meaning of your assertion.
> What is it with you and nesting? We were talking about scoping styles to a component.
I get where you coming for. But the issue that the scoping[0] you're referring to on your other comment is something I've never encountered or heard someone complain about.
In my mental model, an element owns it subtree in terms of styling. Meaning that, if I a component can be placed either statically or dynamically, then it belongs to all the elements that may be its parent. And if it want independent styles, then I reset it at the root of the component. So I assumes, any style property that is not set at the root of any element is inherited from the parent.
No need for elaborate syntax and mechanisms that just drive up the complexity of the code.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scoping
I get where you coming for. But the issue that the scoping[0] you're referring to on your other comment is something I've never encountered or heard someone complain about.
In my mental model, an element owns it subtree in terms of styling. Meaning that, if I a component can be placed either statically or dynamically, then it belongs to all the elements that may be its parent. And if it want independent styles, then I reset it at the root of the component. So I assumes, any style property that is not set at the root of any element is inherited from the parent.
No need for elaborate syntax and mechanisms that just drive up the complexity of the code.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scoping
> But the issue that the scoping[0] you're referring to on your other comment is something I've never encountered or heard someone complain about.
Why do you think BEM exists? Or CSS-inJS? Why do you think web components exist?
All these are attempts to actually do what you claim css is already doing: to make sure that the element owns its subtree in terms of styling.
CSS is global.
> So I assumes, any style property that is not set at the root of any element is inherited from the parent.
Of course not. The hint is in the name: Cascading stylesheets. Your "owned" subtree is owned by every single element above up to and including document root.
> No need for elaborate syntax and mechanisms that just drive up the complexity of the code.
There's nothing complex about Tailwind. It actually reduces all the complexity to a set of small primitives. And since it's still CSS, you can write your own CSS as you wish.
Here's a good overview of how and why you would use it: https://piccalil.li/blog/cube-css/
Why do you think BEM exists? Or CSS-inJS? Why do you think web components exist?
All these are attempts to actually do what you claim css is already doing: to make sure that the element owns its subtree in terms of styling.
CSS is global.
> So I assumes, any style property that is not set at the root of any element is inherited from the parent.
Of course not. The hint is in the name: Cascading stylesheets. Your "owned" subtree is owned by every single element above up to and including document root.
> No need for elaborate syntax and mechanisms that just drive up the complexity of the code.
There's nothing complex about Tailwind. It actually reduces all the complexity to a set of small primitives. And since it's still CSS, you can write your own CSS as you wish.
Here's a good overview of how and why you would use it: https://piccalil.li/blog/cube-css/
> It’s a truly elegant solution for authoring web pages.
It's an ugly hack that undoes a lot of the benefits of CSS.
It's an ugly hack that undoes a lot of the benefits of CSS.
Configuration. Inline styles are direct style Implementations in your html, tailwind is an abstraction that lets your configure and refactor easily.
I can say from experience, being in charge of developing a large product that was bought and merged into a larger corporation, using tailwind from the start allowed us a refactor our app’s design within 1 day instead of it being several weeks worth of work.
And as a bonus it provides best practices in css scaffolding of a product design (typography, grid, colors)
And as a bonus it provides best practices in css scaffolding of a product design (typography, grid, colors)
So how does that work exactly?
For instance now I have class some-button to make the button blue. Next week I‘m told make them yellow.
It’s a change in one class
What would be the equivalent in Tailwind?
For instance now I have class some-button to make the button blue. Next week I‘m told make them yellow.
It’s a change in one class
What would be the equivalent in Tailwind?
It’s less about replacing blue with yellow, which means overhauling design.
My example was when your style system includes several color spectrums - primary, secondary, accent, grey, dark, light.
Your components are styled using these spectrums - button.color-primary-500.bg-grey-300
When you want to change the colors globally it’s extremely simple.
Same with paddings and margins.
Your components are styled using these spectrums - button.color-primary-500.bg-grey-300
When you want to change the colors globally it’s extremely simple.
Same with paddings and margins.
You use components, e.g. react, and replace the `bg-blue-500` class with `bg-yellow-500` in your button component.
HTML already has a button component. How is this better than creating a root CSS style for buttons using CSS variables to abstract the colors?
For this contrived example it isn't better. I was very sceptical of tailwind before I tried it, but in certain scenarios it's nice. I think it shines if you are already using a component focused development process. As others have said you don't need to come up with class names for every thing you want to style. Rather than cross-reference between js/html files and css files everything (structure, style, and interactivity) is in one place. You also don't need to care about specificity.
Personally I think it gets a bit mad when you start wanting to do :hover, :active and media queries, but you can still use classes (using the @apply directive) for that if you wish.
Personally I think it gets a bit mad when you start wanting to do :hover, :active and media queries, but you can still use classes (using the @apply directive) for that if you wish.
The root style is global to one app, the component may be used in many different apps.
But you can use CSS rules to override variable values for more specific selections. So you can define a global --primary-button-color at the root, apply it to every button, then override --primary-button-color in, say, `tool-container`.
So that's exactly the same as using the CSS style directly. The way you've described it, Tailwind provides no benefit whatsoever.
So tailwind needs to be used with some kind of library or framework and not vanilla HTML and JS?
It's possible to use with vanilla, but probably not a good experience. You want either components or at least a templating system where you can break things down into reusable parts.
It's somewhat similar to raw HTML vs something like PHP, you can have thousand of HTML files, but if you wanna change something common (say the header) it's not fun with thousands of individual files.
Lastly you can combine Tailwind with regular css classes
It's somewhat similar to raw HTML vs something like PHP, you can have thousand of HTML files, but if you wanna change something common (say the header) it's not fun with thousands of individual files.
Lastly you can combine Tailwind with regular css classes
.btn-primary {
@apply bg-blue-500 px-2 py-1;
}
mobile selectors, "group" selectors, hover styles... the list goes on and on. like all things, it depends on how your workflow. if you have a super defined hierarchy and naming scheme you can reference then sure, centralize all your CSS. if you have many components and multiple people working on them sometimes it's better to separate everything out and enforce with a guide.
i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for.
FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance.
tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.
i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for.
FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance.
tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.
The thing is, when you are doing CSS properly, you will "anchor" your selectors appropriately. What I mean is the following: Ltes say you got some "component" or whatever you want to call it, and have a button in it, that is special in some way. Of course you are not gonna write "button a {someproperty: specialvalue}". You should be writing the selector as specific for that component in this case, for example "my-special-component button a {...}". If the design is implemented thoughtfully, then most of the problems people claim to have with CSS are simply non-existent.
Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
yeah i'm just tired of making the same argument over and over. for what it's worth i've been doing CSS "properly" since the time when that site was a thing.
back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component.
the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components.
tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component.
the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components.
tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
Or you can just just ".special-component .button" selector adapting the selector to be more specific as needed. Most code reuse in CSS is bad, because they break when the design changes. You don't DRY just because the code are the same.
yeah and when you do that for 100s of components i'd rather just see a utility class on the button itself vs hunting down its meaning in the related section of the component.
this is exactly the shit i was annoyed by when scaling, having to scope a .my-component-X section for literally every component and then grokking it later. you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
now maybe you say name it better or more semantically? congrats you recreated BEM lol. literally all the arguments used against it are purists for purity sake or thinking people haven't gone through this same thought exercise.
just use whatever is best for the task. i still use css the "traditional" way.
/rant
this is exactly the shit i was annoyed by when scaling, having to scope a .my-component-X section for literally every component and then grokking it later. you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
now maybe you say name it better or more semantically? congrats you recreated BEM lol. literally all the arguments used against it are purists for purity sake or thinking people haven't gone through this same thought exercise.
just use whatever is best for the task. i still use css the "traditional" way.
/rant
Why the hyperbolic about 100s of components? Because if that exists somewhere, then it's just plain bad design to me.
Let's say you writing templates for a website and you have a partial named "main-navbar", it has a search input field that looks like the other input, but needs some alteration. Are you going to name all these alteration like "margin-x-2px", "font-small". Or just add a new style block with ".main-navbar .search-input" as the selector.
> you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
Why are you hunting it down? If I need to find the styles that are applied to an element, I just open the web inspector. More often than not, from bottom to top, it's the reset style, the component style, the variant style, and the styles derived from its relation with its parent and siblings.
With tailwind
Let's say you writing templates for a website and you have a partial named "main-navbar", it has a search input field that looks like the other input, but needs some alteration. Are you going to name all these alteration like "margin-x-2px", "font-small". Or just add a new style block with ".main-navbar .search-input" as the selector.
> you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.
Why are you hunting it down? If I need to find the styles that are applied to an element, I just open the web inspector. More often than not, from bottom to top, it's the reset style, the component style, the variant style, and the styles derived from its relation with its parent and siblings.
With tailwind
<div class="mx-auto flex max-w-sm items-center gap-x-4 rounded-xl bg-white p-6 shadow-lg outline outline-black/5 dark:bg-slate-800 dark:shadow-none dark:-outline-offset-1 dark:outline-white/10">
<img class="size-12 shrink-0" src="/img/logo.svg" alt="ChitChat Logo" />
<div>
<div class="text-xl font-medium text-black dark:text-white">ChitChat</div>
<p class="text-gray-500 dark:text-gray-400">You have a new message!</p>
</div>
</div>
<div class="alert">
<img class="alert-icon" src="/img/logo.svg" alt="ChitChat Logo" />
<div>
<div class="alert-title">ChitChat</div>
<p class="alert-message">You have a new message!</p>
</div>
</div>You don't need the classes on the alert sub-elements:
<div class="alert">
<img src="/img/logo.svg" alt="ChitChat Logo" />
<div>
<h2>ChitChat</h2>
<p>You have a new message!</p>
</div>
</div>
.alert {...}
.alert img {...}
.alert h2 {...}
.alert p {...}
I would add, that usually also I would not hunt things down, because I put styling for a navigation into a stylesheet file called "navigation.css". Not much hunting to do there. Sounds crazy, but actually works.
every page in our app is a "component" which could have many sub components, some reused. i think it's actually very common in large scale apps so maybe we're not even starting on the same foot.
would you not consider opening the web inspector "hunting down" when i can just understand the full thing just by looking at the element itself? to your example, let's say now you want to put your search bar next to another item, but that item requires that there be 4rem right margin. Then you put your search bar next to another item in another component that requires 8rem top margin. this starts breaking down at scale. in the past we would just inline the margin value. eventually this moved to basic utility classes which evolved into tailwind.
and with your code, you've just proved my point. i find tailwind overly verbose (necessary evil), but honestly i don't even need to open the "inspector" to understand how this will look. you can give me that 12 months from now and i can understand exactly what it is in 10 seconds. with "alert" i have to referencing something else. and this is just a handful of lines, imagine if your component is larger than that. it's also a bad example because i will just eventually roll the styles for "alert" into its own class if it makes sense. get the best of both worlds.
again, i challenge you to just consider that a lot of other people as smart as you have thought through these issues and made the according trade-offs. the example you're giving is just way too simplistic and pretty much like every example someone gives in these threads.
would you not consider opening the web inspector "hunting down" when i can just understand the full thing just by looking at the element itself? to your example, let's say now you want to put your search bar next to another item, but that item requires that there be 4rem right margin. Then you put your search bar next to another item in another component that requires 8rem top margin. this starts breaking down at scale. in the past we would just inline the margin value. eventually this moved to basic utility classes which evolved into tailwind.
and with your code, you've just proved my point. i find tailwind overly verbose (necessary evil), but honestly i don't even need to open the "inspector" to understand how this will look. you can give me that 12 months from now and i can understand exactly what it is in 10 seconds. with "alert" i have to referencing something else. and this is just a handful of lines, imagine if your component is larger than that. it's also a bad example because i will just eventually roll the styles for "alert" into its own class if it makes sense. get the best of both worlds.
again, i challenge you to just consider that a lot of other people as smart as you have thought through these issues and made the according trade-offs. the example you're giving is just way too simplistic and pretty much like every example someone gives in these threads.
> the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
At that point the design department of your business has failed its job. Case closed. If everything is slightly varied, then there is no coherent design. Not even my backend-dev developed "designs" are that bad.
> tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
I also care about what soup I deliver to any visiting browser. So I care about not having a thousand repeated inline styles, that make it harder to write user CSS for example. Visitors of my site can very easily adapt the styling, by simply changing the styling of 1 class or even 1 CSS variable that I defined in a theme.css.
But you are also making a general mistake. You are letting perfect be the enemy of good. Even if one only succeeds 90% at what I described, this is still great and simple to maintain in 90% of the cases. I doubt tailwind is a big win over that.
At that point the design department of your business has failed its job. Case closed. If everything is slightly varied, then there is no coherent design. Not even my backend-dev developed "designs" are that bad.
> tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
I also care about what soup I deliver to any visiting browser. So I care about not having a thousand repeated inline styles, that make it harder to write user CSS for example. Visitors of my site can very easily adapt the styling, by simply changing the styling of 1 class or even 1 CSS variable that I defined in a theme.css.
But you are also making a general mistake. You are letting perfect be the enemy of good. Even if one only succeeds 90% at what I described, this is still great and simple to maintain in 90% of the cases. I doubt tailwind is a big win over that.
you know, maybe understand actual frontend dev issues more deeply before arguing against toolsets you are unfamiliar with. none of your suggestions/generalizations actually address my actual real world issues and rather they are non-issues in modern dev.
the type of apps i'm talking about aren't just a "theme.css", so whatever mythical large app you're talking about that adheres to this rigid css standard while being easy to maintain i'm ready to be proven wrong lol.
the type of apps i'm talking about aren't just a "theme.css", so whatever mythical large app you're talking about that adheres to this rigid css standard while being easy to maintain i'm ready to be proven wrong lol.
[deleted]
[deleted]
Tailwind makes things like dark mode and group hover/focus states dead simple with modifiers (dark:, group-hover:), keeping all your logic in your HTML. With inline CSS, you’d need messy JS, extra classes, or bloated style tags to handle the same.
It also enforces a design system (spacing, colors, fonts), while inline CSS often leads to small, inconsistent differences everywhere.
It’s a great solution to a problem a lot of people were having. That’s why it’s so popular.
It also enforces a design system (spacing, colors, fonts), while inline CSS often leads to small, inconsistent differences everywhere.
It’s a great solution to a problem a lot of people were having. That’s why it’s so popular.
media and container queries. Pseudo selectors
Even on one element you can combine tailwind classes. With styles you need to write out the final result.
Then you can also use @apply if you wish but leave that out of the argument as it is considered unidiomatic.
Of course if using React you can also use styles directly and then create your own utilities to determine how they compose. Which might give you much of the Tailwind edge without needing the compile step.
Then you can also use @apply if you wish but leave that out of the argument as it is considered unidiomatic.
Of course if using React you can also use styles directly and then create your own utilities to determine how they compose. Which might give you much of the Tailwind edge without needing the compile step.
Even on one element you can combine CSS classes. Easily.
They published a book that I purchased when I was first learning CSS. Truly a different era.
This site had huge effect on me back in the day!
For those who don't know: for the same html content you could submit a design in CSS and images. For example these impressed me the most:
- https://csszengarden.com/202/
- https://csszengarden.com/189/
- https://csszengarden.com/177/
- https://csszengarden.com/136/
- https://csszengarden.com/206/
There was also one which had a position: fixed knife "cutting the page from the middle" when you scrolled, but it doesn't seem to be on the list anymore. Edit: and another one I remember was like so that the top of the page is sea level and you'd scroll to the bottom of the sea, where there was either an octopus, a submarine or a diver, can't remember.
For those who don't know: for the same html content you could submit a design in CSS and images. For example these impressed me the most:
- https://csszengarden.com/202/
- https://csszengarden.com/189/
- https://csszengarden.com/177/
- https://csszengarden.com/136/
- https://csszengarden.com/206/
There was also one which had a position: fixed knife "cutting the page from the middle" when you scrolled, but it doesn't seem to be on the list anymore. Edit: and another one I remember was like so that the top of the page is sea level and you'd scroll to the bottom of the sea, where there was either an octopus, a submarine or a diver, can't remember.
Same. Those designs just remind me how boring web design has become.
I had two designs there and to this day, I get emails from people seeking permission to reuse the CSS.
So happy to see CSS Zen Garden on HN today! Those were the days!
But I've also got to rant now.
What I find most troubling about Tailwind and CSS "frameworks" like it (and modern software development in general) is the growing pride in not understanding the underlying systems.
Tailwind offers a quick, surface-level solution: you can slap some utility classes onto a page and get something that looks "good enough" without ever learning how CSS actually works. Nevermind that the HTML is now a mess where you've got more CSS classes than content!
The attitude is, "Who cares how it works? I got my pretty page. That's a win!"
But this isn't just a Tailwind problem. It's part of a larger trend in the industry: celebrating ignorance, rushing for results without building real understanding.
When did not knowing become something to be proud of? Isn't it sad that depth and mastery are now treated as optional, even undesirable?
/rant
But I've also got to rant now.
What I find most troubling about Tailwind and CSS "frameworks" like it (and modern software development in general) is the growing pride in not understanding the underlying systems.
Tailwind offers a quick, surface-level solution: you can slap some utility classes onto a page and get something that looks "good enough" without ever learning how CSS actually works. Nevermind that the HTML is now a mess where you've got more CSS classes than content!
The attitude is, "Who cares how it works? I got my pretty page. That's a win!"
But this isn't just a Tailwind problem. It's part of a larger trend in the industry: celebrating ignorance, rushing for results without building real understanding.
When did not knowing become something to be proud of? Isn't it sad that depth and mastery are now treated as optional, even undesirable?
/rant
> Nevermind that the HTML is now a mess where you've got more CSS classes than content!
It shocks me how bad most HTML is. I just had a look at Twitter, and a single post in my timeline (a paragraph of text, an image, and ~10 linked icons) was 254 lines and 21.8 kB for just the HTML, and had 104 nested divs and 860+ classes!
That's more classes than characters of text content. About 9 kB of class names alone. And that is then repeated for every post in the timeline.
It should be a few divs max, a couple of classes (+ one for each icon), and a few lines of CSS. Seriously. You could style every post in the timeline with fewer characters than in the class names on one single post.
I don't understand how professional developers can make something so obscenely bloated.
It shocks me how bad most HTML is. I just had a look at Twitter, and a single post in my timeline (a paragraph of text, an image, and ~10 linked icons) was 254 lines and 21.8 kB for just the HTML, and had 104 nested divs and 860+ classes!
That's more classes than characters of text content. About 9 kB of class names alone. And that is then repeated for every post in the timeline.
It should be a few divs max, a couple of classes (+ one for each icon), and a few lines of CSS. Seriously. You could style every post in the timeline with fewer characters than in the class names on one single post.
I don't understand how professional developers can make something so obscenely bloated.
Software development is a layering of abstractions over time. How's your assembly?
How's your Electron app's performance?
It's very concerning when software developers neglect that their tools (abstractions) have tradeoffs.
"If civil engineers built bridges the way software engineers build applications, the bridges would all fall down in a month".
And similar sentiments. Granted, most things aren't mission-critical, but then just because my house won't collapse doesn't mean I want to waste money on poor insulation and broken appliances.
It's very concerning when software developers neglect that their tools (abstractions) have tradeoffs.
"If civil engineers built bridges the way software engineers build applications, the bridges would all fall down in a month".
And similar sentiments. Granted, most things aren't mission-critical, but then just because my house won't collapse doesn't mean I want to waste money on poor insulation and broken appliances.
I get the idea, but don't think that's the case for Tailwind. Tailwind classes map directly to CSS properties, you can't really do much with it if you don't understand CSS
Are you sure? Could it be confirmation bias because you do understand the CSS?
From what I've seen across multiple teams, it's very common for developers to just slap Tailwind onto their project, copy-paste classes they found online and call it "done." Maintainability and reusability are treated as someone else's problem.
From what I've seen across multiple teams, it's very common for developers to just slap Tailwind onto their project, copy-paste classes they found online and call it "done." Maintainability and reusability are treated as someone else's problem.
Copy-pasting code and calling it done isn't limited to Tailwind though.
Blast from the past... I loved the CSS Zen Garden but it's goals and philosophy were oriented to a world where the primary purpose of a website was to serve documents. Our rich media world sort of left this vision of the web in the dust sometime in the mid 2000s.
I wouldn't say it's rich media, but the conversion of the web to be 100% marketing-driven. It's ads all the way down.
That’s a serious downgrade.
https://blog.danieljanus.pl/2019/10/07/web-of-documents/
https://blog.danieljanus.pl/2019/10/07/web-of-documents/
"a world where the primary purpose of a website was to serve documents"
we are still living in this world. and i don't mean it snarkily. beside some maps application, most of the web is still about reading stuff, and it doesn't need so much cruft. it's getting more complex just because developers prefer complexity over simplicity.
we are still living in this world. and i don't mean it snarkily. beside some maps application, most of the web is still about reading stuff, and it doesn't need so much cruft. it's getting more complex just because developers prefer complexity over simplicity.
De facto it's a web app, not a document, world. Have you tried browsing without JavaScript recently? It's even worse in this AI era when content sites want proof of work, only available via JavaScript.
Is "modern media" really rich? I think information density and signal-noise actually degrades
Glad to see the Garden is back! This and Spoono were some of my favorite websites back when CSS-driven web design was bleeding edge and people were just starting to use lots of nested divs instead of lots of nested tables. The book was nice too.
The idea of CSS Zen Garden, that was: to show that you can produce server side simple and semantic HTML, and CSS will be enough to do the rest for the presentation of the content, was an incredible innovation of 200x that was totally forgotten, and that now, younger generation of programmers that grown up with big web frameworks no longer "get". They see CSS as something complex and impossible to handle, exactly because of what modern HTML is (because of such frameworks), without realizing that this is indeed the same problem: that modern web sucks, not that CSS sucks.
What changed was that “web 2.0” happened. Web design’s focus changed from documents to applications.
CSS Zen Garden was about styling “web 1.0” HTML documents.
But dynamic UIs have completely different styling needs. People started building JavaScript applications, and they started needing UI layouts similar to those provided by desktop UI frameworks. And CSS was never designed for that. Concepts like “float” were entirely derived from the word processor universe. CSS had to add several complex new layout engines over the following decades.
CSS Zen Garden was about styling “web 1.0” HTML documents.
But dynamic UIs have completely different styling needs. People started building JavaScript applications, and they started needing UI layouts similar to those provided by desktop UI frameworks. And CSS was never designed for that. Concepts like “float” were entirely derived from the word processor universe. CSS had to add several complex new layout engines over the following decades.
In the age of spaghetti-mixed Web Components, remember kids you can still be good with yourselves and properly split your Web Apps into individual CSS, JS, and HTML templates files, even going framework-less.
Keep the Zen Torch on.
Keep the Zen Torch on.
Loved the site and the companion book. Borrowed it at my local library and kept renewing it. Taught me CSS, coming out of hacking CSS with all the weird tricks at that time, and made me realize that you _can_ make beautiful semantic websites without the crazy hacks.
An oldie but goodie. This was my first exposure to CSS and the foundation for the years I taught web design to low-income high schoolers. We would all go to an end-of-the-year web design competition at the local community college. The kids would have to explain CSS to the judges because they had no idea. :)
Many students walked away winning desktop computers (available due to computer lab upgrades). Probably the proudest accomplishments of my career.
If I remember right, I actually sent a few questions to Dave Shea, Eric Meyer, Andy Budd, etc and they replied with help. Forever grateful.
Many students walked away winning desktop computers (available due to computer lab upgrades). Probably the proudest accomplishments of my career.
If I remember right, I actually sent a few questions to Dave Shea, Eric Meyer, Andy Budd, etc and they replied with help. Forever grateful.
There was a book by Dave Shea and Molly Holzschlag called "The zen of CSS design" that explained some of the tricks of the most amazing themes. On my last cleaning I let go of a lot of now obsolete books but that book remains, it's so beautiful!
i wrote my own version where you can edit the CSS live and see it update :)
https://svelte-zengarden.netlify.app/
(click and drag on the writing hand emoji)
https://svelte-zengarden.netlify.app/
(click and drag on the writing hand emoji)
> Bandwidth graciously donated by mediatemple
I wonder what year this last was true.
I wonder what year this last was true.
"Everything you love about Media Temple is now at GoDaddy."
Oh lord..
How far back will the Time Machine go today in this thread?
Oh lord..
How far back will the Time Machine go today in this thread?
Did anyone ever do a good post-action write-up of how if you actually use the CSS Zen Garden technique for something which isn't a fixed target for demoing the power of CSS and the creativity of those who wield it, you end up with both HTML and CSS everyone is afraid to touch?
When multiple different CSS layouts depend _deeply_ on the specific structure of the markup and the markup _needs_ to change over time, at the least you're in for pain, and at the most you're hosed/rewriting.
When multiple different CSS layouts depend _deeply_ on the specific structure of the markup and the markup _needs_ to change over time, at the least you're in for pain, and at the most you're hosed/rewriting.
I disagree. Most websites are a "fixed target". Creating markup that clearly reflects this and then styling that isn't hard.
Maintaining CSS is easier than picking through markup trying to catch all the class names, especially if you use a preprocessor with nesting.
Admittedly in my professional experience, CSS-only refreshes are rare, but in my case only because it's been more common to change the content at the same time.
Maintaining CSS is easier than picking through markup trying to catch all the class names, especially if you use a preprocessor with nesting.
Admittedly in my professional experience, CSS-only refreshes are rare, but in my case only because it's been more common to change the content at the same time.
The structure of the markup is dependent on the semantic structure of the content that is marked up. The CSS is styling that structure.
The markup shouldn't need to change over time in a way that makes the CSS layouts not work because it just reflects the semantic structure of the document, which shouldn't really need to change. If it does you have quite a different document and so of course it will need CSS changes too.
I was always much more afraid of touching ad-hoc CSS that was written alongside HTML, because it ends up having all these classes and elements that have no semantics and it becomes very unclear what anything actually means. The very worst is the "tailwind" styling where classes etc mean nothing, just styling.
The markup shouldn't need to change over time in a way that makes the CSS layouts not work because it just reflects the semantic structure of the document, which shouldn't really need to change. If it does you have quite a different document and so of course it will need CSS changes too.
I was always much more afraid of touching ad-hoc CSS that was written alongside HTML, because it ends up having all these classes and elements that have no semantics and it becomes very unclear what anything actually means. The very worst is the "tailwind" styling where classes etc mean nothing, just styling.
CSS Zen Garden is the good old days of web when people cared.
Now server side rendering is all the rage again, maybe we will also see a comeback of semantic html and simple stylesheets.
Now server side rendering is all the rage again, maybe we will also see a comeback of semantic html and simple stylesheets.
When I first heard of CSS in a brief discussion, background-repeat and background-position felt like liberation and magic, but also as a strange thing intruding into HTML, as techniques specific to HTML had become tradition, like layout using tables and the 1-pixel gif method to create borders.
Then, later, CSS Zen Garden was very impressive to me, given my limited understanding of CSS.
Then, later, CSS Zen Garden was very impressive to me, given my limited understanding of CSS.
Wow! Haven't seen this since the slashdot days.
Love this!
Would be cool if somebody did a css zen garden 2.0 using modern CSS tools.
Oh and tailwind css is not aloud lol
I wasn’t sure how good CSS was and whether it would be good for layouts and such. Then I found the CSS Garden and it was the shining light that made me understand its power.
Similarly, it was ExtJS that made me realise that web sites could be just as good as desktop apps.
Similarly, it was ExtJS that made me realise that web sites could be just as good as desktop apps.
CSS Zen Garden was the site that helped me to learn about the wonders of CSS.
++1
One of the best websites back then, id guess even today?
it was enlightening to work through this book, i even got a hardcopy of it from the local library while being a student
One of the best websites back then, id guess even today?
it was enlightening to work through this book, i even got a hardcopy of it from the local library while being a student
[deleted]
Before CSS, layouts were implemented by abusing table elements to create a grid. Then images were sliced up into sections, and each section was placed into the table. This has generally been remembered in the present day, however what seems to have been forgotten was the pushback against CSS.
There was a large number of web developers who were happy with the status quo and refused to learn CSS. One of the most persistent myths was that you couldn’t make anything look nice with CSS. Specifically, CSS was accused of only being able to create “boring, boxy” designs.
It wasn’t true at all. Even back in the early days of CSS, you could create great layouts. It was especially absurd because the approach favoured by the people saying this was literally abusing tables to create grids.
So along comes Dave Shea and points out that this is ridiculous, that CSS is capable of great designs, and puts the CSS Zen Garden up. A whole bunch of people contribute good-looking designs and make it impossible for people to claim that “CSS can only produce boring, boxy designs”. I think it’s amusing that he won the argument so conclusively that people forget it was even an argument in the first place.