html vs xhtml

Lets Explore Some XHTML Myths And Misconceptions.
I set out to get to the bottom of the XHTML thing once and for all with real life examples.
The results were not exactly what I expected and even somewhat surprising.
I call it the WL Mark Spin.

==============================================
I jumped to a number of incorrect conclusions originally that were pointed out by Lachlan Hunt
http://lachy.id.au/. He authored an article for sitepoint.com on topic of XHTML
I have included his corrections.
I am not any sort of expert, but merely a student researching this topic.
==============================================

After reading this (below) and a few other write ups regarding XHTML.
http://www.hixie.ch/advocacy/XHTML
which states
QUOTE
* HTML 4.01 contains everything that XHTML 1.0 contains, so there is
little reason to use XHTML in the real world. It appears the main
reason is simply "jumping on the bandwagon" of using the latest and
(perceived) greatest thing.
END QUOTE

And this is the hot rebuttle to the hixie dicussion
http://lists.evolt.org/archive/Week-of-Mon-20030901/147752.html
but if you read on with the threads you find this
http://lists.evolt.org/archive/Week-of-Mon-20030901/147809.html

I set out to make some real life examples and observations to see what the real deal is and if it is a myth.

I have seen and heard numerous references to handle XHTML mime types by doing this:
<META http-equiv="content-type" content="application/XHTML+xml; charset=utf-8" />

This is just one of a million discussions erroneously explaining how ie has full XHTML support and how to do it.
http://www.webdevforums.com/showthread.php?t=10197

Not gonna work - Not even close and entirely missing the point - this is a prefect example of the blind leading the blind.

Here is a quote I received regarding these types or forum posts.
============================================
ABOUT MIME TYPES & HEADERS:

The META element can never be used for determining MIME type
under any circumstances in either HTML or XHTML, since the
MIME type will always be set by the HTTP headers before the content is served.

Headers are (invisible and ) sent before any content is served (including the doctype).
MIME type is determined before any of the page content is delivered and once MIME type is set it cannot be changed.

HTTP headers are, by default sent by the server as (typically) text/html and (typically) without specifying the charset.
Alternatively headers can be sent by a server side scripting language (PHP, ASP, CFM etc..).

When HTTP headers sent as application/xhtml+xml, The META attribute is not used at all,
and specifying content="application/xhtml+xml" in the META attribute is
useless because the real HTTP header, which takes precedence, will have
already been (by default) set to at least text/html, often without the charset parameter.

ABOUT CHARSET:

The charset should correctly be sent in the HTTP headers for text/html,
(The typical header for web documents typically will not contain the charset
which should be provided by a custom HTTP header or by changing the servers configuration.)

Charset should not be sent in HTTP headers for application/xhtml+xml.
(Content-Type: application/xhtml+xml;utf-8
http://www.workingwith.me.uk/articles/scripting/mimetypes/
Which you will find in the PHP code which is incorrect.)

Charset for XHTML should be specified by <?xml version="1.0" encoding="utf-8"?>
As the first content delivered to the browser and before the doctype.

With content served as text/html (without a custom HTTP header) the META element with an
http-equiv attribute may be used as an inferior substitute to specify charset (Not MIME type).

Browsers do determine the character encoding from the META element and it is
better to specify there, than not specifying it at all. However,
the real HTTP headers are the preferred method and the META element is completely useless when
the correct HTTP headers are used.

Likewise the META element should not be used in XHTML, but browsers do understand it when it is
served as text/html which is how most XHTML documents are (incorrectly) served.

The people discussing in the web dev forum post should
not be listened to because they don't know what they're talking about.

============================================

The META tag CAN NOT set the mime type as servers will by default usually send all content as text/html anyway.

I have set up two XHTML documents and both validate as strict XHTML BUT there is a big difference.

(The first link will not open in ie but works in fire fox which proves ie does NOT have true XHTML support.)

http://www.wlmark.com/test.php
http://www.wlmark.com/test2.php

Here are links to the w3c validator service to validate the two above documents. (extended interface)
Notice this first one shows content type as "application/XHTML+xml" and the document doesn't use a META tag in the source.
validator.w3.- check test.php

This one shows "content type as text/html" and it has the META tag in the source.
validator.w3.- check test2.php

