Can I detect XHTML parsing errors using Javascript?

Question

When I have a markup error in my XHTML page, Mozilla Firefox displays the "Yellow Screen of Death", showing only a large red error message on a yellow background.

While these errors are rare, they are extremely user-unfriendly.

Is there a way I can detect these using Javascript, and thereby send a message back to the server?

What I've discovered so far: - Scripts placed before the parsing error still run. (Of course.) - Timeouts and intervals that were set in these scripts will still execute after the parsing error. - In Firefox, the DOM is a <parsererror> with a <sourcetext> inside it. I can detect this if I query document.firstChild.tagName .

Remaining questions: - What events are available that I could listen for to detect this happening? (Polling sucks.) - How can I detect this in other browsers?

Answer 1

Catching parse errors on the client might be possible, but it's really solving the wrong problem.

I know this isn't what you asked for, but unless you're doing something truly XHTML-specific like embedding some other markup language, you should serve your page as text/html instead of application/xhtml+xml. Even if it's XHTML. By serving it as text/html you'll avoid the problem you're running into and allow your page to work in IE as well. Note that it's the MIME type and not the doctype declaration that determines which parser is used -- using a transitional doctype won't do it.

That said, if you're really sure you want your page parsed as XHTML, it's better to handle this kind of error on the server. Generate your page by building up a DOM and then send the result of serializing it. If that's not an option, then start by generating the page as you do now but don't transmit it to the client yet. Take the XHTML that you've generated and parse it server-side with a validating XHTML parser (or at the very least, a generic XML parser). If you get errors, display whatever error page you want. Otherwise, serialize the parsed DOM and send that to the client.

In summary, the basic rules for using application/xhtml+xml are:

1. Don't.
2. (For advanced users) Don't, unless you've proven that you're doing something that won't work if the page is served as text/html. This applies to a tiny, tiny fraction of a percent of XHTMl documents.
3. If you must serve your page as application/xhtml+xml, generate it with some method that guarantees validity.
4. Unless you really know what you're doing, never use application/xhtml+xml for a page that includes user input.

Remember that XHTML is just a reformulation of HTML 4 plus the ability to embed other languages. If you don't use the embedding, what you have is HTML 4 with a different but almost completely compatible syntax. The overwhelming majority of XHTML documents out there are served as text/html and thus treated like HTML 4 by browsers.

Answer 2

这并不能回答您的问题，而是为什么不在生成XHTML之后/之后以及在将其发送到浏览器之前不验证服务器上的XHTML？

Answer 3

My first question would be: Since Internet Explorer does not easily allow you to actually specify application/xhtml+xml as the mime type, nor support it all that well, why do you need to detect XHTML parse errors?

As for detecting the errors - have a look at http://www.quirksmode.org

Answer 4

I'd recommend validating the document on the server side. But if you really want to do it on the client side, there's nothing wrong with polling if done correctly (which means that the poll is guaranteed to terminate).

The following should work in at least Firefox and Opera:

(function() {
    if(document.documentElement &&
        document.documentElement.getAttribute('xmlns') !==
        'http://www.w3.org/1999/xhtml') {
        alert('parsing errors');
    }
    else if(document.body && document.body.lastChild) {
        alert('no parsing errors');
    }
    else setTimeout(arguments.callee, 100);
})();

Answer 5

I know it's probably not the most helpful answer, but have you considered switching to a transitional doctype?

By all means, put your files through a parser to detect errors, but do it offline - the risk of showing users the YSOD is not worth it!