>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.
Like so many things, it only seems awful in retrospect. Perhaps it is time to revisit the indentation implementation Hacker News code and change it to use nested lists for threads. (I wonder how HN is implemented and how the code is updated. It could be anything from a single file lisp program running over a single text file to a whole cluster of more traditional specialized servers. (Is it rude poking around DNS looking for clues about a backend implementation?)
> Like so many things, it only seems awful in retrospect.
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:
> 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.
Here's a talk by Sina Bahram from five years ago -- at around 6:30 he specifically addresses how inaccessible HN is to a visually impaired user. Nothing that he mentioned has been addressed: https://www.youtube.com/watch?v=G1r55efei5c
Usually when people say something would be a simple change, they're not aware of the underlying complexity.
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.
Actually, I think it would be rather straightforward. I'm a bit embarrassed for HN that they're still using tables and spacer gifs and see it as an intentional pushback on "caving" to modern web techniques. Despite CSS being 20 years old at this point.
Maybe you're right. I had a poke through the HTML a while back, and there are actually tables-within-tables for some reason. It was way more complicated than I expected it to be. It does seem kind of weird that it still uses tables for layout, when there are so many easier and better ways to do it.
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.
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.
[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.