XHTML vs HTML FAQ

[RyanReese]

Read page 1 sections titled "Can I set the MIME type with a <meta/> tag?" and "How do I serve XHTML with the proper MIME type?"

[Ulyses]

That tag is too late. The browser needs to know whether it is HTML or XHTML before it reads the first tag in the page content. By the time it reads that tag it is already processing the page content as HTML.

You need to set it in a header and not in the page content itself to serve it as XHTML.

And another thing: in the rest of the browsers, if you have a XHTML in a *.html file, it's still not treated as XHTML. So it's kind of not happy for me.

The Mode for application/xhtml+xml Content (XML Mode)
In Firefox, Safari, Chrome and Opera, the application/xhtml+xml HTTP Content-Type (not a meta element nor a doctype!) triggers the XML mode. In the XML mode, these browsers give the specification-wise correct treatment for XML documents to the extent implemented in a particular browser.
IE 6, 7 and 8 do not support application/xhtml+xml. Neither does Mac IE 5.
In the WebKit-based Nokia S60 Browser, the application/xhtml+xml HTTP Content-Type does not trigger the XML mode due to concerns of compatibility with ill-formed content in mobile walled gardens. (Legacy “mobile browsers” don’t use a real XML parser and, therefore, ill-formed content has been labeled as XML.)

[Ulyses]

You need the server side to do this. You can set the mime type but by then the browser is already rendering the page!@

If you had taken the time to actually read hte first page of this thread where Tommy goes over this, then you'd know.

This is taken frrom page 1

You need to instruct your web server to send the proper HTTP header. The exact technique depends on which HTTP server you use, but for Apache, you can use the AddType directive:
Code:
AddType application/xhtml+xml .xhtml .xht
This makes Apache send an application/xhtml+xml MIME type for files ending with .xhtml or .xht. The directive can be put in the global configuration file (/etc/httpd.conf on most *nix systems) or in a local .htaccess file in a directory.

Sometimes we don't have access to the configuration files, but we need not lose hope quite yet. If we can use a server-side scripting language, we can send the HTTP header ourselves. For instance, using PHP:

header('Content-Type: application/xhtml+xml; charset=utf-8'); 

(Note that this header must be sent before a single byte of document content is written to the response stream.)

Thank you for pointing out that to me.
I now finally GET IT ! And live with it.

Thank you also, felgall, for not snapin'.

One last question: can I get application/xhtml+xml content back in IE by AJAX? Or it will still be text/html, even thou I'm sending a proper header, with PHP or any other server-side language (do you see where I'm getting at?)?

Or better yet: does IE have a XML mode for parsing?
I believe so, at least according to this:

Note: Internet Explorer uses the loadXML() method to parse an XML string, while other browsers use the DOMParser object.

http://www.w3schools.com/Xml/xml_parser.asp

So, I believe that, somehow, IE supports application/xhtml+xml.

Am I still wrong? Kill me, but I need to know!

It seems to me that in all browsers, only with AJAX you can be absolutely sure about XML mode for parsing.

And another thing: in the rest of the browsers, if you have a XHTML in a *.html file, and use Apache rules, it's still not treated as XHTML. So it's kind of not happy for me.

The Mode for application/xhtml+xml Content (XML Mode)
In Firefox, Safari, Chrome and Opera, the application/xhtml+xml HTTP Content-Type (not a meta element nor a doctype!) triggers the XML mode. In the XML mode, these browsers give the specification-wise correct treatment for XML documents to the extent implemented in a particular browser.
IE 6, 7 and 8 do not support application/xhtml+xml. Neither does Mac IE 5.
In the WebKit-based Nokia S60 Browser, the application/xhtml+xml HTTP Content-Type does not trigger the XML mode due to concerns of compatibility with ill-formed content in mobile walled gardens. (Legacy “mobile browsers” don’t use a real XML parser and, therefore, ill-formed content has been labeled as XML.)

[felgall]

Would you be so kind as to be more specific, providing an working example maybe.

The following page is done using PHP to add the MIME type header before the page is sent to the browser.

http://www.felgall.com/realxhtml.php

[Ulyses]

