That's awful... Why would it be done like that?
[0]http://paulgraham.com/arc0.html
>pg: "Arc embodies a similarly unPC attitude to HTML. The predefined libraries just do everything with tables. Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
>(...)
>Tables are the lists of html. The W3C doesn't like you to use tables to do more than display tabular data because then it's unclear what a table cell means. But this sort of ambiguity is not always an error. It might be an accurate reflection of the programmer's state of mind. (...)
... and yes, that decision is baked into the server, web app, HTML and forum code (which to my knowledge have never been changed in the standard Arc distribition,) making it a de facto requirement for all Arc based webapps and a PITA to change.
CSS could match the current appearance exactly. I bet if dang put up the code on GitHub he'd get PRs fixing tons of stuff within a week.
This is a different case -- HN genuinely does not have a complicated UI, and it genuinely would not be difficult to make a UI that worked better with screen readers. It would not be difficult to rebuild a HN UI to stop using tables without even making any visual changes to what the site looks like.
There is very little complicated functionality going on in HN pages. They're paginated, they don't have a ton of content, they don't have a lot of complicated UI controls they need to support. They're mostly static pages with some very minor form controls.
In this specific case, there really is no excuse for HN to be screenreader inaccessible. This would not be a complicated conversion for even a single experienced web developer. You wouldn't need to use React, you wouldn't need to use any 3rd-party library or dependency at all. You wouldn't need complicated CSS features, you wouldn't need to redesign the UI.
Honestly in a lot of ways, the current HN table layout is more complicated than it needs to be, the generated HTML could be a lot simpler. Really, there's a difference between being "retro" and using what works instead of chasing modern trends, and having outputted HTML that's broken and hacky, and was broken and hacky even at the time it was released. HN is very solidly in the latter category.
No, it seemed awful at the time as well. Table layouts were already long obsolete by the time Hacker News was launched. Here’s a discussion from over a decade ago on the subject:
https://news.ycombinator.com/item?id=2019950
Quotes:
> If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
> The big benefit is to accessibility through screenreaders or other alternate clients.
> Look, do what you want. You want to write bullshit markup, be my guest. But there isn't a single web dev in this community who would code output like this for their own site. They're just too chickenshit to tell you.
And here we are, a decade later: nothing has changed, we’re still having the same discussion about the same flaws, and it’s still causing problems for people with disabilities. It doesn’t “only seem awful in retrospect” – it has been awful all along and people have been pointing it out for over a decade.
pg is very proud of HN's quirky implementation that does what he wants very efficiently.
For visual use, I would agree that the site is great, far better than most of the bloated nonsense that is out there these days.
I'm not sure I agree that it does. HN ships a bunch of extra DOM content that it really doesn't need to ship. If you're optimizing for page size, the HTML could be lighter.
The site does what pg wants, but he really shouldn't be proud of it for doing what he wants well. It's not that the HTML is super-optimized but that the optimization has tradeoffs. It's more like whoever programmed it is very familiar with tables, and when all you have is a hammer everything starts looking like a nail.