[egypturnash]

…for non-tabular data such as “your pretty design elements that frame and organize the text because it is 1995 and CSS doesn’t exist yet and this is the only tool at your disposal for aligning stuff across the page”. Or because it is 2000 and putting stuff where you want it is a hell of CSS2 floats and box models and eventually you just say “fuck it” and assign table-like behavior to a bunch of divs because Tables For Layout Are Considered Harmful.

If you’ve got stuff that would look good as a table, use a table.

[temporallobe]

It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible borders were nearly perfect for layout containers.

[jerf]

The "Tables are Harmful" club largely came from the crew who thinks HTML carries lots of semantics and that if you don't use the Blessed Tags that carry those semantics you're doing Bad Design.

The rational evidence in favor of this claim has always been weak. The "div" tag basically finished it off. The people who use HTML "semantically" have always been dwarfed by the people just making it look good on the screen, and the number of applications that use those semantics has always been small and on the fringe for something so putatively important.

However, the idea persists to this day despite its near complete failure to pay off significantly in nearly twenty years, and I'm sure someone will angrily reply to this and list the incredibly useful semantic HTML features that they and fifteen other people have found to be just incredible. Perhaps we'll also get the traditional citation of the Google info boxes, which have nothing to do with the semantic web and everything to do with Google throwing a crapton of machine learning and humans at the problem of parsing distinctly non-semantic HTML until they cracked the problem.

(An honorable mention to screen readers, which sorta do benefit, but still nowhere near as much as you might casually expect.)

Today the reason not to use tables is more just that it's inconvenient to do things like have a mobile and desktop layout. I believe they've got all the tools nowadays to tear into a table-based layout, break the tables apart, and treat it like any other CSS-styled content, but that's relatively recent, and still a silly way to operate when you could just use normal layout elements ("div" if nothing else) like a sane person and not have to undo the table layout before you can manipulate them properly.

[spread_love]

> honorable mention to screen readers

Too limited, and deserving of much more than an honorable mention.

Accessibility should be a fundamental consideration of any reasonably sized app, using <table>s to markup tables is part of that.

Assistive devices are not limited to screen readers, and it's just good practice to use tables for tables.

CSS Grid has landed in all major browsers, if you want a grid layout, use grids for layout.

[WillusFredus]

> the idea persists to this day despite its near complete failure to pay off significantly in nearly twenty years

I am not clear on exactly what "the idea" refers to, perhaps you could clarify. Also, how has the idea "completely failed"? And what would complete success look like?

[jerf]

The idea is the "semantic web". Success would look like almost everyone here having to know a lot more about the "semantic web" to do their jobs, such that I wouldn't have to explain to anyone what it was because it would just be how things worked, because it would be that important, and they couldn't operate without it because they wouldn't be able to compete against other websites without the staggering benefits that super-careful, expert semantic design brings them. Rather than just learning the layout and adding a few extra accessibility tags as needed.

As it stands now, it's very practical to just slap some <div>s down and do some CSS and be done.

[pwdisswordfish9]

Obnoxiously bad take.

> Google info boxes[...] have nothing to do with the semantic web and everything to do with Google throwing a crapton of machine learning and humans at the problem of parsing distinctly non-semantic HTML until they cracked the problem

This is verging on /r/SelfAwarewolves material.

[jerf]

I'm pretty sure you're misinterpreting it. Google did not simply write a web scraper that pulls a <business_hours> or a <dc:business_hours> tag out of the web. They wrote a web scraper that super, super intelligently examines the HTML and looks for "anything that looks like business hours"; maybe it's in a table, maybe it's days of the week separated by &nbsp; and <br>, maybe it's in <div>s or <span>s with suggestive CSS class names, maybe it's just in a pile of other HTML. The exact promise of the Semantic Web was that we could just load up a page and get a <business_hours> out of it. Google had to extract the "semantics" with everything but the "semantic web", because the "semantic web" is a no-show. Throwing a crapton of machine learning and humans at extracting semantically useful information from a page is precisely what the Semantic Web isn't.

Which is why it is bizarrely unselfaware when Semantic Web advocates almost inevitably cite that as their biggest success. It isn't. It's their biggest failure.

[pwdisswordfish9]

