How to Provide Feedback For the W3C Markup Validator
There are many ways to send feedback or discuss the Markup Validator:
Finding help on validation and Web authoring
Your page doesn't validate, and you don't know why, or you have a question about HTML, stylesheets or validation?
The two most common problems are:
Validating pages with
ampersands (&'s) in
Validating pages with
If your problem isn't covered by one of the resources above, you can send it to one of the following forums:
Each of these forums have plenty of experienced HTML authors who are willing to share their expertise. If you are commenting on a specific page, be sure to provide a URL when you ask your question!
Error message feedback
If you think the error messages in the Markup Validator's result pages could be improved, or are not comprehensible, you can send questions and suggestions to our mailing-list.
If you do not understand an error while validating a page, or if you need help on validation, read the FAQ and help (see the section Finding help on validation) and search the list archives for existing mail threads on the topic before sending any message to the mailing-list.
Judging from the link you followed, you probably want to send feedback on error message : "unclosed start-tag requires SHORTTAG YES".
Before you send any feedback on error messages, we encourage you to search the archives for existing messages on this error in case your feedback has already been sent, or answers to your query have already been given.
Below is a pre-filled search box that you can use. Or you can just follow this link.
Once you have checked that your suggestion has not been given yet, you can send your message. To write an efficient message:
- Add a meaningful subject line: summarize your feedback in a handful of words;
- If our system added [VE] at the beginning of the mail subject, keep it. Otherwise, please precise which error message you are sending feedback about;
- Give some context. Generally speaking, this means give the URL of the page you were trying to validate. The more context you give, the easier it will be for others to understand your problem, question or feedback.
- What is your feedback?. Explain your suggestion, or question, in a clear and informative manner. Be precise and thorough.
Once you have checked all the criteria above, send your message to the www-validator public mailing-list.
Discuss and participate
If you are interested in helping to improve this service, by writing code or just providing ideas, you should feel free to join or send a message to our mailing-list.
The public mailing-list to discuss the Markup Validator, Link checker and other tools is
You can subscribe to the list (and unsubscribe), or if you just have a small patch or idea and don't want to join the list, feel free to send it directly to the list. But whatever you do, always use the mail search engine first to check for existing messages on a given topic.
If you just want to have an informal discussion with developers and users of the Validator, you may also join the IRC channel #validator on the freenode network (irc.freenode.net). However, please keep in mind that this is not a support channel.
The W3C maintains a public bug tracking database known as Bugzilla where developers and other technical users can log bug reports and feature suggestions directly. If you are not familiar with issue tracking systems in general or the Bugzilla bug tracker, send your feedback to the mailing list and someone on the W3C Validator Team will take care of logging your issue as appropriate.
Before you enter a new bug in this database, we strongly encourage you to check that it is not yet in the list of opened issues. Here are a few links that you can use:
- W3C issue tracking system homepage
- All open Markup Validator issues
- All Markup Validator issues
- Search Markup Validator issues
- New Markup Validator issue
If you encounter an HTML 5 related issue in the W3C validator, before reporting it in the W3C Bugzilla, see if you can reproduce it also with Validator.nu. If you can, report it according to the Validator.nu bug reporting instructions instead. This inconvenience is because the W3C validator uses the Validator.nu engine which is developed and maintained by a different team than the W3C validator to validate HTML 5 documents, and addressing bug reports directly to the team working on the system in question is likely to result in better and more timely responses.