Herenvardo - 8:20 pm on Nov 3, 2008 (gmt 0)

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(?)

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...); but the example of these element redefinitions was more of a theorical nature.
If you want a practical example, however, I already gave one in my previous post: the namespace clash between XHTML1 and XMLish HTML5 (formally, the XML Serialization form of HTML 5): as the spec is written now, the element definitions on (X)HTML5 would override XHTML1's ones on that namespace, causing older documents not to match the new content model. This is not an issue when in "tag-soup mode", because the "error-recovery" stuff in the spec boringly deals with this case by case; but when the content is served as XML draconic error handling applies. The spec explicitly requires compliant UAs to treat everything as X/HTML5, ignoring doctypes and similar stuff, so trying to detect if a document is actualy good'old'XHTML1 to parse it as such would be non-compliant (and parsing it as (X)HTML5 would soundly fail on most such cases).
That's exactly what I meant when I said that HTML5 is not only backwards-incompatible at the document level (this is already caused by the fact that elements that were valid in HTML4, such as <b> or <big> is not valid anymore in HTML5); but the spec explicitly forbids backwards compatibility at the implementation level.

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

I guess I should have been clearer about that. What I had in mind was making new XHTML2 documents render in already available browsers; but picking single XHTML2 features and make them work on older documents is also achievable, and exactly by the same means. That's the whole point of XHTML's modularization: you get the modules, then you mix'n'match as you please. So, if instead of carrying over an older feature to the new format you want to step into a new feature from a document in the old format, there you go: instead of taking XHTML2's modules as the base, and replacing with some from XHTML1, just do it the other way around: take XHTML1 and plug in the XHTML2 modules you need. Wanna XForms on XHTML1? Already done by some sites :P Wanna the role attribute? Just import the "Role Attribute Module" into your doctype. Need ruby anotations? Get them. XML had the "fail on error" issue as a cost (for those cases where it is actually an issue; I'm actually quite glad to see at a glance on which line and character my server scripts messed some tag up while I'm debugging), but it bought something with that cost: extensibility ;).

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.

Let's see, the past: we got the browser wars, then HTML3.2, then HTML4 + CSS, then some years of IE's monopoly stagnation until alternate browsers started gaining force, and some work starting behind the scenes by W3C and the WHATWG at the same time, finally leading to the current Babel where there are several browsers to keep in mind, a lot of different standards asking you to do things that and that other way at the same time; and when one whish we could just say "shut up!" to both standards and browsers, we get the W3C embracing WHATWG's work, now there are two more standards competing, both saying that you should stop doing things as you are used to, defining a new markup model that (almost) nobody asked for. Welcome to chaos.
Indeed, we still have challenges at the HTML 4 and XHTML 1 levels; but who are we? The W3C doesn't seem to have challenges of their own, so they've gone ahead and started defining the next XHTML. Browsers definitely have challenges with HTML4, XHTML1, CSS, and even WAI guidelines; but apparently they prefer to ignore them and cover with a [sarcasm]new[/sarcasm] [sarcasm]standard[/sarcasm] with is just a specification (and, by extension, a legitimization and perpetuation) of their actual bugs and issues, spiced up with some trivial meaningless stuff to make it pass as something "new".
Actually, they have put so much effort on that disguise that they have come up with some really good ideas, but we won't be able to really benefit from them because they are buried amongst so much non-sense.

Seriously, what portion of the web is ready for two new languages?

Easy one: none. :P

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?

That's not that easy. But what about asking their user to not "upgrade" their browsers, so they can be sure these apps will keep working? I know that this is quite absurd, but it is really the best idea I can suggest.

Ya see how confused one can get?

Yep, I see. Don't worry: it's quite normal, given the situation.

And that is exactly what these two languages do, confuse things even more.

The pity is that, buried deep under the confusion, there are good ideas on both specs. If the WGs were just a bit more willing to listen each other... and to listen someone else...

I'm all for evolving.

I'm too. It's just that I have no idea anymore of where evolution should lead to.
The XHTML2 claims that it's going last call soon; and that most of it already works on current browsers.
OTOH, HTML5 keep claiming that XHTML2 is dead, that HTML5 is going to give you everything, and blah, blah, blah... then one takes a look at their draft and stumbles with stuff like

This API sucks. Seriously. It's a terrible API. Really bad. I hate it.

(Source: HTML5 Working Draft [whatwg.org], as of Nov 03, 2008) :o What's HTML5 providing? APIs that suck?

Look at where we are today.

Ok. I'm looking. But, honestly, I have no idea about where we are :S. If you know, please tell me.
Really, if IE8 finally becomes CSS2 compliant, and replaces its older brothers soon; I have enough with that. Just HTML4/XHTML1 plus CSS2, and server-side scripting for complex stuff, even if it involves some server round-trips. I can live with that. There are things that could be improved, sure, but at which cost? I'm quite a pacifist, and I don't like wars. On wars everybody loses, and this case is no exception. It's a no-win situation:
If XHTML2 overcomes HTML5, we lose all the good stuff in HTML5 (specially the non-markup stuff, which is IMO the best part of the spec, despite it shouldn't belong there)(after all, not all the APIs on that spec suck).
If HTML5 overcomes XHTML2, we lose the good stuff in XHTML2, like a clean content model, clear sectioning and headers (especially the <h> element) or support for decent semantics.

Well, I finally exploded. Sorry for that rant, but I couldn't hold it any longer, and your questions finally triggered it.