If you are looking for backward compatibility (NS 4.0 & co), HTML seems to be a good choice.
If you look ahead, I guess xHTML is the way to go...

Please, not that can of worms again! XHTML vs. HTML

Neither is any better. The differences between the two when served as text/html are minimal.

XHTML, but only because it asks a bit more as far as having closing tags and whatnot. Other than that, it's a toss-up.

It all depends on what your client needs. I'm pretty sure that nearly all clients out there don't need real XHTML. By real I mean delivered with the application/xml+xhtml MIME type. The only people who need that are those who use MathML and the like. Otherwise, you can write XHTML using the plain ol' text/html MIME type and be "forward compatible."

I had this dilemma a while ago and eventually converted to application/xhtml+xml, but only because I wanted to have fun with it and I'm a purist at heart. But not because I actually NEED it.

When served with text/html, there is no need to use XHTML.

I use XHTML 1.0, but I serve it as text/html - why? Just because I LIKE closing every single element, I LIKE that cool "X" in its name and I DECIDED to use it.

But there is no NEED for using XHTML when not parsed as a XML application. There is no benefit - XHTML isn't faster and you're not capable to create anything easier than in HTML.

HTML, for all the reasons listed here, here, and here. Anne and Ian are no dummies.

We've (I've) chosen HTML for our CSS template. There are just too many coders and contractors within our Agency that simply don't (won't/can't?) write XHTML.

Ultimately, it doesn't matter -- a frighteningly expensive CMS is coming. Will it output valid HTML? Supposedly.

With any luck, I'll be on my own by then.

I'd tell the client that the 2 are completely interchangeable, from all practical point of view, at this moment, but that XHTML opens up the possibility for future applications, i.e. that it's an investment for the future with an unclear payoff.

The often overlooked advantage of XHTML comes into play when you're working in a team of developers.

Because it's stricter, for example in the case of the tags and the quoting of attribute values, it enforces a coding standard upon your developers.

It's just good grammar. When someone speaks, writes or codes poorly, I roll my eyes, but I still understand what they are saying. Like good grammar, XHTML is a protocol that web professionals should follow. That's part of being professional and may be more important than a mime type or supposed future compatibility.

My choice has been XHTML1.0 Strict served with text/html MIME type. I think its logic is simple, clean and even easier than HTML. It seems ignoring DOM tree and use of document.write is already outdated. However, the most concern I have is not to trigger quirks mode. I don't use xml declaration for that reason. Browsers are not just ready for use with real XHTML yet and I think that's why we are having these discussions.

According to W3C, XHTML is "A Reformulation of HTML 4 in XML 1.0".

See the "What is XHTML" statement here for the benefits over HTML 4:

http://www.w3.org/TR/xhtml1/#xhtml

I recommend you always use XHTML, but not necessarily HTML Strict.

Always XHTML, for a number of reasons all of which I think have been covered already. It is a modern standard offering future proofing, that developers in our industry should be striving for. In fact as I understand it that is what the whole web standards movement is about. Striving to improve our standards and enjoy all there benefits. I'm sad to say there may also be a little snobbery involved, " Oh look they are only using HTML 4.0 Strict they aren't proper standards developers! " syndrome ;)

I think we need to remember also that your server needs configured properly to serve up various renditions of DOC TYPE, just cause you declare it a certain way doesn't mean it gets served that way. Can anybody clarify this?

XHTML 1.0 Strict but served as text/html. Like Quinn, I like the cleanliness of XHTML. I could try using content negotiation and serving it as application/xhtml+xml but I haven't explored that option yet.

I think XHTML is far best than HTML, even if you serve it as text/html.

Let's point XHTML sintaxis is really good in general for parsing. Most rules and tags closes like HTML but, in HTML you can find a perfectly valid (but not practical) ul list without any single

. Ok, you can parse it, but you can to work more to detect cases...

Even atributes and a lot of stuff in HTML isn't the best way. By the way, you can use it, and when u feel it's proper you serve it as a xml.

Well, I'm currently using XHTML 1.1 with the correct mimetype to those that can use it as described here.

However, I've decided that with a new redesign and overhaul of my site looming that I'm going to go back to HTML 4.01 Strict. The reason? Right now I see no real benefit to use XHTML when I know that I personally will write just as valid code whether I'm using XHTML or HTML. Part of the reason I went with XHTML in the first place was due to the snobbery described above.

XHTML 1.0 is more SCI-FI

XHTML. just 'cause HTML was donkey years ago :D

I use XHTML for the same reason Kevin stated, it enforces closed tags and leaves little room for error. I like to have everything clean and laid out, and little things like self closing tags help me point out where things are in my coding. uppercase tags just look plain obnoxious too

oops, forgot the reference link to Kevin's post I was talking about, here it is: http://www.456bereastreet.com/archive/200601/html_or_xhtml_does_it_really_matter/#comment1

