If you’ve got stuff that would look good as a table, use a table.
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.
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.
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?
> 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.
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.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/CSS/display#int...
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.”
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?
