One PRE, and entities

Terry Allen (
Sun, 27 Jun 1993 16:53:23 PDT

Dear Dave:
Sorry not to respond sooner to your post of Monday last, pointing
out HTML+'s style attribute for PRE. This is okay, but maybe
not the most economical approach.

I think there are two issues: 1) the spec's definition of
leading white space and line breaks as significant within PRE,
and 2) font changes within PRE. Presently, 1 seems to work just
fine (at least in xmosaic and lynx, the two browsers I'm using
for trials), so it should not be necessary to institute a <BR>
tag to get line breaks within PRE. Outside PRE one shouldn't
need them (counterexamples welcome).

Presently, however, PRE is defined as having typewriter type
as its default font, and I think that's wrong. I'd rather have
to invoke that font (by <CODE>) explicitly, the default font
remaining the same as the main text. That way I don't need
an <R> tag, which has also been suggested, and when I
have an address to display, I can type:
and get three indented lines in the main text font.
I think that if the definition of PRE is changed in this way
the style attribute might not be needed.

On another topic you mentioned, charsets, wide fonts, and
outline fonts, what I gleaned from the recent discussion of
Unicode on comp.text.sgml is that it shouldn't wreck the
SGML mechanism. For what is not supported by Unicode, should
we choose to go that rather quirky route, the SGML external
entity mechanism is the obvious method, as you point out.
We already have character entities in the HTML DTD; all that's
needed is to establish how to reference external entity sets not
actually included in the HTML+ DTD. SGML rather envisions that
the entity files are available locally at run time; for WWW it
might be better to be able to indicate the entity files are on
the same machine the document is being fetched from.

And if we can reference external entities, we can do something
requested this week in my office: use entities to represent
URLs. Than means 1) URLs themselves may be extracted from the
main document and collated in a referenced navigational document,
and 2) common link types may be generated automatically: for
any "Next" link, my &next; entity can refer to a script that
looks through a list of filenames, chooses the one after the
current file, and returns that as the URL for the target of
the link.

I'l like to suggest that references to external entities go
in the HEAD of the document.


Terry Allen  (
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472