XHTML vs. HTML

[Kraetos]

http://webkit.org/blog/?p=68 (via John Gruber (http://www.daringfireball.net))

Basically, a doctype declaration of XHTML doesn't mean anything because the mimetype stays text/html, and therefore, is really HTML trapped in an XHTML container.

However, changing the mimetype can have ill effects, especially on IE.

But, declaring as XHTML and then writing XTHML with a text/html mimetype is bad because if something ever tries to parse your stuff as true XHTML, you're shit outta luck.

I am muy confused.

XHTML is BAD now?? Every modern book I read extolls the "XHTML is the future and isn't sloppy like HTML was!"

So, naturally, I switched to XHTML Strict on my sites and validated like my life depended on it.

So what the hell do I do now? The link recommends going BACK to HTML 4.01, but that seems like a step backwards to me.

So, heres a question: what if I declared HTML, validated through an HTML validator...

but wrote XHTML? (It's not like their that different, anyways. XHTML is just cleaner and stricter.)

Seems to me like this is the best way to go about it. Good XHTML 1.1 should validate as HTML 4.01 anyway, right? But this way, if I ever need to actually declare as XHTML, I switch the doctype and the mimetype, but the code is already there.

Or am I overthinking this? Should I go back to HTML 4.01 and just write it well?

[Brad]

So what the hell do I do now? The link recommends going BACK to HTML 4.01, but that seems like a step backwards to me.
Why? Does your XHTML need to be readable by XML readers? What was your reason for choosing XHTML? :) If you didn't have a solid reason for using it in the first place, you don't have a solid reason not to give it up now.

(Yes, I read this blog earlier today too and am going through the same thoughts myself.;))

So, heres a question: what if I declared HTML, validated through an HTML validator...

but wrote XHTML? (It's not like their that different, anyways. XHTML is just cleaner and stricter.)
Note from the blog the point about the use of "/" in self-closing tags:

It’s important to note that this is kind of a hack, and depends on the de facto error handling behavior of HTML parsers. They don’t really understand the XML self-closing syntax, but writing things this way makes them treat / as an attribute, and then discard it because it’s not a legal attribute name. And if you tried to do something like <div />, they wouldn’t understand that the div is supposed to be empty.

What he's saying is that the use of "/" in HTML is undefined by the spec. The only reason it works okay today is that all browsers currently treat it the same way. Since its behavior is not formally defined, though, that compatibility cannot be guaranteed as browsers move forward.

[rollercoaster375]

My suggestion (And what I do): browsersniff for IE, and serve pages as text/html for it. However, for all other browsers, serve it as application/xhtml+xml. His arguments against this really don't stand. In IE, using XHTML and sending it as HTML has no impact on the rendering. As long as you don't try throwing HTML into your XHTML, it will work fine. As for the maturity of the XHTML render engines... The best way to mature them is to use XHTML, and make it a priority, as it should be.

I use XHTML over HTML for the XML-ness. Parsing a well-formed XML document is MUCH easier than a well-formed HTML document. (In fact, my templating engine relies on an XML parser to transform the XHTML).

But yes, there is a real movement to go back to HTML. I really don't see a reason to. There's nothing inherently /wrong/ with serving XHTML 1.0 as text/html [It's allowed by the spec], it's just not the recommended way of doing things [I actually find incremental rendering to be annoying-Things can be misleading].

[chucker]

His arguments against this really don't stand.

Yeah, they do. Especially that Gecko doesn't provide incremental rendering for "true" XHTML. That's quite a thing to consider.

[rollercoaster375]

Why is incremental rendering important?

[chucker]

Why is incremental rendering important?

Because it makes for a huge perceived performance boost.

[rollercoaster375]

Only if you have a slow connection and/or are loading very large pages.

[chucker]

The point is that HTML rendering is far more optimized than XHTML rendering. In Gecko, in WebKit, and presumably also in IE 7.

The benefits of XHTML are far overrated.

[Kraetos]

I personally don't really care if I use XHTML or HTML.

All I know is that until that link, everything I'd read said "XHTML is better and is the way of the future, so you should use it."

So I did. All my pages are already written in "valid" XHTML and I don't care much for going back and stripping all the />.

Nothing about anything I write "requires" XML or XHTML, my pages just aren't that advanced. It would all work as HTML. I can't imagine anything ever needing to parse my pages as XML or XHTML.

So, which is better? Which is more futureproof?

I mean, I guess I'll just ask my question straight up: which should I use?

I mean, rollercoasters solution sounds good, but a little extreme. Given that nothing mainstream requires the application/xhtml+xml minetype to work correctly, I could just stick with what I have. When something pops up that is popular and requires the page to be served as application/xhtml+xml, I could just browsersniff for it.

[chucker]

XHTML is definitely more futureproof. The article's point is not to make you roll back to SGML-HTML. It's that XHTML, for the time being, does not have much of an advantage, and that a lot of people who believe they use XHTML technically don't.

[rollercoaster375]

The point is that HTML rendering is far more optimized than XHTML rendering. In Gecko, in WebKit, and presumably also in IE 7.

The benefits of XHTML are far overrated.

IE7 doesn't even have and XHTML mode. XHTML support is pinned for IE8, according to the IEBlog. But yes, you're right. However, like I said before, it'll stay that way unless we use it.

The benefits of XHTML don't exist when you treat XHTML like it's HTML. XHTML opens you up to many more technologies that you couldn't use otherwise: MathML, SVG, other XML dialects, XML Parsing, and more. Plus, it gives you out-of-the-box syntax checking.

But all of that only happens when you're treating XHTML as what it actually is: XML.

[chucker]

The benefits of XHTML don't exist when you treat XHTML like it's HTML.

Exactly.

XHTML opens you up to many more technologies that you couldn't use otherwise: MathML, SVG, other XML dialects, XML Parsing, and more. Plus, it gives you out-of-the-box syntax checking.

But all of that only happens when you're treating XHTML as what it actually is: XML.

Which you can't do unless you add browser sniffing, in which case things become heavily unpredictable.

Oh, did I mention WebKit doesn't support named entities in XHTML?

[Gargoyle]

I have also read that article (or a similar one) some time ago. I have decided to stick with HTML 4.01 Strict.

I think a more important target for the progression of the web, is not what version of (X)HTML to use, but instead to get the proper document / presentation separation with CSS. However, that is also flawed. IMO, using CSS hacks in your style sheets to get round layout bugs is just as bad as using tables for layout.

The people who make the standards also need to take into account the fact that not everything on the web these days is a "page". I have just had a major nightmare trying to get a map to fill the rest of a page using 100% height in one of my applications.

[rollercoaster375]

IE can handle XHTML has HTML, even with an XHTML doctype. It works... I would say fine, but it's IE.

And yes, I'm aware of that. It's annoying. But it can be overcome without significant difficulty.