Re: TEXTAREA line terminators revisited

CN=Bruce Kahn/O=Iris@IRIS (iris!CN=Bruce_Kahn/
Thu, 12 Jan 95 17:30:21 EST

>So, are we saying that if I, as an information provider (server-side)
>create a TEXTAREA which includes text in it with lines that
>end with something other than CRLF, then my readers (client-side)
>will not see my line endings?

I think the point was to say that as an IP, you _must_ have the proper
termination on your TEXTAREA records (both those you create and expect to
receive). Given a standard, you could then use the same HTML files on both a
non-Unix server (ie Windows) and a Unix based server. There will obviously
need to be some give/take on this since users on each platform may gripe
about not being able to put any arbitrary text in a TEXTAREA (ie pasting text
from a clipboard).

>If, on the other hand, we are saying that when a reader (client-side)
>fills in a form, the client must insert a standard line-ending
>no matter what the default line ending is on that platform,
>then this sounds like a great idea.

You cant have it both ways (servers can present text w/any delimiter but
clients _must_ use a specific one. You then force clients to be lenient
while allowing servers to do whatever they feel like. Both sides need to
play by the same rules or the rules will get bent/broken.

> I only wonder why would CRLF be considered the best candidate?
> Wouldn't it be a lot easier to deal with a single character as a line

Not always. If you are using Unix or Macs then you already use single
character EOLs. If you use PCs / Windows then you have CRLF. Given the
diversity of the platforms current EOLs you could probably argue both sides
quite well.

> What happens
>when a reader on an X Window System machine uses the mouse to
>cut and paste text into the TEXTAREA? Since the X Window buffer
>contains LF's as line endings, is the application required to
>interpret the LF's and prepend a CR for each one?

Yes. On the Mac the same would apply (appending LFs after the CRs). On PCs
there would be no change. No matter what choice we make, there will be some
unhappy authors out there who will grumble about having to clean up some
buffers before they are sent. Then again, browsers should be groking the
input buffers now to do escapifying of some characters (ie &->&) so how
difficult will this new requirement be for them to implement??

Bruce Kahn INet:
Iris Associates Phone: 508.392.5335
Standard disclaimers apply, even where prohibited by law..