HN still uses <table> .. and it works great.
There's a related idea that interests me - ideas that were useful mainly for killing something else. These two things overlap somewhat.
1. "Don't use tables for layout" - helped kill the most horrific era of web-design which was largely based on slicing large photoshop images into parts and reconstructing them in html tables. Responsive design would never have been possible if this practice hadn't have been vanquished. The actual arguments for not using tables for layout were much more nuanced and in some places - just wrong. In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div.
2. REST. Most APIs are still only an approximation of 'true' REST - or just kind of cheating and sticking in some RPC-style endpoints when the going gets tough. The promise of machine to machine API usage without developer intervention is yet to be realised. However - REST stopped SOAP from taking over the world and for that we must be eternally thankful.
3. "Separate content and presentation (HTML/CSS)". Similar to (1) - this was based around a core truth about separation of concerns and maintainability. However it became a mantra rather than just one specific way you could attempt to reduce coupling and create less brittle markup. But it was easy to explain and easy to argue for and it stopped a lot of bad practices.
I had a few more but I can't recall them right now. Maybe the message is "simple to explain but partially inaccurate ideas are easier to transmit than nuanced and complex ones"
> In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div.
This comes up a lot and it niggles at me every time. div/div/div was a large semantic improvement over table/tr/td, not because it specifically describes the content you've put in divs better (it doesn't, obviously), but because it stops being explicit "dishonest" about the semantics of that content.
Defaulting to div/div/div over table/tr/td makes semantic specificity opt-in and explicit instead of opt-out and implicitly wrong for generic non-table content. It means devs who want to use specific tags for greater semantic specificity can do so, while most devs are using generics (divs) because they don't want/need the specific semantics. The previous alternative was that the majority were following a pattern that made intentionally semantic table content indistinguishable from generic[0] content.
Otherwise, good post. I'd like to see that list started and growing.
[0] By "generic" content I just mean any content where there isn't a strong desire/need on the dev side to describe it very specifically.
1) There's no real world benefit to using these elements, in any easily demonstrable way (maybe there's some sort of tiny accessibility or SEO advantage, but it's fractional in comparison with, say, just using H1/H2/H3 correctly), which mostly leaves them as an exercise in academic purity.
2) The definitions are really woolly and require far too much thought, especially given the previous reason. Why bother debating whether something is a SECTION or an ARTICLE or a MAIN when you can just use a DIV, with whatever probably overly specific `class` you were going to use anyway, and it will still work in exactly the same way?
<section>, <header> and <footer> are not too uncommon.
<article> is by far the most used, and is also put to genuine use in parsing by things such as Firefox/Safari's Reader views and other such tools. <section> gets used similarly by some parsers I think, though I've no direct examples off the top of my head.
For the high-level layout elements it's not so bad, but the <i> element being defined as indicating things such as "taxonomic designation, technical terms, foreign idioms, transliterations, thoughts, ship names, or dream sequences" renders it basically pointless. The HTML spec encourages you to use a class attribute to identify why <i> is being used, but then you might as well use <span>.
Most browsers - maybe all modern browsers - actually accept made-up elements and let you apply CSS to them. There's no good reason - other than compatibility - why authors shouldn't create ad-hoc elements - e.g. <dream> or <tabs> - that match up with the true semantics of the content.
Some of the most common layout tags I see are: header, main, footer, section, article, aside, nav
Other things can have <footer> tags too. I've seen plenty of <footer> elements inside <blockquote> tags!
The wrong thing was the one-to-one mapping of the content, presentation and business logic to some specific technologies (them being HTML, CSS, JavaScript). That's why so many people got confused when they saw XML tags in React. OTOH, as you said, we usually need simpler rules. The moment people started to think that "now it's OK to put HTML in JS", we started seeing blog posts being written in React containers.
But HN is also in a very unique position. It has 170 lines of CSS and thousands of talented web developers have inspected it for mobile problems. Every easy fix has been made. Most websites can't do that.
That was actually a bug in Chrome, that was trying to be overly smart and changing font sizes aggressively.
2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages.
3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.