Still don't understand reason to use html 4.01 over xhtml doctypes

[ratman7]

I have been researching this but have not been able to come to a conclusion.

Can somebody tell me, in plain language and practical terms, why coding a valid xhtml page (strict or transitional) served as text/html and using the corresponding xhtml 1.0 doctype is not appropriate? Bear in mind, I am not looking for theoretical arguments on the purpose of xhtml in the first place, or the place of the W3C; we can all come up with those opinions on our own.

To restate my question:
The W3C says use xhtml, so I use xhtml. My xhtml validates with ZERO error on the W3C validator, and displays appropriately in all major browsers. What is the problem with this?

For background, this is a thread on the topic from last year:
[webmasterworld.com...]

Thanks in advance for your input.

[edited by: tedster at 11:40 pm (utc) on Oct. 24, 2007]
[edit reason] fix link [/edit]

[londrum]

i don't understand what all the fuss is about either... some people think serving XHMTL is text/html is for fools, but i don't think there's anything wrong with it.

i can understand their point. there are loads of things that you can do with XML that you can't with HTML (such as MathML). and if you serve it as HTML then you will lose all of those benefits.

but you also gain stuff as well, such as having error-free rigid code. granted, you could gain exactly the same stuff if you just coded it in HTML strict, but what's the difference? at least you're getting your site ready for the future.

on the other hand, you can lose of lot of page weight if you switch to HTML, because you don't have to close some of the tags, and you don't have to quote all your attributes.

at the end of the day, i think it just comes down to personal preference.

[tedster]

The W3C says use xhtml,

Not so. It's one choice in their recommendations. The trouble many people have is thinking that XHTML is "the latest" or "the future". It's not, it's just one possible approach for publishers, helpful in some situations. This idea that it is "the next thing" is where the confusion comes in.

My xhtml validates with ZERO error on the W3C validator, and displays appropriately in all major browsers. What is the problem with this?

Most likely no practical problem right now. The thread that you linked to, and the article it references, outline the possible problems pretty well, I think. The script issues might be one area that can practically affect a site:

A DOM-based script written for an HTML4 document has subtly
different semantics in an XHTML context (e.g. element names are
case insensitive and returned in uppercase in HTML4, case sensitive
and always lowercase in XHTML; you have to use the namespace-aware
methods in XHTML, but not in HTML4).

BUT, if you send your
documents as text/html, then they will use the HTML4 semantics
DESPITE being XHTML! Thus, scripts are highly likely to break when
the document is parsed as XHTML.

...and

Scripts that use document.write() will not work in XHTML contexts.
(You have to use DOM Core methods.)

[ratman7]

I appreciate your response tedster, and it echoes much of what I have been reading: It could do this or that, or you might have some script issues in certain circumstances. It's not that I doubt what you and others are saying; rather, it seems to me that the case to not use xhtml has been made quite strongly for things that may or may not occur.

[Trace]

I'm often asked this exact same question at the office. One of the "best-practices" here is to never use xHtml. Every time a new integrator, or even a programmer, is hired the question comes up.

If I'm not too busy I'll get into a pretty lengthy debate with them.
If I don't have the time to debate it, one simple sentence usually puts the topic to rest;
Internet Explorer does NOT support xHtml.

Even if served as text/html Internet Explorer does not recognize it. It behaves exactly like if you made up your own doctype throwing it into "standards mode" which raises a whole new batch of problems.

[ratman7]

If I'm not too busy I'll get into a pretty lengthy debate with them. If I don't have the time to debate it, one simple sentence usually puts the topic to rest;Internet Explorer does NOT support xHtml.Even if served as text/html Internet Explorer does not recognize it.

But again, based on the example I give in my original post, IE does support xhtml when it served as text/html -- if your definition of support is that the page renders correctly. It is perfectly ok to serve xhtml 1.0 as text. Additionally, doing so without an xml prologue will allow IE6 to render in standards mode.

So again, if your pages are designed to render correctly in the major browsers, I still do not see why in 2007, a valid html 4.01 page is in any way preferable to a valid xhtml page.

It behaves exactly like if you made up your own doctype throwing it into "standards mode" which raises a whole new batch of problems.

