Why not XHTML5

htmlhtml5xhtmlxml

So, HTML5 is the Big Step Forward, I'm told. The last step forward we took that I'm aware of was the introduction of XHTML. The advantages were obvious: simplicity, strictness, the ability to use standard XML parsers and generators to work with web pages, and so on.

How strange and frustrating, then, that HTML5 rolls all that back: once again we're working with a non-standard syntax; once again, we have to deal with historical baggage and parsing complexity; once again we can't use our standard XML libraries, parsers, generators, or transformers; and all the advantages introduced by XML (extensibility, namespaces, standardization, and so on), that the W3C spent a decade pushing for good reasons, are lost.

Fine, we have XHTML5, but it seems like it has not gained popularity like the HTML5 encoding has. See this SO question, for example. Even the HTML5 specification says that HTML5, not XHTML5, "is the format suggested for most authors."

Do I have my facts wrong? Otherwise, why am I the only one that feels this way? Why are people choosing HTML5 over XHTML5?

Best Answer

I would recommend reading How Did We Get Here?. Mark Pilgrim gives an excellent and brief history of HTML up to HTML5.

Essentially though, my understanding is that many webpages don't even take advantage of the "X" of XHTML because they don't specify the proper MIME type for it.

Related Solutions

XML – Why XML is Not Called EML

I took a very pleasant tour through W3C, Google, and Wikipedia and finally found the answer: an annotated XML spec where we find an excerpt of an email from the inventor of the name, James Clark, an email from chairman Jon Bosak who suggested to use the X letter, and some other ideas for names and the final votes:

Votes | Acronym | Full Name
------+---------+--------------------
5     | XML     | Extensible Markup Language
4     | MAGMA   | Minimal Architecture for Generalized Markup Applications
3     | SLIM    | Structured Language for Internet Markup
1     | MGML    | Minimal Generalized Markup Language

This is Jon Bosak's reply to James Clark's suggestion to name it "Extensible Markup Language" and gave birth to the acronym:

In my opinion, the U-combinations won't fly, but if we allow "X" to stand for "extensible", then I could live with (and even come to love) XML as an acronym for "extensible markup language", and I hereby now throw it into the list of current proposals.

^{(Emphasis mine)}

Some bonus - from some old reports of the XML Special Interest Group that I found while looking for some original quote that could answer the question:

M.15 Should the spec refer to XML as "The Extensible Markup Language" or as "Extensible Markup Language" without a definite article (e.g. in the first sentence)?

The WG elected to give no guidance to the editors on this issue (in the full expectation that the result would depend on which editor touched the file last).

Rationale: after several minutes' discussion and increasing hilarity, no consensus had been reached, but the end of the allotted time for the conference call had.

Why No PUT and DELETE Methods in HTML Forms?

This is a fascinating question. The other answers here are all speculative, and in some cases flat-out incorrect. Instead of writing my opinion here, I actually did some research and found original sources that discuss why delete and put are not part of the HTML5 form standard.

As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts. Mozilla had actually implemented this in a Firefox beta, too.

What was the rationale for removing these methods from the draft? The W3C discussed this topic in bug report 10671. Mike Amundsen argued in favor of this support:

Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. [...]

This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]

Other considerations:

Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, PUT responses are not(6), DELETE responses are not(7))

Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").

[...]

It's worth reading his entire post.

Tom Wardrop also makes an interesting point (href):

HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]

It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.

The bug was eventually closed as Won't Fix by Ian Hickson, with the following rationale (href):

PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.

However, that's not the end of the story! The issue was closed in the W3C bug tracker and escalated to the HTML Working Group issue tracker:

https://www.w3.org/html/wg/tracker/issues/195

At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.

Best Answer

Related Solutions

XML – Why XML is Not Called EML

Why No PUT and DELETE Methods in HTML Forms?

Related Topic