Posted by David Dorward on 01/13/06 21:19

Marc wrote:

>> Concerning xhtml 1.1, it can be used if you make the effort to learn it
>> well.

And don't care about mainstream user agent support (e.g. GoogleBot, Lynx and
Internet Explorer)

>> At a minimum, in addition to writing valid html 1.1 code, you
^X

>> must set up your server to serve the page with the mime type of
>> application/xhtml+xml associated with the extension .xhtml, or you can
>> also serve as .xml.

The file extension is irrelevent

>> There are a few bugs in some browsers that can be overcome, such
>> as a CSS body background color one on the Mozilla family browsers.

That is not a bug. Its mandated by the specs.

> Regarding serving an XHTML page with a different mimetype, why should we
> do this?

If you serve XHTML as text/html then it is treated as malformed HTML, and
there is no point in using it. (OTOH, if you serve it as
application/xhtml+xml, then 90% of your audience won't get it, and there is
*still* no point in using it).

> Is it because the browsers do not understand the XHTML
> extension?

URLs don't have file extensions.

> Most of our pages have a .php extension, so what happens in
> these cases - what mimetype would the server pass?

That depends on how your server is configured (unless your PHP script uses
the header() function to specify its own content type).

>> However, IE6 will not display a true xhtml page served correctly, and
>> rumor has it that neither will the upcoming IE7. You could write a
>> special page for IE in html 4.01 strict as well as the xhtml 1.1 page.
>> However, there is a way around this. The server and browser exchange
>> information when they first connect. The server can ask the browser if
>> it can handle the correct mime type for true xhtml. This is taken care
>> of by a php include at the very top of the page that replaces
>> everything above the head tag of the page

So you serve XHTML 1.0 (so what's the point of using 1.1 in the first
place?) or (probably) invalid HTML 4.x.

> I understand your logic, but what about when a user has the ability to
> use HTML in a webform which will then be displayed on the website? How
> do you make sure this is valid and inline with the doctype being used?

Same way as you would do in HTML. Run their code through a validator then
prompt them to fix it and/or try to fix it automatically and/or refer the
code to an editor who can fix it manually.

>> There can be complications if you use some javascript. For example,
>> document.write is not allowed in xhtml 1.1

Yes it is. document.write in XHTML isn't as widely supported as
document.write in HTML, but its allowed.

>> and use of it may cause the
>> page not to display or just give an xml error message. The page is
>> parsed as xml when you serve it correctly, and there is no telling what
>> a document.write might generate such as unclosed tags which are fatal
>> for some xml applications.

There is telling. You just have to know what you are putting into it in the
first place. Its a little harder then if you are outputting straight
markup, but still possible.

> Generally we don't use JavaScript, but an exception would be Google
> AdSense banners which give you some JS to incorporate to display the
> banner - again - how do we know that this JS is inline with our doctype?

The GoogleAd code, which you are not allowed to modify, uses the old "Hide
this code from insanely ancient browsers" comment syntax. This is allowed
in HTML 4.x. Under XHTML it renders the script commented out. Google Ads
are entirely incompatible with XHTML.

>> The reason for xhtml is to make PC html code XML pure. There are now
>> many other computing devices, and XML has become the standard for
>> information exchange between them. Xhtml 1.1 greatly improves the XML
>> purity

Un. How?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Back to original message]