The pain of birth
Having read large chunks of the XHTML 2.0 working draft, I would say that its greatest flaws are not its ideals, not its non-backward compatibility, nor that it might not be realistically implemented in browsers anytime soon. These are not flaws, not at this time. If these are flaws, they will emerge later.
The greatest flaw of the current XHTML 2.0 draft is simply that it is not well written.
You may have the most brilliant spark of inspiration for the most moving poem, but lacking the words to express yourself, your idea would simply wither away unnoticed.
XHTML 2.0 in its current form is truly at a working draft stage — the ideas are not solidified; one can glimpse what it is trying to achieve (or perhaps what it should achieve): markup which unambiguously supports true separation of presentation and content, markup which allows clear expression of semantics in the document it is used for.
Apart from being somewhat deficient in clarity, the working draft is desperately lacking explanations of how authoring tools should behave.
I cannot find the statistics, but I would presume that a greater part of the content of the web is not produced by handcoding. If you take into account the popularity of blogging and website-producing tools, it would seem that most people are not bent towards typing their HTML pages by hand. Authoring tools are responsible for a good part of the content of the Web, and therefore, authoring tools are also responsible for the status of standards-compliant pages online. So, it stands to reason that the considerations which go into designing XHTML 2.0 need not be based on the whims of the handcoder — it should be designed based on semantically meaningful functionality in light of the direction the Web is heading, with authoring tools firmly in mind.
As for whether XHTML 2.0 will be implemented or not ... well, take this as an engineering exercise — a software engineering exercise, for argument's sake. After all, the Web is in a sense, a monstrously large software infrastructure.
Before you build a system, you need to have the specification in hand in order to know what you need to build (not that this happens enough in the real world, of course, but that is yet another developer-hell kind of story). In the corporate world, unless bound by corporate goals, nothing states that a specification has to be completely implemented, but well-written specifications should describe which are core functionalities, and which are secondary and tertiary (in the case of W3C specs, functionalities which are extensible). A specification ought to be an epitome of the ideal because it should describe what is required without being bound by what currently exists. Otherwise, we will never move forward, we will never improve.
There is no need to pass judgments on XHTML 2.0 just yet, because it doesn't yet exist. It is still in the process of being born.
Posted by sniffles at April 26, 2003 09:15 AM