[its-summertime]

Looking at the html of HN's pages, can't blame them really.

Running though https://validator.w3.org/ , the result is abysmal.

At this rate, if web browsers started requiring sites to output HTML that is somewhere in the realm of normalcy, HN would sooner shut down than consider ever updating.

[Aardwolf]

Yet its pages load much faster than most websites, no cookie popups, no "subscribe to our newsletter" slide-ins, no phenomenon where the content loads but then a second later the page resets and re-loads the content again (probably with more ads or something), no images only getting loaded and popping in view while you scroll (rather than do it a bit predicatively beforehand so they'd pop in outside of your view to give a less slow impression), etc...

[sitharus]

I don’t understand how that’s at odds with having spec-valid HTML and CSS

[Aardwolf]

Because updating to become conformant might come with the risk of making it a "modern" overhaul :/

[jraph]

You don't need

> no cookie popups, no "subscribe to our newsletter" slide-ins, no phenomenon where the content loads but then a second later the page resets and re-loads the content again (probably with more ads or something)

to fix rendering layout using tables and cell width to render comment levels.

Just a few lines of CSS and Arc really. That would be a big overhaul only because HN is very small, but not that big in absolute.

[rwalle]

And I just want a reasonable font size. On desktop it is miserable -- I always need to zoom to 133% to match the font size I see on other websites. On mobile it is ok.

[perilunar]

I find it way too small on desktop, but it's not an issue because the browser remembers my zoom level.

But I also find it too small on my mobile, and increasing the font size doesn't improve things, just makes it necessary to scroll sideways to read the comments.

Overall the font size settings on HN are crap. I really wish @dang would listen to the frequent complaints and fix them.

[nick__m]

I use the addon stylus on Firefox and apply a custom css. HN is really easy to customize and it never change.

[gbalduzzi]

Those two things are not related at all though

[noobermin]

So, I'm fearful of that as most people here, but if any entity can manage a respectful update, it has to be someone Y Combinator can pay.

[nightpool]

Because HN's development prioritized "good for the user" over "good for browser developers". https://www.w3.org/TR/design-principles/#priority-of-constit... https://datatracker.ietf.org/doc/html/rfc8890

Anyway, the "errors" that OP mentions are simply just deprecated attribute styling and like, one or two instances of center tags. Hardly breaking anybody's back to continue supporting those.

[nozzlegear]

Apparently not “good for the user”, given how many people here have commented about the increased font size or custom CSS extensions they need to use on HN to make it readable.

[_heimdall]

I don't know the HN codebase, but based on the HTML validation results I'd be surprised if it took more than a day or two to fix most or all of the issues.

Almost all of the warning and errors are related to using obsolete Element attributes and invalid <table> definitions. Those shouldn't need any larger rework to clean up.

I don't say this trying to imply that HN needs to fix these or are being lazy in not doing it. YC has priorities and provide HN for free. It's totally up to them whether fixes are worth it, I just wouldn't expect it to be a huge lift.

[Narretz]

All this has nothing to do with outputting standard conformant CSS+HTML.

[sharpshadow]

And no JS needed for most of the functionality.

[bastawhiz]

The HTML is immaterial. If it parses into the correct DOM (which, by all accounts, it does), there's no reason why the HTML should affect how the CSS renders.

[runarberg]

The table based layout is a nightmare for assistive technology though. I can’t even imagine how users who rely on assistive technology use this site (of which I know there are indeed plenty).

A semantically correct HTML would be something like a frontpage with an <ol> and the comment section would be a series of nested <article> each with a <header> containing the author a <time> and an extra bonus if the parent/context/sibling links can go under a <nav>. And the separators between the header elements should not be a text content pipe character `|` but rather a CSS border-inline-start: 1px solid currentcolor;

A minimal and semantically correct HTML does not only offer superior experience for users of assistive technology, it also make your page machine readable, so users can install browser plugins to e.g. do something useful with the <time> element, and ultimately makes your page much easier to style with CSS.

[its-summertime]

https://html.spec.whatwg.org/multipage/parsing.html I really love the length of this page.

[qingcharles]

Lives up to its category of "multi page"!

[arp242]

Pretty much all of the HTML validator "errors" warnings for outdated attributes and the like. The "No space between attributes" one is pretty much the only real error.

[debugnik]

Pointing the validator at this submission and filtering out obsolete elements/attributes and all warnings/info messages, I still got 221 errors: No DOCTYPE, an script element after closing the body, duplicate element ids, and invalid attributes (not obsolete, they must be be using them like data-*).

[arp242]

None of which are serious errors. Certainly not the type that introduce rendering errors.

[fallingknife]

If you remove trivial errors for no space between attributes, table formatting, and use of "obsolete" inline styling instead of CSS it really isn't many. Could be cleaned up with a couple days engineering time or less.

[its-summertime]

I think most people could clean it up within a day, maybe two at most.

Whoever is currently maintaining the codebase has taken years. They have been making changes to the HTML of the site: SVGs were added for the voting arrows as the first example I can think of, so its not like its being left to languish completely. They just don't care.