As I wrote in my article about this subject, there's no reason to use XHTML... yet. Since IE doesn't support the application/xml+xhtml media type you can not even use real XHTML. Using XHTML served as text/html has no advantages at all. So why should one use it? Because it's newer? That's bullshit...

Until user agents properly support XHTML and other namespaces such as SVG and XForms, I don't see a reason for using it. Some say they like it because they it's stricter, others say they like it because it prepares them for "the future", but why should you make it yourself harder when you don't get anything in return for it!?

XHTML served as text/html is utter garbage. How's that for mood setting?

Therefore if you use XHTML for a www site you'll either have to do content negociation and rewrite the output as HTML for Internet Explorer (and Lynx, etc.), or you restrict your audience to 10 to 50 % of the population depending on your target audience (from Amazon to Boing Boing).

So from that point of view HTML is definitely better.

Regarding semantics, XHTML doesn't offer a single new attribute or element. Wanna bet?

You can write HTML as strict as any flavour of XHTML. Those who can't or say otherwise simply don't know HTML very well.

XHTML's draconian error handling can hurt your site. It is not adapted for most commercial websites (see http://www.gamevillageshop.nl/, via Anne van Kesteren).

But on the plus side, XHTML is sooo cool, it's the choice of a new generation, so I guess it must be worth it.

For whatever it's worth:

When it comes to HTML versus XHTML, I just do not care. Sure, sure, people will tell you that XHTML is XML so it?s more transformable or something. That?s a very good argument when the XHTML is well-formed and valid. It?s also a very good argument for using HTML when it?s well-formed and valid. Conversely, neither HTML nor XHTML is easily transformed when ill-formed and invalid. This is an experiential point of view, too: I?ve written XSLT (which is itself so tortuous and ugly that it almost by definition cannot be called well-formed) to transform both HTML and XHTML, and the effort is pretty much the same each way?assuming well-formed, valid markup.

-- from "Slashdot's Validity"

Jero,

I totally agree with you, but it's not application/xml+xhtml, it's application/xhtml+xml.

see http://www.iana.org/assignments/media-types/application/

Stupid mistake, thanks for the correction.

And to thank you, I'd like to point out that it's "recommendations", not "recommandations" as you've used on your website under the What standards mean heading. Recommandations is French if I'm not mistaking ;)

Does it really matter? Choose one and do it well. That's it.

I wrote a little more extensively about it in HTML or XHTML and that's my conclusion about it (sorry for the shameless self promoting).

Jero - Are you using CSS? Apparently the latest release of this standard is not fully supported in all browsers. Are you going to stop using CSS and go back to HTML presentational attributes? Probably not.

The point is XHTML strict is a better standard because of its syntax rules and future extesibility. The only drawback is the lack of current support for application/xhtml+xml, a delivery method. The main problem with HTML is how loose it has been and what a pile of garbage code it has made of the web.

For now, if you use well formed valid XHTML or HTML , there is no difference. I prefer the former.

No question about it for me, XHTML all the way. Despite the fact that I know how to write valid and future-proof HTML, once in a while I still miss something by accident. And as others have mentioned, just because many of us are smart enough to write good code doesn't mean everybody else is too.

I always recommend HTML 4 to all clients, there is absolutely no valid reason to publish XHTML on the web for commercial sites yet.

Dave: Server response headers are first priority, overruling any other declaration.

Sage: Been a long time since I read those articles, but I recall the arguments as specious$this->normalizeEntities16bit("8212")if you mess up the markup, you're screwed in the future. Well, duh. Write it correctly to begin with. It's not difficult to test as application/xhtml+xml.

HTML4 or XHTML1, either is fine, though there is no sane reason to write a new document to other than a strict DTD. I prefer to write against xhtml1, but that's just me. I'll put myself in Robert N's camp.

Lachlan: I'll agree. There is also no valid reason not to publish xhtml for a commercial site.

cheers,

gary

bart,

Your argument about XHTML's future extensibility doesn't hold.

XHTML's extensibility is real only when XHTML is served as XML. Since this will not be viable for commercial sites until Internet Explorer (or whatever represents over 80% of the browser market in "the future") supports XHTML.

As I said, I don't see that happening soon, since IE7 won't support XHTML, and therefore widespread support for XHTML might only happen when IE8 (if it does support XHTML) is itself widespread.

At the current rate of browser release by Microsoft and the current rate of browser renewal worldwide, I'm gueessing so many redesigns will have happened in the meantime for any given site, that betting on HTML today is still a safe choice.

gary,

"There is also no valid reason not to publish xhtml for a commercial site."

Yes there is. That's my whole point: if you serve XHTML as text/html, you're actually sending broken XHTML to the user agent.

Why do that when you can serve perfectly valid and lean HTML that all will understand?

I know this is a very sorry excuse, but I'm too used to writing XHTML anyway (serving as text/html) though, such as the closing of every element.

Besides W3C says XHTML 1.0 (Strict) "should" be served as application/xhtml+xml instead of the "must" in XHTML 1.1.

So unless someday W3C disagrees, I'm really too lazy to convert to the "right" practice.

