> 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).
One use is for <BR> with <P CENTER> to get some centred lines, but which
all belong to the same logical paragraph.
> 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:
> <PRE>
> Name
> Address
> Telephone.
> </PRE>
> 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.
I'm not sure that most people would agree with your preference to explicitly
invoking a fixed pitch font.
Rather than an <R> tag, I would like to augment the EMPH rendering hints to
include additional font types beyond TT. This has a certain feeling of
completeness to it. The obvious step is to then also include the same font
attributes in PRE (defaulting to fixed pitch), i.e.
<!ATTLIST PRE
id ID #IMPLIED -- link destination --
style CDATA #IMPLIED -- various styles --
tr (tr) #IMPLIED -- render in serif (Times Roman) font --
hv (hv) #IMPLIED -- render in sans serif (Helvetica) font --
width NUMBER #IMPLIED -- e.g. 40, 80, 132 -->
e.g.
<PRE TR>
Name
Address
Telephone
</PRE>
With PRE right aligned text would only work in a particular window size.
PRE stops the browser from being able to adjust margins etc. to get the
alignment ok for the current window size. I would therefore like to allow
greater flexibility for normal paragraphs via rendering hints, e.g. your
example becomes:
<P INDENT>
Name<BR>
Address<BR>
Telephone.
The change to a container model for the P tag ensures that the scope is well
defined. The style attribute for PRE should be retained so that authors can
indicate the logical role of the preformatted text in an extensible manner.
On the subject of changing fonts, thanks for your comments on using the SGML
external entity mechanism.
> 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.
As far as Latin-1 goes it is a simple matter to map entity definitions to an
8-bit ASCII code. More generallt, this breaks down into two parts:
a) mapping the entity name to a character code and char set
b) how to render fonts in this char set (at least for the
character codes needed for the current document)
It would be neat if we could use outline fonts for this. From the point
of view of HTML+ all that is needed is (a). The rest is a matter for the
protocol spec. Perhaps for now we need a mechanism like #INCLUDE that
works across the network. This could be implemented using the LINK tag.
> 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.
Tell me more about the reasons people were asking for this feature.
It seems to me that Next and Previous can be adequately handled using
the existing framework:
a) defined by LINK elements with REL attribute
b) sequences defined with the GROUP tag in the parent doc
These will need to be clarified in the RFC for HTML+.
Regards,
Dave Raggett