The default javascript API uses document.write, which isn’t a DOM method and hence is not a method of true XML documents. It’s not a new issue either, wp-recaptcha has had a history of breaking XHTML. The thing is, the WordPress plugin (which uses the PHP library by the recaptcha people) has an option to “Be XHTML 1.0 Strict compliant”; but this only fixes the use of iframes and noscript!

Updated: pushed fork to github

Under firefox, you get an error like:

Error: uncaught exception:
[Exception... "Operation is not supported"  code: "9"
 nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
 location: "http://www.google.com/recaptcha/api/challenge?k=xxx Line: 12"]

While under Chrome it’s

Uncaught TypeError: Object #<a Document> has no method 'write'
api.recaptcha.net/challengek=xxx

The real solution is to use the reCAPTCHA AJAX API, which for whatever reason isn’t exposed in the PHP library. You can grab my xml fix for wp-recaptcha from github.

Error: undefined entity
Error: uncaught exception: [Exception...
 "Component returned failure code: 0x80004003
 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]"
  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"
  location: "JS frame :: hxxp://example.net/prettify.js ::
             replaceWithPrettyPrintedHtml :: line 1414"
  data: no]

My insistence on trying to use XHTML on the blog is partly to blame. Prettify tries to add “ ” entities to the source (even if it’s a pre element) to appease Internet Explorer. This entity only semi-works in XHTML: I’ve run into similar problems with some HTML entities not being loaded, because some browsers don’t load the DTD (which in turn loads the entity sets). It also appears that while Firefox claims to support HTML latin 1 entities in a document with a PUBLIC XHTML identifier, it doesn’t actually reparse innerHTML assignments according to those rules.

My solution is to add a conditional test for XML. Having a look at the Javascript document object there doesn’t seem to be a reliable way to detect whether the browser is treating the document as XML from javascript. My best attempt was:

document.xmlVersion && (document.compatMode=='CSS1Compat');

which works for Firefox and Opera.

As a separate issue, Chrome and Safari (and presumably anything WebKit based) don’t allow assignment of innerHTML for XML documents, giving NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7.
Fixing prettify to use only DOM methods instead of building up a string and assigning it to innerHTML could be a lot of work. At least this exception, unlike the Firefox error, doesn’t leave the pretty-printed block in an inconsistent state.

I submitted a patch to the prettify issue tracker.