XHTML

MediaWiki 1.3 attempts to generate output compliant to XHTML 1.0 Transitional (see also XHTML). For the most part it seems to be doing pretty good, but there are some ups and downs...

Why produce XHTML

• Potentially easier to reuse and transform the output for non-web use
• As a general good practice it forces us to be more careful about producing correct code
• Embedded MathML is possible for better inline TeX output (texvc's MathML output mode will need to be completed to fully make use of this, but this should be easy)

What's wrong with our support

• For best compatibility, we still have to use a text/html mime-type in many cases
• User-supplied HTML is not fully validated, and sometimes ends up being not well-formed (which can break the page completely if served with XML mime type)
• Some JavaScript-based extensions don't work in XML land, and will need to be updated to use the DOM

Compatibility issues

• Some browsers, particularly older ones, won't accept code as XHTML (application/xhtml+xml), but if code is served as HTML (text/html) some things don't work right (MathML) or behave differently (some style differences, javascript). This leads to browser sniffing to send the right content type... yuck.

There is a good fix that I use:

$wgMimeType = in_array('application/xhtml+xml', array_map('trim', explode(',', $_SERVER['HTTP_ACCEPT']))) ? 'application/xhtml+xml' : 'text/html';

This only checks to see if the browser can handle the content type and not specifically sniff for a browser. This breaks a few things in wikibits.js, but I have fixed them and I am preparing my changes to be sent to the Bugzilla. -- Avochelm 11:47, 16 May 2005 (UTC)

• Safari (as of 1.2.1) has a few odd problems in XML; notably some character entities such as " " (that's &nbsp;) are interpreted as literal text instead of the proper characters. Check the standard to make sure that those are ok... maybe we'll have to filter. A test page should be made available to test with Safari 1.2.4 (or later)