[ralusek]

I always thought this was funny. This was the embodiment of the original CSS philosophy, which was to "label your html elements semantically with what they ARE, and then worry about styling those in the CSS." The whole point was to get anything style related out of the HTML altogether, the HTML would just be semantic/content related.

But then Bootstrap and other CSS libraries came out, and completely inverted the philosophy back to what HTML originally looked like pre-CSS, which is that you had all of these rules you could place directly in the HTML that would directly control how the element was styled. In CSS Zen era you could look at my HTML and have no idea how I intended it to LOOK, whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.

Now people just make components and will maybe use style variables/tokens. Just funny how things change.

[jacurtis]

The ultimate anti-pattern of this philosophy is Tailwind.css (the newest, "coolest" css framework). Not trying to hate on it, but I find it ironic that the whole point of Tailwind is that you can basically style your entire website within the HTML, without needing to customize it with CSS.

For someone who learned CSS during the CSS Zen Garden era where we were told to only use the HTML document for structure and never style, it makes Tailwind cringe-worthy.

Yes, I know lots of people customize it and stuff, but the idea still stands that 95% of styles are done within the HTML document through tens of thousands of ultra-specific css classes which basically just tweak a single css property.

[rvense]

I also grew up in the CSS Zen Garden era, and I've become a big Tailwind proponent.

To me what is cringe-worthy is hanging on to ideas about what this medium is that just no longer apply. For better or worse, the web stack has been appropriated into an application framework. I am not making documents that have styles applied to them. It's just not a metaphor that works anymore.

The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always.

Tailwind, to me, solves a bunch of very real ergonomic issues when working with large web applications, and results in far clearer code.

[Benjammer]

>The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way

This is orthogonal to the issue. It's still possible to separate the functional layers of a website or application, even if the entire stack is JS or whatever.

I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.

[dasil003]

SPAs don't invalidate the concept of separating structure and styling, but as with all technical architecture decisions there are tradeoffs. Whenever you add another layer you are paying some base overhead cost with the goal that each individual layer ends up simpler. Whether or not this is a net win depends largely on the interface between the layers (see also: microservice trainwrecks). Content and style is tightly coupled and application-dependent, so abstract principles that sound good may make zero sense in a particular use case depending on a whole slew of technical and operational concerns about how the markup and CSS are generated and served.

In the old days, website were primarily documents, and as browser formatting grew more sophisticated the ratio of content to styling markup grew lower and lower, and when you're formatting simple documents the amount of redundant styling is very very high. Because HTML was designed with a small number of elements that provide pretty good coverage over basic documents, and because most documents were created by hand, the original CSS design and philosophy behind CSS Zen Garden was an absolute slam dunk for content creators of the era. The assumption is a small amount of CSS covers styling for a huge library of markup documents, minimizing overall code size.

As web apps evolved to be more dynamic, first with bits of AJAX and then graduating into full SPA with more and more functionality ported to client-side APIs, we found the semantics of HTML which were tied to more universal concepts of written documents (heading, paragraph, list, quote, etc) did not cover the semantic needs of describing UI widgets. At this point CSS is still useful but the optimal structure is not as obvious. Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis".

This fundamental problem was attacked from many different angles, lots of code generation, web components, OOCSS, BEM, Sass, etc. I consider Nicole Sullivan's work in this area to be seminal, leading to the optimal approaches large web products use at scale, and directly informing the design of React and modern SPA approaches. The reason Webpack processes markup, css and javascript all together is because things are so tightly coupled in practice, that you need tooling to optimize overall code structure and legibility. Purist approaches don't work very well for large projects because HTML & CSS were not designed to build GUIs.

[Benjammer]

>Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis".

Really, only two approaches are viable? There's no middle ground here? What would be the point of highlighting the extremes?

It's as if the entire tech industry has lost the ability to tell a designer to sit down and come up with a basic typography set and color palette even. Obviously you can't just create the entire style sheet set in one pass, but can't there be an iterative approach rather than throwing the entire thing out and building giant systems just to let picky designers pointlessly tweak small pieces of the application, in isolation?

What does a complex, "dynamic" widget have to do with not using standardized typography and colors in your application? Once you start there, can't you just evolve the styles to meet product needs? It just seems to me that 99% of the time, the point where it's decided that this whole thing should be thrown out, is almost always the point where someone wants to put "built a component system" on their resume...

Another grey area:

>create very specific markup for each UI element

vs.

>create UI-oriented classes

There's another middle ground here where you just have really big CSS selectors, and many things share styles, while still pointing to structure-oriented html classes. Can you achieve a middle ground better than individual styling, without resorting to UI-classes?

[dasil003]

That's exactly my point, the two extreme approaches are on a continuum, and the interface between the two is very tightly coupled, leading to the optimal approach for a typical SPA being very different from the approach being touted in the Zen Garden era.

[z3t4]

Can you give an example where CSS is duplicated?

div's should be avoided. Use semantic elements instead! If you absolutely need them you should consider making a custom element instead. (with it's own base CSS).

[rvense]

> I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.

It does not. But using utility-first frameworks like Tailwind doesn't mean you're not separating things. It just means you're not separating things in CSS files. You have the Tailwind setup (which allows you to customize colours, spacings, etc.) and the functionality of whatever component framework you're using. The point is that in the context of SPAs, "styling" (visual presentation) is not limited to CSS.

[rglullis]

