Re: Suggestion for HTML Text Format Elements

Andre J. Emmell (sgml@globalx.net)
Tue, 4 Jul 95 11:36:12 EDT

>To: html-wg@oclc.org
>
>Dear HTML Working Group:
>
>Having some experience with HTML formatting, and having read the 6/15 2.0
>specs and the latest 3.0 specs, and not having found what I was looking
>for, I would like to propose several new HTML text formatting elements
>for your consideration.

.... <snip> ... <snip> .... <snip> .....

>I hope you will consider these suggestions in the helpful spirit I've
>intended. I have enjoyed learning HTML (the more so because it's so
>similar to LASERQ), and see great potential for it to allow much more
>control and creativity to the benefit of both web authors and web users,
>as well as the burgeoning off-line use of hypertext formatting.
>
>If you have any questions or comments, I would be pleased to address them
>at your convenience.
>
>Paul Havemann
>HSH Associates
>paul@hsh.com
>

While I value the effort and the benefits suggested in this proposal, and
with all
due respect to the work that has already been acomplished, I think that
this proposal goes against the very reason HTML was created in the first
place. HTML documents, like all SGML source document should restrict
themselves to DECLARING the elements and text offered by the authors and leave
the formatting, page layout, and the fancy "rendering" to the rendering
tools such as Netscape, Mosaic and others. I believe that it is inappropriate
for the source to contain ANY "style" or page oriented or screen oriented
directives. To do so is to condemn the source files to an "intended view"
and thereby limit its usefulness. Living in the real world means that some
compromises must be tolerated so there needs to be a balance. HTML is
not postscript or a styles description language. It is a element declaration
standard for WWW documents. We need to respect that. Failure to do that
will cause many documents to "break" in the future and will limit the usability
of current documents.

Furthermore, HTML is becoming so big and complex that it will soon become
too difficult for the average person to "put his/her document on the net".
Even with
better editors and automated tools. For many the concept of HTML is becoming
difficult to grasp. Most of us in the documentation business are well
versed in the
latest and greatest editing and viewing technology. WE, ourselves, have a
learning curve on this fast growing technology.

On behalf of ALL newbies, uninitiated, not too familiar users, and
occasional users
could I ask for the development to slow down a bit, minimize the explosion of
additions & modifications to HTML and allow HTML to stabilize for a few
months? Let us not try to make HTML to be everything to nobody and nothing
for everybody

I am a document architect and I train people in SGML and HTML. I find that
I can no
longer teach HTML to the average person in one day unless I limit myself to the
very basics and point them to good information on Internet. I suspect that
other
trainers also find that HTML is becoming more and more complex. Many people
are given the task of putting their text on Internet and have a difficult time
learning the local jargon, the Internet jargon, and the HTML workings. The
result is that HTML files are filled with <pre> elements and "litterals" and
manual
placements of text in a desperate attempt to display their information in a
quick and dirty manner while achieving some short term gains for long
term pains.

Let us remember that we have no idea how OUR HTML SOURCE FILES will be
used and displayed in the future. The proof of this is the new ways
Netscape and
Mosaic leap frog each other in fancy features. One thing I can predict,
based on
my experience, is that one day USERS will dictate locally how each element will
be displayed, printed and used on their systems. The author who wants to
dictate from the source how the text should be displayed will be
"out to lunch" very soon.

Let each SGML function do what it is designed to do best. Let DTDs define
the elements and their relationships; let authoring tools author; let rendering
tools render; and let printing tools print. The technology is quite capable of
converting on the fly.

I hope that these comments will contribute to more consistent documents
and a more efficient use of our precious bandwidth. My intent is to make it
easier and simpler for the average users to create better looking documents
and for the average administrators to maintain and distribute these documents.

Andre J. Emmell sgml@globalx.net