Herenvardo - 4:39 pm on Nov 3, 2008 (gmt 0) Anyway, it is a good thing that both HTML4 and XHTML1 provide the same set of elements (even the same three "flavors"). To put it in some other words (just to make sure I express myself decently this time), vendors said "Hey! They admit that we're right. So, if we are right, why don't we make a 'right' spec from scratch?", then threw everything XHTML2 gives, be it good or bad, to the bin, and started writting (and implementing on the fly) a spec that is as flawed and as bloated as HTML3.2 was. I'm not saying they did this with any intention to "harm" the web or to impose their criteria just to acquire more power; it's just that they are blind to the fact that they can make as many mistakes as anyone else can: we're all humans after all. And, since they don't realize they can make mistakes, they are simply rejecting any kind of feedback that involves that possibility. To top it up, the WHATWG miserably failed to scope their efforts, to the point that the document which is supposed to define their "ideal new markup language" almost forgets about the markup itself, and focuses on lots of side-stuff like the DOM, error-handling, implementation details, and so on. I want to emphasize on the "implementation details" part, because I thing this is plainly enough by itself to take that spec and set it on fire: by mere definition, a spec intended for the web must be implementation-neutral.
pageoneresults brings up an extremely important point - the question as posed above is a false dilemma. The choice is not between XHTML2 and HTML5. The choice is between those two, HTML 4.01 and XHTML 1.0.
Currently, this is true. And the actual choice between HTML4 and XHTML1 can get reduced to very simple questions:
- Do you need any of the XMLish features provided by XHTML (such as XSLT, or embeeding of other XML-based formats such as MathML or SVG)?
- Are you Ok with XMLish draconic error handling (a.k.a. "fail on error")?
If you answer yes to both questions, then XHTML 1.0 is for you (or it should be). If you answer no and yes, respectively, then the choice doesn't matter that much. If you answer no to both, definitelly HTML4 is for you. And if you answered yes and no, respectivelly, then you face a tough choice.
When we get browser support in mind, however, IE's silly handling of the "application/xhtml+xml" mimetype leans the balance quite a bit towards HTML4. There are some other factors that may come into play (for example, I've heard that Google's AdSense has some issues with pages being served as XML); but these are often quite case-specific.
The original question on this thread's subject was not intended to ask which would you choose for authoring your pages: browsers will probably choose for us instead. The main point was to bring out what people perceives as the best and worst things on each, their pros and cons.
Insight. Just that. When I initially joined the HTML5 list, I got excited by the apparent openness of the process and, I'll admit it, heavily biased. The few feedback I had seen by that time had been, effectively, been dealt with appropriately; it's just that it wasn't a representative enough sample. Two months later, having seen many more discussions, I've noticed a pattern that I already mentioned earlier:
Feedback expressed in terms of what current implementations do is properly dealt with.
Any other kind of feedback is either discredited as soon as some side-comment arises the chance or simply ignored if no such chance appears.
Honestly, I've only been following the lists for two months, and this means some tenths of discussions (ranging from a single message to around a hundred per discussion), but that pattern applies to all the discussions I've seen since there.
But my point is it wasn't just "tyrannical" browser companies who thought XHTML2 was flawed, experts like Tantek and Mark Pilgrim, and even XHTML advocates like Zeldman, were equally unconvinced.
Actually, I can quite agree with that view. Although I got a quite good impression of it the first time I looked at the XHTML2's spec drafts, I'm not really convinced by it, and the deeper I look at it the more issues I see.
To that I want to add that I am (or, at least, used to be) a XHTML advocate: even I aknowledge there are some use-cases for which XHTML is not good; I used to think that the more sites switched to XHTML, the better the Web would be as a whole.
Your post portrayed the browser's companies decision to not support XHTML2 as some nefarious plot on their part, imposed on the rest of us.
Then I apologize, I failed to express myself properly. Let me fix that issue now.
Initially, there were solid reasons to step away from XHTML2 (a couple of examples would be the "XForms arrogance" or forcing draconic error handling whitout letting autors to opt-out of it).
These legitimate reasons were aknowledged, which made browser vendors enter a "power intoxication" state, leading to despotic* behavior, not neededly intended.
* BTW, I'm now realizing that the "despotic" adjective matches better what I meant with "tyranic". So, please, assume that where I said the later in my previous posts, I meant the former. This is just a linguistic and expression issue; after all I'm not a native English speaker and sometimes make mistakes.
So, this is not some conscious "nefarious plot on their part", but just childish and irresponsible behavior that is, at the end, leading to exactly the same results.
Finally, to round up the package, HTML5 adds the "bonus" (please read that with an implicit sarcasm) of a document so badly structured and ugly formatted that attempting to read it is just a race between your brain and your eyes to see which starts bleeding sooner. Anyway, that one is just an editorial issue with the document that defines the format, rather than with the format itself; and I hope it will be fixed as the spec matures (it's already quite better than two months ago).
XHTML on the web failed (or perhaps more accurately, "fail on error" on the web failed).
Even more accurately, XHTML (1.x) succeeded despite its "fail on error" nature. More on the "fail on error" topic later on this post, when I get down to g1smd's reply.
(X)HTML5 is backwards compatible, XHTML2 isn't.
(X)HTML5 is not backwards compatible, despite it claims so. It requires older documents to be processed as (X)HTML5 by conformant UAs, and it redefines some elements with incompatible semantics. This means that, in order to be HTML5-conformant, a UA must treat documents in a way that is guaranteed to differ both from how a HTML4 (or earlier) UA would treat it, and from how the author originally intended it to be treated. Furthermore, the HTML5 spec doesn't allow older documents to be treated according to older (relevant for that document) standards. So, not only (X)HTML5 is not backwards compatible (ie: valid HTML4 will not always be valid HTML5), but it also explicitly forbids UAs from providing such backward compatibility at the implementation level.
XHTML2, on the other hand, is defined in such a way that it only applies to documents which explicitly identify themselves as XHTML2; thus ensuring that UAs can provide backward compatibility at the implementation level. Due to this, XHTML2 doesn't need to be backwards compatible at the document level (ie: if a document is not XHTML2, then it isn't marked as such and it's not treated as XHTML2; so where is the need to make XHTML2 a superset of older specs?). Furthermore, XHTML2 takes advantage of having lifted such constraint; so it doesn't need to carry over the flaws of previous versions of X/HTML. This also means, of course, that XHTML2's flaws are XHTML2's own; since "backwards compatibility" at the document level is not an excuse anymore (for example, due to the way it is designed, it doesn't make any sense for it to preserve elements such as <a>, <img>, or the <h1>...<h6> headings).
So HTML5 can be adopted gradually/progressively as browser support for individual features is added (like XMLHttpRequest has been adopted), but XHTML2 required a year-zero, all-or-nothing approach to adoption.
Actually, this isn't entirely true. Exluding the interactive (forms and events) stuff, XHTML2 can be rendered in any current browser that supports XML + CSS2; and the default CSS2 style-sheet you'd need for that is already part of the XHTML2 spec. Furthermore, thanks to XHTML modularization (IMO, one of the best things provided by XHTML), you can easily build a DTD that imports the "document" stuff modules from XHTML2, but then take the "classic" forms module from XHTML1.1. If even that isn't enough flexibility for you, you still have the option to go nuts with XSL and transform the document into the HTMLish tag-soup browsers seem to love so much.
HTML is not broken
There has to be a compelling reason to add another html version, and I just don't see it right now.
That's a really good point. IMO, neither XHTML2 nor HTML5 provide any such compelling reason. However, this doesn't rule out the possibility that a good enough spec could be compelling enough.
People will use neither of the standards, and continue to write broken code that conforms to no known standards of any sort (or will manually edit and break code produced by a tool that did originally provide compliant code).
Indeed. There are two obvious reasons for that: the first is the lack of good, affordable for individuals/hobbyists, authoring tools, so people who can't afford an authoring tool manually write their code. The second is the fact that even the best tools are not good enough (otherwise, why would someone manually edit the code?).
Leading/popular tools will default to one or the other and people will produce code using one or other of the standards, without even realising they had a choice, or what the alternatives actually were.
Yep, this is already happenning now, and has been happenning for many years. I haven't too much to say about it, only that I wonder what would authoring tools choose as their defaults, and what would their choice based on.
I see lots of people producing XHTML-like code when HTML 4.01 Transitional would have been more than good enough: and many have no idea that there was an alternative.
I'm not sure what do you mean with this. XHTML1 Transitional is not too different from HTML4 Transitional (just the "always lowercase", "always close your tags" requirements, and the draconian error handling).
Maybe are you speaking about pages that are XHTML (ie: using the XHTML doctype and namespace, and abiding to the "X-rules") but served as text/html? I'll get a mention at that issue at the end of this post.
The web will continue to be broken unless browsers get more active in alerting users to code errors. IF XHTML2 breaks all previous standards, this could be a good time to make it more strict in application; will it be more strict in not processing files if they are not compliant?
XHTML1 already does that. Well, at least when it is actually served as XHTML.
More specifically, this is what browsers do (or claim to do) depending on what the server gives them:
Anyway, it is a good thing that both HTML4 and XHTML1 provide the same set of elements (even the same three "flavors").
To put it in some other words (just to make sure I express myself decently this time), vendors said "Hey! They admit that we're right. So, if we are right, why don't we make a 'right' spec from scratch?", then threw everything XHTML2 gives, be it good or bad, to the bin, and started writting (and implementing on the fly) a spec that is as flawed and as bloated as HTML3.2 was. I'm not saying they did this with any intention to "harm" the web or to impose their criteria just to acquire more power; it's just that they are blind to the fact that they can make as many mistakes as anyone else can: we're all humans after all. And, since they don't realize they can make mistakes, they are simply rejecting any kind of feedback that involves that possibility.
To top it up, the WHATWG miserably failed to scope their efforts, to the point that the document which is supposed to define their "ideal new markup language" almost forgets about the markup itself, and focuses on lots of side-stuff like the DOM, error-handling, implementation details, and so on. I want to emphasize on the "implementation details" part, because I thing this is plainly enough by itself to take that spec and set it on fire: by mere definition, a spec intended for the web must be implementation-neutral.
In addition, I want to mention that there are some cases where strict error handling isn't a good idea; mainly blogs and forum sites that allow visitors to format their comments with HTML code: since the site can't control what the users put in there, they can't afford the entire page breaking if someone posts broken code. It's possible to elegantly use CDATA blocks in an XHTML document, and then sending it through a trivial XSLT; but that's quite an overkill compared to using lenient HTML directly (unless you really want strict error handling on the "official" fragments of the page).
Ouch! Now that I thought I was done, I refreshed the thread's page and found more replies ^^;
@tonynoriega: rather than quoting and replying inline, I'll just say this: 100% agree. IMO, "Web 2.0" is just the brand name of brokenness.