Proper XHTML handling with PHP

Hayo Bethlehem | 14 April 2006

A little known fact about XHTML 1.1 is that it can't be shown as a regular text document. XHTML is a subset of XML, and should as such be served as application/xhtml+xml, and not as text/html.

By adding some code to your documents, you can have proper xml, with proper draconian error handling. For example, we can do that using a little bit of PHP code, and putting the following bit at the very top of your XHTML documents:

<?php 
   if (stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")) {
      header("Content-type: application/xhtml+xml;charset=utf-8");
   } else {
      header("Content-type: text/html;charset=utf-8");
   }
?>

This will make sure browsers that actually support proper XHTML will show it as such, and browsers that don't have support, will not.

A side note: XHTML 1.1 should always have an UTF-8 character encoding.

Bibliography

Permanent link | Filed under: HTML and XHTML

About the Author

Hayo Bethlehem has been hooked to computers since he was four years old. Having had his first glimpse of the world wide web in 1993 (Netscape 2 was bliss), he now co-owns a small internet company called Plerion, building websites, and selling his services to all takers.

Besides being obsessed with internet he can also be found roaming the streets with his photocamera. He also does a lot of volunteer work for local media and in politics.

Articles by Hayo Bethlehem

13 Comments

| Post a comment | Comments Feed

jordan : http://ratafia.info

14 April 2006, 12:44 : Permanent link to comment

For those who are obsessive about file size, the code can be shortened to:

$content_type = stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”) ? “application/xhtml+xml” : “text/html”; header (“Content-type: {$content_type};charset=utf-8”);
Matthew Pennell : http://www.thewatchmakerproject.com/

14 April 2006, 22:21 : Permanent link to comment

For true XHTML conversion, shouldn’t the script also do stuff like remove the trailing space before the closing slash of self-closing tags and add CDATA sections around in-page style and script elements (for example, if you use @import in your HEAD element)?

True XHTML should also have stylesheets attached differently, and authors have to be aware of the way that some CSS is applied differently (e.g. styling the HTML element for backgrounds).

Also it’s not the case that XHTML must use UTF-8, but if you don’t use it you have to include the XML prolog.

Further reading: The perils of using XHTML properly
James AkaXakA : http://akaxaka.gameover.com/

15 April 2006, 00:02 : Permanent link to comment

True that Matthew, but you can do most of that stuff and still have valid HTML to send to legacy browsers.

Of course, you can just use HTML 4 for your site instead and not worry about this stuff.

Further reading: Sending XHTML (even 1.0) as text/html Considered Harmful
Sébastien Guillon : http://sebastienguillon.com

16 April 2006, 05:37 : Permanent link to comment

I see two problems (to begin with) with your code:
– It allows for sending XHTML 1.1 as text/html, which as you said yourself shouldn’t be done – it does not take into account the preference of the User Agent (specified with the Q parameter)
I think proper content negociation should be used instead, and this implies many more changes to the document.
James AkaXakA : http://akaxaka.gameover.com/

17 April 2006, 02:45 : Permanent link to comment

Following on Sébastien’s comments:

You do realise that xHTML can’t be sent as xHTML to 84+% of the browser population. Hence, you’re sending invalid markup, even with content negotiation (at present)!

That’s why it’s generally adivised to use xHTML 1.0, or even better HTML 4 Strict.
Jan Brašna : http://www.janbrasna.com

17 April 2006, 08:47 : Permanent link to comment

Well, I don’t see a proper value parsing from the headers and there’s a HTTP Vary header missing as well. I wouldn’t say this is a showcase of a best-practise way of doing this – sorry Hayo :(
Sébastient Guillon : http://sebastienguillon.com

17 April 2006, 13:12 : Permanent link to comment

@James AkaXakA

I’m not sure I understand what you mean, so I’ll expand on what I think content negociation means:
Sending a valid XHTML 1.1 (for instance) document as application/xhtml+xml to UAs that support it and a valid HTML 4.01 strict document to those that prefer text/html is, to me, good content negotiation; serving the same document (content-wise and functionality-wise) in two formats.

If you accept to serve your document either as application/xhtml+xml or text/html I’m assuming you’re not mixing namespaces or using any XHTML 1.1 or XML functionality that is not available to HTML.

In that case valid content negociation is possible.

You’ll have to have close control on your content and rewrite what has to be re-written, but basically if you write valid XHTML 1.1, there is very little to rewrite for HTML. You should even be able to serve the HTML page with stylesheets included in link elements, and the XHTML stylesheets included with XML Processing Instructions, for instance.

As I said there may be much more work to do (JavaScript, CSS…)

PS: I can’t post using Opera (8.54 on Win XP)
James AkaXakA : http://akaxaka.gameover.com/

18 April 2006, 13:01 : Permanent link to comment

Sébastien: I mean, that the W3C explicitly states that xHTML 1.1 should not be send as text/html.

And that when you do (send xHTML 1.0 as text/html), User Agents handle it in the same way they’d handle tag soup.

But I’m getting ahead of myself here, you’ll have to wait for my article on why Bite Size is HTML 4 Strict.
Sébastien Guillon : http://sebastienguillon.com

18 April 2006, 16:29 : Permanent link to comment

Well then I guess I agree with you.

I translated Sending XHTML (even 1.0) as text/html Considered Harmful into French so I’m aware of the pitfalls.
Hallvord R. M. Steen : http://www.hallvord.com/

19 April 2006, 03:20 : Permanent link to comment

Pardon the spam, I’m trying to work out if the mentioned problem with posting comments with Opera still exists. Ed: We're still working on it.

To post something on-topic: here is documentation on the Vary header:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44

Note in particular the statement “An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation”

UAs do not at the moment do useful things with Vary as far as I know but it might change.
Hallvord R. M. Steen : http://www.hallvord.com/

19 April 2006, 03:23 : Permanent link to comment

For the record: seems the posting problem is caused by Opera not sending name=value entry for an INPUT type=”image”. This is a known bug.
Mark : http://beingmrkenny.co.uk

19 April 2006, 03:23 : Permanent link to comment

As I see it, this is strictly a hack until either a) more browsers start to support application/xhtml+xml, or b) you get round to migrating back to HTML4.

I jumped on the XHTML bandwagon far too early, when really HTML 4 would have been fine. But I guess it’ll make things easier when XHTML 2 comes round (though that’s likely to be a long wait…).
Ben 'Cerbera' Millard : http://projectcerbera.com/

20 April 2006, 04:04 : Permanent link to comment

Imho, this “bite” should be removed. It is encouraging a practise which breaks important standards. It will only work with sites that are using Appendix C compatible XHTML 1.0, too. Modularised XHTML (such as 1.1) allow things like MathML, SVG and other technologies which cannot be converted into an HTML compatible format.

The only time this technique will work is when the XHTML is only doing the things HTML can do and is UTF-8 encoded. In which case, it’s far better to use HTML due to the simpler syntax, optional end tags, far better browser support, no content negotiation, etc, etc, etc.

The makers of Bite Size Standards seem to know all this. I hope they’ll remove this Bite and write a new one to cover choosing the correct of document type. I haven’t seen anyone manager to explain these issues concisely, so I hope BSS can acheive it. :-)

Commenting is closed for this article.