Carriage return inefficiency in a textarea control

Patrick · Sep 23, 2003

I'm developing an application which requires
a textarea to display large amounts of data.
I'm storing the information in an array and then
using join to dump the contents into the textarea.
It appears, however that textareas don't handle
carriage returns very well as illustrated by the following code.
If would appreciate if anyone knows the reason for this behavior
and a possible workaround.

<HTML><HEAD>
<TITLE>Textarea</TITLE>
<SCRIPT>
var arr= new Array;
function GenString(s){
arr.length=0;
for (var i=0;i<5000;i++)
arr[arr.length] = i + ' = [abcdefghijklmnopqrstuvwxyz]'
var d = new Date();
if (s=='||')form1.textarea1.value=arr.join('||')
else form1.textarea1.value=unescape(arr.join('\n'))
var d1= new Date()
alert((d1-d)/1000 + ' seconds' + '\n' + 'Textarea length= ' +
form1.textarea1.value.length);
}
</SCRIPT>
</HEAD>
<BODY>
<FORM NAME="form1">
<TEXTAREA ROWS="10" COLS="40" NAME="textarea1"></TEXTAREA>
<BR><INPUT TYPE="button" VALUE="Generate || string" NAME="button1"
ONCLICK="GenString('||')">
<INPUT TYPE="button" VALUE="Generate \n string" NAME="button1"
ONCLICK="GenString('\n')">
</FORM>
</BODY>
</HTML>

Lasse Reichstein Nielsen · Sep 23, 2003

It appears, however that textareas don't handle
carriage returns very well as illustrated by the following code.
If would appreciate if anyone knows the reason for this behavior
and a possible workaround.

You failed to tell us what the behavior is, what you expected, and
which browser exhibits the bad behavior.

Is the problem that the string joined with "\n" takes ~four times longer
to insert into the textarea?
In that case, it has nothing to do with Javascript, but is an artifact of
the underlying implementation of text areas. Any solution would include
not using a text area.
/L

Patrick · Sep 24, 2003

It appears, however that textareas don't handle

You failed to tell us what the behavior is, what you expected, and
which browser exhibits the bad behavior.

Is the problem that the string joined with "\n" takes ~four times longer
to insert into the textarea?
In that case, it has nothing to do with Javascript, but is an artifact of
the underlying implementation of text areas. Any solution would include
not using a text area.
/L

Lasse

Thanks for your reply.

To clarify: I'm experiencing this behavior on IE5.0. (I'm actually
developing for the Pocket PC version of IE which in this case shows
the same behavior as IE5.0). When you run the supplied code snippet in
IE5 - the double pipe "||"
renders the entire string to the text area in approx. .1 of a second
as opposed to the "\n" version which takes 7.5 seconds - for the same
sized string. I've run the code on some other browsers with the
following results:
Browser "||" "\n"
IE5.0 0.12 sec 7.5 sec
IE6.0 0.15 sec 0.7 sec
Opera7.11 12 sec 12 sec
NN7.02 4.5 sec 12 sec

As you see quite a difference between browsers and in some instances
the render times for the two strings. What is even more curious is
that Netscape reports a different string size ie. 178889 for the "\n"
option as opposed to 183888 for the "||" option. I tend to agree with
you that this text area behavior seems to be due to the underlying
browser implementation - if there are any solutions that would prevent
this behavior - is another question.

Lasse Reichstein Nielsen · Sep 24, 2003

When you run the supplied code snippet
in IE5 - the double pipe "||" renders the entire string to the text
area in approx. .1 of a second as opposed to the "\n" version which
takes 7.5 seconds - for the same sized string. I've run the code on
some other browsers with the following results:

Browser "||" "\n"
IE5.0 0.12 sec 7.5 sec
IE6.0 0.15 sec 0.7 sec
Opera7.11 12 sec 12 sec

Opera 7.2 is faster, and gives results similar to IE 6.

NN7.02 4.5 sec 12 sec

As you see quite a difference between browsers and in some instances
the render times for the two strings.

Yes, quite a difference. Are IE 5 and IE 6 running on different
operating systems? Because I would expect the operating system to be
the important factor if the browser uses standard system widgets
(which I don't think Mozilla/NN7 does).

What is even more curious is that Netscape reports a different
string size ie. 178889 for the "\n" option as opposed to 183888 for
the "||" option.

That is probably because Mozilla uses UNIX End-of-line encoding (one
newline, 0x0a) and the other browsers uses DOS/Windows EOL (carrige
return+newline, 0x0d 0x0a).

I tend to agree with you that this text area behavior seems to be
due to the underlying browser implementation - if there are any
solutions that would prevent this behavior - is another question.

I doubt it.
/L

Filename undefined for Blob ?	1	Oct 28, 2023
In javascript, XML File Create, File Save	2	Jul 17, 2023
Song requests	4	Aug 16, 2023
Script to send email not working	1	Apr 10, 2023
sorting a textarea.	8	Nov 2, 2008
add carriage return?!	9	Sep 13, 2005
Self-resizing textarea	2	Nov 24, 2006
manipulating text in a textarea	4	Dec 18, 2005

Carriage return inefficiency in a textarea control

Patrick

Lasse Reichstein Nielsen

Patrick

Lasse Reichstein Nielsen

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads