Re: comments on the Nov 22 draft spec

Albert Lunde (
Mon, 28 Nov 94 13:52:50 EST

At 6:51 AM 11/28/94 -0500, Peter Flynn wrote:
>> > It says:
>> > Interpreted as a word space in all contexts.
>> > but what about PRE?
>> >
>> An LF is the only character which is interpreted as a newline.
>> The CR is interpreted as a word space in all contexts.
>Can someone with experience of Mac browsers and servers interpret this:
>If you edit a .html file on a Mac and put it into a Mac server, and it
>contains a <pre> element, does the server spot this and add LFs to those
>lines between <pre> and </pre> (or to the whole file) or what?

There are some interesting questions lurking here.

When HTML is sent over the network, we need to standardize the
interpretation of end-of-lines.

But when HTML is stored locally, it is reasonable that it will be stored
with local end-of-line conventions, like plain text.

I'm not sure what end-of-lines mean in the context of "SGML applications",
but I know there are systems that use <CR>, or <LF>, or <CR><LF> or
out-of-band record lengths as end-of-line terminators.

It's even feasible to store HTML as EBCDIC with due care about code
mappings and use of Non-ASCII Latin-1 characters.

I think the correct treatment of non-native end-of-line sequences in local
files may depend on the local end-of-line conventions.

In particular the rule of thumb of treating <LF> as a line-break and <CR>
as a word space works well for resolving a sloppy mix of Unix end-of-line
and Internet Net-ASCII end-of-line conventions.

It doesn't make as much sense when talking about HTML stored on a system
that uses <CR> (Mac) or record counts (CMS and others) as line-breaks.

Is there a MIME or SGML "way" to distingush between local storage of files
and the canonical way they are sent over the net?

    Albert Lunde