Ticket #4466 (closed enhancement: wontfix)

Opened 1 year ago

Last modified 9 months ago

Serve application/xhtml+xml if browser compliant

Reported by: werwin Assigned to: anonymous
Priority: low Milestone:
Component: Optimization Version: 2.2.1
Severity: minor Keywords: xhtml, application/xhtml+xml
Cc:

Description

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.

Change History

06/14/07 14:15:38 changed by Otto42

  • milestone changed from 2.3 (trunk) to 2.4 (future).

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. ;)

07/31/07 14:45:10 changed by 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. :)

12/09/07 13:01:29 changed by DD32

  • milestone changed from 2.4 to 2.6.

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.

01/05/08 01:11:32 changed by rmccue

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

01/05/08 01:19:11 changed by rmccue

Wait, it's already possible through pre_option_html_type

02/29/08 18:05:23 changed by markjaquith

  • status changed from new to closed.
  • resolution set to wontfix.
  • milestone deleted.

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