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
- llamafile is the new best way to run a LLM on your own computer - 29th November 2023
- Prompt injection explained, November 2023 edition - 27th November 2023
- I'm on the Newsroom Robots podcast, with thoughts on the OpenAI board - 25th November 2023
- Weeknotes: DevDay, GitHub Universe, OpenAI chaos - 22nd November 2023
- Deciphering clues in a news article to understand how it was reported - 22nd November 2023
- Exploring GPTs: ChatGPT in a trench coat? - 15th November 2023
- Financial sustainability for open source projects at GitHub Universe - 10th November 2023
- ospeak: a CLI tool for speaking text in the terminal via OpenAI - 7th November 2023
- DALL-E 3, GPT4All, PMTiles, sqlite-migrate, datasette-edit-schema - 30th October 2023
- Now add a walrus: Prompt engineering in DALL-E 3 - 26th October 2023