Re: Processing instructions for style tweaks?

Patrick Stickler (patrick@voyager.gate.net)
Sun, 4 Dec 94 11:32:48 +0100


Date: Sun, 4 Dec 94 11:32:48 +0100
From: patrick@voyager.gate.net (Patrick Stickler)
Message-Id: <9412041032.AA28678@voyager.gate.net>
To: www-html@www0.cern.ch
Subject: Re: Processing instructions for style tweaks?


 Liam Quin writes:

 > * we need to work on making HoTMetaL accept invalid documents, and make it
 >   at least as good as HoTMetaL PRO is now.
 > 
 > The last point is for completeness.... but also because just as a browser
 > that rejects invalid files is bad, so is an editor that rejects invalid files.

The inability of HoTMetaL to handle errors in input documents is the
single reason I still write HTML using a text editor and validate with
sgmls. In general, I think it is an excellent tool and laud SoftQuad
for offering it to the WWW community; and I am encouraged to see that
you folks understand the great need for an HTML editor that can also be
used for "debugging" HTML documents created with other non-validating
tools.

 > HOWEVER: imagine a server that requires that you `import' a file to its
 > `database' before it will deliver it.  There's an ideal opportunity both
 > for indexing the text and for validating.  That way, you're doing it once,
 > not once per transaction, and you're helping keep garbage off the web.

Intelligent servers which index/classify doucuments are a good example
why not only must HTML documents be valid, but authors must (in some
way) be taught/convinced to encode their documents using functional
markup and not merely for attaining a particular appearance (e.g. using
<H6> for a copyright string because Mosaic displays this in a nice
small font, etc.).

I can easily envision there being tools such as the World Wide Web Worm
which not only search URL's, titles, etc., but gather up
indexing/classification information from each individual server to
provide even more refined information retrieval. Unfortunately, this
will not work well (if at at all) if Web documents are not functionally
tagged -- and future extensions and refinements to HTML must encourage
and facilitate functional markup over format markup such that it will
be easier and/or more productive for authors to specify the function of
an informational element rather than its format. 

Consider all the folks who don't mark addresses with <ADDRESS> because
they don't like how it appears in italics in Mosaic... Style sheets
should address this phenomenon a great deal as authors will have
defined in a style sheet specifying how *they* want addresses to
appear, and therefore will need to mark addresses with <ADDRESS> to get
the desired appearance.

The major advantage of attributes over processing instructions is that
the author must use *some* tag. I.e. if processing instructions are
used, it will be feasible to use nothing in the <BODY> but a single
<P>, an assortment of format-based tags such as <BR>, anchors, and
processing instructions to encode a complete HTML instance that
displays as desired!  If the formatting specification can only be
encoded via attributes (i.e. processing instructions are not
available/supported), then an author will most likely use something
like <ADDRESS FONT="Helvetica" STYLE="B" SIZE="4"> (or whatever
attributes might be standardized upon) to encode an address that the
author prefers to be displayed in relative-size 4 Helvetica bold type.
The major point is that the author is *encouraged* to choose the most
applicable functional tag without any concern over formatting -- since
he/she can simply specify the element's appearance using either style
sheets, attributes, or both. I.e. choosing an element type will not
be motivated solely by how it will be formatted.

 > -- 
 > Liam Quin, SoftQuad Inc +1 416 239 4801 lee@sq.com   <URL:http://www.sq.com/>
 > HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval
 > SoftQuad HoTMetaL/HTML Editor; SoftQuad Panorama/WWW SGML Viewer (unreleased)
 > See our Web page for HoTMetaL ftp sites...  Take off those shoes and relax.
 > 
 
===============================================================================
    Patrick Stickler                        Email: patrick@voyager.gate.net
    Senior Computer Systems Engineer        Phone: (407) 356-9852 Office
    Information Group                                    356-6094 Lab 1
    Martin Marietta Corporation                          356-7725 Lab 2
    MP1270, 12506 Lake Underhill Rd.                     356-5685 Lab 3
    Orlando, Florida 32825 U.S.A.           Fax:   (407) 356-8949
-------------------------------------------------------------------------------
    Don't put off for tomorrow what you can do today; because if you enjoy
    it today, you can do it again tomorrow...
===============================================================================