Only 2.6% of the most visited websites have fully valid HTML(validatehtml.com) |
Only 2.6% of the most visited websites have fully valid HTML(validatehtml.com) |
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.
Specially if the context size grows to the point that wasting tokens on such trivia is not seen as too wasteful
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
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/...
Well, if it ain't broke...
Which overlaps with, but isn't the same as, JS quirks mode.
"Accessibility failures are near-universal."
<img> is missing required "src" attribute
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.
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.
Making sure a site can be used from a high-dropout or high-latency connection is an afterthought now.
Making sure a webapp can run effectively on anything but the development team's hottest new hardware is an afterthought now.
Making sure all the buttons and features still work is an afterthought now.
All of these things are on the same order of "easy" as accessibility, but the reality is that teams variously either don't know what they're doing or don't care what they're doing.
The norm for the last decade is to just to push out layers and layers of slop as fast as possible, optimizing on feature bulletpoints and "release cadence".
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?
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.