Re: Suggestion for HTML Text Format Elements

Scott E. Preece (preece@predator.urbana.mcd.mot.com)
Wed, 5 Jul 95 10:51:55 EDT

From: sgml@globalx.net (Andre J. Emmell)
|
| 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.
---

I can agree with most of what you say, but I would point to several of the things Paul Havemann suggested that are, in fact, useful extensions of the declaration facility: FILL/NOFILL (which presumably should be an attribute of container elements) is usefully more specific than PRE, indicating *only* that the lines are pre-broken and not restricting content or implying the use of a fixed-width font. BOX, which could be re-named DISTINGUISH or SIDEBAR, to indicate that a chunk of content should be visually distinguished from the surrounding content (the browser could be trusted to draw a frame around it or use a background color shift or otherwise differentiate the material).

Page break suggestions (this could be an attribute, perhaps SECTION, on heading elements) to allow the author to indicate that there is a major change in content, allowing the browser to start put the heading at top of screen or page. This is real information about content, *not* just presentation.

Running-head information (which the browser could use on printed pages or in the title bar or in a sub-frame). The intent is, again, to allow the author to declare something useful about the document or about a section of the document, not to control how the information is presented.

Here's a similar suggestion of my own:

Add a "HEADING" attribute to the TR element, to indicate that if the browser paginates or scrolls a table, it should try to keep HEADING rows visible at all times.

In all of the above, the intent is not to let the author control the way the information is presented (which I strongly agree should be in the hands of the browser, preferably via a powerful style-sheet facility), but to allow the author to provide information allowing the browser to do the right thing.

---
| 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.
---

While I sympathize with this sentiment, I basically disagree. HTML is still too small and simple. It will inevitably slide towards the scope and complexity of the major existing standard DTDs (like DocBook), for the obvious reason - those standards have evolved their complexity based on real-world users' needs. The key thing the working group has to do is to make sure the evolution does respect the declaration vs presentation division and to make sure change happens smoothly - that compatability is preserved as change occurs and that debate preceding change is sufficient to avoid major misdirections.

---
| 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
---

One of the good things about HTML is that it can be learned progressively - you don't need to know about all the attributes and all the elements to write legal, useful documents. It should not be necessary to learn all the wrinkles before doing anything. But the language should continue to grow in power so that experienced users and powerful tools can express the content of their documents effectively.

| ... 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.

---

On the other hand, those same mis-uses are also the only recourse of those who have hit the limits of the current language. HTML without tables, for instance, was *much* less useful and *much* more prone to the use of <pre>.

---
| 
| 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.
---

Exactly, but also provide enough expressive power to allow authors to describe their information in a way that will allow those tools to do a good job and to allow style sheets to offer useful controls.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com