Opened 10 years ago
Closed 3 years ago
#25863 closed defect (bug) (duplicate)
Core not working when served as application/xhtml+xml
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 3.3 |
| Component: | Administration | Keywords: | has-patch |
| Focuses: | template | Cc: |
Description
All pages in Core has the following first lines:
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>
The Doctype implies HTML5, but the xmlns attribute implies XHTML. The server I'm deploying on is interpreting the file as XHTML and serving it as application/xhtml+xml. Some Core pages contain named entities such as , which do not work when the page is served as application/xhtml+xml (at least not in WebKit/Blink browsers).
What is the point of the xmlns attribute, as it is deprecated in HTML5? Should we remove it?
Or change the named entities to numeric? related: #13341 #9030
Attachments (2)
Change History (16)
#5
@
10 years ago
My server is some kind of custom solution, and the administrator is reluctant to change the server configuration. So right now I have no choice but to remove xmlns manually.
I just thought I might contribute, and that it hopefully could be fixed upstream :)
#6
@
10 years ago
Do you know if I could put anything in my .htaccess file to make apache serve all php files as text/html as an interim solution? I have tried AddType text/html .php, but then it just stops evaluating the php code.
#7
@
10 years ago
You should look into your default_mimetype PHP INI setting. Since this is Apache, you might have override for PHP ini settings. Try this:
php_value default_mimetype text/html
#8
follow-up:
↓ 10
@
10 years ago
- Component changed from Validation to Template
I could go for ticket-25863-xmlns-removal.patch, though I am not particularly familiar with the ramifications of it.
#10
in reply to:
↑ 8
@
9 years ago
Replying to nacin:
I could go for ticket-25863-xmlns-removal.patch, though I am not particularly familiar with the ramifications of it.
I don't think there should be any. By default, User Agents conforming to the HTML5 specification will place HTML elements in the http://www.w3.org/1999/xhtml namespace (Source).
Related (for bundled themes): #14226
Also see: #18202 (HTML5 doctype for core)
It's not deprecated, but it is supposed to be irrelevant to HTML documents (as far as I understand it). However, I could see how some servers might interpret this as xhtml+xml since this is how you're supposed to define polyglot markup now, which is implied to be XHTML.
Note that #14226 points out that this could affect use of MathML and SVG. But I generally still agree with @nacin that as a CMS, WordPress shouldn't even be trying to support XHTML.
I'm fairly certain we should remove it (and will have a patch for it in a bit), but it should also be possible to prevent your server configuration from assuming it's XHTML, and serving it as
application/xhtml+xml(WordPress is not responsible for this). What is your server running?