> I'm pretty sure you're misinterpreting it

You should be more sure of the things you're pretty sure of before saying you're sure of them.

There was no misinterpretation—from this end, that is. Your comment wasn't particularly sophisticated. It didn't require explanation.

> Google did not simply write a web scraper that pulls a <business_hours> or a <dc:business_hours> tag out of the web. They wrote a web scraper that super, super intelligently examines the HTML and[...]

No shit. The value proposition of the semantic web follows from how the world would be much better off if that weren't necessary. It has always been the case that, without the "semantic" half of "semantic web", attaining Google-level mastery over the Web's messy inputs is really, really difficult and requires Google-level resources. This isn't news. Yet you presented it as if it were in insightful observation wrapped in sage wisdom.

In your attempt to "prove" by counterexample what's Wrong with the semantic web, you just end up undergirding its very premise.

> Which is why it is bizarrely unselfaware when Semantic Web advocates almost inevitably cite that as their biggest success.

You cited them. You are literally the only person who mentioned them here, at all. You brought them up.

Saddling someone who advocates for X with the burden of defending position Y that you yourself have pulled from thin air is a textbook example of a bad argument. If you defeat some easily take-downable opponent (a 6-year-old, let's say—and one who is made of straw, for good measure) and then plan to enter the ring in subsequent matches having only bothered yourself with the thought that you will face the threat of another strawchild, that's not wise. It's stupid.

[eyelidlessness]

The semantics being wrong is convincing enough to me. That’s fundamental to accessibility. But if that doesn’t convince you: they’re not even good at layout. It’s much harder to make a page even minimally responsive with a table than with more semantically appropriate markup; you’d effectively have to revert all of the table styling, at which point why bother?

[kixiQu]

https://eev.ee/blog/2020/02/01/old-css-new-css/ <-- Sounds like it depends on how complicated you want things to get within those containers; Eevee here mentions nesting three levels of tables, which... Ew.

Also, not being able to rearrange blocks for different size displays is kind of a non-starter relative to the mobile internet, which I'd guess was more important than frameworks.

In my own hobbyist stuff, though, there's just something a little gross about putting layout in the HTML -- I want HTML to represent semantic structure, in ways I'd be okay with Lynx displaying, and I want CSS to do all the lunatic nonsense to make me happy with how it looks on a modern browser. I wonder how much it's this aesthetic principle of separation that motivates others as well.

[giantrobot]

Tables don't lend to responsive layouts. If you've got a stereotypical layout with the middle row having a main content and sidebar column you can't really reflow that sidebar below the main content on mobile. With block elements (divs or semantic blocks) and CSS it's super simple to collapse multiple columns down to a single column for mobile. It's also simple to redo the same layout to handle super wide displays as well.

Tables for layout were fine back when everyone was browsing the web on SVGA, XGA, or even SXGA screens at 96dpi (72dpi on the Mac). Now a visitor might be on a high DPI display in portrait orientation, full screen on a 4K monitor, or anywhere in between I think it's a bit disrespectful to visitors not have have a responsive page layout. Tables are a liability for responsiveness and should only be used for tabular data.

[marcosdumay]

Doing layout with tables creates a mess of non-semantic cells, with spans everywhere. That is hard to read, hard to write, brittle on changes, and obscure the actual content. If you take a random page from the tables era, the odds are great that you won't be able to tell what text goes next to what other text.

Divs that follow the document's semantic hierarchy and are positioned on your CSS have none of those issues.

Anyway, a lot of ways to use Bootstrap and other grid-based frameworks introduce the same problems back. And if you want to really display things in a table, well, a table fits quite well your requirements.

[clairity]

you can still use table layout, just not tables for layout, via `display: table` and it's many cousins (table-row, table-cell, etc.). it's a bit cumbersome, so not something to use everywhere like the old days of tables plus spacer.gif's.

https://developer.mozilla.org/en-US/docs/Web/CSS/display#int...

[frosted-flakes]

...and absolutely unreadable for anyone using a screen reader.

[layer8]

This was never true, I believe, and only a theoretical issue invented by the semantic-HTML obsessed.

From [1]: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.”

[1] https://webaim.org/techniques/tables/

[sylware]

yep, then no pb as a layout.

[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.