Thank you for the practical demo. You are right.

Did you read my speculation as to AJAX serving xml content to IE, content that can be added to DOM, thus enabling XML mode for parsing, thus IE supports, in a way, application/xhtml+xml?

I would like your opinion on this, please.

[felgall]

IE4+ supports XML but while XHTML is a form of XML serving the XHTML as XML means you don't pick up all the default styling that is normally associated with it.

[Ulyses]

I'm sorry if I'm being too persistent. I just like this matter taken to it's very end.

You said "...serving the XHTML as XML...". Lets take it step by step.

1. XHTML content in a *.xhtml file will be downloaded, not redered by IE.

2. So, we put the XHTML content in a *.html. We have doctype and mime for a XHTML in that file, but this does not help (at this point, at least). Do they count for something later on? Let's see.

3. IE starts rendering it as html, XML mode (used for rendering XHTML) is not triggered, regardless to the doctype and mime. So far so clear. IE does not support application/xhtml+xml this way.

4. After the page finishes loading, we, at the client, make an AJAX request for a well formated XML (not a file, a response).

5. On the server-side, we use any server-side language to send:
- first the header: application/xhtml+xml
- second, the XML

6. At the client-side, we receive the XML. At this point, doctype and mime are saying XHTML all the way. Does this count for something now?

7. We use a XSLT transformation to the XML received, to produce XHTML elements and we add them to the DOM. What's the outcome look like?

Now, my perplexity is this:

Renderind this new elements is done according witch style: xhtml as specified in doctype & mime of my xhtml document, or html as a result of a inheritance of styling?

LoadXML() (used to get the XML) and/or doctype & mime are they now trigering XML mode for rendering XHTML insted of html?

The new elements being added to the DOM are they styled XML/XHTML way?

Do we get, after all, a application/xhtml+xml behaviour this way?

[AutisticCuckoo]

1. XHTML content in a *.xhtml file will be downloaded, not redered by IE.

The file extension has nothing to do with anything. It's the MIME type sent by the server that controls how a web resource is interpreted.

2. So, we put the XHTML content in a *.html. We have doctype and mime for a XHTML in that file, but this does not help (at this point, at least). Do they count for something later on? Let's see.

If you serve the document as text/html then it must be parsed and interpreted as HTML. A <meta> tag makes no difference, since the content type must be known in advance.

3. IE starts rendering it as html, XML mode (used for rendering XHTML) is not triggered, regardless to the doctype and mime. So far so clear. IE does not supports application/xhtml+xml this way.

IE does not support application/xhtml+xml in any way. There are no different 'ways' at all.

7. We use a XSLT transformation to the XML received, to produce XHTML elements and we add them to the DOM.

Yes, to the HTML DOM that IE has constructed after reading the initial HTML document. It's still HTML.

Renderind this new elements is done according witch style: xhtml as specified in doctype & mime of my xhtml document, or html as a result of a inheritance of styling?

HTML, since you're still working with the HTML DOM created from the original HTML document.

Do we get, after all, a application/xhtml+xml behaviour this way?

No. IE does not support XHTML in any way, shape or form. It supports HTML (including pretend-XHTML thanks to sophisticated error handling), and it supports XML. But it doesn't support the semantics of XHTML, nor does it natively support other common applications of XML, such as MathML or SVG.

[Ulyses]

Thank you very much! I could ask for more clarity, but then it would start hurting.

But let's take it a little further, shall we?

If it's a html DOM, how come it is allowing non-standard elements and atributes being added to it's content?

It's supposed to be more strict, no? How are we being able, in any of the browsers for that matter, to use this xhtml features if the DOM is still html?

Is XML the answer? Being that our page it's only XHTML, not XML.

[Ulyses]

The file extension has nothing to do with anything. It's the MIME type sent by the server that controls how a web resource is interpreted.

I was here reffering to the association made in Apache conf files between extensions and headers.

[Ulyses]

After pissing off, I'm sure, two or three nice and otherwise very patient ppl on this forum , I draw my conclusion.

We have here, IMO, the same lack of standards, on all sides: IE, FF, Op, Saf, Ch.

Why? (examples below rely on the fact that Apache is the most used)

