Show less errors
2nd September 2003
The W3C Validator team are seeking help with the latest version of their validator, dubbed the “Zeldman Made Us Do It!” release. They want people to play with the beta and submit suggestions for error messages that would make more sense to the average user. They also have a new feature called “fussy mode” which acts a bit like a lint tool for checking code, highlighting problems that aren’t necessarily illegal markup but may not be best practise techniques.
It’s great to see improvements to error messages being made (a classic example is the head-scratch-inducing “NET-enabling start-tag requires SHORTTAG YES”, which means you used <br />
or <img />
in a normal HTML document) but in my opinion the best thing the validator could possible do is display less errors. Let’s take CNN.com as a classic example of an invalid page. Feed it through the new validator and you get a list of 206 errors that scrolls for pages and pages. The average non-standards clued up web designer is going to take one look at that list and give up on the spot: the site works in all the browsers they have tested, and fixing 206 errors is just going to be a waste of their time. I can distinctly remember thinking that exact thing the first time I tried the validator, and consequentially ignoring it for well over a year afterwards.
Anyone who’s managed to fix up a page using the validator before will know that errors frequently cascade: one missing tag can cause a dozen or so related errors on the page, which all vanish when the initial missing tag is re-added. Further, a lot of errors boil down to exactly the same concept. If a designer has forgotten to escape the &s in the URLs on a page it could add a hundred or so extra errors to the validation results. They only need to be told once. If the validator came back with a condensed list of 6 or 7 errors along with human explanation and a note that the error occurred X times on the page it would be far less likely to send people recoiling in horror from information overload. Such a condensed report would not need to be the only interface to the validator, although I would recommend it as the default interface simply because advanced users can work out where the “verbose” option is themselves; it’s the newbies who need a helping hand and a condensed, easily understood report.
I submitted this suggestion to the validator mailing list a few days ago, but as I haven’t had any replies there I thought I’d throw it open to the blogging community to see what people think.
More recent articles
- Qwen2.5-Coder-32B is an LLM that can code well that runs on my Mac - 12th November 2024
- Visualizing local election results with Datasette, Observable and MapLibre GL - 9th November 2024
- Project: VERDAD - tracking misinformation in radio broadcasts using Gemini 1.5 - 7th November 2024