Ultimately, Slowparse's error reporting is really about making writing HTML/CSS easy and fun for the user rather than confusing and error-prone. Really fatal errors like unclosed quotes and comments are ideal for this, because browsers will silently fail when given such input and present documents to the user that are extremely likely to be quite different from the their expectations.
However, clients should be able to build UIs on top of Slowparse that aren't obsessively pedantic. There are many "minor" errors like CLOSE_TAG_FOR_VOID_ELEMENT (see #20) which are treated as fatal but nonetheless aren't that bad in practice--browsers still work fine when such errors are present and most people write HTML for years without knowing that such things are technically incorrect.
So, we should add an option to Slowparse.HTML() that allows such errors to be reported as warnings instead of fatal errors. We might even want to simply cease reporting them as errors and only report them as warnings.
Note that we also currently have a class of fatal errors that aren't actually pedantic, but which represent "technically valid code that likely doesn't do what you expect it to". See #21 and UNQUOTED_ATTR_VALUE for examples of these. We may also want to report these as warnings rather than fatal errors.
Another option at the API level is to simply define a set of errors that can be recovered from, and allow clients to pass in a list of which ones they want to enable recovery for. This would allow individual clients to tailor their UIs to their particular audiences, rather than being forced to comply with our classifications, which are likely to be tailored to people who have never seen HTML/CSS before.
I just blogged about some things relevant to this bug in a new post entitled Learning and Grammatical Forgiveness.