This seems backwards. Desktop/GUI application developers have separate layout/theming engines and you don't see them asking for theming frameworks to be intertwined with components properties.

[lallysingh]

> The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always.

I've heard different forms of this argument for decades in dozens of systems. Same old "why pay for abstraction" argument. I'm not going to answer. Either you figure out the answer or you don't.

[rvense]

I'm not saying you shouldn't make abstractions. I'm saying that Tailwind (in the context of a SPA framework) makes for better abstractions than traditional CSS.

[Wowfunhappy]

> I am not making documents that have styles applied to them. It's just not a metaphor that works anymore.

And xml-based markup was just never a good format for that. The concept lives on in markdown, and in CMSs like WordPress, where an author creates content in a common format that is styled based on site- and page-specific rules

No one wants to write in html. If you’re working in html directly, it’s probably because you’re building something more complicated.

(If any of those assumptions are wrong, tell me! I’d love to hear a counterargument on why pure html is a great format for producing content!)

[moron4hire]

Maybe for 80% of people, it doesn't matter that your HTML isn't semantic, but for the 20% of other people who have need for accessibility features, that's basically the same size as the entire market of web browsers not named "Google Chrome".

[allover]

You are conflating unrelated things.

Using a framework like tailwind does _not_ affect whether your actual HTML elements are semantic, which is what would affect accessibility.

[leppr]

That arbitrary separation never made sense, when HTML always harbored presentation information. From controlling the cascading of styles to spatial layout, your HTML and CSS are tied.

The separation of concern that actually makes sense, and on which we ended up, is structured data (JSON) piped into a presentation layer (SPA lib like React). That's what XML tried to do before it became gimped as HTML.

[uk_programmer]

Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document.

If you look at other document writing system such as LaTeX. You will see that there are Sections, SubSections etc.

The link to the CSS simply told the browser how these should be presented. LaTeX has something similar as you can create a document class and Word has different styles you can import.

Having a concept of a document structure with a set of styles attached which you can change easily is a good idea.

The HTML document should make sense without a style sheet and if you write/generate semantic markup it does work properly.

[olalonde]

> Not at least with HTML 4 and XHTML. HTML didn't harbour presentation information. It told the browser the structure of the document.

I disagree. Unlike JSON which is truly presentation agnostic, the position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around. Despite the popular claim to the contrary, HTML was always part of the presentation layer.

[rglullis]

> position of the HTML elements always did affect the layout and some designs were pretty much impossible to achieve without having to move HTML elements around

The results you see on CSS Zen Garden show that this is not true at all. It was hard, but not impossible then and nowadays grid layout and CSS3 fixed a lot of the issues.

[qes]

> It was hard, but not impossible

Oh great let me get right on that. Wait, no, I have far more important things to do with my time.

[thinkloop]

To achieve that tho you need a ton of superfluous non-semantic html wrapping everything in triple so that you have the flexibility to do what you need.

[uk_programmer]

At the time CSS wasn't as feature rich as it was today. The problem was a lot of the time the designs didn't respect the medium at all. There were even designs that were impossible. The technology was being pushed to do stuff it wasn't really supposed to do.

You are complaining about the wrong thing.

> Despite the popular claim to the contrary, HTML was always part of the presentation layer.

Not at all. It is document format. Designs that do not respect that doesn't change it's intrinsic nature.

This is like complaining that a shoe isn't a very good mallet.

[olalonde]

Apart from the false dichotomy (the fact that HTML is a document format and that its structure plays an important role in browser layout are both true), I totally agree with you. HTML was indeed never meant for that but it was often sold as such by evangelists, hence the last remark (I wasn't complaining about HTML).

[Silhouette]

HTML didn't harbour presentation information.

That's not entirely true. Even ignoring the elements that were explicitly about formatting and have since been deprecated, the order and nesting of elements could have a profound effect.

For example, the entire model for how to do layout using CSS floats fundamentally depended on the order of elements in the source HTML document. It wasn't until much later that CSS finally added tools like flexbox and grid where you could explicitly reorder the content from multiple source elements in the rendered output using CSS alone.

Even today, certain effects such as column-based formatting for a table are much easier to specify in CSS if your HTML has additional elements such as <colgroup> included, yet there is little reason to include such elements in the markup except to support that kind of formatting.

[uk_programmer]

What you are talking about is the still part of the document and the document structure. Generally where writing something you will have a beginning, a middle and and end of a document. You will have parts of a document that will have lists, tables etc. These are structural elements. You can look at the markup itself (if done semantically) and you will be able to ascertain its meaning.

Yes a table will need to have the correct elements in the right order. This isn’t presentational it is semantic.

HTML5 does this better than HTML 4 as it has more semantic elements as a response to the more complicated layouts of modern web pages.

[LordOfWolves]

Enjoyed reading your POV on this. Thanks for sharing.

[skellera]

Sure you could do everything on the HTML with Tailwind but they do recommend composing component classes for regularly used things. I’m not saying that solves all your concerns but it helps.

Abstracting out CSS into utility classes can make it much quicker to get a consistent looking site up while still giving you a little more control over the look and feel. Of course you can misuse this but I think people who don’t understand standard CSS make a much bigger mess of it than if they have something like Tailwind.

[ivanhoe]

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

[keithnz]

Checkout Adams (tailwinds author) reasoning

https://adamwathan.me/css-utility-classes-and-separation-of-...

[inopinatus]

I’ve followed a similar path but since become a huge fan of Tailwind’s compositional style. It refactors style at the point of HTML generation, which in this component oriented era makes a ton of sense.

CSS was explicitly designed not to be Turing complete. Had DSSSL been the choice twenty years ago, we might not be constantly twisting in the wind for a better paradigm.

[iimblack]

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

[ARussell]

You absolutely could. But most don't, because, as has already been mentioned in this thread, and explained by Adam Watham himself(1), it's not usually the appropriate thing to do. Components are usually a better abstraction than CSS classes.

1: https://adamwathan.me/css-utility-classes-and-separation-of-...

[adamlett]

The gospel of separating styling from content comes from an era when most web sites were comprised of collections of hand crafted HTML documents, when it was a pain to make site wide changes to styling because it meant updating each of these documents by hand.

These days web sites are mostly comprised of HTML pages rendered on the fly by some type of web app which composes pages from nested templates injected with content from a database. In this scenario separating the styling from the markup gains us little, because to change the styling site wide you only have to update a few templates, not every single page that uses these templates.

[Ayesh]

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

[jfengel]

Unfortunately, prototypes are rarely thrown away. Prototypes become production code, because code that works is usually more important than code that's clean. Cleanliness comes with refactoring.

And that's actually OK, most of the time. In some situations you have to be certain you get it right the first time, but the web encourages you to try, deploy, and fix later. It's messy and has long-term debt, but a lot of that debt rarely comes due. You might just be the one holding it when the bill comes in, and that's no fun, but people do this because on the whole the amortized cost is less.

Just don't fool yourself into thinking that this is just the prototype. Unless you have specifically allocated resources to throwing it out and starting over, acknowledge from the beginning that this is going to be production code. That way you make fewer of those "Oh, well, it's a prototype" decisions. Not zero, just fewer.

[allover]

In the context of Tailwind though, the situation isn't really "that".

Tailwind allows you to "feel" like you're just quickly prototyping, without afaict compromising maintainability at all.

If you're concerned about the ability to reuse an HTML fragment and associated styles (or just a bunch of styles), they have decent docs on that: https://tailwindcss.com/docs/extracting-components/

[JJMcJ]

> prototypes are rarely thrown away

Fred Brooks' admonition to plan to throw one away almost never happens. Instead more and more features are force fit onto the prototype.

For CSS/HTML, speaking of Fred Brooks, this is an essential complexity, the tension between style and content.

[williamdclt]

Because it was "the whole point" doesn't mean that it was a "good idea", especially when the web changed so much since then.

It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes?

I find the approach by Bootstrap (or better, Tailwind) much easier to work with: compose utility classes to make up higher-level components. It still require some encapsulation of these higher-order components (with a Web Component, React Component or even just a class with @apply), but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around. Ultimately I code faster with less bugs and easier maintainance: I take it as a subjectively better approach.

[uk_programmer]

> It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes?

If the markup is done properly in the first place. It is incredibly easy to restyle and you typically don't to rework much markup. It just ends up working.

> but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around.

I have seen no evidence of this in practice. This is only true if you design is basically a skin of these frameworks. If you have anything remotely custom you end up overriding so much you might have well just started with a normalise/reset style-sheet. So for some internal application that never seen on the outside, you can use bootstrap and slap something together quick sure. However if you are actually building something with a unique it just doesn't really work.

If you think about what you are doing instead of just jumping in and coding. You can break stuff down properly without the need for hundreds of classes that typically come with these CSS frameworks. You do end up with clean CSS and the markup is clean and you do have less code.

By doing things properly i.e. you markup and css is correct. You have less cross browser bugs. I end up in my current being asked by a coworker to pick up IE bugs (yes we still support IE9 upwards). Only 10% of the fixes are actually problems with IE. 90% of the problems are correcting the markup (making it valid) and cleaning up the CSS and it just works cross browser. Sure you will have to work around things like you don't have flexbox and other niceties and you have to use an alternative style-sheet. But fixing the markup normally gets it from "not rendering properly at all" to "rendering only slightly wrong".

[ratww]

> I have seen no evidence of this in practice. This is only true if you design is basically a skin of these frameworks. If you have anything remotely custom you end up overriding so much you might have well just started with a normalise/reset style-sheet. So for some internal application that never seen on the outside, you can use bootstrap and slap something together quick sure. However if you are actually building something with a unique it just doesn't really work.

I had the opposite experience. I've build a few projects with Tachyons and Tailwind, and I rarely have to create custom CSS. In one of the largest ones (that actually had a 100% custom UI toolkit with over 40 widgets) we only had about 120 lines of custom CSS, pretty much just overriding colors and adding some utility classes for animations, custom drop shadows and some weird hover states.

The reason we need so little extra CSS that is that those frameworks use the same defaults that designers use: everything is a multiplier of 4px/8px, font sizes are proportional, and it follows design principles. Actually, if you work with a designer chances are most of your CSS is already very repetitive, because designers love patterns.

[uk_programmer]

I've heard all this before. I am extremely sceptical and tbh I wouldn't want to build a site this way at all.

It goes against what CSS was supposed to do and generally the results are IMO hard to work with because you have the overhead of having to learn how the framework works rather than just using the fundamental principles of what you are working with. Also the markup is horrendous to read.

With modern CSS you are given so much control. Your style-sheets aren't complicated anyway.

[mellow2020]

I agree. I like CSS, and I don't like anything the frameworks offer, they're just the worst of all possible worlds: a LOT of CSS (it's not just the "custom CSS" that counts, from the perspective of the browser even off-the-shelf Bootstrap is 100% custom), with no aesthetic pleasure to show for it.

But that's for my own projects I work on as a single dev, in a team I might not mind as much. For something corporate, unless it's a corporation I can really get behind, I will not care at all, because I know it'll be thrown away soon. Let's make it bland then, I don't mind. But for my own things, it's not even a consideration.. I don't even start with a reset stylesheet, I start with a blank file, and I enjoy thinking up the overall structure just as much as I enjoy tweaking values here and there, and I still like things I made over 10 years ago. Care for the little things always ends up showing, somehow.

[dsego]

If you look at some talks on ideas behind oocss you can understand that a lot of elements share similar styles. It's all boxes in the end. There is this one talk about refactoring a huge pile of css into a small number of reusable visual styles, I think it was for facebook. The semantics of an element might be a comment box, but visually it's a box with a shadow and a chat box or sidebar might share the same look, thereby it would make sense to assign them the same class (classes are intended for extracting common visual styles). Doing styles the zen garden way was usually done via long selectors to target the elements and you would end up with css code that is tightly coupled to your markup. Moving html sections would cause the styles to break. Using strictly visual styles (ie functional classes) makes it easier to distinguish the style aspect from the content and HTML is already a presentational medium.

[saagarjha]

> classes are intended for extracting common visual styles

No, they’re intended to group together semantically similar elements. There’s no reason that a blue button and a blue link should be related–what if I want to make the button red later?

[sbergot]

What about a classes like primary-color, secondary-color, danger-color & success-color?

Having two elements share the same color creates a relation between the two elements. If you have decided to use the same color for both elements it is probably because this color has a specific meaning. If the color of one of the elements changes it is probably a good idea to also change the other element.

[saagarjha]

That sounds like an excellent use case for CSS variables.

[dsego]

Those were not supported across all browsers for a long time (recently IE11). Also, a variable only covers one property and is not adequate to extract many shared properties. Less/sass mixins and inheritance are a good way to extract reusable parts shared between components.

[uk_programmer]

If you call things what they are it works out better e.g. a class for a call to action class="btn-cta". Want a large call to action button class="btn-cta btn-large" or similar.

I really should write something on forgotten simpler CSS / JavaScript techniques.

[justanotherc]

This is exactly what Bootstrap does...

[uk_programmer]

Kind of and kind of doesn’t. I am saying you should call stuff what it is. So a larger component maybe (this comment text box for example) the styling that belongs to that should all be grouped logically together. The easiest way to do this is have a element with a class attached called comment text box.

Bootstrap does this on some components but it has loads of positional bits and pieces mixed. Also the components are fairly generic.

[crispyambulance]

> ...in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.

Part of the blame for this has to fall onto the lap of CSS itself.

Up until CSS-grid it has been too damn hard to get layout to "just freaking work" with CSS.

To be fair, it was even more of a dumpster fire back in the early naughts when almost everyone just used HTML tables to do their layouts. The folks behind CSS should have caught on at that time and focused on making layout better and eliminate thousands of person-years of frontend people grinding their gears... BUT NO, not until 2018-ish did we get CSS-grid.

[pjmlp]

And ironically CSS-grid was born as part of WPF's Grid component.

[crispyambulance]

Not surprising at all. The desktop application world has long enjoyed relatively fuss-free layouts. Java swing had nice layout mechanisms too. MIG-layout comes to mind.

[thomascgalvin]

I've seen people seriously recommend marking up your document like this:

  <div style="display: table;">
    <div style="display: table-row;">
      <div style="display: table-cell;">
      </div>
    </div>
  </div>

How in the nine fires of hell is that better than just using a table?

[runawaybottle]

Once upon a time every website layout was defined via the Table element. Your side bar would be a cell spanning multiple rows, and inside the sidebar you’d have another nested table that defined more layout. The shift to table-less divs came almost as a massive over-correction to the abuse of nested tables.

We are in similar egregious territory now days with how we’re doing styled components directly in the javascript and totally forgoing some of the principles of CSS (we are effectively in-lining styles , for everything). That’s alright, we go through this upending in frontend every 3 years anyway.

[deckard1]

It's a bit worse than that, even. Instead of the abuse of semantic elements, you don't have semantic elements at all. It's a giant mess of div tags. We've 100% given up on accessibility on the web. We've also thrown in the towel on device-agnostic HTML as well. For all of the grand plans of the '90s and W3C, they all failed. Every. Single. One. This includes CSS, which is an abomination.

If that weren't bad enough, let's discuss the fundamental core of the web: links.

Links are dead. They are buried under a mountain of SPA walled garden jank, teased at (but never granted) on Pinterest or Quora or LinkedIn or Facebook, or out there scamming users with shortened URL services. Corporate users are subjected to annual security training lessons where they are taught never to trust links (email, text message, or otherwise) because the alternative, training users to understand domain names, is just so impractical that we have all given up. Google gave up, with Chrome. They don't even want to show a domain. It's that bad and awful.

To give you an example of how shit it all really is, I recently had to look up an issue related to a Microsoft product. A quick Google search lead me to a number of Stackoverflow and blog posts on the issue. I found a number of links, pointing to Microsoft's bug tracker (links from just a year or two ago). And here's the kicker: all the links 404. The bug tracker is simply not there anymore. This is Microsoft we're talking about. They have given up on links. They have so given up on links that they can't even be bothered to let the user know what happened to those links.

Things are significantly worse on the mobile web. I would estimate that a good 90% of the web doesn't work on mobile in any sort of way that would delight a user. It's more that users just deal with this massive pile of shit. Watch someone use a mobile web browser sometime. Watch the nonsense they have to deal with. The janky-ass scroll popup sluggish ad-infested dumpster fire. All of it.

[type0]

> Watch someone use a mobile web browser sometime. Watch the nonsense they have to deal with. The janky-ass scroll popup sluggish ad-infested dumpster fire. All of it.

Hence each website tries to create their own app. Users are drawing in apps that track every move they make and batteries do not keep their charge even to make an emergency call.

[wvenable]

NetObjects Fusion allowed you to create pixel-perfect HTML layouts before CSS using just nested tables. It was both amazing and frightening.

https://en.wikipedia.org/wiki/NetObjects_Fusion

[whoisthemachine]

I remember a tool a lot like this in my teenage days (late 90's). Even then, I knew the things it was doing were horrendous...

And for what it's worth, NetObjects still exists - http://netobjects.com/

[spdustin]

Because assistive technologies (like screen readers) won’t interpret it as a table, but the browser will, giving you the ease of table-based layouts without the accessibility hang-ups.

[csnover]

At least VoiceOver on Safari uses the `display` CSS property to decide how to describe an element unless you explicitly give an element a different ARIA role in the HTML, so this isn’t 100% correct in practice (although it obviously should be!). [0]

[0] https://bugs.webkit.org/show_bug.cgi?id=197786

[lisper]

The right way to fix that would have been to add a simple annotation that the purpose of the table was for styling, not semantics, something like:

  <table type=for-display-only ...>

[goto11]

Why do you consider that better? If I understand your suggestion "type=for-display-only" would semantically turn the <table> into a <div>. Why not just use a div in the first place?

[lisper]

Because it's DRY. With the top-level annotation, the rest of the table spec remains unchanged, so if you change your mind and decide that you really want a display table to be a semantic one or vice-versa you only have to change on thing whereas if you used DIVs you now have to change not only the top level but also every row and cell.

[goto11]

You don't decide on a lark if you want some content to have table semantics or not! Tags are selected to indicate the semantics of the content. Content don't change semantics unless you rewrite it to actually be something different.

In any case, you might just as well decide the table was a list item or headline then, right? So you would need

   <table what-i-actually-mean="ol">...

[extrapickles]

You can do this already with ARIA attributes:

<table role="presentation" ...>

[edit] See https://www.w3.org/TR/wai-aria-practices-1.1/#presentation_r... for details

[98codes]

A11y hang-ups? It's a benefit that it makes it less accessible? That doesn't make any sense to me at all.

[vntok]

You have it the wrong way round, it's a benefit that it makes it more accessible.

Abled people benefit from a system where their browser considers that div as "table-like" in the way content flows through it. Likewise, disabled people benefit from the fact that their screen-readers consider the div as a simple container without imparting any sort of tabular semantics ie expecting some data organized in rows and columns.

[e5india]

I think they mean to say that sometimes you might want the visual structure of a table but you don't necessarily want it announced as a table via screen readers since it isn't data that's being represented.

[jstummbillig]

This is straight out of the CSS renaissance: There used to be a world, where the only sensible way to get something look a certain way on the web was using tables. But since using the actual table element, for anyone who cared about html semantics and accessibility, was a no go, assigning "display: table" to a non-semantic element was the next best option (or rather the least bad).

It will not surprise you to learn that this concept was not exactly well understood (to be fair, most things were not well understood, including js) and people started building all sorts of actual data tables out of divs with "display: table" applied, because apparently that's how you were supposed to do it.

Nowadays this is obsolete, of course, mostly thanks to flexbox but also grid.

[mgr86]

This makes me cringe. I may have been 12 but I was making websites in 1998. And they were decent--I mean, it was a lot of right click > view source copying. But I fell in love with the Web Standards movement. I was probably the only 13 year old whose book shelf included books on perl, css, xml, and the like.

[carldaddy]

I feel the same way. It's probably because I'm 90s kid and nostalgia, but I wish web standards were taken seriously.

[globular-toast]

Ah yes. I saw this happen in the mid-2000s during the backlash against tables. You see, some visionaries had realised that the table element in html was being abused to create layout. The tools to do layout were added to css instead and the advice was to stop using tables for layout. Simple enough. But during these times there are always people who don't get the original message, or don't understand it, and just start blindly following some derivative of the original advice. That advice was "use divs". So they did. They would look at an html source and if they saw "table" they would turn their nose up but if they saw "div" they would rejoice.

The irony is it was completely against the original intention which is to use html to give semantic meaning to elements. Tabular data doesn't just have a visual layout, it is rows and columns. Most people still don't understand this today although with things like markdown people are doing it even if they don't realise (unless they start embedding html/css, of course).

[djsumdog]

There were a lot of grid base frameworks which did this. Foundation 5 was unique in that it still used these rows, but you uses scss to assign those attributes to your elements. Your pre-compiled CSS looked clean and your HTML looked clean and your final CSS was a minified blob of crap you tried not to thing about.

Really CSS Grid does the same thing; there's just more in CSS now and it's a whole lot cleaner.

[sgift]

Aside from what people said about screen readers (which at least makes it a bit better than tables) this is still a bad layout.

Here[1] is a revised edition of a book I read in 2006 about this topic how people often just replace all table elements with div elements and call it a day instead of using all the options CSS provides. Another topic was using all the tools the browsers with the best standard support gave you while still providing a more limited, but at least usable, version for browsers which hadn't implemented some features (yet). Even back then you could make pages which read well if CSS wasn't available and were visually appealing with CSS applied and today almost any browser has all these tools available.

[1] https://stuffandnonsense.co.uk/transcending-css-revisited - there's a free online version available

[goto11]

Depends - if the content isn't semantically a table (data points with a two-dimensional relationship) but you just want a table-like presentation and you want to conform to accessibility guidelines, this might be totally fine.

Sure it might be more elegant to do it with a stylesheet, but for a one-off situation it is not that bad.

There is a persistent attitude that presentational information in the markup is Bad and Evil. This is only partially true.

Misusing semantic html elements (like using <table> for purely layout purposes) is bad because it hurts accessibility for other people. But putting CSS directly in the HTML does not hurt anybody but yourself. If you do it all over the place it becomes a mess to maintain, but in particular cases it might be the simplest solution.

[HideousKojima]

Probably to avoid the dumb limitations on having forms within a table? Still an awful and ugly way to do it

[castis]

I am convinced that people who recommend things like that have no idea where we are or how we got here.

[gridlockd]

Something about accessibility and screen readers that people virtue signal about, but never actually test for.

[hinkley]

CSS Zen Garden seemed to have a message that you don’t need tables for everything, but it was astonishing how few of the featured designs ever handled responsive layout properly. Getting text to fit into a rectangle by cheating was very common and you’d see bleed everywhere at a different resolution.

Until flexbox, there was no way to fix this without resorting to table cell behavior. It ultimately soured me on the Garden. And thankfully I got to use CSS3 shortly after.

[djsumdog]

Keep in mind Zen Garden was written WAAAAAAAAY before mobile layouts were a thing. Back then, you had mobile sites .. for people with PalmOS, BlackBerry or flip phones with tiny browsers. I think my edition of this book came out before the first iPhone (I remember owning it when the girl behind me at work got the original iPhone EDGE), so responsive design wasn't a thing (I don't think media queries even existed in the CSS standard, or if they were, few were using them yet).

[gshdg]

Heck, when the Zen Garden was first released, you couldn't even browse the web on a Blackberry. 1024x768 monitors were a luxury. 760px wide was all you could count on for a browser window once you accounted for window edges and scrollbars on the average user's 800x600 monitor (a few years later as 1024px monitors became more common, a 960px site width became the standard); and I had co-workers who were still getting by with 640x480.

[hinkley]

I was fighting my coworkers with 1440 monitors to make sure we still worked on 768 width (plenty for 800px + scrollbar, or portrait on the brand new iPad). UI people like to maximize negative space in their mockups and it's not uncommon for them to use extremely short example text to emphasize that effect. Like how your living room looked so big until you put all of your crap into it.

And the thing is, even if you had a 16XX monitor, who wants to maximize a tool that you might be transcribing data in or out of? I might actually need two windows side by side to facilitate that work.

[hinkley]

I was pitching responsive (or at least, fluid) design by 2011, and I was not blazing trails. I started using the iPad as an example but tiny laptops were an issue, and in a business setting, most production projectors were only 1024 pixels, hardly anyone had the 1280s, and the cheap ones were 800x600 native with terrible interpolation.

Wikipedia has this timeline:

> Cameron Adams created a demonstration in 2004 that is still online.[46] By 2008, a number of related terms such as "flexible", "liquid",[47] "fluid", and "elastic" were being used to describe layouts. CSS3 media queries were almost ready for prime time in late 2008/early 2009.[48] Ethan Marcotte coined the term responsive web design[49] (RWD)—and defined it to mean fluid grid/ flexible images/ media queries—in a May 2010 article in A List Apart.[2] He described the theory and practice of responsive web design in his brief 2011 book titled Responsive Web Design. Responsive design was listed as #2 in Top Web Design Trends for 2012 by .net magazine after progressive enhancement at #1.

And while the Garden was indeed around long before that, IMO it didn’t get properly cool until maybe ‘07. And once fluid and responsive came in it wasn’t keeping up.

The point, I thought, was to be able to send people there to learn, and I was afraid of having to fix that kind of smoke and mirrors in our production code so I stopped telling people about it, other than other seasoned UI people fora particular design, and half the time it was to laugh at one, not learn from it.

[brigandish]

> IMO it didn’t get properly cool until maybe ‘07

Wikipedia says the book came out in 2005, which if I remember correctly had plenty of colour pics inside. You don't get that kind of tech book unless you're already properly cool.

[lmm]

Responsive design was absolutely a thing, because the web was responsive from the start. It was CSS that made it non-responsive; sites that used tables for layout reflowed properly on PDAs or phones, and still do.

[jandrese]

Virtually every CSS Zengarden site was filled with exact pixel counts and page offsets. As an art project it was neat, but practically speaking it was a disaster.

When I was first learning CSS I was trying to replicate a very easy 3 column layout where the middle column would grow and shrink with the screen and consist of multiple variable sized elements arranged neatly in a column. What should have been one of the most basic layout styles turned out to be quite a challenge to achieve with CSS. I wasn't even trying to have anything fancy like columns that disappear on super narrow screens. Just the most basic three column layout that didn't leave wasted space on the page. In my struggle to get it to work I went to sites like CSS Zengarden to figure out how they did it and was extremely disappointed to discover that they hadn't found the solution either. My thought was it couldn't be difficult because it was so easy to do with tables and literally everybody online was telling me that tables for layout were completely surpassed by CSS. Plus I was working with CSS 2, so any glaring deficiencies like this from CSS 1 would have definitely been fixed by then. I mean this was the point of CSS right? To do layout?

[dsego]

Ah, the three column layout with equal heights, the holy grail.*

*https://en.wikipedia.org/wiki/Holy_grail_(web_design)

[hinkley]

One of my big coups was fixing the reflow on our multicolumn layout. The page I fixed it on was survivable as it was, but a whole third of our UI would not have worked at all without it.

The first time I got to use flexbox in production (different project) I was happy as a pig in shit.

[gridlockd]

Even with "display: table" or flexbox you couldn't do something as simple as colspan.

[hinkley]

Oh man, I had blotted that out. There’s a somewhat arcane set of table styles that will give you proportional layout of blocks that is more powerful than colspan. I found that it was often worth the trouble of reaching for the more sophisticated solution.

[jguffey]

I've long thought about this too. Eventually I've come to the conclusion that CSS Zen Garden was more about "Hey you can do all of this with pure CSS" than it was "You should do it this way". At the time that I discovered Zen Garden, CSS was in it's more early, primitive days. As a front-end developer, it was easy to say "I can't achieve this design without changing the HTML Structure". Zen Garden showed us that this was just an excuse, (just about) any design could be achieved without a requirement to fundamentally change the HTML of the page. It was eye-opening to see some of the ways theme authors rearranged content, broke down those box boundaries, and used design tricks that stretched the limits of CSS and HTML in that era.

It was awfully inspiring, and I think the point was never - "this is the way you should encode pages" it was more about taking excuses away.

[regularfry]

The point absolutely was "this is the way you should encode pages", or rather "this is what is possible if you encode pages this way". The purpose of Zen Garden was to highlight the separation between style and content; that separation is why we've got CSS as a separate language to HTML in the first place.

[jtms]

No, it was absolutely about the way you should "encode" your pages. I would choose the word "markup" here instead as that's what it is, but it was 100% a recommendation on the benefits of separation between markup and presentation.

[bluetwo]

Or, was it to prove that yes, you can live without Flash.

[lazyjones]

People are far too concerned with these things anyway, IMO. All ways work well enough and perhaps I'm just ignorant, but in the past 25 years I haven't seen a single good example of a situation where someone won against the competition because of better presentation or better choice of frontend framework. That excludes those who shot themselves in the foot with Flash though.

IOW, put the effort into backends / core functionality and not elegant styling or elaborate frameworks.

[rimliu]

I think this reversal is sad, actually. Even sadder, that one of the driving reasons was people just giving up on CSS ("too complex/weird") and going for spaghetti and a wall approach. Then trying to use tools to plug the knowledge hole.

[klodolph]

Honestly I say the reason it’s sad is because of the idea that CSS promised something it couldn’t deliver. The sad part isn’t that people gave up on CSS, the sad part is that people believed it could work this way in the first place.

Writing CSS stylesheets by hand is like writing HTML pages by hand. It just doesn’t scale, and you run into a million tiny problems every time you change something in a medium size project. So for HTML we use templates and components. For CSS, we want the CSS for a component right next to the component itself in our VS Code window, so that actual humans have good insight into what styles will affect a particular component. The alternative—keeping the CSS separate—requires its own set of tooling to plug the holes, like all those fancy web developer tools built into browsers these days.

[wtetzner]

I always thought the approach of returning XML from your web server and having it refer to an XSLT stylesheet made the most sense. Unfortunately, XSLT is a very verbose and clunky style language. If it had been a better language, I think it could have been a good solution.

[klodolph]

I think component systems like React are the closest we have to achieving that dream. This is why Vue, React, Angular etc. all look something like writing your own tags and then implementing them in terms of, eventually, standard HTML tags.

You can even swap out the web browser front-end, to an extent. I know that some mobile apps are done this way.

[sbergot]

It is only sad when you have not worked on a medium sized website/webapp.

For a small document like css zen garden where the goal is to produce a diversity of design without changing the html? css selectors are perfect. But how often is that the goal of the UI team?

The goal of a ui team is to have a consistent ui that is easy to change. Components helps with consistency. It also helps in separation of concerns: you can have someone writing the component library and someone else using it.

The goal of a ui team is also to minimise the amount of ui bugs, and the amount of ui code. If you let people go wild with css selectors, you end up with badly scoped class names and very painful integration phases where selectors breaks the ui across the whole application. When fixing bugs people are too afraid to remove anything because it means that they have to test a huge scope.

The trend I see is not spaguetti (except in places that don't care). It is the use of a very restricted type of selector: .class_name. Some people use css BEM or functional css and write those names themselves. Some people use a css in js library that generates them.

We have started adopting css BEM two years ago and now we are considering using a css in js library. I had to manage a css library update recently and 90% of the issues were in place where people didn't have this kind of methodologies.

[z3t4]

Just like with programming you have to limit scope. And avoid using global scope. Its fine to have a "private" base style for components. The power of CSS however is that users can overrule those styles. Its however important to organize the css in a cascade and not have rules for the same element spread out all over the place with !important everywhere.

[echelon]

You used to see CSS frequently used by hobbyists making personal websites. As a result, you'd see a lot of posts about what cool stuff they could create, their opinions on how to structure things, semantics, etc.

Now these same people are mostly doing it for the paycheck. And there are a lot of new people doing it as well. In fact, dozens or hundreds of authors may be maintaining the same stylesheets. You just have to get your changes in.

People get older, begin to care less. The web has surrendered to commercial platforms. It's not as exciting.

[gridlockd]

Even with the most powerful CSS methods, you simply cannot completely separate the structure of the HTML from the layouting.

It's better to give up on this ideal right from the beginning than to build something that ends up getting complicated with work-arounds and edge-cases.

[mightybyte]

For awhile now I've felt that the CSS libraries like Bootstrap, Semantic UI, etc are never the "right" way to organize your markup and CSS for a large project. They're great for getting out something quick and dirty that looks decent. But once your project passes a certain scale (in size or time spent maintaining it), the balance shifts in favor of semantic markup and style in CSS using BEM or something similar as an organizational paradigm. The latter just doesn't seem conducive to off-the-shelf styles because semantic organization is different for every project.

Another way of thinking about it is that CSS libraries build infrastructure for universal reusable widgets. In the beginning of a project it makes sense to build your app by putting together these building blocks. But as time goes by and the app grows, you start to develop a layer of higher level UI abstractions that are specific to the domain of your app. And when that happens it is often in conjunction with some kind of a re-styling and the old universal building blocks are no longer what you want. I've seen multiple large frontend projects go through these phases, and am starting to see them as a natural evolution of frontend projects.

[bromuro]

Well I think it went that way because CSS is lot of frustration and not much zen.

[leeoniya]

> whereas in the Bootstrap era you would look at my HTML and see "row" and "col-sm-3" and know exactly what I was going for visually.

say what you will about utility classes, but the grid classes are absolutely necessary, especially when many elements might need specific behavior for different screen sizes and must interact gracefully. without the grid classes your css would be an absolute nightmare of a thousand often-nonsensical "semantic" classnames littered with a crapload of fragile media queries.

[nickelcitymario]

This is no longer true with CSS Grids. The grids are all defined in the CSS itself, allowing us to once again separate style and content, as well as allowing us to define custom templates for different screen sizes (rather than simply force them into a single-column, left-to-right order).

I know this is still barely being used, but it's clearly the better way to go.

[nitely]

Sass removes most of the cruft. I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities, even in the css side [0]. This was before CSS Grid Layout was widely supported, nowadays you can use plain CSS grids and get similar results.

[0] https://github.com/nitely/semantic-flex-grid/

[leeoniya]

> I made a semantic flex grid many years ago, and the result was a lot more clean than using utilities

your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives.

complex/nested responsive grids are not simple, unfortunately. i've made one, too: https://github.com/leeoniya/flecks

[nitely]

> complex/nested responsive grids are not simple, unfortunately.

How does utilities make complex/nested responsive grid simple, again? I'm arguing semantic css is simpler than using utilities all over the HTML, not that it magically makes responsive design easy.

> your grid has zero media queries in it, which means whatever grid classes you were using before were not responsive - which is where 90% of the complexity lives.

There are some in the examples [0][1]. Both for responsive design and nested grid, sadly not for both at the same time. It's not much more complex, though, well I guess it depends on how complex are we talking about. Anyway, CSS Grid makes semantic layout a lot simpler now.

[0] https://github.com/nitely/semantic-flex-grid/blob/gh-pages/s...

[1] https://nitely.github.io/semantic-flex-grid/

[penneyd]

<handgrenade>tables handle grids quite nicely</handgrenade>

[hinkley]

Bootstrap still gives me an eye twitch. It didn’t handle color customization properly until at least 3.0 (oh you could color many things, but you want light text on a dark background and you’ll have to override a ton of stuff).

I was ordered to use a version that didn’t even handle responsive design properly. Right after we had agreed to make the app responsive.

[kevin_thibedeau]

It's a shame that Foundation never caught on fire because they were/are way ahead of Bootstrap in these and other areas.

[bmn__]

To "become popular" is just "caught on", not "caught on fire".

https://www.lexico.com/definition/catch_on

[hcarvalhoalves]

Because every 10 years you have people who haven't been around for the past 20 years (re-?) inventing things.

[wdb]

Personally, I find the mixes of class names like with Tailwind really confusing and need to keep looking it up when using it. Doesn't really make things easier imho

[tylerjwilk00]

So long as structure and design overlap there will always be some inescapable coupling. The choice is deciding which one should master over the other.

[arvinsim]

Funnily enough, styled-components in React does allow me to focus on the semantics meaning without worrying about the style.

[jakearmitage]

http://smacss.com tried to push this, but failed

[hinkley]

Can’t remember which, but there was someone who made a CSS library that patterned like a fluent interface.

They had lots of selectors that were adjectives, and most of them composed. So you could have a class=“tiny button” or whatnot.

[mpranjic]

Perhaps Semantic UI?

[hinkley]

YES. That's the one. Thanks.

[arkh]

And now we're back to table-based design and flash-like but less powerful javascript based application.

[lmm]

It's a failed experiment. We've had over a decade of people trying to use CSS to style websites and ending up with worse results than if they'd just changed the HTML.

Let it die.

[gridlockd]

Semantic HTML has never been something that businesses asked for. HTML has never been a good format for structured data.

Things have simply moved towards what's actually manageable in a production environment, not what some ivory tower designer thought was good practice.