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?
As it stands now, it's very practical to just slap some <div>s down and do some CSS and be done.
> 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.
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.
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.
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?
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.
