views:

492

answers:

6

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?

A: 

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!

nickf
Transition/Strict is neither here nor there, they will both fail to parse if you server non-well-formed content as XML. But yes, checking well-formedness before it hits the user is the way to go.
bobince
+1  A: 

This doesn't answer your question but, instead, why not validate your XHTML on your server, after/when you generate it and before you send it to the browser?

ChrisW
+2  A: 

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.

+1 to all of that, except that user input is not really more dangerous in XHTML than plain old HTML; if an attacker can sneak a < in, there's an XSS security hole, which has got to be at least as bad as the YSOD.
bobince
No you absolutely should not serve xhtml as text/html -- xhtml is not html, and all those browsers that od support xhtml (eg. everything except IE) will be put into strict mode html by the doctype, so you now have IE in quirks mode html, and all the other browsers in strict mode with broken content.
olliej
+1  A: 

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

cofiem
+1  A: 

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);
})();
Christoph
A: 

I dont know myself, but before you implement a function that catches errors, you need to implement a function that loops itself constantly, without using up too much client side processing, and to time itself out if the browser closes. Polling might suck, however you need to stick with whatever works. What I'd recommend you do, is you put your xhtml to a global html editor, and then check it for errors through that. I would recommend dreamweaver or microsoft frontpage, but those dont do firefox from memory. Basicly, stick to IE. Its simpler, and if you have issues with it, it means what your trying to do is WRONG!

Raptor Jesus