If IE gets a header application/xhtml+xml (for a *.xhtml, by Apache conf), he'll try and download it. We have to send it as text/html or text/xml in a *.html or *.xml (or change mime xhtml to xml, thus using *.xml for xhtml, which is not that far from the truth).

If FF/Op/Saf/Ch get a *.html (according to Apache conf is text/html) with xhtml content, it's still not treated xhtml, but html, even thou they can handle xhtml.


Life would've been so easy if:
- xhtml would be always sent off as text/html by our server-side
- we then have to include a meta tag in our file, specifying the http-equiv attribute with the value content="application/xhtml+xml" (which should be equiv with the http header or more, like inline vs. external CSS style!!!) and the user agent would then apply either html or xml DOM.


As I see it, we are left with two options here:

a) Send XHTML to all browsers as text/html, using the guidelines set here http://www.w3.org/TR/xhtml1/#guidelines.

b) Use XML for XHTML, and w3org is happy with that http://www.w3.org/International/articles/serving-xhtml/.

IE6 may not be OK, but hey, I've heard he's gone anyway.

I go with a).

[AutisticCuckoo]

We have here, IMO, the same lack of standards, on all sides: IE, FF, Op, Saf, Ch.

No, not in this case. Firefox, Opera, Safari and Chrome do the right thing. Internet Explorer lacks support for XHTML and also does the right thing by refusing to accept it.

If IE gets a header application/xhtml+xml (for a *.xhtml, by Apache conf), he'll try and download it. We have to send it as text/html or text/xml

If you send it as text/html you are not using XHTML at all, but HTML.
If you send it as text/xml IE will treat it as XML, but not XHTML. (BTW, text/xml is a very bad choice of MIME type; use application/xml instead.) Why not realise that XHTML is completely unusable for public websites, and probably will remain so? Just stick with HTML, which works everywhere.

If FF/Op/Saf/Ch get a *.html (according to Apache conf is text/html) with xhtml content, it's still not treated xhtml, but html, even thou they can handle xhtml.

Yes, that's exactly what they should do! If you promise that they are about to receive an HTML document (by the MIME type text/html), they must treat whatever comes next as HTML. No matter what it is.

Life would've been so easy if:
- xhtml would be always sent off as text/html by our server-side

Why? With things as they are, this is what happens:

1. A browser requests a web document.
2. The server responds, saying that the document is as XML application (using the MIME type application/xhtml+xml or application/xml).
3. The browser chooses its XML parser and starts interpreting the document.
4. When reading the root element's start tag it sees the XML namespace declaration and knows that it's, in fact, an XHTML document.

With your proposal the browser would have to anticipate that the server might be lying, saying that it's an HTML document when it's really an XHTML document. It would then have to choose the HTML parser (since an XML parser might choke on HTML syntax) and deliberately misinterpret the '/>' syntax (violating the HTML specification) until it finds a specific <meta> element – which is by no means a required element – and then examine the HTTP header equivalent. This 'equivalent' would then not, in fact, be an equivalent of the actual HTTP header, since it proclaimed the MIME type to be text/html. So we would have a mismatch between the real MIME type and a purported equivalent, and you are saying that the browser should believe the equivalent rather than the true header? And this would be better?

Okay, let's say we go along with this. Now the browser finds out that the document is really XHTML, not HTML. It may already have read hundreds of kilobytes of CSS style sheets, JavaScript, etc. (Content within the <head> can come in any order.) And then it has to stop, switch to its XML parser and start over again.

This is not a good idea. XHTML is not a kind of HTML, so it would be very, very wrong to label it as text/html and still expect it to be treated as XHTML.

It is much better that the server sends an HTTP header stating the content type before the document body, as is the case right now. You first tell browsers what to expect, then give them the content. Doing it in the opposite order is Bad.

Would you also suggest that all images should be served as image/jpeg and that browsers should then use content sniffing to decide whether it actually is a JPEG image, or a PNG image, or a GIF image?

[Ulyses]

[...]
With your proposal the browser would have to anticipate that the server might be lying, saying that it's an HTML document when it's really an XHTML document.
[...]

