3 ms·

https://meiert.com/en/blog/valid-html-2021/ https://meiert.com/en/blog/valid-html-2021/ Most sites still don't have valid HTML. EDIT: my link is old. 98% of t

https://meiert.com/en/blog/valid-html-2021/ https://meiert.com/en/blog/valid-html-2021/ Most sites still don't have valid HTML. EDIT: my link is old. 98% of the top 100 sites had invalid HTML in 2021, in 2022 we've managed to hit 100%, great job everyone! https://meiert.com/en/blog/valid-html-2022/ https://meiert.com/en/blog/valid-html-2022/

zelphirkalt 4y ago
This does not surprise me at all, with all the "must be a web app", still treating HTML mostly as a string in many web frameworks and semantically inappropriately using tags. It is exactly as I thought, the ratio of invalid HTML has become even worse. Probably most web devs these days do not even check their websites for HTML validity, because achieving it with the frameworks they chose is hard or impossible.
- smolder 4y ago
  I think you severely underestimate "frameworks" if you think generating valid HTML is somehow harder with them than without.
dolmen 4y ago
Well, the W3C validator also has issues which do not help. For example, Wikipedia doesn't validate [0] because its CSS has "aspect-ratio: 1" which looks ok to me regarding the spec [1]. [0]: https://jigsaw.w3.org/css-validator/validator?profile=css3svg&usermedium=all&vextwarning=true&uri=https://en.wikipedia.org/ https://jigsaw.w3.org/css-validator/validator?profile=css3sv... [1]: https://w3c.github.io/csswg-drafts/css-values-4/#ratio-value https://w3c.github.io/csswg-drafts/css-values-4/#ratio-value
chrismorgan 4y ago
“Invalid HTML” is completely irrelevant. HTML parsing is defined exhaustively; “parse errors” are purely “you probably made a mistake, but I’ll keep going” indications, and all browsers will do the same thing.
- rob74 4y ago
  And that's why we can't have nice things, er, why we will never have valid HTML on a significant percentage of websites: browsers are historically very lenient with HTML errors (because otherwise they wouldn't be able to show 90% of all sites), and no one uses HTML validators to check if their HTML actually conforms to the spec. It's a chicken and egg problem really: the browsers can't be more strict because there are so many broken sites, and the sites won't be fixed because the browsers aren't strict enough.
  - arp242 4y ago
    I did a quick check, and most of the errors it reports are "unknown attribute" or "element such-and-such not allowed here". Those "errors" would be allowed anyway for forward compatibility, and aren't really a big deal. IMO the validator's definition of "invalid HTML" is just too strict; it should only count parse errors and completely non-sensible things. And the specification is also too strict at times; on my own website I have "Element style not allowed as child of element div in this context." This is because on some pages it adds a few rules that apply only to that page and this is easiest with Jekyll. I suppose I could hack around things to "properly" insert it in the head, but this works for all browsers and has for decades and why shouldn't it, so why bother? If the specification doesn't match reality, then maybe the specification should change...

zelphirkalt 4y ago

This does not surprise me at all, with all the "must be a web app", still treating HTML mostly as a string in many web frameworks and semantically inappropriately using tags. It is exactly as I thought, the ratio of invalid HTML has become even worse. Probably most web devs these days do not even check their websites for HTML validity, because achieving it with the frameworks they chose is hard or impossible.

smolder 4y ago
I think you severely underestimate "frameworks" if you think generating valid HTML is somehow harder with them than without.

dolmen 4y ago

Well, the W3C validator also has issues which do not help. For example, Wikipedia doesn't validate [0] because its CSS has "aspect-ratio: 1" which looks ok to me regarding the spec [1]. [0]: https://jigsaw.w3.org/css-validator/validator?profile=css3svg&usermedium=all&vextwarning=true&uri=https://en.wikipedia.org/ https://jigsaw.w3.org/css-validator/validator?profile=css3sv... [1]: https://w3c.github.io/csswg-drafts/css-values-4/#ratio-value https://w3c.github.io/csswg-drafts/css-values-4/#ratio-value

chrismorgan 4y ago

“Invalid HTML” is completely irrelevant. HTML parsing is defined exhaustively; “parse errors” are purely “you probably made a mistake, but I’ll keep going” indications, and all browsers will do the same thing.

rob74 4y ago
And that's why we can't have nice things, er, why we will never have valid HTML on a significant percentage of websites: browsers are historically very lenient with HTML errors (because otherwise they wouldn't be able to show 90% of all sites), and no one uses HTML validators to check if their HTML actually conforms to the spec. It's a chicken and egg problem really: the browsers can't be more strict because there are so many broken sites, and the sites won't be fixed because the browsers aren't strict enough.
- arp242 4y ago
  I did a quick check, and most of the errors it reports are "unknown attribute" or "element such-and-such not allowed here". Those "errors" would be allowed anyway for forward compatibility, and aren't really a big deal. IMO the validator's definition of "invalid HTML" is just too strict; it should only count parse errors and completely non-sensible things. And the specification is also too strict at times; on my own website I have "Element style not allowed as child of element div in this context." This is because on some pages it adds a few rules that apply only to that page and this is easiest with Jekyll. I suppose I could hack around things to "properly" insert it in the head, but this works for all browsers and has for decades and why shouldn't it, so why bother? If the specification doesn't match reality, then maybe the specification should change...