[PLUGIN] application/xhtml+xml
[PLUGIN] application/xhtml+xml 1.1
Checks to see if a document has custom content type of application/xhtml+xml. If yes, then checks to see if the browser can accept that content type. If the browser can not accept the mime type of application/xhtml+xml, the page header is sent as content type text/html.
Works with MODx Version(s): All
Submitted: Jan 2nd 2007 | License: GPL - GNU Public | Downloads: 1259
Submitted: Jan 2nd 2007 | License: GPL - GNU Public | Downloads: 1259
For MODx users who create XHTML valid templates:
This plugin (Set to onWebPagePrerender) Checks to see if a document has custom content type of application/xhtml+xml. If yes, then checks to see if the browser can accept that content type. If the browser can not accept the mime type of application/xhtml+xml, the page header is sent as content type text/html.
This plugin (Set to onWebPagePrerender) Checks to see if a document has custom content type of application/xhtml+xml. If yes, then checks to see if the browser can accept that content type. If the browser can not accept the mime type of application/xhtml+xml, the page header is sent as content type text/html.
What determines if my document is HTML or XHTML?
You may be a bit thrown off by the talk of treating an XHTML as HTML. After all, if my document is XHTML, that should be the end of the story, right? After all, I put an XHTML doctype! But it turns out that things are not so simple.
So what really determines if a document is HTML or XHTML? The one and only thing that controls whether a document is HTML or XHTML is the MIME type. If the document is served with a text/html MIME type, it is treated as HTML. If it is served as application/xhtml+xml or text/xml, it gets treated as XHTML. In particular, none of the following things will cause your document to be treated as XHTML:
* Using an XHTML doctype declaration
* Putting an XML declaration at the top
* Using XHTML-specific syntax like self-closing tags
* Validating it as XHTML
In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the sloppy (lenient) error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.
HTML is probably what you want
Perhaps you’re just now realizing that your lovingly crafted valid XHTML document is actually invalid HTML. You have a couple of choices:
1. Serve your content as application/xhtml+xml. That’s probably not such a good idea though. Microsoft Internet Explorer will not handle XHTML at all, and serving it such a MIME type will lead it to download. Unless you’re willing to completely lock out IE users, you probably don’t want to take this option.
2. Serve as text/html to IE, but as application/xhtml+xml to other browsers. This way your content at least has a chance of working in IE, and uses HTML-compatible XML for its original intended purpose, as a fallback compatibility hack. However, there are still downsides. Your documents will be processed in entirely different ways in IE vs other browsers. A construct that may be perfectly valid HTML could totally break XML parsing, due to the strict error handling rules. Or conversely, some kinds of valid XHTML changes might result in an HTML document that looks wrong. Furthermore, the XHTML modes of the browsers that support it are not nearly as mature or well tested as the HTML modes. This is definitely the case for Safari. And Mozilla also discourages this practice due to lack of support for incremental rendering. And they have a list of some of the many differences in processing XHTML vs HTML.
3. Stick with the status quo. Another option is to just stick with the status quo - generate XHTML content but serve it as HTML. The disadvantages here are mainly that you are losing out on HTML validators, which will validate the document in a way that matches how browsers parse it; and that you run the risk of subtle incompatibilities if your document is ever actually processed as XHTML. But this also raises the question: what do you think you are getting out of using XHTML? You may have heard a lot of hype about it, experts may have told you it’s the next big thing, but what kind of benefits do you get if in the end it’s just treated as HTML tag soup?
If you have taken the care to validate your pages as XHTML, you should make a custom content type for your pages in the manager to serve them as the correct mime type (application/xhtml+xml).
Log into your MODx Manager and select Tools -> Configuration. Under the "Site" tab, there is a section called "Custom Content Types". Add "application/xhtml+xml" here if you haven't already.
Next, in your documents that use an XHTML template, select the "Page settings" tab and choose "application/xhtml+xml" from the content type drop down list.
This plugin will send the page through as is for browsers that can correctly display a document of mime type application/xhtml+xml, and for those that cannot display the page, will fall back and send a header of content type: text/html, so non-standards compliant browsers such as IE (even IE 7) will be able to display the page.
This plugin (Set to onWebPagePrerender) Checks to see if a document has custom content type of application/xhtml+xml. If yes, then checks to see if the browser can accept that content type. If the browser can not accept the mime type of application/xhtml+xml, the page header is sent as content type text/html.
Description
For MODx users who create XHTML valid templates:This plugin (Set to onWebPagePrerender) Checks to see if a document has custom content type of application/xhtml+xml. If yes, then checks to see if the browser can accept that content type. If the browser can not accept the mime type of application/xhtml+xml, the page header is sent as content type text/html.
What determines if my document is HTML or XHTML?
You may be a bit thrown off by the talk of treating an XHTML as HTML. After all, if my document is XHTML, that should be the end of the story, right? After all, I put an XHTML doctype! But it turns out that things are not so simple.
So what really determines if a document is HTML or XHTML? The one and only thing that controls whether a document is HTML or XHTML is the MIME type. If the document is served with a text/html MIME type, it is treated as HTML. If it is served as application/xhtml+xml or text/xml, it gets treated as XHTML. In particular, none of the following things will cause your document to be treated as XHTML:
* Using an XHTML doctype declaration
* Putting an XML declaration at the top
* Using XHTML-specific syntax like self-closing tags
* Validating it as XHTML
In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the sloppy (lenient) error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.
HTML is probably what you want
Perhaps you’re just now realizing that your lovingly crafted valid XHTML document is actually invalid HTML. You have a couple of choices:
1. Serve your content as application/xhtml+xml. That’s probably not such a good idea though. Microsoft Internet Explorer will not handle XHTML at all, and serving it such a MIME type will lead it to download. Unless you’re willing to completely lock out IE users, you probably don’t want to take this option.
2. Serve as text/html to IE, but as application/xhtml+xml to other browsers. This way your content at least has a chance of working in IE, and uses HTML-compatible XML for its original intended purpose, as a fallback compatibility hack. However, there are still downsides. Your documents will be processed in entirely different ways in IE vs other browsers. A construct that may be perfectly valid HTML could totally break XML parsing, due to the strict error handling rules. Or conversely, some kinds of valid XHTML changes might result in an HTML document that looks wrong. Furthermore, the XHTML modes of the browsers that support it are not nearly as mature or well tested as the HTML modes. This is definitely the case for Safari. And Mozilla also discourages this practice due to lack of support for incremental rendering. And they have a list of some of the many differences in processing XHTML vs HTML.
3. Stick with the status quo. Another option is to just stick with the status quo - generate XHTML content but serve it as HTML. The disadvantages here are mainly that you are losing out on HTML validators, which will validate the document in a way that matches how browsers parse it; and that you run the risk of subtle incompatibilities if your document is ever actually processed as XHTML. But this also raises the question: what do you think you are getting out of using XHTML? You may have heard a lot of hype about it, experts may have told you it’s the next big thing, but what kind of benefits do you get if in the end it’s just treated as HTML tag soup?
Instructions
Copy this to a new plugin and set System Event to onWebPagePrerender.If you have taken the care to validate your pages as XHTML, you should make a custom content type for your pages in the manager to serve them as the correct mime type (application/xhtml+xml).
Log into your MODx Manager and select Tools -> Configuration. Under the "Site" tab, there is a section called "Custom Content Types". Add "application/xhtml+xml" here if you haven't already.
Next, in your documents that use an XHTML template, select the "Page settings" tab and choose "application/xhtml+xml" from the content type drop down list.
This plugin will send the page through as is for browsers that can correctly display a document of mime type application/xhtml+xml, and for those that cannot display the page, will fall back and send a header of content type: text/html, so non-standards compliant browsers such as IE (even IE 7) will be able to display the page.
Previous Releases
[PLUGIN] application/xhtml+xml 1.0
Initial Release
Works with MODx Version(s): All
Submitted: Dec 17th 2006 | License: GPL - GNU Public | Downloads: 337
This resource has been deprecated.
Submitted: Dec 17th 2006 | License: GPL - GNU Public | Downloads: 337
This resource has been deprecated.
Extras
No results found.