cf request from SteveB and following
W3C's position:
The Extensible HyperText Markup Language (XHTML™) is a family of current and future document types and modules that reproduce, subset, and extend HTML, reformulated in XML. XHTML Family document types are all XML-based, and ultimately are designed to work in conjunction with XML-based user agents. XHTML is the successor of HTML, and a series of specifications has been developed for XHTML.
XHTML FAQ
Does the community really want us to "reproduce, subset, and extend HTML, reformulated in XML"? Do we really expect a marketplace of "XML-based user agents"? Do we really want to use the same technologies for XHTML as are used for SVG, SMIL, XForms, MathML, and al the other UI technologies that W3C has, or shoud HTML continue to have a different, incompatible set? Chris considers it wis that the HTML WG has been making HTML compatible with what the rest of W3C uses. DanC thinks HTML has considerable more penetration than the rest of the combined.
Yes, of course the community wants us to do that! That was the result of the 2 day workshop we held before rechartering the HTML WG.
XML: I hope that speaks for itself; even Microsoft is using XHTML in Infopath.
Subsetting: that's what the mobile community is doing. XHTML Modularization allows consistent subsetting (and supersetting) so that you restrict the ways that XHTML gets subsetted, so that variants are at least more compatible than they used to be.
Extending: That is what the CDF is now doing, using XHTML Modularization. If there were no XML version of HTML, they would have to invent one themselves.
The reason the community needs an XML version is to be able to combine it with other vocabularies, and use it in XML tools. IPTC for instance wraps XHTML stories in their own metadata wrappers; people need it for sending it in SOAP messages. The list is endless.
Making up your own vocabulary is one of the worst possible things to do in terms of accessibility, semantic web content analysis, and user control. Hickson, 18 Aug 2002
Which is an interesting statement, especially since WhatWG is making up their own vocabulary.
Why generic XML on the web is a bad idea 31st May 2005 by Anne van Kesteren
But he's absolutely right. He's arguing against people using 'generic' XML to create documents in their own vocabulary. Most people don't have the first idea of what the accessibility and semantics issues are when creating new markup. That's why the W3C process is so good at this: many eyes make markup bugs shallow. At XTech this year, the Mozilla people briefly showed some of their new markup on the screen. I could immediately see two or three accessibility and internationalization problems at a glance. They said "we haven't dealt with accessibility yet; we'll do that later" but they can't: you have to design accessibility in from the beginning, it is not an add-on.
In an the
exchange between Kragen and DanC in #microformats, in response to Steven's XHTML2
slides for XTech, Kragen said, it says "XHTML2 is the next version
of the XHTML family". Actually Web Applications 1.0 is the next version
of the XHTML family
What became of all the objections to the XHTML 2.0 draft back in 2003?
You should be able to follow the thread in the XHTML WG issues database.
Without namespaces, the meaning of generic attributes is unclear and each W3C WG is constrained. Other standardization groups are similarly constrained. Unless W3C is supremely arrogant and believes that it is the only creator of XML vocabularies, namespace support is essential for markup. Events are also being namespaced; DOM Level 3 adds namespaced event support due to immediate pressing need.
In the hallway at XTech, Hakon said this was a show-stopper for the WHATWG. I don't completely understand their position; or maybe I just disagree with it.
from the exchange between Kragen and DanC in #microformats:
If you misspell a namespace URL, nothing works and you get no error
message, usually; and the namespace URLs are quite large, and the ':'
separator is grossly incompatible with CSS. And there's the horrible dumb
breakage with XPath and unqualified names, and probably half a dozen
other issues related to XML namespaces that mean that they aren't really
an option. half a dozen other issues I haven't actually encountered
myself, I mean. Because after the first few I gave up on trying to use
XML namespaces.
what have you done instead of namespaces?
Thrown everything in the same namespace, the same way we did from
1990-2000
er... and when not everybody agrees?
Things break. But that's better than having things broken all the
time. In CSS, syntactically "xhtml2:separator { display: block; }"
selects the xhtml2 elements with the nonexistent pseudoclass "separator".
I'm not saying the *idea* of namespaces is bad or unnecessary or even
unimportant. I'm saying that particular details of the XML namespace spec
in the real world are playing out to make them hard to use.
Well, duh! The HTML WG has been warning about namespaces from the beginning. "If you misspell a namespace URL, nothing works and you get no error message, usually; and the namespace URLs are quite large" couldn be quoted just as easily from one of our emails. But this is not an XHTML issue, it is a W3C issue, and the sooner the W3C takes the bull by the horns the better!
But the CSS argument is spurious. CSS1 all along pointed 췍﷽﷽ Ƙ̈ᑀ̋鮐˫
W3C's position:
Because earlier versions of HTML were special-purpose languages, it was necessary to ensure a level of backwards compatibility with new versions so that new documents would still be usable in older browsers. For instance, this is why the <meta> element has its content in an attribute rather than in the content of the element, since it would have shown up in older browsers.
However, thanks to XML and stylesheets, such strict element-wise backwards compatibility is no longer necessary, since an XML-based browser, of which at the time of writing means more than 95% of browsers in use, can process new markup languages without having to be updated.
Kragen's perception: Too bad they decided to abandon backward
compatibility and add dependencies on XML Events, XFrames, and XForms
they've renamed <hr/> to <separator/>. For essentially
trivial reasons.
We can either heap more stuff in the same Internet Media type as is currently full of broken HTML, or we can use a different Media Type that clearly indicates the different processing requirements. Chris feels that mixing XML and non-XML and attempting to muddle along was clearly a mistake, and we should not make the same mistake twice in succession. Dan feels that whatever Media Type we use will result in the same challenges once it gets popular, including getting content producers to produce well-formed XML.
At XTech 2005, Hixie publicly claimed support from Opera, Apple, and Mozilla. Google seems to support his work now.
The most recent (Sep 2005) XHTML/XForms ftf had participation from just 2 W3C members: Origo Services Limited (Mark Seaborne) and IBM (Kevin Kelly).
Kragen, How would you feel about sending your comments to
them?
I anticipate that it will be a waste of time.
Also, a list from Steve: