> Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear"

Table markup was discouraged. There’s nothing intrinsically wrong with display:table from a CSS/semantic markup evangelist’s point of view, it’s just awkward to use, requires you to arrange and order your markup just so (sometimes contrary to semantics), and was rarely mentioned in the days of float/clear because IE screwed it up in various ways (that were more difficult to fix than those for floats). It works reliably now, but as far as laying out the page goes the requirements for ordering the markup will probably be incompatible between desktop and mobile. For insides of buttons and such, though, go nuts.

CSS never recommended float/clear as an alternative to table-based layout. CSS had ‘display:table’ for when you needed a tabular layout without the semantic baggage of the table-tag.

CSS is just a language + words of paper spec.

CSS, as in "CSS evangelists", influential web designers, guidelines in web development resources, books, and so on, recommended and advocated for the use of clear/float.

You might not have been there, but float layout was a big thing back then, and everybody was guilt-pressured to use that - neither tables, nor "display: table" (which was used by some, but also discouraged).

You are probably remembering advice from the dark age of IE6 dominance where display:table was not well supported. I have also seen advice againt using html tables in the early days of mobile browsers since they handled them badly.

The problem is people forget context. The advice “dont use tables <in this specific context under these specific constraints>” is remembered as “tables are bad, never use tables or anything which remotely looks like a table”.

I never saw anybody discourage people from using display: table. The reason why nobody used it was because Internet Explorer 6 didn’t support it.

'display: table' wasn't consistently supported and '<table>' for layout caused issues for screen readers because they (rightfully) expected content that's tabular in nature.

Nobody was guilt-pressured into using floats. You might say some were guilt-pressured into writing accessible web sites but that is a significant destinction. Many public/government web sites were mandated by law to be accessible, so many developers had to write accessible html whether they liked it or not.

Of course for your personal Tranformers fan site you can use html tables to your hearts desire. Nobody is likely to complain.

But most web-design focused media is targeted professionals for whom it is a necesssary skill to be able to design pages which look good for most users and is accessible. During the dark age of IE6 it was necessary for developers to know and use a large array of hacks (including the abuse of floats) to achive this.

> everybody was guilt-pressured

What, no? I did a lot of web development in those days and read a lot of blogs. You just needed to filter out anyone who was obviously over-opinionated and lacked any nuance. Most pragmatic people used tables and didn't feel guilty about it. If you delivered working software with a decent UX, why on earth would you care what some shouty internet person said??

Many public institutions was mandated to follow the WCAG (Web Content Accessibulity Guidelies) which recommend against tables used purely for layout.

So it it not really about vague “guilt-pressure”, it is just that many web developers had to follow WCAG as part of their job.

Oof - I didn't know that. Kind of a weird requirement, were/are screen readers rendered so ineffective by the content being in a table as opposed to in divs?

Not inneffective as such, it just presented a confusing user experience because the screen reader would assume the table represented data structured in two dimensions and e.g present navigation options for going cellwise left/right and up/down.

This would be pretty confusing if the table was just used to create a margin and most cells only contained spacer gifs. Especially with deeply nested tables (as was the fashion at the time) it could be pretty confusing.

Today you can just add an ARIA-hint indicating a html table is used purely for layout and a screen reader can then treat it just as divs. But this did not exist at the time.

Of course the WCAG just assumed it was not a big deal to avoid tables for layout since CSS2 supported tabular layout through pure CSS. But the reality of a web dominated by IE6 made this a much larger problem.

"CSS" (not sure what you're referring to here, the standards bodies?). Endless articles from the mid 2000s kept saying tables bad, here's how you layout without tables. All of them used floats for layout, not display:table. Partly I suppose this was because IE didn't support it until 2009, I think.

Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.

> Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.

I think this is the core misunderstanding in this discussion. CSS 2 supported both text-flow and tabular layout and both layout models were reverse-ingeneered from how Netscape rendered HTML.

There is this weird idea that CSS is somehow opposed to tables or tabular layout, while a significant part of CSS2 is actually the codification of how tables render.

I don’t think there’s much of a misunderstanding here. There are historical reasons why CSS was so weak on layout for so long, but there’s always reasons. To understand what was missing look at what they’ve added (flexbox and grid). I don’t like the implementation of either, but they are in the right space.

The reason for the advice against tables was that the "semantic web" was all the rage (probably mostly because Google wanted to make it easier to index stuff). If you have tabular data, using tables was just fine. The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table. Same reason you don't use <H1> just to make the text bigger.

>The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table.

There shouldn't be any semantic basis needed.

HTML is not a semantic data exchange format, was not designed to be (the pathetic handful of semantic HTML5 tags added to be used ad-hoc included), and it inevitably includes content, style, and behavior (js).

The semantics should belong to data intergchanged (and storage format), and the reusability should be on the data storage/query backend, not to the markup language.

Adding semantics to the markup duplicates the semantics already present in your DB or JSON API scheme or query server/storage in general.

Semantic markup is what makes both web crawlers and screen readers recognize that <a href> is a link to another URL. The web couldnt work without it.

Yeah there was a period of time when IE didnt support display:table and ARIA hints wasnt as developed. So if you wanted to create accessible web sites with nice layout you had to resort to weird hacks, often using floats.

Floats was never intended for that purpose though, it was just a desperate hack to get around IE limitations.

But html tables was not a viable alternative for organizations which was required to have accessible websites.

(Today I believe it is possible to create accissible html tables through ARIA hints, but that was not an option at the time.)

Meh, discouraged by some bloggers, sure. Those of us doing web development in that time (I built some pretty large websites in the days before flexbox) ignored obviously overbearing advice like that. I still occasionally use tables for layout, even when something isn't 100% a grid of data. Granted those cases are quite rare and generally flex is the right solution.