- From: Michael[tm] Smith <mike@w3.org>
- Date: Mon, 30 Sep 2013 01:10:34 +0900
- To: Jaime Iniesta <jaimeiniesta@gmail.com>
- Cc: "www-validator@w3.org" <www-validator@w3.org>
Hi Jaime, Jaime Iniesta <jaimeiniesta@gmail.com>, 2013-09-25 21:15 +0200: > Hi all, > > Validating this URL on Validator.nu makes it crash with a "Fatal Error: > Cannot recover after last error. Any further errors will be ignored." > > http://validator.nu/?doc=http%3A%2F%2Fvalidationhell.com%2Fpages%2Fabyss%2F99 > > Please notice that this site is intentionally invalid, it's the one I use > to test validators, but I thought you'd like to be notified of this issue. The reason for any "Cannot recover after last error" message you get from the validator is that in the backend we run the HTML parser in truly streaming mode. That's for performance reasons, among other reasons. However, there are some cases of parsing behavior defined in the spec which require non-streaming behavior. The document at http://validationhell.com/pages/abyss/99 has an instance of such a case. Another example is <table><input></table> which per the HTML spec needs to end up in the DOM with the <input> element foster-parented to be before the <table> start tag. If you want the HTML parser in a validator instance to not stop when in encounters errors that require non-streaming recovery, you need to alter the code for your instance to not have the parser call setStreamabilityViolationPolicy(XmlViolationPolicy.FATAL), which is the thing in the existing code that causes the validator to run in truly streaming mode. Of course if you do that you're no longer going to be running the validator in streaming mode, and no longer going to be getting the benefits of that. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Received on Sunday, 29 September 2013 16:10:46 UTC