Some browsers (in particular Internet Explorer) may barf and die when served content with application/
xhtml+xml. A wiki running in strict XHTML mode for savvy browsers should be able to automatically
downgrade for browsers that won't take it, perhaps based on the Accept: headers.
Without this, the XHTML mime type mode is useful only for testing.
Note that this may have implications for caching.
Version: 1.4.x
Severity: enhancement
| Unknown Object (Diffusion Commit) |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T2672 Complete MathML output mode for texvc | |||
| Declined | Aklapper | T2213 XHTML mime-type autodetect |
avarab wrote:
A simple way to do this in php would be:
if ( stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml') ) {
header('Content-type: application/xhtml+xml');} else if ( stristr($_SERVER['HTTP_ACCEPT'],'application/xml') ) {
header('Content-type: application/xml');} else if ( stristr($_SERVER['HTTP_ACCEPT'],'text/xml') ) {
header('Content-type: text/xml');} else {
header('Content-type: text/html');}
However this is probably something better done at the squids.
mrnobo1024 wrote:
What benefit would this give? The only difference I can see in Firefox is that
extended characters don't work (apparently it ignores the <meta> content-type,
so you need <?xml version="1.0" encoding="iso-8859-1"?> )
At the moment, the main benefit of using the application/xml+xhtml
content-type is for testing, to ensure we're producing well-formed output
and not relying on quirks of the HTML renderer. Since we can't yet
guarantee well-formed output at all times, we wouldn't actually want to
turn on an auto-detect at the moment.
The meta content-type is not actually necessary, as a real Content-Type
header is used. Its only benefit is for people who save the page to an .html
file on disk and reload it from disk.
avarab wrote:
(In reply to comment #3)
At the moment, the main benefit of using the application/xml+xhtml
content-type is for testing, to ensure we're producing well-formed output
There's also the benefit of being able to embed other XML namespaces inside our
XHTML, e.g. MathML and SVG.
phillip.stewart wrote:
Keep in mind that Mozilla's XML display is not yet incremental:
https://bugzilla.mozilla.org/show_bug.cgi?id=18333
sspecter wrote:
Hi, I am running a wiki with XHTML for viewing MathML (MathML only work with
XHTML for Mozilla browsers) and i think I have some interesting issues here.
I have 2 problems with it:
1- This problem is not serious, but its a bit annoying: The edit buttons
disapear. I didnt searched for it, but the buttons implementation are not
compatible with XHTML.
2- This is the serious problem: Every bad-formed tag structure make the page
stop working. It is unnaceptable to happen in a user-authoring content. The
worse it that some of the erros are created by the wiki sanitizer, not the user,
but I wont post it here, as I already will post it as bugs.
This is my conclusions:
crash and burn. Mediawiki still require some heavy parser/sanitizer fixes for
that work.
My sugestions
parse is done (and not just for the user content).
redirecting the user to edit the page, warning where the error is. I dont like
much this solution because it forces the wiki user to fix his errors, making the
wiki less flexible. Besides, some of the errors are generated by wiki itself.
I think we're just not going to do this. The web standards world has rebelled against XHTML 2.0 and is looking to HTML 5 work for the future. While we'll still do our best to always make compliant output, serving to typical end-users as application/xhtml+xml just isn't going to be our target.
It's more likely that we'll eventually migrate to HTML 5's non-XML formulation.