Kwabena Owusu

I find a validation error interesting only once I know what the consumer does with it, which means reading the specification rather than the error message. A page can validate completely and render in a way nobody intended, because validation says nothing about whether the elements chosen are the right ones. It is a grammar check, and a useful one: most real problems on a page come from a stray unclosed tag or an attribute quoted wrongly, and both are grammar errors.

Some HTML errors are load-bearing. An unclosed element changes the structure of everything after it. A duplicated attribute is resolved by taking the first and discarding the second, silently.

An attribute value containing an unescaped ampersand turns the following text into an attribute name. Each of these produces a page that renders and is wrong, which is why an error count of zero matters less than the absence of structural errors. CSS has an equivalent set. A selector that matches nothing fails silently, and an invalid declaration is dropped while the rest of the rule applies.

The result is a rule that mostly works and is not quite doing what the author thinks. Schema validation is the same idea at the data layer, and the pipeline is worth stating: parse, then validate against a schema, and treat the two as separate results, because a document can be well formed and invalid. The pattern repeats across all four formats: parse the structure first, validate the meaning second, and report which one failed rather than merging them into a single count.