Re: SGML Open recommendations on HTML 3

James D Mason (MASONJD@oax.a1.ornl.gov)
Tue, 21 Mar 95 14:08:57 EST

I would like to second some of the issues raised by the SGML Open
contribution. As in the case of my seconding Terry's comments on character
sets, I am primarily interested in making HTML the best SGML application it
can be.

I particularly support SGML Open's comments on making HTML just another
formatting language. Even though I've spent much of my publishing career in
typesetting-related activities, I have a strong distaste for seeing
typographic material put into HTML. We need to accept a new model for
information delivery in which appearance is in the hands of the recipient even
more than in the hands of the originator. We need to think structure and
organization of information in the abstract. We shouldn't say "make this
bold"; we should say "this is important, so we should tell the rendering
engine (i.e., browser, user agent) to do whatever the use has told it to to
show important things. If our user community wants to have typographic control
of so many things, we should tell them to use PDF and build themselves Acrobat
servers.

I've already posted a long essay about the need for hierarchy and container
elements, so I'll just say that I agree with SGML Open's need for such things.
I likewise support their deprecation of asynchronous elements. I've used such
things, but they mean an added burden on the creators of documents because
they throw away the ability of the parser to match ends of an object.

Although I generally support the position on tables, I agree with those who
prefer ems (or some such proportional unit) to hard measurements for table
alignment. Just moving from one platform to another makes hard-coded
dimensions a difficulty, not to mention the issues of rescaling a document on
a given platform. (Actually, I'd like to see browsers that set column widths
dynamically, depending on content: it's possible, though obviously not easy.
Formatting information hard-coded in tables is just as distasteful to me as
adding format oriented elements to the base HTML language. I need tables, and
I need them directly in HTML rather than captured in dead GIF images, but I
don't want to be in the postion of having to calculate a lot of column widths
that won't work on all screens anyway.)

I also agree that deprecated practices should not be defaults. We shouldn't
invalidate existing documents, but we shouldn't encourage continuation of bad
practices. If having a clean 3.0 means causing browsers to have to read the
results of two DTDs, so be it (I've already proposed such things in the past).

Jim Mason

Dr. James D. Mason
(ISO/IEC JTC1/SC18/WG8 Convenor)
Oak Ridge National Laboratory
Information Management Services
Bldg. 2506, M.S. 6302, P.O. Box 2008
Oak Ridge, TN 37831-6302 U.S.A.
Telephone: +1 615 574-6973
Facsimile: + 1 615 574-6983
Network: masonjd @ ornl.gov