Symphony.

I was just looking at a new blogging software called Habari and while reading some parts of it's wiki I found a statement about why they use HTML 4 instead of XHTML. It's an interesting point of view and I started to investigate some more about this "Faux XHTML" concept.

I just wanted to know Symphony's comunity opinion on this. Also, one of their arguments is that it's hard to control what posts and comments do to an XHTML document (creating non-valid XHTML), but considering Symphony's nature and that everything needs to be valid XML before being processed by XSLT and therefore is valid XHTML, why does Symphony still serves pages as text/html instead of application/xhtml+xml.

why does Symphony still serves pages as text/html instead of application/xhtml+xml.

Not all browsers support the latter declaration.

Not all browsers support the latter declaration

I should have expected that...

Symphony will send a Content-Type: text/html header with pages by default, but this can be overridden on pages you want to serve with a different MIME-type. The XSLT processor automatically adds

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

when you set an HTML doctype via xsl:output. (This is quirk specific to LibXSLT; Saxon, for example, will let you set your own or omit this element.) There was a discussion about this a while ago, if you want more info.

In response to the article linked, both Faux XHTML and HTML4 Strict will trigger the same rendering mode in browsers, and it's really up to the author to decide which one to use. HTML5 is another option too, but it's a little more effort to produce with XSLT currently.

The main problem here I think isn't to do with what output Symphony generates, but the strict requirement that field values must be valid XML. Symphony runs field values through an XML parser before saving them, so there's no chance that invalid data can get through the gates (and thus completely break any page using a DS that fetches those invalid fields). But its response to the user who entered that invalid data in the first place is completely unhelpful: Symphony just says "Oops, this is invalid XML. You'll need to fix that before I'll let you save it." which is meaningless to non-technical users, but worse, the problem may lie in the text formatter code, and especially with complex or multiple text formatters, it's really hard to guarantee valid final output for all possible input.

This can't really be solved in the short term; it's just a consequence of using XSLT. In the future, when the HTML5 spec for deterministic DOM tree parsing from any input (regardless of XML-validity) makes its way into PHP's DOMDocument implementation, Symphony will truly be able to gracefully handle bad input, and in many circumstances recover the correct DOM tree.

@Scott Thanks for the link, I never check Overture since I discovered Symphony after S2 beta 5.

For an interesting discussion of the issue from a browser author's point of view, see "Understanding HTML, XML and XHTML" by Maciej Stachowiak:

http://webkit.org/blog/68/understanding-html-xml-and-xhtml/