Posted by Andy Dingley on 02/06/06 16:47

Alan J. Flavell wrote:

> Bearing in mind that - in a practical sense - HTML served as text/html
> has to be parsed by some kind of tag-soup slurper with masses of error
> fixup code; whereas we were told (by some, at least) that XHTML was
> going to put an end to the need for all that fixup code - just a
> simple parser, and predictable rendering routines.

I don't recall ever hearing this, outside of the mobile devices crowd.
Certainly lightweight parsers _could_ be made that operated on XHTML,
but these were generally seen as being parsers without even display
renderers - smart agents jabbering away at each other, not
lighter-weight desktop browsers. After all, XHTML certainly wasn't
going to _replace_ HTML tag soup any time soon, so if browsers did
choose to do anything smart with it, they'd have to do it in a modal
manner.

I remember early XHTML as pure geekthusiasm and the feeling that
"everything had to be ported to XML, just because it _could_ be".
There's no need to ascribe reason or logic to this, other than the lure
of c00l.

Early sightings of "XHTML will lead to simpler browsers" claims would
certainly be interesting from the historical aspect.


> It seems to me inevitable that when the masses do get it into their
> heads to switch from text/html to application/xhtml+xml, there's going
> to be massive clamouring for all these tag-soup documents to be
> rendered "correctly" (in *their* sense of correctly, i.e "looks the
> same as what MSIE used to do"), just like the mess that developed with
> HTML.

First we kill all the lawyers. Then we start on the marketing
department and anyone who thinks .psd bitmaps are an appropriate design
tool for the web. This jihad is _long_ overdue.

There's certainly a risk here, and the scenario you describe would be
appalling. Fortunately I think even M$oft are smart enough to avoid
doing it - we're just left with the risk of Apple or Winer doing it to
make podcasting "down with the kids".

> > The more subtle problem, and from where tag soup really arises, is
> > with SGML. Clever DTD-based parsing rules are all very well when
> > they're done properly, but how often are they?
>
> If you wanted HTML without omitted tags, you could have had it with
> SGML all along. If you wanted to eliminate SHORTTAGS, you can do so
> in SGML.

I don't understand why HTML didn't do that (it's before my time, and
you know I'm no SGML geek). <rhetorical>Was HTML ever intended to
actually support SHORTTAG and use it? I've never heard of it being
used deliberately, only heard by vague repute of it even being
implemented and it does seem contrary to the idea of "HTML as simple"

> Taking out the parts for which SGML does have a solution, then, your
> argument is based just on XML's concept of well-formedness.

Exactly. SGML was a failure and HTML and XML have both been successful,
if we judge them in terms of live desktops and bodies running the tech
daily. Having architected well-budgeted projects within SGML's core
competency and _still_ been unable to justify using it ('97 and we went
with PDF) I'm extremely unimpressed with SGML as any sort of
_practical_ solution to almost anything outside aerospace or
government. When a telco can't get it to work and looks for something
simpler, then that's a technology that has made itself unapproachable
by the masses. My_Cat_Mittens@Geocities is the best thing about the web
- worldwide publishing for grannies without budgets.


> > SGML is all very clever, but it's no bloody use ! Real people, in
> > suits and ties, just can't work it.
>
> There's certainly far more in SGML than HTML needs.

There's more in SGML than _people_ need.


> > >Then we get into *real* sophistry, for example that HTML purports
> > >to be an application of SGML
> >
> > Does it?
>
> How else would you interpret this, then?
> http://www.w3.org/TR/REC-html40/conform.html#h-4.1
>
> || An HTML document is an SGML document that meets the constraints of
> || this specification.

The fact that {an SGML document that meets the constraints of the HTML
spec} is also a HTML document does not imply that all HTML documents
are neccesarily SGML documents. It may even be so (my understanding of
SGML minimal conformance requirements is sketchy), but as I understand
things HTML is a sufficiently reduced subset of SGML that it can no
longer claim real conformance. Of course they're hugely similar, but
this isn't enough to justify some of the claims that Hixie makes (those
of the form "SGML can theoretically do this, therefore the web should
be doing it right now").

[Back to original message]