That's the case now for IE, and IE has a larger audience. Who would have to win now, tell me?

Let's take, for example, this forum page, where we exchange ideas. Is it not true that it's a XHTML sent as texl/html? So it's not a proposal, it's a fact.

Why it's not a html doctype on this page, but a xhtml?

I'm sure, that, in theory, you are 100&#37; right. In practice, there comes a redneck like me that wants a new attribute for his html element. There comes to rescue him xhtml. Very easy. And crossbrowser.

Why all IE, FF, Saf, Op, Ch allow usable non-standard elements and attributes in a html DOM?

You have told me how things supposed to be. I'm showing you they are different in practice. Prove me wrong. Prove me that a text/html header will restrict elements and their attributes in html DOM created to standard. Why is not this the case?That's my real question here. For all browsers, since they all allow this.

I'm sorry for the bold tone of my intervention. I don't mean any offence, and the least of all, not to you .

[AutisticCuckoo]

That's the case now for IE, and IE has a larger audience. Who would have to win now, tell me?

No, that is not the case now for IE. There's a huge difference. You serve something as text/html and IE treats it as HTML, just as it should. Your HTML is invalid, containing a lot of extraneous '/' characters and some invalid attributes like xmlns and xml:lang, but that doesn't matter much. Invalid attributes are just ignored, and the extra solidus characters are, unfortunately, ignored as well (not just by IE, but by virtually all browsers).

So the 'fault' here lies with you, for stating that you are serving HTML while your document is invalid HTML. But the browsers do the right thing and treat it as HTML when it is declared to be HTML.

But with your proposal, you would state that it's HTML but expect browsers to treat it as XHTML. That would be very, very bad. Content sniffing is a recipe for disaster. Have you tried serving an HTML code example as text/plain and seen what IE does with it?

I don't understand why you think it would be better to lie in the content type declaration and expect user agents to try to figure out what they got. Isn't it much better to declare what is coming and then expect user agents to believe you?

Why it's not a html doctype on this page, but a xhtml?

Mostly, I think, because it's built on a commercial software package which probably generates XHTML markup. But since the most common browser doesn't support XHTML, and there is no advantage (but plenty of disadvantages) in serving XHTML even to compliant browsers, SitePoint has chosen to serve it as HTML. Also, some of the guys at HQ still have a thing about XHTML, believing that pretend-XHTML is in some mysterious way superior to HTML.

In practice, there comes a redneck like me that wants a new attribute for his html element. There comes to rescue him xhtml.

Nope. You cannot make browsers understand a new attribute simply by using XHTML. You need to write a new version of the browser, or at least some sort of plug-in.

The extensibility of XHTML is largely a myth. Yes, you can create another XML-based markup language with its own namespace and integrate that into an XHTML document. But browsers have to be updated to support this new markup, or will need a plug-in to handle it. Try including some MathML or SVG in your XHTML (served as application/xml) to Internet Explorer, and you'll see what I mean. Extensibility is a pipe dream, that's all.

Why all IE, FF, Saf, Op, Ch allow usable non-standard elements and attributes in a html DOM?

Mainly for reasons of compatibility with legacy code from the Bad Old Days of the browser wars. In some instances also for expected compatibility with future standards, e.g., the <video> tag that may appear in HTML5 one day.

You have told me how things supposed to be. I'm showing you they are different in practice. Prove me wrong. Prove me that a text/html header will restrict elements and their attributes in html DOM created to standard.

Now you are talking about something completely different.
Browsers use non-validating HTML parsers, with lots of built-in error handling to try to make some semblance of sense out of the tag soup that most authors are feeding them.

The purpose of HTML is to make it easy for people to publish content on the web. Therefore browsers are lenient and accept badly invalid markup and still manage to render it the way the author intended.

XML has a very different purpose. It's meant as a data storage and transfer format, for machine-to-machine communication. It's intended to be created by software – not hand-coded – and thus expected to have the correct syntax. This means XML parsers don't have to worry about error handling. In fact, they are required by the XML specification to abort as soon as they encounter a well-formedness error. This makes XML – including XHTML – very poorly suited for web pages, especially if they are hand-coded or may be hand-edited. People make mistakes, but XML doesn't allow any mistakes.

