Posted by ao2 on May 28, 2009 at 10:41am
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
| Issue tags: | WSCCI, xhtml compliance |
Issue Summary
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
Comments
#1
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
#2
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
#3
Changing the status.
#4
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
#5
Some more references:
Also, my current patch breaks ajax in drupal, maybe because of jquery using
document.writeand friends? I'll post an update as soon as I figure out how to solve that.#6
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.
#7
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.
#8
Given the amount of Javascript that
application/xhtml+xmlbreaks, 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.#9
+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.
#10
You can use the php str_replace() function to replace the string. See the example below that changes
<?php// 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']
);
}
?>
<?php// 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'
);
}
?>
#11
tag
#12
Nowadays IE9 + jquery-1.5 finally seem to work with
Content-Type: application/xhtml+xml; charset=utf-8so hopefully this bug's fix isn't too far away....#13
Bump, I wanted to know what the opinion is on this one these days.
#14
Drupal 8 is now serving HTML5 by default.
#15
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
#16
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.
#17
@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