The validator's HTML is invalid too. All I get is "Enable JavaScript and cookies to continue" but of course doing that doesn't actually work either. It's crazy that even the W3C has put itself behind cloudflare's walled garden. You'd think if anyone would respect the open web and standards it'd be them. At least HN's page is actually HTML even if it might not be fully standards compliant. That's far better than the W3C's showing here.
Some lines don't have a trailing semicolon while the majority do. 0 probably doesn't need units. ".votelinks.nosee div.votearrow.rotate180" could just have one class rather than this nested thing.
The single-pixel gif as a spacer, that takes my mind back to Geocities.
Sums up software pretty well. If it works, move on to the next thing. No need to get lost in the details that a tiny handful of people see.
> And yet to see a browser that actually cares about DOCTYPE...usually its pretty obvious when the next line is <html>
How do browsers determine which mode to use?
For HTML documents, browsers use a DOCTYPE in the beginning of the document to decide whether to handle it in quirks mode or standards mode.
The DOCTYPE shown in the example, <!DOCTYPE html>, is the simplest possible, and the one recommended by current HTML standards. Earlier versions of the HTML standard recommended other variants, but all existing browsers today will use full standards mode for this DOCTYPE, even the dated Internet Explorer 6. There are no valid reasons to use a more complicated DOCTYPE. If you do use another DOCTYPE, you may risk choosing one which triggers almost standards mode or quirks mode.
Make sure you put the DOCTYPE right at the beginning of your HTML document. Anything before the DOCTYPE, like a comment or an XML declaration will trigger quirks mode in Internet Explorer 9 and older.
The only purpose of <!DOCTYPE html> is to activate no-quirks mode. Older versions of HTML standard DOCTYPEs provided additional meaning, but no browser ever used the DOCTYPE for anything other than switching between render modes.
I'm mistaken then; from the block you copy and pasted I misread it to suggest only IE 9 cares about quirks. In my personal use I'd never seen it matter cross-browser before
Of course HN works fine, if it didn't work fine it'd be fixed by now. "Working fine" is an extremely low bar for any site. As a developer you will still want to avoid quirks mode because it just makes your life harder for no reason.
I'm a bit glad to see the HTML specification evolve rather than stay backwards compatible forever. The committee drew a line between logic, layout, and content. <center> is purely layout. I'm sad to see it go for nostalgic reasons and am often confused when I need to center a non-text, non-flexbox element, but centering does belong in "layout".
I just wish the Tailwind community (and those from other big-ass CSS frameworks) would internalize this concept. It feels so unintuitive to have your compiled HTML just element after element of class="lg:block fixed inset-0 top-[3.8125rem] drop-shadow-md justify-center hunter2-blue overflow-hidden pointer-events-none"
...especially when elements like <p> have the exact same giant class definition throughout an entire page.
> And yet to see a browser that actually cares about DOCTYPE
If a web page does not have the correct doctype, browsers run it in quirks mode instead of standards mode. If a web developer is fine with their websites running in quirks mode, they are not a good web developer, and you should probably stay away from them.
This year every credible CSS expert is using grid-item-gutter-closed-start specified in qem units. Last year it was flex-interval-bound-distance: 1, auto, 100% but the spacing wasn’t artisanal enough. Many people are also discovering the Tailwind organic vintage where you just add sx-dff-7 gb-y it-9-em on all your elements.
CSS padding and border-spacing properties can be used instead (they recommend using CSS).
The cellpadding [0] and cellspacing [1] attributes are still supported but deprecated. I'm impressed by the usage numbers, though. I do not believe this will be removed from browsers anytime soon, but that's just my opinion.
IE5's box model was the good one (* { box-sizing: border-box; } is the vestigial "please use the IE box model" in almost every CSS file today). It was Netscape/early Mozilla's box model that was hard to reason with.
But also, using Tables for page layout had less to do with box layout problems and more to do with the lack of something like CSS Grid (finally, decades later). Tables let you define regular grids in a way that was closer to designing a grid (thinking in terms of spans across cells instead of widths/margins). Tables for layout didn't truly go away until around the Bootstrap era with its column grid helpers (and their complex CSS math to make that work before both flexbox and native CSS Grid).
As a Firefox partisan since back when it was still Phoenix, of course I'd argue it was IE 5's box model that sucked. But the real problem is that there wasn't one box model that behaved identically across all the popular implementations.
The old Netscape/Phoenix/Firefox box model had borders take up half-inside half-outside and doing any sort of math with it and getting things to align at all was terrible effort in CSS.
I love Firefox to this day, but mathematically the choices that box model made made sense as easier on the renderer but was awful to work with for the web developer.
It's great that we have the choice between box models today and their behavior is better standardized. I know if you surveyed CSS in the wild you'd find most CSS is written for the IE box model (border-box) and yet it is funny that that is the one you have to opt-in to because that adds to the overall impression that CSS by default is broken and needs reset stylesheets and boilerplate.
All true, but the point at which web dev more generally moved to CSS over tables was considerably later, not least because early CSS was pretty hard to find resources on and work effectively with. Firebug helped a lot from 2005 on, as of course also the browser-native devtools it inspired, but in 2007 it remained far from a surprise to see sites built in what was then still a current, if not the latest, style.
I think a lot of those are bogus, but there are some real ones such as cases where there is no space between attributes, like
<element this=“that”in=“out”/>
there are a lot of old elements being used where css could be used instead, probably if the HTML was updated like that and they were smart about selectors it would get the page size down a bit. Then there is the <doctype> thing which may seem like a lot of bullshit, I don’t know how it now but years ago it did make a difference because if you didn’t have it browsers would go into a compatibility mode with old web pages.
Part of Netscape’s competitive advantage back in the day was that it handled broken HTML in an undocumented way and broken HTML is so common that a browser that doesn’t handle broken HTML the same way is a broken browser. One of the many great things in HTML is that it defines that behavior.
It would be a fun project to CSS-ize the HN front page with an aim to minimizing size.
> Then there is the <doctype> thing which may seem like a lot of bullshit, I don’t know how it now but years ago it did make a difference because if you didn’t have it browsers would go into a compatibility mode with old web pages.
This is still true. Browsers run HN in quirks mode. Just open the devtools console in Firefox, and it will tell you.
I think it's a mistake to conflate being correct (technical property) with being right (moral judgement). Adhering to a standard is quite optional, and most HTML ever written does not. That's just the way it is. This isn't wrong, but it is incorrect.
The question is, is adhering to the HTML Standard (in other words, getting zero errors in the HTML validator) beneficial to websites? For example, does it make the job of web developers easier? Are there fewer user-reported issues in browsers?
Speaking of the HTML it would be great to have a way to increase the text size for mobile devices. The Hacker News layout doesn't look to great in reader view.
If your mobile browser is Chrome-based, there should be an Accessibility setting called "Show zoom option in main menu", which I believe then shows up between Recent Tabs and Share. I'm able to zoom HN this way.
There was a time when I demanded of myself that all the sites that I built for clients had a perfect validation score. Well, I no longer build web sites.
It's not a fool's errand. It's quite simple to do, especially incrementally. Even still, you're implying a false dichotomy; HN's HTML can certainly be much, much improved from where it is now, even if it's not perfect.
Since everything in web technology is circular he is just waiting for the page to become compliant again. It'll look impressive on the Internet Archive, so far ahead of its times! And with no effort whatsoever. This also applies to the visual style.
Ugh… Don’t get me started on HTML in emails. What was so wrong with plaintext for emails? Vomit (meant to type Comic, but the typo is staying) Sans? Non-W3 compliant contrast ratios? Nineteen embedded images?
Seriously, if I want to send you the pictures from the beach I can do it with an attachment.
Plaintext works, but as the great David Bowie said: “If it works, it’s out of date.”
