Philosophy behind XHTML (Was RE: why distinctions within XHTML?)

Mark Birbeck Mark.Birbeck at
Wed Sep 1 21:14:30 BST 1999

David Hunter wrote
> It [XHTML] *does* have to do with changing our ways, at
> some point, and writing XHTML instead of HTML.

But XHTML will eventually not be a single vocabulary, it will be a
collection of modules. If you are really concerned about 'changing our
ways' you are better off waiting for XHTML to be completed.

Anything else is, no matter how much people puff and pant, a stop-gap.
Can parts of XHTML 1.0 be used in compact devices like mobile phones or
toasters? No - until it's modularised you have to take the whole damn
lot. Can parts of it be used in other grammars when you want a table but
don't want to re-invent the wheel? Well, yes if you can live without
validation, but no, otherwise. Can I include other grammars in an XHTML
document? Again, only if I forgo validation.

Yet all of these things are stated goals in the XHTML proposals. So, it
is (a) nowhere near complete (b) nowhere near its stated goal (c) a
stop-gap. (Or as Dr. Evil would say, "Stop-gap, stop-gap, stop-gap.
That's W W W dot stop-gap.")

> XHTML is not an "intermediary", until we're ready to
> write everything in another XML vocabulary.

In the context of my last email, by 'intermediary', I meant conduit,
rather than evolutionary stage. Just as you might convert XML to 'XSLFO'
and then convert it to postscript or HTML, so you might go

You seem to think I mean that HTML and its variants will disappear, and
that instead, XML will be used everywhere with CSS or something to
display it. Actually I don't, but I think it will eventually only exist
as fragments in stylesheets that are applied to XML, and very small
devices that have not got an XML parser, but have got parsers for
various XHTML modules.

> But it's not.  The purpose of XHTML today and tomorrow is the 
> same as the purpose of HTML was yesterday and today:  to convey 
> information to a human.
> Period.  (Usually visually, i.e. in a browser.)
> That has nothing to do with transforming HTML to another XML 
> vocabulary, as in your previous email.

Why should the joys of HTML be preserved for humans? Why shouldn't my
server take your web pages and re-format them as marked-up data? Seems a
pretty good use of XHTML to me. Eventually the whole world will be
marked-up data, you won't be able to move for it. But that's a long way
off, so XHTML is crucial in the meantime. You seem to be saying that I
should wait until someone comes up with weather forecasts in XML before
I can put weather on my site, but I'm saying that I could take one of
the thousands of web sites currently dishing up weather, tidy up the
HTML to XHTML, and then run XSL on it to get weather forecasts in
WeatherXML (or whatever).

If you insist that this is not a valid use for XHTML 1.0 then why bother
having it? Any other use of XHTML 1.0 will be superseded by the modular
version of XHTML which will be a far better thing to use if you are
writing a web browser. Your XHTML 1.0 documents will still work, but
they won't be 'best practice'. And you will also need the schema
proposals to be completed so that namespaces can be mixed in the same
document (and validated). And while we're at it, we would need fragment
proposals to be complete too.

One last thing. You say:

> It [XHTML] doesn't really even have anything to do with
> transforming other XML vocabularies into XHTML

but that is not true. In fact, one of the good things about XHTML is
that it gives us a standard to transform XML to, when we want it
displayed. Since XSL is meant to output XML, then you aren't really
supposed to be outputting HTML (although I notice that XSLT lets you do
it now). Over the last year we all adopted slightly different ways of
getting round this, when we sought to generate XML structured HTML pages
without causing browsers to squeal. Now we can all adopt the same

(As to the namespace issue, I've voted for 3 already.)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list