On Sep 1, 2006, at 21:36, John Boyer wrote:
XHTML served as text/html are not treated as XML because your
current code makes no effort to attempt that first. In my earliest
posts on this subject, I said that an application should lead with
the attempt to parse XML, then follow with recovery strategies, or
that it could try HTML first until it found "new features" then
switch to an attempt to use XML.
What would you do with running scripts when you decide to halt the
parser and reparse with another one?
The explanation for why not to do it this way has so far been "Cuz
we don't wanna!'
No, the explanation is that the HTML WG said that browsers shouldn't
do such things.
The goal here is not to try to optimize the error cases to the
point of perfection.
Real-world browsers need to interoperate even in the error cases.
Saying that apps do what they please after a well-formedness error is
not good enough.
Moreover, with the appendix C guidelines for XHTML combined with
making the important ease-of-authoring changes to XForms that *are*
what we need to harvest from WF2
If XForms is "harvesting" stuff from WF2, what's in it for WF2?
Elliote Harold: In a typical browser, yes. However I routinely
download such pages with non-browser-tools based on XML parsers;
and there the results are quite different. In these contexts, the
XML-nature of these pages is very useful to me.
JB: +1, precisely my point about being able to grow the web over
time in new and interesting ways. The enticement to XML well-
formedness helps bring about new capabilities.
But above you were advocating automatic error recovery, which in
practice would mean that well-formedness is thrown out of the window!
So if well-formedness is really a precondition for growing the web
over time in new and interesting ways, what you suggested above would
defeat it.
(BTW, when I download text/html in my own non-browser apps, I use an
HTML parser that emits SAX events as if parsing XHTML.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
