Jeff has been adding SVG annotation, as well as objects to his weblog design. When using SVG, the first issue that arises is serving up XHTML in order for the SVG to be processed correctly. This also means serving up your Atom feeds, accordingly.
In Jeff’s case, he’s using the object element to incorporate SVG annotating the post type. If he inlined his SVG, and wanted it processed correctly in feed readers (both big ‘ifs’–stripping out the SVG is also an acceptable response), two things need to be modified.
First, there’s an html_type option value that needs to be adjusted. The only want to do this at this time is to manually update it in the database. I had thought there was a modification made to WordPress to add this as an Administration option, but I couldn’t find it in the checked in code.
To ensure the two feed files don’t get overwritten, I have a plug-in that I use to override the location of the atom feed files, pointing the location to files in my theme directory.
This is only a temporary fix, though. The real fix would be to provide an option to set the html_type in the admin page, which then serves the weblog pages up accordingly, as well as being used to set the type in the feeds. The value should also be used to determine the output of the content in the feeds.
All of this could be done in plug-ins. What can’t, is handling input from readers when serving up XHTML pages. Input from readers enters WordPress in several different places in the code, most of which do not have hooks allowing us to override the code to provide our own. The only way WordPress will be able to effectively do XHTML is through a commitment to make this a change in the underlying base code.
Since the WordPress developers have not shown any interest in supporting XHTML, and since I haven’t seen a lot of interest in XHTML support in WordPress from my own explorations and published posts, this is just not a challenge I’ve been eager to take on.
The real question is will Microsoft support the XHTML MIME type in IE8? Not having support for XHTML is one of the major browsers is probably the biggest hold up on more widespread support for XHTML. Otherwise, I would think that the increasing interest in SVG would start generating enough movement towards XHTML to finally trickle it’s way into the WordPress community, regardless of the aversion to XHTML of the development team.
PS I would appreciate help testing my current XHTML validation in my comments. You can’t hurt anything with the way the comments are now currently moderated.