WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#4466 closed enhancement (wontfix)

Serve application/xhtml+xml if browser compliant

Reported by: werwin Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Template Keywords: xhtml, application/xhtml+xml
Focuses: 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 (22)

comment:1 Otto427 years ago

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

comment:2 idle7 years ago

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

comment:3 DD326 years ago

  • 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.

comment:4 rmccue6 years ago

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

comment:5 rmccue6 years ago

Wait, it's already possible through pre_option_html_type

comment:6 markjaquith6 years ago

  • Milestone 2.7 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:7 sampablokuper5 years ago

  • Milestone set to 2.7.1
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 2.2.1 to 2.7

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?

comment:8 DD325 years ago

  • Milestone 2.7.1 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed
  • Version 2.7 deleted

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

comment:9 sampablokuper5 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:10 sampablokuper5 years ago

  • Milestone set to 2.7.1
  • Version set to 2.7

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.

comment:11 DD325 years ago

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.

comment:12 follow-up: sampablokuper5 years ago

  • Priority changed from low to normal
  • Severity changed from minor to normal

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.

comment:13 in reply to: ↑ 12 Otto425 years ago

  • Milestone 2.7.1 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed
  • Version 2.7 deleted

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.

comment:14 sampablokuper5 years ago

  • Milestone set to 2.9
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version set to 2.7

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.

comment:15 follow-up: jacobsantos5 years ago

  • Component changed from Optimization to Template
  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

comment:16 in reply to: ↑ 15 sampablokuper5 years ago

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! :)

comment:17 sampablokuper5 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:18 jacobsantos5 years ago

  • Milestone set to 2.9

comment:19 jacobsantos5 years ago

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

comment:20 jacobsantos5 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

comment:21 jacobsantos5 years ago

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

comment:22 jacobsantos5 years ago

  • Milestone 2.9 deleted
Note: See TracTickets for help on using tickets.