Re: HTML should not be a file format, but an output format

Paul Prescod (papresco@calum.csclub.uwaterloo.ca)
Sun, 23 Mar 1997 20:13:07 -0500


Message-ID: <3335D523.289B@csclub.uwaterloo.ca>
Date: Sun, 23 Mar 1997 20:13:07 -0500
From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
To: www-html@w3.org
Subject: Re: HTML should not be a file format, but an output format

Benjamin Franz wrote:
> Now imagine a world not only like BASIC - but one in which you had to
> write code that would successfully run under *all* those variants without
> any source changes and without doing anything fatal. You begin to see
> where the HTML designer today lives - and why automated tools are of only
> marginal use to them.

To be fair to Akimbo, Word for Windows is not exactly a Desktop
Publishing Program that a professional would use, but most people still
find it good enough. The dream of a web that anyone can publish on will
be fulfilled when it is as easy as possible to publish on the Web as it
is to write a Word doc, not when it becomes as easy to write beautiful
web documents as it is to use FrameMaker.

For the sites I work on, I definately have to choose quantity of
information/navigational tools over hand-crafted beauty in every
browser. For those types of sites automation is critical, whether
WYSIWYG or batch. If something like GlobeTrotter didn't trap my data in
a binary format specialized for software on a potentially endangered
platform I would use it for simple jobs, or more likely give it to the
other people who I work with that maintain smallish web pages.
 
> I have to push sites out the door *today* - and just because something is
> in the standards doesn't mean I can use it:  Criteria #1 in my
> implementation book is _don't break people's browsers_.  I would *LOVE* to
> be able to use OBJECT - but it breaks MSIE3. I would love to use external
> Client Side Image Maps - but they break NS3.

Actually, some of these problems can be helped by automation. You could,
for instance, design your client side image maps as external documents
and let your automated tool "include them" for you until Netscape
supports them externally.
 
> The
> solution *might* be XML - but then again, I seem to recall someone saying
> that NS has refused commitment to it (something I can well believe since
> there does not seem to even be one Netscape name in the XML draft
> credits). This may be enough to render XML a dead letter - which would be
> a crying shame.

Netscape cannot kill XML. It is a child of the SGML community and it has
been conceptually in gestation for a decade. But it also does not look
like the Web community will reject XML. Microsoft is already basing new
standards upon it and I expect that the many RFCs issued by
non-Microsoft companies will increasingly do the same. Why reinvent the
context free grammar for each RFC? There are going to be dozens of
object description and meta data languages developed in the next few
years and I expect most will be based on XML.

I can't see far enough into the future to see if XML will be a major
publishing format (as opposed to storage format and object description
format) in the near future. It depends on whether the market strong arms
Netscape into supporting it. My impression is that Netscape is
supporting CSS basically against their will: new tags are more their
style. I hope XML will be the same.

 Paul Prescod