If you are doing Selenium testing using Chromedriver2 0.8 and are having problems with self-signed SSL certificates, this is a known problem and will be fixed in a subsequent release. In the meantime I found that using the Chromedriver 26.0.1383.0 still worked without problems for Chrome 27 and also did not have this SSL certificate regression in it.
I've been using MathML for a while now for some of my documentation work on 3D graphics. Unfortunately the only way at the moment is to use XHTML 1.1 modular doctype to include either or both of MathML and SVG. In HTML 5 these have become embedded content parts of the specification. So for example, using MathML would be as simple as doing:
<!DOCTYPE HTML> <html> <head> <meta charset="utf-8"> <title>MathML test</title> </head> <body> <math> <mrow> <mi>y</mi> <mo>=</mo> <msup> <mi>x</mi> <mn>2</mn> </msup> </mrow> </math> </body> </html>
Unfortunately the only browser to support either MathML or (parts of) HTML 5 at this moment is Firefox 3.5. However, the MathML or SVG embedded content did not render under 3.5. After reading John Resig's post about a new HTML parsing engine in Mozilla's Gecko engine I set out to test this engine's support by downloading the latest nightly and setting html5.enable to true in about:config and 'lo and behold, it renders as expected.
I needed to look up something within a XHTML specification over at the W3 Consortium website. So I went to the XHTML2 Working Group Home Page. I was greeted with various encoding issues. Trademarks showing up as â„¢ character sequences. Now, normally when you see a page with an Â or â at the start of a strange sequence you can be fairly certain it is a Unicode encoding, typically UTF-8. So at first I thought my auto-detect within Firefox was not turned on, checked it, no, it was definitely on. Selected Unicode as encoding myself and, indeed, the page displayed normally. So I checked the page's source. I was lovingly greeted by the following:
<?xml version="1.0" encoding="iso-8859-1"?>
I am sure most of you can appreciate the delightful irony that the organization that has a multitude of XML-based standards and specifications, which almost always use UTF-8 as default encoding, encode a page wrongly. Yes, mistakes are human, but to see something like this on the W3C site...