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 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!

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.

Updated: pushed fork to github

The situation is this: imagine you have a faceted plot that is tall enough that the x-axis ticks and labels become obscured (e.g. when using a clipped viewport such as a browser window). This is particularly destructive when you’re using an x-scale with manual breaks or a transformation.

library(ggplot2)
g <- ggplot(diamonds, aes(carat, ..density..)) +
   geom_histogram(aes(fill = clarity), binwidth = 0.2) +
   facet_grid(cut ~ .)
print(g)

There simply isn’t a way to repeat the x-axis labels in ggplot2 at the moment without discarding faceting and rendering each facet as a separate ggplot call. I’ve seen some examples of selective plotting used to good effect in combining multiple plots with common elements, but I can’t find anything applicable to keep consistent scales and binning without duplicating a lot of the (internal) facet and bin logic.

Instead my best shot was to clone some of the grob elements and redraw them at different locations:

grob <- ggplotGrob(g)
xtext <- getGrob(grob, "layout::axis_h::axis.text", grep = TRUE)
xtext <- editGrob(xtext, gp = gpar(fontsize = 8))
downViewport("background::panels::layout::axis_h-13-3") # ids from grid.ls()
pushViewport(viewport(y = unit(34, "npc"), name = "axis_h_rep-1"))
 grid.draw(xtext)
popViewport()

Unfortunately I couldn’t find a consistent way of querying the grid graphics internals for the measurements necessary to move the “mirrored” axis labels to the right place. The 34 there is a magic number I found with grid.locator() and trial-and-error; it changes depending on the graphics device. At one point I hoped I could clone the entire axis_h viewport, pry some vertical space from in between the facet panels, and paste the clones in between. Unfortunately grid layouts don’t seem to be very mutable once they’ve been created, and redrawing the text grob seemed like the best I could do to reuse the output.

While looking at the stackoverflow answer for the same problem, I came across Harlan’s assessment:

GGplot’s philosophy is about doing the right thing with a minimum of customization, which means, naturally, that you can’t customize things as much as other packages.

This is more significant when contrasted with the context of R itself; in R, the user retains full control. Coming up against ggplot’s choice of only exposing high-level primitives often leaves the user with the choice of:

• accepting The Way ggplot Does Things and not getting what they want
• waiting for Hadley to write a patch (next summer, if you’re lucky?)
• wading through ggplot internals so you can duplicate its functionality with plyr and grid calls
• abandoning ggplot completely

Ubuntu and Debian ran into plenty of bashisms when they tried to change, how about Mac OS X? So far I’ve found problems with /usr/libexec/path_helper (I just changed the shebang line to #!/bin/bash). There was also a problem with X11′s startx, and my patch was quickly committed.

Interestingly enough, when I went to move the sh binary, there are actually two versions of bash in /bin. Both report

GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)

but differ at the binary level (they aren’t even the same size). I wonder if Apple tried to optimize their /bin/sh given that it gets more usage.

I built dash-0.5.5.1 from the tarball without a problem.

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.