|
|
Posted by Alan J. Flavell on 01/19/06 21:59
On Thu, 19 Jan 2006, David Dorward wrote:
> Converting HTML 4.01 Strict to XHTML 1.0 Strict is trivial to do
> programatically. So using XHTML now will not save you "much trouble"
> later on.
Right. But IMHO more to the point - those who keep warning us about
all the dreadful things that are going to happen when we code
HTML/4.01 directly, because of all the SGML-related horrors which the
HTML DTD permits, should know that XML-based processors can be invited
to output their results in normalised HTML/4.01, with those SGML
nasties automatically eliminated.
Hixie's famous rant includes, among other things, a comment along the
lines that much of which purports to be XHTML/1.0 is in reality just
XHTML-flavoured tag soup, relying just as much on browser foibles to
get the right answer, as was the HTML-flavoured tag soup which it
replaced; but if it was ever to be taken seriously as XHTML, they'd
get a nasty surprise. Based on what I've seen out there as text/html
with XHTML DTDs, I'd say the situation is at least as bad as he
predicted there. The hordes have jumped on the XHTML bandwagon
thinking it was sexy, without paying much attention to what it really
involves.
Current browsers are, after all, tuned to treating text/html as HTML,
not as XHTML. It's technically accurate to say that they only render
XHTML as intended because they implement a bug (emacs-w3, for one, had
to get the bug deliberately introduced, when it turned out that it had
been taking SGML a bit more seriously than was good for it). As long
as text/html is the practical Content-type to send, I reckon that
sending HTML is the right thing to do; XHTML will be worth using when
there's something useful to do with it, such as embedded MathML, SVG
or whatever, but then sending *that* as text/html is wrong.
An alternative approach would be to validate HTML against a
stripped-down HTML DTD, designed to disallow optional omissions etc.;
but there is no such officially-supported HTML DTD, so it's
understandable that the opponents of HTML wouldn't want to hear about
that. However, there are SGML processors which would normalise the
HTML, and address most of the issues which are in dispute (including
exposing the issue of the "<tag/content/" HTML/SGML short form which
is such a source of friction between theorists and pragmatists).
Navigation:
[Reply to this message]
|