[layer8]

There was never a well-substantiated argument for the alleged harm of layout tables. Demonizing them mostly just stemmed from the cult of wanting to completely confine layout to CSS vs. expressing semantics with HTML. In the end that “CSS zen” was never really achieved, because the dependencies between HTML structure and styling are just too many and too strong.

[WillusFredus]

> There was never a well-substantiated argument for the alleged harm of layout tables.

What was the best argument that you can recall? What were some of the bad ones? What does "harm" mean in this context?

> because the dependencies between HTML structure and styling are just too many and too strong.

Which dependencies? What would a structure/styling language combination look like that that lacked or had weak dependencies?

[layer8]

> What was the best argument that you can recall?

I mostly recall “layout belongs into CSS files” (so a matter of principle) and “layout tables are bad for accessibility”, which while in theory could be an important point, in practice screenreaders had already adapted, and had (still have) very practical heuristics to distinguish layout tables from data tables (see e.g. https://webaim.org/techniques/tables/).

The thing is, at the time, using CSS to achieve the equivalent of layout tables was an exercise in frustration and futility, in that the results were exceedingly brittle and very often broke when either the table content, the surrounding elements or the browser window size changed too much.

Nowadays we have CSS grid and flexbox of course, but I imagine that in some cases a layout table could still be the most straightforward solution today.

> Which dependencies?

The fantasy back then was that it would be possible to define the HTML content and structure completely independently from layout and styling considerations, and then a separate CSS file could be used to specify any conceivable styling and layout for that content. While that is true to a certain extent, it usually breaks down as soon as you need HTML elements to be in a different order or nesting relation, or when you need additional intermediate nesting DIVs, etc.

In reality the HTML structure and the CSS structure (bound to each other by IDs, class names, hierarchical selectors etc.) is so closely intertwined, and the mapping points (i.e. IDs, class name combinations, etc.) are so many that, for the most part, only superficial changes can be made to one side without having to also make some adjustment on the other side. Ideally, it would be possible for an HTML author and a CSS author for the same web page to mostly work independently from each other. In reality this is almost impossible, except for the case where the HTML remains basically unchanged and the CSS can change within the constraints of the existing HTML structure.

Banning layout tables was never going to be a major factor in coming substantially closer to the imagined ideal here.

> What would a structure/styling language combination look like that that lacked or had weak dependencies?

I think it’s inherently difficult, because you will always need to specify which styles/classes should apply to which element in a rather fine-grained manner, which just means there will always be a lot of dependencies between the two sides.

One thing you’d need in order to realize arbitrary layout is a way of mapping structured content into a different structure. That basically means having a functional programming language to define the mapping, if you want to have full flexibility.