world wide shitstain

Serving XHTML pages as text/html is the cancer that is killing The Extensible Hypertext Markup Language.

So is the fact that the most widely used browser happens to not support it.

"PROVE ME WRONG"

This spot is reserved.

Serve as xhtml+xml, NO EXCEPTIONS.

>>4
EXPERT PROGRAMMERS disagree with your opinion, HTML is dead or dying and cannot be fixed.

http://www.sitepoint.com/article/future-html-xhtml/

XHTML leverages core skillsets and world-class team synergy to provide clients worldwide with robust, scalable, modern turnkey implementations of flexible, personalized, cutting-edge Internet-enabled e-business application product suite e-solution architectures that accelerate response to customer and real-world market demands and reliably adapt to evolving technology needs, seamlessly and efficiently integrating and synchronizing with their existing legacy infrastructure, enhancing the e-readiness capabilities of their e-commerce production environments across the enterprise while giving them a critical competitive advantage and taking them to the next level.

>>8
>No concrete reasons

Nice try troll.

>>11
Its future-proof.

>>13
Do you even know what XHTML is?

>>14
A miserable pile of XML

You guys do know that XML nature of XHTML makes it easier to parse and work with than HTML which has less rigid rules.

>>16
HTML "has less rigid rules"
XML "Easier to parse"

>>16
That doesn't mean xml is any good. It just means it sucks slightly less cock.

>>16
Parsing XML is far  harder, thats why schemas and DTD exist.

>>19
Of course, HTML doesn't need a DTD at all.

XHTML is probably the only thing XML is good for. Pretty much like HTML, only it prevents ENTERPRISE web developers from using retarded tag soup.

Guys, HTML 5 is coming out soon. In both XML and plain SGML flavors. So relax.

>>21
How do you propose doing OpenDocument Format or XMPP without XML.

>>23
Anything which is 10 times smaller then tagged text.

>>19
The purpose of DTDs and Schemas is to give meaning to a set of XML elements. Without it, you can get overlapping elements that would make things ambiguous.

>>24
So you're just shit-talking. Understood loud and clear. 5/10.

>>24
Servers can GZIP all this XML better then your format.

>>19
lel wot
Parsing XML has nothing to do with validating XML.

>>22
Just what we need, more incompatible shit.

>>28
I thought they were planning HTML 5 to be backwards compatible with 4?

>>29
It is... mostly.

Internet Explorer needs to jump on the badwagon so EXPERT programmers can finally stop beating the dead horse and turn a new page.

Expert programmers beat the dead hose because they like it.

>>31
Mixed metaphor detected

>>33
YOU DON'T SAY!

>>34
Well. Way to ruin the joke

>>27
I hope you're trolling. These "tagged text" formats are fucking shit. The "XML crap inside ZIP files" is even worse, yet like all shit, it attracts developers like crazy. Now both MS Office and the freetard stuff use them, and Adobe wants to make PDF that shit too ("Mars" I think it was called).

It's funny, Excel 2007 has an optional hybrid format which uses a binary file for cell contents in order to avoid being slow as fuck. The autosave-every-10-minutes is done in binary too.

Files are made to be read by machines. If you want to have source text or interpret them, more power to you, but the final distributed stuff should be in efficient, compact binary form. Then you use GZIP *on that* (besides, just throwing GZIP at everything is retarded: XML-style garbage can benefit a lot from preprocessing before compression, improving both speed and size, but the browser people are too busy masturbating over the tag soup to notice).

XML vs binary, a point-by-point comparison:
* Size: binary wins
* Compressed size: binary wins
* Read/write speed: binary wins, by about an order of magnitude, in some cases two (good thing file parsing isn't much of a factor anymore, unless you are trying to do serious stuff)
* Human-readability: XML wins, still not optimal for reading though (just open the fucking file, for fuck's sake)
* Human-writeability: XML kind of wins, yet for complex stuff it's useless anyway (maybe for correcting a typo or moving some element or whatever, but I hope you're not thinking about editing an ODT/ODS file by hand)
* Code size and complexity: I hope you're kidding. Good thing you can use some monstrous, hideously bloated libraries to process it, otherwise XML would see no use
* Extensibility: tie. A properly designed binary format can be just as "extensible" (read: backward- and forward-compatible, for the unenterprised people) as XML. A random example is the old DOC/XLS/PPT format that served Office from version 97 to 2003 and can still be saved by 2007 (yes, you can open them in 97 even if they use newer features)

tl;dr: Enjoy your bullshit kool-aid and wanking about trivialities, your CPU-bound servers, and your bandwidth bills.

Anybody notice software quality is inversely proportional to the ammount of XML used? Correlation does not imply causation, but that rule-of-thumb seems to be working pretty well so far.

>>36
TIFF minus the image.

XHTML is not XML

>>39
Yes, it is.