Rendered at 14:40:21 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jerf 23 hours ago [-]
To a first approximation, this doesn't matter anymore. "Valid HTML" used to be a big deal because when you left the HTML spec you were inviting the various browsers to interpret your non-standard HTML in differing ways, sometimes quite catastrophically so for the styling or how the Javascript would interact with the page.
This is no longer anywhere near as important as it used to be because HTML5 defines a method for turning more-or-less any sequence of bytes into the same DOM tree: https://dev.w3.org/html5/spec-LC/parsing.html And that's only the beginning of the process. I can't seem to find a good link to the whole 8.2 section of the HTML5 spec but the whole process is freaking huge. But it's defined now.
I hedge on the "more-or-less" because I'm sure there are still bugs in various parsers and perhaps there are pathological sequences that wouldn't be handled by this process, but such sequences would be very, very distant from being HTML at all. But one difference with HTML5 is that the parsers would be considered buggy; in previous versions it could be debatable what the parser should do. HTML5 should fully specify that. If it doesn't that is now a bug in the spec. I would hope it has been banged on enough at this point that any possible remaining corner cases must be pretty small by now.
It is in my considered opinion perfectly sensible to define "HTML" as "what comes out of the HTML5 parsing process" and not really be all that worried about whether this tag does or does not need to be closed before this set of tags but not this other set of tags. It is no longer such an invitation to the browsers to render things completely differently. What was once an academic concern and a user-experience concern is now largely an academic concern.
In fact, if you're handling HTML5 correctly, which is to say, using a real, conformant parser to operate on the resulting parse tree rather than trying to handle it as a string... you can't even tell the difference between "valid" and "invalid" HTML anymore! The parser will wipe that away entirely before the HTML gets to your code. That's how important it is now.
tomkarho 23 hours ago [-]
> "Valid HTML" used to be a big deal
To a point that there was an actual badge for it.
account42 7 hours ago [-]
That doesn't mean much, there was also a badge for "works best in IE".
alt227 1 days ago [-]
This is exactly why HTML is so ubiquitous, because it is so tolerant of mistakes in formatting, syntax, and just about anything else.
Most browsers will even read and process most of the things listed on this page because even if the spec doesnt say so, it just makes sense to anyway.
quectophoton 24 hours ago [-]
React.js with JSX (which people use to avoid writing HTML) is basically the opposite on its tolerance for mistakes but somehow it seems pretty popular, to say the least.
win311fwg 23 hours ago [-]
JSX is a little pickier about structure, but doesn't give much care towards conformance, which is where the bulk of HTML violations occur. I expect close to 98% of React output is also invalid, which is why users are using React and not something like Qt.
dylan604 1 days ago [-]
Is HTML that way because of it being HTML, or have browsers just decided to brute force their way into handling the slop so that people won't blame the browser for not doing it correctly?
alt227 24 hours ago [-]
In my experience a lot of the "best practice" warnings are reductive.
A couple examples from this list are not requiring a type parameter on certain tags, or style tags being valid under html and body tags but not div tags. These types of things would take extra coding in a browser to check for certain singular tags not requiring things that all others do. Therefore it is simpler to leave these checks out and leave sloppy syntax checking as it does no harm at all to the rendered markup.
You may be right in some situations, but the nature of HTML having everything applied to all tags and then selectively reduced definitely helps make it a more resilient and accommodating language.
shevy-java 24 hours ago [-]
Totally agreed.
ndiddy 24 hours ago [-]
Well it's obviously a better experience for someone who's not the page author if the browser tries to render an invalid page rather than throwing up its hands and showing an error. That way you can at least try to read the page rather than not being able to and having to track down the author and try to get him to fix his site. The "strict parsing" fans tried to force correctness with XHTML, but it was a failure and didn't see much use.
The main problem with "handling the slop" used to be that different browsers would render invalid HTML differently, so poorly written sites could look very different depending on the browser you used. Modern HTML standardizes how browsers handle invalid HTML so this isn't a problem anymore. See https://html.spec.whatwg.org/multipage/parsing.html
sublinear 11 hours ago [-]
Blaming the browser was the god's honest truth until fairly recently. You might be surprised to hear that IE didn't officially die until 2022. Safari and Firefox are still about 15% of users on desktop, and the situation is even worse on mobile.
It doesn't really matter if it parses correctly when the browser vendor has their own opinions about rendering and behavior. W3C specs aren't always airtight and I assume that malicious compliance is free leverage for everyone at the table that isn't Google.
All that is going to mean the users and devs suffer a bit. Even the most diligent and talented of web devs must eventually take bites of this shit sandwich along with everyone else.
A lot of the complaints in sibling threads are from people who just don't understand how bureaucratic the web is. Goes to show how quickly everything can snowball into politics. It's worth thinking about when you look at the rest of the world too.
INTPenis 24 hours ago [-]
As someone who valued that "Validated by w3c" button on my website back in the day, if a website today has FULLY valid HTML, I gaurantee you the admin is a massive nerd.
pc86 24 hours ago [-]
I also think it's pretty likely that if a website has fully valid HTML, that website makes little to no money. Because if it actually was a revenue-generating venture it's extremely unlikely the person or people behind it would be worrying about what tags have which attributes and which tags are self-closing and which aren't when it has zero impact on revenue.
INTPenis 23 hours ago [-]
Oh yeah, it's a labor of love. But it might be the corporate website of a business that makes a lot of money, not through the website though.
nextaccountic 23 hours ago [-]
That's actually a good point, your markup can reveal some info about you. Like, today this kind of info is mostly unnoticed, because there are too much details in the world and too few eyeballs to notice them. But in the (not so distant) future AI agents might be able to do a lot of inference by drawing from info like "this person hand-authored their website since the 2000s and cared a lot about obscure details etc etc"
Specially if the context size grows to the point that wasting tokens on such trivia is not seen as too wasteful
flomo 23 hours ago [-]
IIRC, that "w3c validator" was overly strict, and would error on attributes it didn't recognize, even though they were technically 'valid' (and supported in ~every browser). So there were always a couple things like, ehhh, doesn't matter.
thiht 23 hours ago [-]
Being valid XHTML 1.0 strict was a badge of honor
account42 23 hours ago [-]
The claim in the title does not match the linked website. The 2.6% figure only includes websites that also follow some arbitrary set of "best practices" in addition to being valid HTML, some of which actually contradict best practices from the past.
teo_zero 23 hours ago [-]
> An unclosed tag occurs when an opening HTML tag like <div>, <p>, or <span> is missing its corresponding closing tag.
Since when does <p> requires a closing tag? Note that TFA lists this among "spec violations" and not merely "best practices".
francisofascii 23 hours ago [-]
I think the closing </p> tag became required under the HTML 5 spec (2008). Before it was optional, except when using XHTML.
NooneAtAll3 23 hours ago [-]
p stands for paragraph. It's not a line break
ahakki 23 hours ago [-]
The spec on <p>:
"The start tag is required. The end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <details>, <div>, <dl>, <fieldset>, <figcaption>, <figure>, <footer>, <form>, h1, h2, h3, h4, h5, h6, <header>, <hgroup>, <hr>, <main>, <menu>, <nav>, <ol>, <pre>, <search>, <section>, <table>, <ul> or another <p> element, or if there is no more content in the parent element and the parent element is not an <a>, <audio>, <del>, <ins>, <map>, <noscript> or <video> element, or an autonomous custom element." [0][1]
Nonetheless, <p> is automatically closed by the occurrence of another block-level element, like another <p> tag or ones like <div> or any header. <li> and <tr> have similar rules. We close them because we're not savages and want to see container tags balanced in the editor, but the html5 spec doesn't strictly require it.
elAhmo 23 hours ago [-]
I always assumed all tags should be closed.
darrenf 23 hours ago [-]
AIUI plenty of tags don't need to be closed. `<input>`, `<hr>`, `<img>` are the first three off the top of my head. Probably in XHTML you would've self-closed them.
account42 7 hours ago [-]
Those are different from <p> as they are always self-closing immediately and thus cannot even be manually closed. <p> is only automatically closed if there is no </p> before the next block element.
JSR_FDED 1 days ago [-]
50% of my errors are “<font> is deprecated”. If browsers stop supporting that I’m guessing huge swathes of the web will be affected, so I’m guessing it will never happen.
Seems the majority of it is just using obsolete tags, and suggesting that CSS be used instead lol
Well, if it ain't broke...
cyanbane 1 days ago [-]
I would def argue this is a feature of the net ( that people from all walks of browsers can see mostly the same thing ) and not a bug.
blakesterz 1 days ago [-]
"Accessibility failures are near-universal."
Why does it seem like Accessibility is always an after thought? It is usually so easy to do while a site is built. We just don't think about it until someone complains?
tdeck 1 days ago [-]
Almost nobody is testing their website with a screen reader so they don't think of it as part of the user experience. In fact, I think most developers are only vaguely aware of what web accessibility actually is for and how it affects users.
wasmperson 23 hours ago [-]
I'm curious about how many test with a screen reader even among those who do claim to care about accessibility. Most advice online around accessibility is about using alt attributes and semantic html tags or whatever, not testing your site with accessibility tools.
tdeck 4 hours ago [-]
Probably not much. Personally I think it's worthwhile because it becomes obvious exactly how broken the user experience is and makes it more motivating to fix (for me). It's pretty obvius what the problem is when all your buttons are just called "button", for example. But there is a learning curve for using a screen reader.
kps 24 hours ago [-]
Ironically the site does not support `:prefers-color-scheme`.
throwlifeaway 23 hours ago [-]
prefers-color-scheme is not an accessibility feature. The idea that dark mode matters for accessibility is a meme.
xigoi 6 hours ago [-]
Being able to read a website at night without blinding yourself is a part of accessibility.
kps 23 hours ago [-]
Dark mode is bad for people with astigmatic halation.
Light mode, I've read, is worse for people with cataracts.
Visual accessibility doesn't just apply to the totally blind. There's a reason things like WCAG exist.
--
I can't reply to the reply, but if I've been mislead, can someone persuade me to see dark mode text clearly? It would help a lot.
throwlifeaway 23 hours ago [-]
[dead]
zamadatix 24 hours ago [-]
prefers-color-scheme has shipped for something like 7 years now and not even all of the major sites I frequent which already have a dark theme toggle support it yet. Obviously accessibility is more important than a dark theme (though it can be part of an accessibility story), but if it takes a minute to ship prefers-color-scheme on those existing themed sites and it's been so many years you get the idea of how little it's about when something is easy or not.
account42 23 hours ago [-]
The problem with prefers-color-scheme is that it doesn't indicate an actual user preference since the default is not "no preference" (which used to exist as a possible value in at least FF before it was intentionally removed) but rather whatever the OS/browser picked. So any website that wants to choose a "default" appearance but still provide choice to users who actually care cannot use this mechanism at all.
zamadatix 8 hours ago [-]
It can use this mechanism, it just has to default to not using it. E.g. look at LinkedIn.
23 hours ago [-]
iLoveOncall 24 hours ago [-]
Because 0.5% of the world population is blind and it costs much more than an extra 0.5% to make a website accessible?
Everytime this question is asked I wonder if people are genuinely not understanding that. It's just not financially worth it.
I'm not defending this position, but it's just glaringly obvious.
robin_reala 24 hours ago [-]
(a) accessibility is about all disabilities, not being blind
(b) overall “significant” disability levels are more like 16% [1]
(c) the 16% is at any one time. The chances of us all experiencing disability during our lifespan are much higher
(d) accessibility is a legal requirement for many systems in many regions. Even if you’re not engaging with a region with a legal requirement yet, do you want to have to build from scratch when you do?
Accessibility is about way more than just people who are blind.
ef2k 23 hours ago [-]
The number is eye-catching but it's measuring how non-conforming the source code is, as opposed to whether it results in the intended DOM. This is why HTML validators largely went out fashion since it's more practical to consider source "valid" if it renders correctly in the browser. The way the browser handles non-conforming source code is part of the spec [1].
As an aside, what is up with the design of clearly vibe-coded websites? You can tell it's AI from intuition, but is there a list of "tells"? Like black background, gradient text, font? Would love to learn more and how to combat
Which overlaps with, but isn't the same as, JS quirks mode.
simonw 24 hours ago [-]
<img> is missing required "src" attribute
On 1,093 sites, 41.2% of the sample?
maverwa 20 hours ago [-]
My guess for this would be that sites leave it unset in the rendered html and set it from some attribute dynamically from Js to enable lazy loading of images? loading=lazy is somewhat „new“ and the behavior may not be exactly what hat every one wants? But that’s pure speculation.
collabs 1 days ago [-]
I would be interested to see if the metric moves meaningfully based on switching to a different set of parameters for example running from the US vs the EU and multiple attempts over multiple days to see if anything changes...
sublinear 11 hours ago [-]
I take this to mean that only 2.6% of these websites are trivial enough to be written with a tiny subset of HTML.
shevy-java 24 hours ago [-]
The question is how important it is to have fully valid HTML.
The HTML validator complains about a ton of useless crap IMO. At one point I simply gave up on that. Just blindly adhering to that validator makes little sense really.
hodder 1 days ago [-]
And not a single person cares. What does fully valid even mean anymore?
24 hours ago [-]
wild_pointer 23 hours ago [-]
Honestly more than I thought
xyst 19 hours ago [-]
hn receives a "D" grade with 139 errors, 37 warnings
Someone has been slacking in the self proclaimed "hacker" news feed
account42 6 hours ago [-]
Hackers care more about making things work than what some standards busybody thinks should be the best practices today. In particular, avoiding all errors and warnings means needlessly breaking backwards compatibility with older or simpler browsers whereas the so-called "deprecated" attributes and elements work just fine everywhere and in many cases have no real disadvantage.
theo_dcrx 1 days ago [-]
[flagged]
mervz 24 hours ago [-]
Legit who cares? It's not stopping people from visiting them
rogix 1 days ago [-]
At this point, with all the tools available, if your site does not have fully valid HTML, it is because you don't care. LLMs are your friends, dev.
pc86 24 hours ago [-]
What does "fully valid HTML" get you that "mostly-valid HTML" doesn't?
I'm not trying to be flippant but this just seems like a really silly thing to aim for and an even sillier thing to try to shame people about when ~98% of websites that people use just fine don't do it.
system7rocks 24 hours ago [-]
When I met my future wife, the first thing she did was to check if my personal homepage was fully validated. It was. And we are celebrating 20 raucous years this year!
rogix 23 hours ago [-]
Honestly? I have no idea. But, hey, if it works, it works.
pc86 32 minutes ago [-]
The whole point is that it works fine without being valid. So your two comments seems diametrically opposed to each other.
This is no longer anywhere near as important as it used to be because HTML5 defines a method for turning more-or-less any sequence of bytes into the same DOM tree: https://dev.w3.org/html5/spec-LC/parsing.html And that's only the beginning of the process. I can't seem to find a good link to the whole 8.2 section of the HTML5 spec but the whole process is freaking huge. But it's defined now.
I hedge on the "more-or-less" because I'm sure there are still bugs in various parsers and perhaps there are pathological sequences that wouldn't be handled by this process, but such sequences would be very, very distant from being HTML at all. But one difference with HTML5 is that the parsers would be considered buggy; in previous versions it could be debatable what the parser should do. HTML5 should fully specify that. If it doesn't that is now a bug in the spec. I would hope it has been banged on enough at this point that any possible remaining corner cases must be pretty small by now.
It is in my considered opinion perfectly sensible to define "HTML" as "what comes out of the HTML5 parsing process" and not really be all that worried about whether this tag does or does not need to be closed before this set of tags but not this other set of tags. It is no longer such an invitation to the browsers to render things completely differently. What was once an academic concern and a user-experience concern is now largely an academic concern.
In fact, if you're handling HTML5 correctly, which is to say, using a real, conformant parser to operate on the resulting parse tree rather than trying to handle it as a string... you can't even tell the difference between "valid" and "invalid" HTML anymore! The parser will wipe that away entirely before the HTML gets to your code. That's how important it is now.
To a point that there was an actual badge for it.
Most browsers will even read and process most of the things listed on this page because even if the spec doesnt say so, it just makes sense to anyway.
A couple examples from this list are not requiring a type parameter on certain tags, or style tags being valid under html and body tags but not div tags. These types of things would take extra coding in a browser to check for certain singular tags not requiring things that all others do. Therefore it is simpler to leave these checks out and leave sloppy syntax checking as it does no harm at all to the rendered markup.
You may be right in some situations, but the nature of HTML having everything applied to all tags and then selectively reduced definitely helps make it a more resilient and accommodating language.
The main problem with "handling the slop" used to be that different browsers would render invalid HTML differently, so poorly written sites could look very different depending on the browser you used. Modern HTML standardizes how browsers handle invalid HTML so this isn't a problem anymore. See https://html.spec.whatwg.org/multipage/parsing.html
It doesn't really matter if it parses correctly when the browser vendor has their own opinions about rendering and behavior. W3C specs aren't always airtight and I assume that malicious compliance is free leverage for everyone at the table that isn't Google.
All that is going to mean the users and devs suffer a bit. Even the most diligent and talented of web devs must eventually take bites of this shit sandwich along with everyone else.
A lot of the complaints in sibling threads are from people who just don't understand how bureaucratic the web is. Goes to show how quickly everything can snowball into politics. It's worth thinking about when you look at the rest of the world too.
Specially if the context size grows to the point that wasting tokens on such trivia is not seen as too wasteful
Since when does <p> requires a closing tag? Note that TFA lists this among "spec violations" and not merely "best practices".
"The start tag is required. The end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <details>, <div>, <dl>, <fieldset>, <figcaption>, <figure>, <footer>, <form>, h1, h2, h3, h4, h5, h6, <header>, <hgroup>, <hr>, <main>, <menu>, <nav>, <ol>, <pre>, <search>, <section>, <table>, <ul> or another <p> element, or if there is no more content in the parent element and the parent element is not an <a>, <audio>, <del>, <ins>, <map>, <noscript> or <video> element, or an autonomous custom element." [0][1]
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[1] https://html.spec.whatwg.org/#the-p-element
Well, if it ain't broke...
Light mode, I've read, is worse for people with cataracts.
Visual accessibility doesn't just apply to the totally blind. There's a reason things like WCAG exist.
--
I can't reply to the reply, but if I've been mislead, can someone persuade me to see dark mode text clearly? It would help a lot.
Everytime this question is asked I wonder if people are genuinely not understanding that. It's just not financially worth it.
I'm not defending this position, but it's just glaringly obvious.
(b) overall “significant” disability levels are more like 16% [1]
(c) the 16% is at any one time. The chances of us all experiencing disability during our lifespan are much higher
(d) accessibility is a legal requirement for many systems in many regions. Even if you’re not engaging with a region with a legal requirement yet, do you want to have to build from scratch when you do?
[1] https://www.who.int/health-topics/disability
[1] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
Which overlaps with, but isn't the same as, JS quirks mode.
The HTML validator complains about a ton of useless crap IMO. At one point I simply gave up on that. Just blindly adhering to that validator makes little sense really.
Someone has been slacking in the self proclaimed "hacker" news feed
I'm not trying to be flippant but this just seems like a really silly thing to aim for and an even sillier thing to try to shame people about when ~98% of websites that people use just fine don't do it.