[Ulyses]

OK, you make a lot of sense, and I thank you for the lessons you are teaching me, regarding html and xhtml.

Now, please find me a solution when I want to use HTML (4.1/5) and I want a customizied markup in my html code, that's not xhtml and it's error ways related.

What I want to do is this: I have a html element, let's say a div. Mainly my concern is CSS styling for it.

I don't want to use a stack of classes for it to make a selector in CSS. But instead, I want to be able to declare an attribute for it and combined it with a class selector.

Let's say, that insted of

<div class="class1 class2">

with the following CSS selector

div.class1.class2

I want do do something like this

<div class="class1" objtype="class2">

and use a attribute selector like this in CSS

div.class1 [objtype="class2"]

Please don't mind that div could be missing from the selector, don't mind id selector or any other things that could be changed in code, and don't ask why this way, let's say I have my reasons. You know that sometimes you are faced with decisions out of your personal control.

[AutisticCuckoo]

Now, please find me a solution when I want to use HTML (4.1/5) and I want a customizied markup in my html code, that's not xhtml and it's error ways related.

The way I see it, you have two options:

1. Do what you outlined in the post above and accept that it won't validate and that there are no guarantees for how future UAs will deal with it.
2. Accept that HTML provides two attributes, id and class, specifically for this purpose and work within the parameters offered to you.

I don't want to use a stack of classes for it to make a selector in CSS.

Sorry, but that's how it's supposed to work. You can either accept that and get on with your life, or spend a lot of energy trying to reinvent the wheel for no real purpose.

And the discussion is inappropriate for this FAQ, as what you are proposing is equally invalid in XHTML as it is in HTML.

[Ulyses]

First of all, it's not the way I wanted, the client is always right.

Secondly, thank you for taking the time with me and this argument I've done.

Thirdly, this was not for nothing. I believe you've made a follower out of me. I'll try and use html 4.1 strict doctype instead of xhtml 1.0 strict, see where it gets me.

I'm almost convinced now that the list of recommended doctypes http://www.w3.org/QA/2002/04/valid-dtd-list.html are to be used when appropiate . Just because one exists and it's new and shiny does not make it also a default choise.

For public sites, I now believe html doctypes are the way to go. Otherwise, it depends on the UAs you will be targeting for that project first, and then on the features each doctype may offer.

UAs are not my real concern, as they ALWAYS provided backward compatibility. My concern is, when this great feature, of error friendly, easy handling, in html world world of documents, will became a weakness.

But be aware, if I ever find my self in a conandrum using html doctypes, I just might be on your hair!

But, unlike you, I believe xhtml has a future. HTML5 specs says so http://dev.w3.org/html5/spec/introdu...#html-vs-xhtml. I believe UAs (as a hole) are not ready just yet for it, just like CSS was not an answer for a while.

Thank you mr. Tommy Olsson.

[AutisticCuckoo]

But be aware, if I ever find my self in a conandrum using html doctypes, I just might be on your hair!

No worries about that!

But, unlike you, I believe xhtml has a future.

I think there may be a future for XHTML as well, but not the way most people anticipated back in 2003 (and still do, for that matter). I simply don't think it's suitable for general sites, due to the draconian error handling. It would require user-friendly publishing tools that guarantee well-formed markup and, hopefully, reasonably semantic markup as well. And those tools would have to be free (as in beer) or very very inexpensive to gain a sufficiently widespread user base. Hand-coding real XHTML is perhaps something for a small group of computer nerds, but not for the general public.

No, I think the future for XHTML might lie in specialised applications for limited audiences – like intranets – where you can be sure that the appropriate plug-ins are available. Or when you are compiling with XML information from several different sources, where it might make sense to use XML tools across the board.

On the other hand, it wouldn't surprise me if HTML5 will allow XML-like namespaces (like XHTML5) so that you will be able to integrate things without using the XML serialisation. Who knows?

Thank you mr. Tommy Olsson.

You're very welcome!

[noonnope]

hi.

i was reading this very carefully and i think it's a very good point for using html not xhtml.

