Hi,

currently drupal hardcodes the http-equiv Content-Type to text/html in includes/common.inc
Can you please add support for other content types like for instance application/xhtml+xml?

Right now the user could still change it in THEME_preprocess_page() with some ugly string replacement, but that isn't even always possible (in D6) like stated in #451304: Drupal outputs two meta content-type tags.

Thanks,
Antonio

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ao2’s picture

Will something alog the lines of [#56733] (link here) be accepted?
Another way of doing it here.

Some more references here.

I mean, also the real http header sould be set appropriately, not only the http-equiv meta element, right?

Regards,
Antonio

ao2’s picture

Status: Needs work » Active
FileSize
2.02 KB

A rough patch to show the basic idea is attached, it has been tested with FF and IE and no trivial problems showed up.

It needs to be improved to support client-side preference as in the references above and to get better integration and provide an API to set the content type the theme prefers to be served with. But here I need some help.

Comments?

Regards,
Antonio

ao2’s picture

Status: Active » Needs work

Changing the status.

ao2’s picture

Title: Support http-equiv Content-Type different from text/html » Support Content-Type different from text/html
Status: Active » Needs work

Just a supportive argument for adding this functionality: it helps to spot bad-formed output which pass unnoticed with text/html, you can see examples in #478856: Unterminated entities in taxonomy module break page validation. and #478908: SEO checklist output is not valid..

Thanks,
Antonio

ao2’s picture

Some more references:

Also, my current patch breaks ajax in drupal, maybe because of jquery using document.write and friends? I'll post an update as soon as I figure out how to solve that.

gaele’s picture

You can use
drupal_set_header('Content-Type: application/xhtml+xml');
in e.g. template.php. This will replace the default text/html header.
Then change the http-equiv from page.tpl.php.

apaderno’s picture

The hard-coded value has been added to avoid issues in the case a theme doesn't set it; for what I remember, the problem is not setting the encoding to UTF-8.
I am looking for the issue reported about that for another report; I will add here the link.

Damien Tournoud’s picture

Version: 7.x-dev » 8.x-dev

Given the amount of Javascript that application/xhtml+xml breaks, it's safe to bump that to D8. By the time D8 is released, HTML5 will probably have taken off, which will make this feature request moot.

ohnobinki’s picture

+1

XHTML doesn't seem worth it unless if the browser is actually interpreting the pages as XML and following standards instead of using quirks mode. Drupal appears to be ``half compliant'' which really means no compliance.

Also, jQuery().html() breaks with application/xhtml+xml.

kabarca’s picture

You can use the php str_replace() function to replace the string. See the example below that changes

// replace the content-type tag for Drupal 6
function ThemeName_preprocess_page(&$vars, $hook) {
  $vars['head'] = str_replace(
    '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />',
    '<meta charset="utf-8" />',
    $vars['head']
  );
}
// replace the content-type tag for Drupal 7
function ThemeName_html_head_alter(&$head_elements) {
  $head_elements['system_meta_content_type']['#attributes'] = array(
    'charset' => 'utf-8'
  );
}
ohnobinki’s picture

Issue tags: +xhtml compliance

tag

ohnobinki’s picture

Nowadays IE9 + jquery-1.5 finally seem to work with Content-Type: application/xhtml+xml; charset=utf-8 so hopefully this bug's fix isn't too far away....

ao2’s picture

Bump, I wanted to know what the opinion is on this one these days.

Damien Tournoud’s picture

Status: Needs work » Closed (won't fix)

Drupal 8 is now serving HTML5 by default.

ao2’s picture

Status: Closed (won't fix) » Needs work
Issue tags: +WSCCI

I'll try to reopen the issue, tagging it WSCCI as it might be pertinent to that initiative.

Let's see what people interested in WSCCI think about the mime type issue, and if it is totally pointless even from their perspective with HTML5 as the default format.

If the issue will be closed again I won't complain, I promise :)

Thanks,
Antonio

Crell’s picture

Status: Needs work » Closed (won't fix)

Presumably WSCCI should make it possible to serve any arbitrary requested mimetype. xhtml is not a specific target we're concerned about, though, as it is basically incompatible with any site that accepts user-entered content.

Marking this won't fix as it's not a primary task, but more of a convenient side-effect.

ao2’s picture

@Crell, OK.

Could you just elaborate a little more on what you mean by “[xhtml] is basically incompatible with any site that accepts user-entered content”? Isn't user submitted content usually filtered anyway to be made secure and valid? Maybe you refer to the fact that in XHTML there are restrictions about changing the DOM dynamically?

Thanks,
Antonio