Can you elaborate on this? My intention is not to argue with you, but I suspect that many of the reasons people cite for not wanting to use xhtml doctypes have to do more with bias and personal preference than anything else.

[penders]

It behaves exactly like if you made up your own doctype throwing it into "standards mode" which raises a whole new batch of problems.

@Trace: *I think* you mean "quirks mode"? But it doesn't. Using an XHTML doctype will 'throw' it into the same 'standard mode' as if using an HTML doctype.

I don't normally debat on the XHTML/HTML issue, but some prefer the added strictness of validating to an XHTML doctype - having to close all tags etc.

[ratman7]

This from the [hixie.ch...] that everybody quotes:

"Therefore the main advantage of using XHTML, that errors are caught early because it _has_ to be valid, is lost if the document is then sent as text/html. (Yes, I said _most_ authors. If you are one of the few authors who understands how to avoid the issues raised in this document and does validate all their markup, then this document probably does not apply to you -- see Appendix B.)"

What I take from this document is that if you serve xhtml as text/html and not application/xml+xhtml, you lose the potential advantages that xhtml was originally designed to offer, and potentially risk some script and other minor issues. Fair enough.

But assuming that, as he states, your pages are valid and tested xhtml, this is not a good enough reason to warrant going back and changing all of your xhtml pages to html 4. Plus, as others have noted, there is, probably wrongfully, a notion of xhtml being "newer and better".

I would like to think that either HTML5 or XHTML2 will resolve this, which I'm sure this has been discussed at length on here as well. Here's an article I came across today from earlier this year on the subject:

[digital-web.com...]

[RonPK]

at least you're getting your site ready for the future.

The future to me seems to be HTML 5. Lots of new features coming up, such as new elements (nav, article, aside, header, footer, dialog, etcetera), progress display built-in, forms with built-in validation, canvas element for drawing purposes, client-side storage that goes beyond cookies, to name some.

If you like sir Tim believe in the semantic web, than XHTML may be more appropriate.

[Trace]

@Trace: *I think* you mean "quirks mode"? But it doesn't. Using an XHTML doctype will 'throw' it into the same 'standard mode' as if using an HTML doctype.

Penders: Nope, it really does run in "Standards Mode". Sounds strange at first but it makes sense. To be future compatible, when it encounters a doctype that it does not recognize it assumes it's a new valid doctype.

So use a xHtml doctype or create your own, IE will behave in the same way.

[ratman7]

Browsers don't kick into standards mode -- it's the other way around.

According to this: [w3.org...]

IE6 will render in standards mode, regardless of whether the doctype declaration is xhtml 1.0 or html 4. Including the <?xml version="1.0" encoding="utf-8"?> above the doctype is what kicks it into quirks mode.

[penders]

Trace
Penders: Nope, it really does run in "Standards Mode". Sounds strange at first but it makes sense. To be future compatible, when it encounters a doctype that it does not recognize it assumes it's a new valid doctype.

Blimey! Thanks for the clarity! For a long time I've been thinking that simply an invalid DOCTYPE would cause IE6 to render in quirksmode, but that's not the case. IE6 will render in quirksmode with certain DOCTYPEs, no DOCTYPE or something before the DOCTYPE (such as an XML prolog).

However, the following will in fact 'throw/kick' IE6 into standards mode (W3C box model etc.):

<!DOCTYPE html PUBLIC "something">

IE7 as well I presume? :o

[mikedee]

My opinion is that there is no benefit in switching from XHTML to HTML4, there is also no benefit in switching from HTML4 to XHTML (which is why there are 2 camps of thought here).

For new code I would personally start writing for HTML5 so you can make it XML compliant if you really want to (but still keeping HTML4 compatibility).

Bear in mind that there is no benefit if serving as text/html and you risk your pages breaking if you serve as text/xml to non-IE browsers. Having a paragraph look slightly wrong is nothing compared to having your entire page break because of some third party code. If you are serving as text/html then why bother to write valid XHTML? (surely it requires more investment of time than HTML4).

So my question is why would you start writing XHTML and then serve it as text/html? It will look just like HTML, but without any of the benefits of the 'X'.