View page source (firefox) and both are virtually identical - As a mater of fact after reading numerous discussions and looking at page source, you would think the page that has the META tag (test2) should be the one to have application XHTML, but the META tag is for other uses.

The META tag in this case is pretty much just decoration and does NOT enable the XHTML mime type.

This must be accomplished using server side scripting or changing the servers configuration - I use php to send the header as app. xml in test.php

(An XHTML document can have any extension (php,htm,html,asp,jsp) and it is the combination of doctype and mime type that determines if it is XHTML.)

Is ie even aware that it is an XHTML document when it encounters the XHTML doctype? Lets see.
We know it will not support the mime type application/XHTML+xml which is pretty much what XHTML is all about.
So what makes you believe that an XHTML doctype is supported?

Here is a small quick look at quirks mode (ie) which sets the stage for the next observation.
look at:
http://www.wlmark.com/tabless/index.php (XHTML)

in another browser window window look at
http://www.wlmark.com/tabless/index2.php (html)

And toggle between the two. The only difference is the doctype, one is XHTML the other is HTML.

I am using the doctype
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
on index2 which actually triggers quirks mode in ie.

To get standards mode, the doctype needs to be changed to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Then all works as standard mode but for this example we need quirks mode.

Notice the red font change and the gap that appears between the left and center.
in the style sheet the "P" is defined first and then the rules for the red text which is in a "P" element.
(Also the right content shifts down with html doctype if border is set to 0)

They both use the same style sheet which was designed for the XHTML version
(with hacks needed to compare browsers).

#centercontent{
margin-left: 159px; //----------For firefox
margin-right: 148px;
voice-family: "\";}\"";
voice-family: inherit;
margin-left: 152px; //---------- For ie
margin-right:152px;
}

leftcontent and right content{
width: 150px;
border: 1px solid #ADD8E6;
}
Here is what I have found in ie.

The center content does not change width as its width is not defined.
The left and right content with defined width measured from the outside of both borders is:
150 px with doctype HTML (quirks mode). which reflects the width above and places borders within the box.
152 px if doctype is XHTML(standards mode). - Places borders outside the box so - add two pixels.

Why does ie handle style sheets differently according to doctype.? Quirks mode!
I had to find out what was happening here and made up my own doctype.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD xyz 7.05 Transportional//EN">

http://www.wlmark.com/tabless/index3.php

Funny! If you make up a phony doctype, ie all of a sudden displays with the same behavior as XHTML.?
You would think a phony doctype would trigger quirks mode.

An unknown doctype will be treated as standards mode NOT quirks mode.
Why??
This is to make it future compatible. Lets say a new doctype is introduced tomorrow (or you create your own), You would want your (modern) document treated as standards mode.

This is a quote I received regarding this comment:
Is ie even aware that it is an XHTML document when it encounters the XHTML doctype?
We know it will not support the mime type application/XHTML+xml which is pretty much what XHTML is all about.
So what makes you believe that an XHTML doctype is supported?
===============================================
No. For IE, the XHTML DOCTYPE is unknown, and standards mode is
triggered in all browsers for any unknown DOCTYPE.
===============================================

So if the above statement is correct,
You can make up and use any doctype which will give the exact same results (in ie) as an XHTML doctype served as text/html.
If you have an XHTML doctype the w3c validator will look to make sure you have written (the space is not important)
The w3c will not validate unknown doctypes even though they trigger standards mode.

Now one more question -
If the only thing that the XHTML doctype does is trigger HTML standards mode in ie-
Is it better to write or ? (as is not an html standard)
Here is a quote regarding the above statement.
============================================
Actually, that is valid HTML too; it just has a different meaning in
SGML from XML, although no modern browser supports that SGML syntax
correctly.
============================================

I am looking at this (feedback is in red)
http://www.workingwith.me.uk/articles/scripting/mimetypes/
Quote:
However, according to the W3C specifications, things like are not valid HTML.
Wrong. These are equivalent:
hello world!
<p/hello world!/

and these:
 
<br/
<META ...>
<META .../

These examples use a special SGML syntax known as SHORTTAG NET (Null End
Tag). Because the "/" is means the end of the tag, the symbol ">"
afterwards is actually not markup.

Thus, is actually equivalent to writing:

>
 >

