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.
> XMP
>
>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
>
></XMP>
>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
<XMP>
foo
</XMP>
as
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
<XMP>foo</XMP>
I'm not sure how we should resolve this.
> PRE
>
>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.]
Dan