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.
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.
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.
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?
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.
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
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?
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.
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.
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.
(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?
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.
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...
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.
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!
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.
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.
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.
> 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".
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.
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.
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?
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.
Totally agreed.
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
I wonder how many of them only work because of things like https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
Which overlaps with, but isn't the same as, JS quirks mode.
HN is not one of them https://validator.w3.org/nu/?doc=https%3A%2F%2Fnews.ycombina...
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.
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.
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.
Ironically the site does not support `:prefers-color-scheme`.
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.
(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?
[1] https://www.who.int/health-topics/disability
Accessibility is about way more than just people who are blind.
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.
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.
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...
Honestly more than I thought
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.
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.
Honestly? I have no idea. But, hey, if it works, it works.
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!
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.
And not a single person cares. What does fully valid even mean anymore?
Legit who cares? It's not stopping people from visiting them