Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by shevy-java
  • 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].

    [1] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...

    by ef2k

  •   "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?
    by blakesterz
  • 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.
    by zamadatix
  • 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.

    by iLoveOncall
  • Ironically the site does not support `:prefers-color-scheme`.
    by kps
  • 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.
    by tdeck
  • 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.
    by cyanbane
  • HN is not one of them https://validator.w3.org/nu/?doc=https%3A%2F%2Fnews.ycombina...
    by personalityson
  • Seems the majority of it is just using obsolete tags, and suggesting that CSS be used instead lol

    Well, if it ain't broke...

    by Hugsbox
  • 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.
    by JSR_FDED
  • > 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".

    by teo_zero
  • I always assumed all tags should be closed.
    by elAhmo
  • p stands for paragraph. It's not a line break
    by NooneAtAll3
  • I think the closing </p> tag became required under the HTML 5 spec (2008). Before it was optional, except when using XHTML.
    by francisofascii
  • 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.
    by account42
  • 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.

    by alt227
  • 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?
    by dylan604
  • 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.
    by quectophoton
  • 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.
    by INTPenis
  • Being valid XHTML 1.0 strict was a badge of honor
    by thiht
  • 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.
    by flomo
  • 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

    by nextaccountic
  • 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.
    by pc86
  • 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.

    by jerf
  • > "Valid HTML" used to be a big deal

    To a point that there was an actual badge for it.

    by tomkarho
  • It never mattered. It only mattered that your site worked in the big browsers. Internet Explorer then, Chrome and iOS Safari now.

    Developers would write their standards-compliant code, boast about it on Slashdot, then put in the hacks and weirdnesses to make it work on IE6. They could have skipped the standards step.

    I don't say this is a good thing: I probably have XHTML pages on one of my old, private sites, and I ran them through validators.

    But it was a waste of time, just like, I dunno, using WinUI instead of Electron is now, or not using React. Go with reality.

    by alasdairking