Serve application/xhtml+xml if browser compliant

[werwin]

Right now, Wordpress serves up the blog's headers by using

get_option('html_type')

which as far as I know, can only be changed in the database. Changing it to application/xhtml+xml would make sense, if the browsers would all handle it, but they all don't, which is why right now we have XHTML complaint pages served up as using the text/html mime type -- so everything can be viewed if the browser can't view the application/xhtml+xml mime type.

However, I propose a 'hack' around this issue, which should allow the older browsers to still view the pages with the text/html mime type, and the newer browsers to view the pages with the application/xhtml+xml mime type.

I'm not quite sure about all the code and just did a quick hack, which seems to work to my knowledge, so I won't include a diff, just a quick example of wp-includes/classes.php (~ 171)

@header("Vary: Accept");
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml")) {
@header('Content-type: application/xhtml+xml; charset=' . get_option('blog_charset'));
}else if (stristr($_SERVER["HTTP_USER_AGENT"], "W3C_Validator")) {
@header('Content-type: application/xhtml+xml; charset=' . get_option('blog_charset'));
}else{
@header('Content-type: text/html; charset=' . get_option('blog_charset')); }

There are prettier and more proper ways, just throwing this option out there to see what people think.

[Otto42]

As we discussed on wp-hackers, changing to application/xhtml+xml affects quite a bit. It's quite likely that most Wordpress blogs and/or themes and/or plugins are wholly incompatible with a mime type of application/xhtml+xml.

Serving as application/xhtml+xml breaks virtually all javascripts, for example.

While the idea is good, and code should be added to prepare for this sort of thing, it is premature to actually be serving up pages as application/xhtml+xml. All the kinks in the various javascript codes has to be worked out, for one thing. And even then, backwards compatibility needs to be addressed, since you're not going to be able to update every plugin/theme.

I say to only add code to *allow* people to change that sort of thing, and start making the codebase compatible with it, but by the time you actually get there, IE will finally support application/xhtml+xml as well. ;)

[idle]

I have been doing this for about two years on my blog, and had no problems at all. As a matter of fact, I've managed to turn my old hack into a usable plugin. I just need to put it out there for others to download. :)

Basically, it checks the accept string of the browser, determines the priorities (some browsers may support application/xhtml+xml, yet prefer text/html), sets the "html_type" variable accordingly, and appends the appropriate meta content tag to wp_head().

Until I do get around submitting the plugin, you can always email me if you want to try it out. :)

[DD32]

moving to 2.6, a lot of themes are not xhtml complient, and browser support varies.

There is no great advantage of running application/xhtml+xml over text/html for most users, and those users who do want to run with it, can easily do so allready.

[rmccue]

What about adding a filter for themes that want to change it themselves?

[rmccue]

Wait, it's already possible through pre_option_html_type

[markjaquith]

If you want to do it, you can use the filter rmccue noted. This isn't something that should be user-facing.

[sampablokuper]

Sorry, but it's not clear to me how to use pre_option_html_type . I can't find any documentation on it, and a Google search for it doesn't give any results.

Please could somebody either link to documentation on how to use pre_option_html_type in a template/plugin, or make a patch to allow Admin users to specify the html_type through the admin panel?

[DD32]

sampablokuper: You need to use the ​Plugin API and add a filter function for the filter 'pre_option_html_type'

[sampablokuper]

DD32 wrote:

sampablokuper: You need to use the Plugin API and add a filter function for the filter 'pre_option_html_type'

Thanks for the tip, but there's still no documentation on pre_option_html_type (when it's called, what it's supposed to be used for, etc.). Surely it ought to at least be listed in ​http://codex.wordpress.org/Plugin_API/Filter_Reference.

[sampablokuper]

Also, it sucks if developers can't make a site compliant with XHTML Strict with a theme alone.

That would mean that if I were a theme developer creating XHTML Strict themes, I'd also have to distribute a plugin along with my theme, which my customers would have to install and activate in addition to installing and activating the theme; or else I'd have to require them to manually edit the database.

Neither of those solutions is really satisfactory.

[DD32]

but there's still no documentation on pre_option_html_type

Thats because there IS no documentation needed on how to do it, The actual filter is "pre_option_" + option_name, The 'pre_option_' is listed in the filter reference, It'd be impossible/crazy to list pre_option_blah, pre_option_blah2, etc. for the hundred or so options (and then you've got update_option_, and option_, etc.)

You can use the Plugin API within your themes functions.php file as well.

Trac is not a support forum, Any furthur information on how to use Filters or Actions of any type need to be directed to the Support forums, This is not a bug, its how WordPress operates, Theres the ability for people to change it via a theme/plugin if required, but the majority of wordpress themes are NOT xhtml strict compliant, infact, i'd be surprised if the output of all WP functions would pass validation when served with application/xhtml+xml which would cause even more problems.

[sampablokuper]

DD32 wrote:

The actual filter is "pre_option_" + option_name, The 'pre_option_' is listed in the filter reference

