This answers some of the most frequently asked questions that aren't dealt with (or that people overlook) in the documentation and the apachetutor tutorial.
That depends entirely on libxml2. mod_proxy_html supports charset detection, but does not itself support any charsets. It works by passing the charset detected to libxml2 when it sets up the parser.
This means that mod_proxy_html inherits its charset support from libxml2, and will always support exactly the same charsets available in the version of libxml2 you have installed. So bug the libxml2 folks, not us!
libxml2 uses utf-8 internally for everything.
Generating output with another charset is therefore an additional
overhead, and the decision was taken to exclude any such capability
from mod_proxy_html. There is an easy workaround: you can transcode
the output using another filter, such as mod_charset_lite.
In practice, this causes complexities for a few users. It is under review, and future versions of mod_proxy_html may support output transcoding, or alternatively may offer better integration with mod_charset_lite including arbitrary determination of HTTP and "meta" charset declarations.
It doesn't. Your javascript is simply too badly malformed, and libxml2's error correction isn't what you expect! Check it with a validator, or with libxml2's xmllint --html (which uses the same parser as mod_proxy_html). Here is a fuller explanation.
The best fix for this is to remove the javascript from your markup, and import it from a separate .js file. If you have an irredeemably broken publishing system, you may have to upgrade to mod_publisher or resort to the non-markup-aware mod_line_edit.
mod_proxy_html is based on W3C HTML 4.01 and XHTML 1.0 (which are identical in terms of elements and attributes). It supports all links defined in W3C HTML, even those that have been deprecated since 1997. But it does NOT support proprietary pseudo-HTML "extensions" that have never been part of any published HTML standard. Of course, it's trivial to add them to the source.
This has been the most commonly requested feature since mod_proxy_html 2.0 was released in 2004. It cannot reasonably be satisfied, because everyone's pet "extensions" are different. mod_proxy_html 3.0 will deal with this by taking all HTML knowledge out of the code and loading it from httpd.conf instead, so admins can meet their own needs without recompiling.