Forum Moderators: open
If you ask Google [google.com], it spits out roughly 80k answers to the issue in less than half a second (fortunatelly, you can check only those that appeal you, and you can take as long as you want to review them ;) )
Whatever happens there, it will surely affect us, the webmasters. And what a better place to discuss the topic that at Webmaster World?
Basic guidelines: this is mostly common sense, but I think some points should be stated out.
This is a debate, not some sort of exam: feel free to say what you think and, especially, why do you think so. There is no goal of achieving any "consensus" or common ground, the only goal is to gather as many opinions as possible, so we all end up with a bigger picture of the whole topic.
This is a debate, not a battlefield: this topic is already polarizing in several sectors, and a debate like this might start heating up as soon as there are a few members on each side. I think it's worth to remind here the point 14 of the ToS [webmasterworld.com]:
14. Please keep your language clean and decent. This include personal inflammatory language as well as obscenities.
This is not a competition: it's unlikely that we will be changing anything from this thread, so don't get obsessed. There are no winers and losers in this debate: if we end up with a deeper understanding of the goings-on of the process then we all win; if we end up with everybody being upset or angry, or we manage to get this thread blocked due to uncivilized behaviour, then we all lose.
In summary, try to exercise your freedom of opinion and speech, and make your best to respect these freedoms' of others.
Ready? GO!
I believe HTML 5 - simply because of its backwards compatibility - is going to win. If using a language on the web intrinsically blocks users - why use it? You could create the page in multiple languages - but its not worth it IMHO.
Of course, its all about timing too. If they make the newest browsers of today (IE 7 & 8, FF3, etc) compatible with XHTML 2 and release 5 to 10 years from now, it may very well be a viable option. But the setup for XHTML 2 has to be there - it needs pre-existing backwards compatibility. Otherwise its best use will be for simple intranets.
I've done XHTML1.1 awhile now. But the simple-minded manner in which I use it amounts largely to grammatical strictness over HTML4.1: lowercase tags, close tags, tags properly nested, attribute values properly cited (even e.g. selected="selected")...
My English teacher said, "No split infinitives! Use different *from* and not different *than*!" In MY type of usage, perhaps, XHTML is purely pedantic.
Insofar as what real-world browsers will support first, I "suspect" HTML5.
If they make the newest browsers of today (IE 7 & 8, FF3, etc) compatible with XHTML 2 and release 5 to 10 years from now, it may very well be a viable option.
Following its approval by W3C Members, this group will commence in August 2002 and will terminate in August 2004.
1. 2007-05 HTML5 and Web Forms 2.0 specs adopted as basis for review
2. 2007-11 HTML Design Principles First Public Working Draft
3. 2008-02 HTML5 First Public Working Draft
4. 2009-03* HTML5 Last Call Working Draft* editor's estimate is 2009-10
5. 2009-06 HTML5 Candidate Recommendation
6. 2010-06 HTML5 Proposed Recommendation
7. 2010-09 HTML5 Recommendation
About how the W3 works (and about all these flavors of specs):
[b]Editor's Working Draft: that's the working draft the WG works with on an every-day basis. When it becomes something "human-readable", a Public WD is released.
Public Working Draft: A date is defined for the first, because there will surely be a first public draft, but there might be only one, or there might be dozens. The main goal of the public draft is to draw feedback from the different interested parties (although the HTML5 WG is doing this directly from the Editor's draft, which is also public in this case, so this one doesn't have too much meaning). Feedback is normally translated into "Issues" and issues are dealt with by the group. When all the issues are dealt with, the next public draft is released, and so on until a draft arises no issues (due to the openness of the HTML5 process, this is being done in a much more dynamic way, but the concept of issues is similar: once there is a draft that has no issues and no new issues are opened in a given timespan, the spec advances to Last Call).
Last Call WD: Also known as "Call for implementation", the release of the LC denotes some stability of the specification and invites interested vendors to implement it. At this point only implementation feedback is gathered. If this feedback translates to new issues, a new LC adressing such issues is published, and so on until a LC "survives" long enough (I'm not sure how long it takes) without new issues, it moves forward to CR. In the case of HTML5, since major browser vendors are already implementing the most "stable" parts of the spec on the run and providing feedback, the LC stage should be quite short for this case.
Candidate Recommendation: Basically, on this stage test suites must be made available, so implementations can be tested (I'm not sure if test suites need to be ready at some early stage, however). Once there are at least two public, general use implementations (ie: no betas, experimental builds, and other unusual stuff are counted, only public "final" releases) that are valid according to the test suites, then the spec takes a step forward in the process. This is likely the point where HTML5 will take longer: according to the FAQ "20,000 tests for the whole spec would probably be a conservative estimate". Actually, the same FAQ states that they aim for reaching CR by 2012, which means just 4 years from now; and then 10 more years only for the "testing" part.
Proposed Recommendation: At this point, the only thing to be done is to vote the spec within the W3C. If the voting is successful, then the spec becomes a Recommendation. If it's voted against... then I don't know what it happens :S .
Recommendation: At this point, the specification is an "oficial" W3C standard, and in theory it may be relied upon by content authors and tool (including authoring tools, browsers, and any other relevant software) vendors.
Here ends the boring part.
In summary, the specification should become stable by 2012, and become an official standard by 2022. However some parts will be available for developers to use even before that: for example, major browsers already implement the <canvas> element; and many features of HTML5 can be emulated through JavaScript to achieve a "smooth" adoption.
So, that's everything you may need to know about the dates. If you want to be aware of updates on these estimate dates, keep checking the relevant links.
Now, my opinion:
I think that, comparing the documents right away, XHTML2 is currently better: it provides a cleaner content model, draconian error handling is not an issue for me (I author compliant and well-formed documents), and it provides some improvements that I really like, such as the sectioning model, or the complete separation of presentation, structure, and semantics. For example, if you want to have a list for navigation (and be recognized as a navigational element by supporting UAs), in XHTML2 you'd use the <nl> element, probably with a role="navigation" attribute. In HTML5 you would need to use a <nav> element, which defines both the "navigation" semantics and sectioning structure: if it is navigation, then it will be forced to be a section. If you indeed wanted the navigation to be a section, XHTML2 allows you to define that as
<section role="navigation">
<nl>
...
</nl>
</section>.
Another advantage of the XHTML2's sectioning model is the <h> section header element, which is equivalent to the <h1..6> appropriate for the current level of <section> nesting. This becomes really useful when maintaining a dynamic site: you added a header and now you need to uptade all the <h3> and deeper tags in who knows how many other scripts and includes.
Of course, browser vendors' support for HTML5 is also an important factor, but it will probably get eclipsed by an even more important factor in favor of HTML5: although the XHTML2 spec is currently better when analized by its own merits (ie: without counting that browser vendors have already make their choice, or that it doesn't deal with the existing legacy of tag-soup on the web), it is already "closed" (it won't be changed at all except for the redundant appendices and editorial corrections), while HTML5 is more open than any other spec in the W3C's history: the spec is being built by the ~900 subscribers of the mailing list, with the WG members acting mostly as moderators. And I can state first-hand that the feedback provided through the lists is properly dealt with. This doesn't mean that every feature request will automatically become a HTML5 feature, but that the Editor and other group members will review it and consider it based on its technical value (ie: if it solves a real problem, it will most likely in; but if you ask for a <blink> tag without even exposing a reason you will most likely be ignored).
So all in all, I feel that currently XHTML2 is, technically speaking, better in many aspects; but HTML5 has the potential to become even much better than that. Adding to it that it has most of support, it is most probably going to "win" for good.
Regards,
Herenvardo
I use HTML 1.0, some javascript, PHP...
Why should let my sites or my users to waste a second with the 2022 standards?
LC: September 2007: it seems that they are almost a year late already
CR: February 2008: already late
PR: June 2008: also already late
Rec: September 2008: hurry, hurry! you can still make it! :P
I'm still waiting for the U.S. to go metric. Wasn't that suppose to happen, oh, 30 years ago. It is fine to sit back and say "we'll do this and we'll recommend that," but the real world does not work that way.
Marshall
A standard like this should follow the normative guidelines. You cannot provide for every practical contingency and situation, so you must give strict guidelines on a generic, categorised level. Keeping the practical implementation as flexible as possible. In addition, it should foresee in future additions.
(X)HTML5 is simply a very bloated version of HTML4. It is too stringent and does not provide for any flexibility. As I read it it felt more like a law than a standard. I also think that some mechanisms in (X)HTML5 do not do a good job of separating style from content.
XHTML on the other hand has done a fine job of not overcomplicating things while still produce a standard that is both flexible and innovative. One of the best things (for me) in XHTML2 is the fact that virtually anything can be a link or a picture. This one, simple mechanism not only gives us a huge flexibility in design, but also does wonders for accessibility. And for the latter, XHTML2 also provides a special element.
It is not to say that (X)HTML5 does not have any good ideas. The <mark> tag for example could very well be included in XHTML2 as far as I am concerned, and although I do not agree with the redefinition of the i- and b-tag in (X)HTML5, I still think XHTML2 should redefine them in a similar way (to make them more semantic).
But other than that, I can only hope that we will be able to use XHTML2 sooner than (X)HTML5. In the end it is a personal choice and it shouldn't matter, I just pray browser manufacturers will implement both equally fast and complete. My choice is XHTML2.
[edited by: Bert36 at 10:01 am (utc) on Nov. 1, 2008]
Put me in the who cares category. I have thousands of pages in HTML 4 and as long as they still work in browsers, why worry about it?
For example, any javascript relying on the DOM may be heavily affected when/if browsers switch to HTML5, since the spec requires the UA to insert "anonymous" <section> elements based on the <h1> through <h6> elements (this makes some sense, since the headers are supposed to describe the sectioning hierarchy; but will break any script that tries to "browse" through the document tree).
Ok, it is a bit of an oldish topic, but I have been reading both the drafts for XHTML2 and (X)HTML5 for the past two months now. Going through them vigorously. And I would *hate* it if (X)HTML5 became the popular standard.
(X)HTML5 is simply a very bloated version of HTML4. It is too stringent and does not provide for any flexibility. As I read it it felt more like a law than a standard. I also think that some mechanisms in (X)HTML5 do not do a good job of separating style from content.
XHTML on the other hand has done a fine job of not overcomplicating things while still produce a standard that is both flexible and innovative.
But other than that, I can only hope that we will be able to use XHTML2 sooner than (X)HTML5. In the end it is a personal choice and it shouldn't matter, I just pray browser manufacturers will implement both equally fast and complete. My choice is XHTML2.
a good internet site i found on google about it: [xhtml.com...]
seems like it is better to still use xhtml 1.0/1.1 or html 4.01 for a while
Honestly, when I started this thread, I had some hope with HTML5. With the process being as open as it was claimed to be, it would have just been a matter of time for the spec to become better than XHTML2. However, after participating in many discussions for the last two months, I have realized that this is just a facade, and feedback is only observed from the vendors viewpoint: if they like it, it gets into the spec; otherwise it doesn't.
[edited by: tedster at 7:28 pm (utc) on Nov. 2, 2008]
The only reason the W3C has adopted it is because vendros told the consortium something like "we aren't going to do XHTML2, but we will do HTML5, so you either pretend to agree, or you will have no more credibility".
The W3C decided it would not be developing HTML any further, to focus exclusively on XHTML2, and so for the next 9 years the W3C ignored the current web. The damage this did to the W3C's credibility and relevance was self-inflicted.
It wasn't just browser makers who thought XHTML2 was impractical, overly-complex and mostly pointless. Even Zeldman, the high priest of XHTML-advocacy, said he couldn't see any benefits.
Some folks eventually got so fed up with this situation they decided that if the W3C was not going to develop standards for the current web they would, and setup the WHATWG.
If you believe XHTML2 is the way forward, then HTML5 provides a stopgap solution to the decade-long stasis that the web has suffered under the leadership of the W3C, until XHTML2 takes over. OTOH if, like me, you're unconvinced by the case for XHTML on the web, HTML5 provides an alternative path for future development, conveniently rescuing the W3C from itself at the same time.
The W3C decided it would not be developing HTML any further, to focus exclusively on XHTML2, and so for the next 9 years the W3C ignored the current web.
It wasn't just browser makers who thought XHTML2 was impractical, overly-complex and mostly pointless. Even Zeldman, the high priest of XHTML-advocacy, said he couldn't see any benefits.
Some folks eventually got so fed up with this situation they decided that if the W3C was not going to develop standards for the current web they would, and setup the WHATWG.
If you believe XHTML2 is the way forward
then HTML5 provides a stopgap solution to the decade-long stasis that the web has suffered under the leadership of the W3C, until XHTML2 takes over.
OTOH if, like me, you're unconvinced by the case for XHTML on the web, HTML5 provides an alternative path for future development
[edited by: Herenvardo at 12:17 am (utc) on Nov. 3, 2008]
Yes, I've read all the topics on why you shouldn't use XHTML, blah, blah, blah. I'm on a Windows platform and I do have a choice. But, if I choose to force HTML, it comes with many challenges. Our pages MUST validate. Blending HTML and XHTML is challenging, I tried it and switched back to XHTML. Since then, things have run very smoothly under XHTML 1.0 Strict and Transitional DOCTYPEs.
Truthfully? I don't have any complaints about the existing standards, none whatsoever. Oh wait, they aren't promoted enough, that would be my only qualm. Everything appears to be working for me and has been for many years. Is something broken and we need another level of HTML? ;)
I had started to follow the HTML5 development, I'm now ignoring it. It's an interesting academic exercise, and has probably more chance of eventual adoption than the flawed XHTML2, not least because it is being developed by and for the browser makers and bank-rolled by Google. XHTML2 is unfunded and ignored by those who would need to implement it.
However, HTML5 is long-term at best. The simple fact is that HTML is not broken, so there is no compelling need for a new version. There is nothing today which makes any developer start longing for a new version of (X)HTML. HTML 4.01 and XHTML 1.0 (as
text/html
zeldman
Zeldman evangelised XHTML as head of the "Web Standards" movement, wrote the seminal "Better Living through XHTML" article, and was imho largely responsible for getting the masses to adopt XHTML1 - for no apparent reason.
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.
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. This was not the case. XHTML on the web failed (or perhaps more accurately, "fail on error" on the web failed).
[WHATWG] are ignoring the same way every feedback that doesn't come in the form "this browser has implemented this" or as a praise.
You said above:
And I can state first-hand that the feedback provided through the [HTML5] lists is properly dealt with
What changed...?!
HTML5 provides an alternative, but it's not that better than X2.
(X)HTML5 is backwards compatible, XHTML2 isn't.
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.
HTML is not broken
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).
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.
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.
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?
i have been designing and developing since '00 and have seen what i call the separation of "church and state". i still know people that develop entirely in pure HTML X.X and dont include any other language that might discriminate against anyone. Then i know people that go with XHTML X.X strict, with Flash and the whole kit and caboogle who dont care about those left behind.
you can try to force those behind to upgrade, conform, and accept your new rules and implementations but when forced, only reject.
Web 2.0? who in the heck decided there was a web 1.(anything) Someone got an itch, named a new type of design and communication methodology, called it 2.0 and it caught on... and took its own path.
its not an interconnected web of communicating machines anymore, its a confused mix n mash of competing machines to see who can come out on top.
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.
Anyway, it is a good thing that both HTML4 and XHTML1 provide the same set of elements (even the same three "flavors").
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.
What changed...?!
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.
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.
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.
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.
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.
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).
(X)HTML5 is backwards compatible, XHTML2 isn't.
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.
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.
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).
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.
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.
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?
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 ^^;
I'm torn. I'd like xhtml2 to win because it's cleaner and seems less vendor-owned; but I like html5 for being more evolution than revolution.
@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.
Seriously, what portion of the web is ready for two new languages? Webmasters are still battling with basic HTML. As I mentioned in my previous reply, all Windows Web Applications are based on XHTML, what is your proposal for the application developers? Should they stop what they are doing and revert back to HTML 4.01 so they can prepare for HTML 5? Ya see how confused one can get? And that is exactly what these two languages do, confuse things even more.
I'm all for evolving. Look at where we are today. :)
HTML5 is not backwards compatible... it redefines some elements with incompatible semantics.... 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.
Can you give me an example of an actual RW problem this will cause? HTML offers such limited presentational semantics I can't see how minor changes to an element's "meaning" will affect anyone(?)
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... you can easily build a DTD ...take the "classic" forms module from XHTML1.1...
Yes, after you've re-written all your content in XHTML2, it's possible to make it work again in current browsers, like it did before. I think this re-writing qualifies as an all-or-nothing, year-zero approach ;)
HTML5 *doesn't* require us to rewrite entire sites and publishing systems to use a new feature. So when for example Canvas is widely supported we'll be able to add it to an existing website (HTML4/XHTML1/tag-soup) and it'll just work. Probably. :)
Seriously, what portion of the web is ready for two new languages?
XHTML2 is effectively dead, so that's one less language to worry about :)
HTML5 is an evolution of HTML4/XHTML1. Most people just refer to it as HTML5, but it will be available in HTML and XML versions. You can safely ignore it until its new features have widespread browser support and you want to use them.
all Windows Web Applications are based on XHTML, what is your proposal for the application developers?
Keep using XHTML1. When/if you want to use new features in (X)HTML5 just change your doctype. XML syntax is valid in the HTML version of HTML5, so in the future you should be able to upgrade to HTML5 or XHTML5 pages without problems.
Can you give me an example of an actual RW problem this will cause? HTML offers such limited presentational semantics I can't see how minor changes to an element's "meaning" will affect anyone(?)
Yes, after you've re-written all your content in XHTML2, it's possible to make it work again in current browsers, like it did before. I think this re-writing qualifies as an all-or-nothing, year-zero approach
While its great to really be discussing the future of the web, I'd like to first address the history and current status. The future can wait, we still have challenges at the HTML 4 and XHTML 1 levels.
Seriously, what portion of the web is ready for two new languages?
Webmasters are still battling with basic HTML. As I mentioned in my previous reply, all Windows Web Applications are based on XHTML, what is your proposal for the application developers? Should they stop what they are doing and revert back to HTML 4.01 so they can prepare for HTML 5?
Ya see how confused one can get?
And that is exactly what these two languages do, confuse things even more.
I'm all for evolving.
This API sucks. Seriously. It's a terrible API. Really bad. I hate it.
Look at where we are today.
Well, I finally exploded. Sorry for that rant, but I couldn't hold it any longer, and your questions finally triggered it.
I'm wondering how a HTML5-compliant non-visual UA would be supposed to deal with an <i> element in an old document (before HTML5 it should normally be ignored, because it is only presentational, but now HTML5 gives it a meaning...)
And that meaning is: "a span of text in an alternate voice or mood... whose typical typographic presentation is italicized"
I suspect this isn't going to break the web :)
...picking single XHTML2 features and make them work on older [well-formed XHTML] documents is also achievable, and exactly by the same means.
Emphasis added. But what about namespace clashes eg <input> in XForms and XHTML1 Forms?
XML had the "fail on error" issue as a cost... but it bought something with that cost: extensibility
The problem for XHTML is that extensibility doesn't require "fail on error" as a cost...
...I suspect this isn't going to break the web
Emphasis added.
But what about namespace clashes eg <input> in XForms and XHTML1 Forms?
The problem for XHTML is that extensibility doesn't require "fail on error" as a cost...
I gave you a more practical example [of HTML5 breaking backwards compatibility]
The namespace clash? I must admit I didn't understand your point, but assumed it was basically a theological issue like the <i> and <b> examples :)
So you see well-formedness as an issue
I think well-formedness is an issue with most pages on the web today - especially, but not exclusively, with the HTML ones :)
If you tell me an example of that obscure reason [an XHTML1 form and an XForm on the same page resulting in namespace clashing]
Adding an XForm to a page that has a simple search form in the page header at the top. This is a quite common requirement. <input> is not namespaced in XHTML1 or XForms(?)
Actually, the cost wasn't that big.
The problem with the fail on error cost in XHTML is it falls on the wrong person - the visitor, not the author. The author can be completely unaware of the error for some time - that's the problem.
Actually, I used to use a FF addon to achieve exactly this: when I got an XHTML page crashing due to an XML error, the addon re-feeded it to the parser as "text/html". Actually, any browser could have taken a similar approach: if the XML parsing fails, just show something on the status bar like "This page cannot be rendered according to standards", and allow the user to get a deeper explanation by some means (for example, by clicking on that notice).
Or just use HTML and avoid forcing visitors to deal with problems they a) can't do anything about and b) don't care about anyway.
I don't entirely disagree with your POV on XML. I too think if XHTML had taken off, browsers would have introduced their own error-recovery routines. And then we'd be in exactly the same situation as we are currently with HTML: undefined, non-standard error-recovery in browsers, and lots of non-conformant pages.