Ah, so it is. However, because searching for 'pre_option_html_type' didn't yield any results, and presumably this would be true of any 'pre_option_...' hooks that aren't explicitly documented, I wonder if it mightn't be worth documenting them all (even if only with a link to the documentation on 'pre_option_'), so that people can find what they're searching for.

You can use the Plugin API within your themes functions.php file as well.

OK, I didn't know this. It isn't mentioned at ​http://codex.wordpress.org/Plugin_API

This is not a bug, its how WordPress operates, Theres the ability for people to change it via a theme/plugin if required, ... i'd be surprised if the output of all WP functions would pass validation when served with application/xhtml+xml which would cause even more problems.

If this is how WP operates, then WP needs enhancement, as this ticket indicates. With the growing need to incorporate elements of MathML, SVG, RDFa, etc, in web pages, it's increasingly important that CMS systems are capable of XHTML Strict compliance. Drupal's ​on the case. Other platforms are getting their acts together too. The ability to serve application/xhtml+xml is rapidly becoming mandatory for any web platform worth its salt.

[Otto42]

Replying to sampablokuper:

This is not a bug, its how WordPress operates, Theres the ability for people to change it via a theme/plugin if required, ... i'd be surprised if the output of all WP functions would pass validation when served with application/xhtml+xml which would cause even more problems.

If this is how WP operates, then WP needs enhancement, as this ticket indicates. With the growing need to incorporate elements of MathML, SVG, RDFa, etc, in web pages, it's increasingly important that CMS systems are capable of XHTML Strict compliance. Drupal's ​on the case. Other platforms are getting their acts together too. The ability to serve application/xhtml+xml is rapidly becoming mandatory for any web platform worth its salt.

There's really very little point in making the system capable of application/xhtml+xml when the most commonly used browser isn't even capable of rendering it yet.

If/when xhtml+xml gets support by IE, then it might be worth looking into. As it stands now, I'd say that it's not. Although if you want to contribute some patches for any problem areas, then I'm sure they'd get integrated into the core code.

[sampablokuper]

Otto42 wrote:

There's really very little point in making the system capable of application/xhtml+xml when the most commonly used browser isn't even capable of rendering it yet. ... If/when xhtml+xml gets support by IE, then it might be worth looking into. As it stands now, I'd say that it's not.

To me, that doesn't sound like a "wontfix". It sounds like a "willfixinthedistantfuture". So I've reopened this but pushed the milestone back to 2.9 because that's the most distant milestone Trac is letting me assign.

In the meantime, using something like

<?php
function set_content_type_for_xhtml_strict() {
    return "application/xhtml+xml";
}
add_filter('pre_option_html_type', 'set_content_type_for_xhtml_strict');
?>

in the theme's functions.php is a workaround that will force the content-type for those who want it to be "application/xhtml+xml" regardless of browser capability.

[jacobsantos]

No, it is a theme specific option. The suggestion that maybe when IE6, IE7, and IE8 is dead is also web site specific. If you don't want to support IE browsers, then you can do it now. However, WordPress will not handle it now or in the near future.

Actually, you really need to look at that example function because it isn't going to work for IE. You need to check for IE before returning that.

IE 9 or 10 won't be coming out for another 2 to 4 years, and there is nothing to suggest that those versions are going to support XHTML either. So what you have is a situation where IE 6, 7, and 8 do not support that MIME type. IE 9 is probably not going to either. However, who knows, if Microsoft continues its support for HTML5, it will eventually have to also add support for XHTML5. In that case, IE may add support for that MIME type.

Even after that, you still have 3+ versions of IE that you'll need to support until the amount of users drops to a level you are fine with not supporting them any longer.

[sampablokuper]

Replying to jacobsantos:

Actually, you really need to look at that example function because it isn't going to work for IE. You need to check for IE before returning that.
... IE 6, 7, and 8 do not support that MIME type.

True enough. I wasn't previously aware of this. A pity, but MS's fault, not WP's. Apologies for the noise. Let's hope IE8 will support "application/xhtml+xml"... it's not out of beta yet! :)

[sampablokuper]

OK, I've created ​a bare bones parent theme which gets WP 2.7 to serve XHTML+RDFa content as application/xhtml+xml to compliant browsers and as text/html to non-compliant ones. It's GPL-licensed, so a patch can be developed from it. As a bonus, it even takes into account the issue discussed ​here.

As for the point, mentioned above, that serving as application/xhtml+xml can break JavaScript, it's worth saying that JQuery at least is taking the application/xhtml+xml MIME type seriously: ​http://dev.jquery.com/ticket/3896. Since the use of JavaScript frameworks like JQuery, as opposed to raw JavaScript, is increasingly prevalent, as are debugging tools like Firebug, so too is the portability of JavaScript code across MIME types.

At this point, I do think it's fair to reopen this an an enhancement request, in compliance with the guidelines at ​http://codex.wordpress.org/Development_Planning.

[jacobsantos]

Way way in the future. Probably like 3.2-ish.

[jacobsantos]

Just kidding, this is a themes issue, if it was added to WordPress then it would most likely break themes that aren't fully comform with XML rules.

[jacobsantos]

Sorry, it will break themes that don't conform to the strict XML rules.