Since most of the SHORTTAG syntax is not supported by browsers, this
does not occur in the real world. But it does mean that is valid
in HTML because occurs where text is also allowed.

However, <META .../> or <link .../> is not valid with the ">" on the
end, because it is plain text that occurs where text is not allowed in
the head element.

<META .../ and <link .../ without the ">" on the end is valid, but
unsupported.

Now, for the majority of real world browsers, this is not an issue, as they will quite happily parse these closed single tags as if they were just normal HTML. However, there are a few implementations (most notably the standard Java routines) which, if you give them closed single tags, will interpret the first half (<br, say) correctly, and then display the /> as text.
Then that implementation is even more broken. If it outputs the "/" as
well, it's wrong. It *should* output the ">".
So, to ensure that everything works as expected for them, we need to make sure that if we send the web page out with the "text/html" mime type, then we must also change closed single tags into normal single tags.
Bad advice. The answer is to simply never serve XHTML as text/html, and
don't use the SHORTTAG NET syntax in HTML even if it is in the html spec.

End Quote

It is possible from the above quote that ie, when parsing the XHTML formatted document may use some sort of error correction as it is seeing it in an HTML standards mode. (I have searched and cannot find any documentation stating whether ie has shorttag support for and the other assorted xhtml (Closed) tags.) See references (at the end of this document) "shorttags" and look at the example.

There are also many articles stating that (php, asp etc. . ) browser detection would be the recommended technique to remove the XHTML formatting from ie. browsers for forward compatibility.

However others strongly disagree.
http://hsivonen.iki.fi/doctype/
(Scroll down to the addendum at the bottom of the page.)

and

Here is a quote regarding the above comment.
No! Serve HTML 4.01 as text/html and XHTML as application/xhtml+xml.
DO NOT use any form of browser sniffing.

So that pretty much sets me straight.

Then you have this (lame) argument:
http://forum.textpattern.com/viewtopic.php?id=7019&p=1
States:
======================================
go re-read the W3C Note on XHTML Media Types (which states XHTML ‘SHOULD’ be sent as application/xhtml+xml, not ‘MUST’), and Appendix C of the XHTML 1.0 spec for some general guidelines for XHTML documents to be served as text/html.
======================================
I guess this person still argues to use fonts as well, separation of style and content is also not a must.
If there is something you 'Should' do according to guideline recommendations then why shouldn't you do it?

If you still want to write documents in XHTML it's a good idea to fully understand what you are actually writing and realize that in a quest to become compliant you are actually doing the opposite,

No matter what argument you choose you are missing the point, ie does not recognize the XHTML doctype and all you have done is triggered standards mode by using an unknown, unsupported doctype.

Strict HTML is the recommended approach and results will be identical or possibly better and would be the compliant solution in today's browser environment.

ANALOGY:
If you go to the gas station you can find unleaded - at one time leaded was also an option at the stations.

Poor old ie is still running on leaded (HTML) while the more modern
browsers have made the switch to unleaded (XHTML) but will still work just as well with leaded.

Your website is similar to a gas pump and you have to supply the proper fuel to the browsers.
Using the wrong fuel or having a blend of leaded and unleaded will not work properly for anything.

I predict that in 3 more (long) years everyone will be able to use XHTML as it was meant to be used.
I see its use being identical to the use of css that kicked nn4.xx off the web.

References: (other than W3C)
Serving the xhtml mime type to browsers that can understand them:
http://keystonewebsites.com/articles/mime_type.php
http://www.rikkertkoppes.com/thoughts/common-xhtml-problems

Doctypes and the modes that they trigger:
http://www.mozilla.org/docs/web-developer/quirks/doctypes.html
http://www.opera.com/docs/specs/doctype/
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp
http://hsivonen.iki.fi/doctype/

Valid coding:
http://www.cs.tut.fi/~jkorpela/html/empty.html
http://www.goer.org/Journal/2003/Apr/index.html#results

Comments regarding Appendix C
http://annevankesteren.nl/archives/2005/03/appendix-c

Short tags (very interesting)
http://www.rikkertkoppes.com/thoughts/2005/01/27

Thank you for your time.
Cheers,
Loren Wolsiffer

http://www.wlmark.com Tampa web design

The WL Mark spin.