but there's a common ground here for all web technologies used: take care of IE in a special way.

the only problem is that IE downloads application+xml. otherwise it supports xhtml and xml. at least, to my understanding.

so, i was wondering if there is a xhack. can a page be forced to re-render (after it was loaded completely and parsed in an html DOM)? like with tables, only this time there is a error in rendering that forces UA (IE UA) to start all over with the document, but using meta info, not http header data? this time in a xhtml DOM? without downloading the page again? maybe if the page is a table layout, and use that progressive rendering, only in reverse.

or perhaps meta info will only lead to the same outcome: downloading. perhaps something else?

also, wil it be a good practice to first determine UAs at server side and then serve either xhtml either html?

thx.

[ralph.m]

People have come up with various hacks, such as this one, if you really can be bothered.

Here are some others I bookmarked in the days when I cared:
http://perishablepress.com/press/200...-and-htaccess/
http://keystonewebsites.com/articles/mime_type.php

... and if Tommy ever bothers to fix up his site (!)
http://www.autisticcuckoo.net/archiv...nt-negotiation

[AutisticCuckoo]

the only problem is that IE downloads application+xml. otherwise it supports xhtml and xml. at least, to my understanding.

No, not really. Internet Explorer supports XML inasmuch as it can parse it and also render it if a CSS style sheet is provided. But it doesn't really support XHTML. It doesn't recognise it 'semantically'; it sees XHTML as any other XML if you serve it as, e.g., application/xml.

If you provide a style sheet which contains every little detail needed to control all aspects of the presentation, then you can make it render as wanted. But IE7 and older don't support CSS well enough to do that.

Unless you have very, very special needs, there is no point in using XML for web content anyway. It's just a major hassle, at least unless you have a content management system that absolutely guarantees well-formed output.

[noonnope]

thx for references, ralph.m.
thx for answers, AutisticCuckoo.

if i need xml content, ajax would be the solution. no need for xml webpage.

but if i want to use technologies related to xml? namespaces are out of the question? what else do i lose?

[AutisticCuckoo]

if i need xml content, ajax would be the solution. no need for xml webpage.

No, that wouldn't work. Not with what I mean by 'XML content'. I'm talking about integrating markup from other XML namespaces, such as SVG or MathML.

but if i want to use technologies related to xml? namespaces are out of the question? what else do i lose?

Namespaces is the only thing of importance. You'll also lose the ability to use CDATA sections, since the HTML parsers in most browsers don't support that even though they should. Opera and Lynx do, though.

You'll also 'lose' the ability to parse and treat your web page content as XML, e.g., for integrating it elsewhere. But, of course, you can still store your content as XML server-side, and just transform it to HTML (or pretend-XHTML if you insist) before serving it to browsers.

[noonnope]

restricting my self to html use shows i'm following general availability and standards.

but if xhtml pretend works, i should negotiate content and use it? because using it, even as poorly as IE's doing it, i'm gaining.

is there a need for different classes of browsers: for web pages, for web apps (paint, paint.net, photoshop)? other apps areas have evolve that type of classification.

is it too much to ask from a single app, or making an universal app (which over decades has not) will be someday a goal come true? will it be too late? will it become obsolete?

because standards appear to be one step behind. html5, like it is now, does some good, but only looking from html 4.01 perspective. it doesn't show a vision. it's somewhat resemblent to xhtml, specific and restricted to a pattern. it's innovative steps in some areas are clouded by a specific pattern: header, footer, article. is html5 a template rather than a step forward?

[AutisticCuckoo]

but if xhtml pretend works, i should negotiate content and use it?

Only if, for some reason, you like to do a lot of extra work for no gain.

because using it, even as poorly as IE's doing it, i'm gaining.

No, you do not. Not unless you really have two separate instances of copy (no conversion) where one is a 'full' XHTML version with elements from other XML namespaces and the other is a 'dumbed-down' HTML version with less content aimed for HTML-only browsers.

Let me repeat (for the umpteenth time): there is NO technical gain in using pretend-XHTML instead of HTML. There cannot be, because pretend-XHTML IS HTML as far as user agents are concerned. Invalid HTML, to boot.