Re: dealing with new-lines

Dan Connolly <>
Message-id: <>
Cc: "Thomas A. Fine" <>,
Subject: Re: dealing with new-lines 
In-reply-to: Your message of "Fri, 08 Jan 93 12:09:41 +0100."
Date: Fri, 08 Jan 93 12:50:48 CST
From: Dan Connolly <>

>For what it is worth, the way the CERN implementations are supposed to work is:
>This means that any number of newlines  
>will only produce one white space character.  [It involves a horrid "are we in
>the middle of a word?" flag.]

I don't think this flag is "horrid." It's a pretty normal text-formatting
thing to do.

>Spaces, however, always produce spaces, so multiple spaces will come out as  
>multiple spaces.

Is anyone distressed by the situation where some browsers compress
multiple spaces [in typeset paragraphs] into one, and some do not? I'm not.
I'd say "Don't do that" to the fool who put multiple spaces in
his source.

>Within <XMP> I went all the way and said that from the trailing > of <XMP>
>to the beginning <of </XMP> all data was litteral, including newlines.  
>Therefore example sections typically are marked up as
><XMP>This is an example line
>That was an example.  There are no new lines between the <XMP> and the example
>line because the XMP section causes a paragraph break, and the style for the  
>normal paragraph specifies a minimum white space after each paragraph.

This looks like sound policy to me.

> Beacuse
>each XMP section is like a black box, any white spce inside it would not be  
>seen by the white space management logic which overlaps the white spaces  
>required around successive paragraphs, and extra white spce would result.

Unfortunately, this conflicts with the SGML standard. An SGML parser
will report

an XMP start tag
the string "foo" [NOT "\nfoo\n"]
an XMP end tag

And so it is, strictly speaking, illegal to treat the above markup
differently from

I'm not sure how we should resolve this.

>By the way, I think we agreed (I gave in) that the <PRE> sections would have
>siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
>gives double spacing on my browsers.  So I tread newlines as newlines in all
>the <PRE> element just as XMP.

This is a situation we need to resolve, one way or another. I'm inclined
to decide that <p> elements are allowed in PRE elements, but they have
no significance. They were put there to cause the old linemode browser
to break the line, so they have always been redundant. So Tim's treatment
of newlines in PRE is correct, but his treatment of <P> there is not
[by this new convention.]