I have been using a browser with an HTML5 parser for both my work and leisure browsing for a bit over a week now. I think in-browser HTML5 parsing is now ready to be tested by others as well.
If you’re the kind of person who runs Minefield nightly builds and understands the risks of doing so, you can help by running an HTML5 parsing-enabled build of Minefield to see if there are compatibility problems with real Web content or stability problems in the parser. On the other hand, if you haven’t been previously in the habit of running nightly builds of browsers, you probably shouldn’t run these builds, either, as they can eat your Firefox profile.
You can get HTML5-parsing enabled builds from the tryserver (link updated 2009-04-30) or you can build your own by pulling from the HTML5 parsing repo (if you want to modify the parser, you need to pull from the Validator.nu HTML Parser SVN repo as well).
By default, the HTML5 parser is used when text/html
content is loaded into a browsing context and when innerHTML
is set. You can make these operations to use the old HTML parser by
setting the html5.enable preference to false
via about:config. Other HTML parsing operations still
use the old parser unconditionally.
Note that these builds assign HTML elements to the
http://www.w3.org/1999/xhtml namespace unconditionally
even when the old parser is enabled. Also, the localName
DOM property no longer upper cases its return value.
The Bugzilla convention for marking bugs that pertain to the HTML5 parser but not the trunk is to start the bug summary with “[HTML5] ”. (The keyword “html5” is used for trunk HTML5 compliance issues regardless of whether they apply to parsing or other areas of HTML5.)
Happy HTML5 parsing. Please report your findings.