S$this->normalizeEntities16bit("233")bastien said "Yes there is. That's my whole point: if you serve XHTML as text/html, you're actually sending broken XHTML to the user agent."

That xhtml is made html compatible does not mean it's broken. For one, the W3 clearly allows for it (see http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#text-html ), for another, I'm quite used to the syntax and would find it difficult to change, since, thirdly I do indeed extend the DTD with my own elements, entities and attributes for an IE-free intranet, writing html compatible xhtml and serving it as application/xhtml+xml.

He also wrote, "Why do that when you can serve perfectly valid and lean HTML that all will understand?"

All will equally understand my perfectly valid and lean xhtml when written compatibly and when served correctly as text/html. Why buy a Porsche when the speed limits will only test a Renault? Is that what you mean?

cheers,

gary

What I meant is : "if you serve XHTML as text/html, you're actually sending broken *HTML* to the user agent.", sorry.

The markup may be valid by itself but when served as text/html, UAs will still treat XHTML markup as invalid HTML. I never meant to imply that markup following Appendix C guidelines of XHTML is invalid.

I know that note, I translated it into French, it's a NOTE not a recommendation.

As for the car analogy, let's say for the time being XHTML is a Formula 1: you can only use it on closed circuits, not for shopping, not for transportation, and HTML is my good old trusty Porsche, which I can also take on the highways, regardless of speed limits.

I'm sure this is going well beyond the expected scope of the subject, but I have to ask, in what way is html compatible xhtml1, served as text/html, "broken *HTML*"? Second, in what way does the UA treat that xhtml as invalid html? I have yet to see any negative effect from this 'invalid html', nor do I expect to.

I expect a note to express intent or to clarify a point. In lieu of contradictory recommendations, I will accept it as authoritive until something else comes along.

Your anology is specious. XHTML is not an F1. Anything html can do, xhtml can do, and then do more when circumstance allows.

There is no compelling reason to choose one over the other, nor is there compelling reason to reject one in favor of the other. Ian Hickson quite rightly suggested that if you get xhtml wrong, it could bite you in the butt somewhere down the road. So, someone who can't get it right might oughta avoid xhtml. Otherwise, dance with the one you like.

gary

Of course Jonathan can pull the plug on that thread any time he wants...

Gary,
A closed meta element is invalid in HTML.
A UA receiving markup served as text/html, attempts to parse it as HTML. So that UA will be encountering an HTML error very soon in case of XHTML served as text/html.

And that's not to mention UAs that choke on XML prologs.

I'm done pushing the enveloppe here, if anyone wishes to reach me, my e-mail can be found on my website (or use the form on my contact page).

The closing tag is forbidden on all(?) empty elements. It is speculation on my part that the space prior to the virgule, added for compatibility, causes html UAs not to read /> as a closing. :shrug:

The xml prolog/declaration is optional on xhtml as long as xml1 and utf-8 or utf-16 are used. When delivered as text/html, it is superfluous and should not be included. And that covers IE's quirk mode problem.

It comes back to there being no practical reason to choose one or the other, though there may be arcane and esoteric technical or religious reasons. Those are beyond my ken and have no bearing.

Thanks, Jonathon. A good discussion with no true conclusion serves to whet the mind. Kinda like arguing Debian policy. :)

cheers,

gary

I've gladly switched to HTML 4. I realized that there's no advantage to using XHTML 1.0 as text/html. MIME Types > all, so even if the doctype says XHTML, it's still HTML.

The strictness, the module support, all the advantages of XHTML can not be used with text/html.

Until the most widely used browsers support it, XHTML can not be realistically implemented.

HTML, for all the reasons listed here, here, and here. Anne and Ian are no dummies.

Sage, are you saying Jonathan, Douglas Bowman, Dave Shea, Molly Holzschlag, Dan Cederholm and hey, Jeffrey Zeldman are all dummies? Because they all use XHTML, and for perfectly good reasons, too.

[quote]The closing tag is forbidden on all(?) empty elements[/quote]

The W3C validator doesn't like them in the head (html4.01 strict), but is quite happy with <img /> and <br /> in the body.

xhtml can make using modern (degrading) JS methods troublesome. I use it on my own sites, but after four years of xhtml use have reverted back to html 4.01 for the time being for client sites.

Everybody ought to use XHTML, because it is the future, HTML4, is like, so outdated, even now.

Sebastiaan,

You should read http://www.456bereastreet.com/archive/200512/transitional_vs_strict_doctypes/ and follow a few links.

Faruk: http://en.wikipedia.org/wiki/Reductio_ad_absurdum

PS: My Name is not S?bastien Guillon

XHTTML is weigh kewl! eVry1 who yoozez HTTML 4.x SUX!

I rite XHHTML 1.0 and I kan GeT IE to werk! EveN iF it iZ teknikally "broken HTMML" iT DuzznT mAtTer to the EnD uzEr.

Yew Peeple R 2 uptite!

lol ima h8ckr