By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,143 Members | 1,854 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,143 IT Pros & Developers. It's quick & easy.

losing leading blank line on posts

P: n/a
Hi. I'm finding that if I have text entered into a
<textarea ...> </textarea> in a form, and that text
has leading blank lines (with no spaces or anything
else), that when I retrieve the entered text, I
lose the leading blank line. Each time it goes through
a post any top-leading blank line is lost. Only one-
if I have several blank lines in a row at the top,
only the first is lost. (If the top blank line has
a single space, it's handled properly).

Is this normal? When I retrieve, would using htmlentities
to this? No other blank lines are effected, whether in
the middle or the end.

I hope there's some way around this. Any help greatly
appreciated,
-dg
Jul 17 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
dan glenn wrote:
Hi. I'm finding that if I have text entered into a
<textarea ...> </textarea> in a form, and that text
has leading blank lines (with no spaces or anything
else), that when I retrieve the entered text, I
lose the leading blank line.


Is it really getting lost? Are you using your browser's presentation
of the data to check this? If so, check the actual data instead.

--
Jock
Jul 17 '05 #2

P: n/a

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...
dan glenn wrote:
Hi. I'm finding that if I have text entered into a
<textarea ...> </textarea> in a form, and that text
has leading blank lines (with no spaces or anything
else), that when I retrieve the entered text, I
lose the leading blank line.


Is it really getting lost? Are you using your browser's presentation
of the data to check this? If so, check the actual data instead.

--
Jock


Yes, Jock, it seems to really be getting lost. Try the following:

file: testtextarea.php
<?php
if (isset($_POST['t_textarea'])) {
$t_textarea = $_POST['t_textarea'];
} else {
$t_textarea = '';
}
echo <<<TESTIT
<html>
<body>
<form action="testtextarea.php" method="POST">
<textarea wrap="soft" cols=40 rows=12
name="t_textarea">$t_textarea</textarea>
<p>
<input type="submit" name="woof" value="Post & Reload">
</form>
</body>

TESTIT;
?>

Create the above php file and run it. Put the cursor in the
textarea, hit ENTER around 5 times to create some blank
lines, then type in something like "here's a line". Then
click on the Post & Reload button and watch the line you
typed crawl upwards with each click.

It makes no difference what argument you use for "wrap" in
the textarea tag, either. I tried "soft", "hard", and left
it out altogether. Same deal.

This isn't the end of the world, but it still sucks. Surely
it's not supposed to act this way??? Is there a work-around?

-dg


Jul 17 '05 #3

P: n/a
dan glenn wrote:
Yes, Jock, it seems to really be getting lost.
Well, it's not. Check the *actual* data, not your browser's
presentation of that data.
Try the following: [...]

Create the above php file and run it. Put the cursor in the
textarea, hit ENTER around 5 times to create some blank
lines, then type in something like "here's a line".
Line breaks immediately following start-tags, any start-tag, *must*
be ignored. That means any line breaks after the TEXTAREA start-tag
ought to be ignored. Browsers not doing that are broken. Your
browser is apparently behaving correctly.
It makes no difference what argument you use for "wrap" in
the textarea tag, either.


About the only useful value for that non-standard attribute is "off".

http://www.cs.tut.fi/~jkorpela/forms/textarea.html#impl

(Hmm, another reason why education is far better than bald
recommendations.)

--
Jock
Jul 17 '05 #4

P: n/a
John Dunlop wrote:
Line breaks immediately following start-tags, any start-tag, *must*
be ignored. That means any line breaks after the TEXTAREA start-tag
ought to be ignored.


No it doesn't John! I don't know what I'm saying.

A *single* line break following a start-tag must be ignored.

--
Jock
Jul 17 '05 #5

P: n/a
John Dunlop wrote:
John Dunlop wrote:
Line breaks immediately following start-tags, any start-tag, *must*
be ignored. That means any line breaks after the TEXTAREA start-tag
ought to be ignored.


No it doesn't John! I don't know what I'm saying.

A *single* line break following a start-tag must be ignored.


And, of course, if I'd been awake, I'd've mentioned that what's
happening is every time you submit the form, a line break is getting
ignored. So, effectively, a line disappears each time.

Phew! That was hard work, wunnit? :-)

--
Jock
Jul 17 '05 #6

P: n/a

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...
John Dunlop wrote:
Line breaks immediately following start-tags, any start-tag, *must*
be ignored. That means any line breaks after the TEXTAREA start-tag
ought to be ignored.


No it doesn't John! I don't know what I'm saying.

A *single* line break following a start-tag must be ignored.

--
Jock


I'm just curious - WHY in all of creation MUST a linebreak immediately
following any start-tag be ignored??? This is not clear to me. First of
all, it doesn't make any sense to be talking about "linebreaks immediately
following a start tag". The <textarea ...> </textarea> tags are in the php
source merely to contain the starting value for the field and define
the size of the input box that the browser will create - the rows and
cols callouts define the size of the "box" that the user can type into.
When the user types in an initial linebreak, he is not typing it in
immediately after any start-tag! There are no tags at all at this point
- just the input fields that were created by tags when the page loaded.
That input box is dead empty when he starts - there's no reason the
initial linebreak should be ignored any more than any initial character,
that I can see.

I just tested my little testtextarea.php program in all my browsers,
and I find that in Opera the leading linebreak is NOT lost. Yea Opera!
In IE, NN, and Mozilla, it gets gobbled. Opera is behaving correctly,
the others are in error, in my opinion, as little good as that's worth.

Anyway, regardless, what you seem to be saying is that it is simply
IMPOSSIBLE for me to provide a multi-line input field in a form from which
I can accurately pick up what a user types in, if it's possible for the
user to start with a blank line. Impossible! This sounds incredibly lame -
surely there has to be a way of doing this. The nature of the fields I'm
prompting for are such that it is quite likely that occasionally a user
will want to put a blank line in at the top. I can't be ignoring it.

By the way, thanks so far for all your input. I do appreciate it, even
though it is going so frustratingly for me...
-dg
Jul 17 '05 #7

P: n/a


dan glenn wrote:

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...
John Dunlop wrote:
Line breaks immediately following start-tags, any start-tag, *must*
be ignored. That means any line breaks after the TEXTAREA start-tag
ought to be ignored.


No it doesn't John! I don't know what I'm saying.

A *single* line break following a start-tag must be ignored.

--
Jock


I'm just curious - WHY in all of creation MUST a linebreak immediately
following any start-tag be ignored??? This is not clear to me. First of
all, it doesn't make any sense to be talking about "linebreaks immediately
following a start tag". The <textarea ...> </textarea> tags are in the php
source merely to contain the starting value for the field and define
the size of the input box that the browser will create - the rows and
cols callouts define the size of the "box" that the user can type into.
When the user types in an initial linebreak, he is not typing it in
immediately after any start-tag! There are no tags at all at this point
- just the input fields that were created by tags when the page loaded.
That input box is dead empty when he starts - there's no reason the
initial linebreak should be ignored any more than any initial character,
that I can see.

I just tested my little testtextarea.php program in all my browsers,
and I find that in Opera the leading linebreak is NOT lost. Yea Opera!
In IE, NN, and Mozilla, it gets gobbled. Opera is behaving correctly,
the others are in error, in my opinion, as little good as that's worth.

Anyway, regardless, what you seem to be saying is that it is simply
IMPOSSIBLE for me to provide a multi-line input field in a form from which
I can accurately pick up what a user types in, if it's possible for the
user to start with a blank line. Impossible! This sounds incredibly lame -
surely there has to be a way of doing this. The nature of the fields I'm
prompting for are such that it is quite likely that occasionally a user
will want to put a blank line in at the top. I can't be ignoring it.

By the way, thanks so far for all your input. I do appreciate it, even
though it is going so frustratingly for me...


Actually,
<textarea>
//print stuff here
</textarea>

should work. Though that'll probably add an extra line on opera, unless you
check the useragent (which is unreliable due to user preferences) and adjust
your HTML accordingly :(

Ignoring a line break after an opening tag allows more-readable HTML code.
You're not forced to put all code on a single line if you want to prevent extra
spaces being added.

Regards,
Shawn
--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com
Jul 17 '05 #8

P: n/a
"dan glenn" <da********@yahoo.com> wrote in message news:<9HT_b.29919
<form action="testtextarea.php" method="POST">
<textarea wrap="soft" cols=40 rows=12
name="t_textarea">$t_textarea</textarea>


change
name="t_textarea">$t_textarea</textarea>

to: Note the space.
name="t_textarea"> $t_textarea</textarea>

This fixed it in Konqueror and Mozilla.

Justin
Jul 17 '05 #9

P: n/a
dan glenn wrote:
First of all, it doesn't make any sense to be talking about "linebreaks
immediately following a start tag".
I think it does. This is all about your browser's presentation of
the data, not what is sent to the server. You'd be better off
discussing this in an HTML group (you'd be even better off reading
past discussions from an HTML group). And by that token, it's off-
topic here. But since we've made it this far...

I'm assuming the data is passed correctly to your PHP script. Check
the actual data to confirm this. By changing the method to GET,
you'll see what is passed in the query component. Line breaks will
be represented, in the default encoding, by %0D%0A (a CRLF pair).
You'll see something like:

http://domain.example/path?t_textare...this+is+a+line

The value of t_textarea is, unencoded: two line breaks and the string
"this is a line". Echoing this into a TEXTAREA:

<TEXTAREA rows=5 cols=20>$data</TEXTAREA>

results in the first line break being ignored. That's the theory at
least; whether mainstream browsers get this right is another matter.
If, however, you wrote:

<TEXTAREA rows=5 cols=20>
$data</TEXTAREA>

you've introduced a line break of your own, which ought to be
ignored, so the line breaks of the user's data won't get ignored.
I just tested my little testtextarea.php program in all my browsers,
and I find that in Opera the leading linebreak is NOT lost.
Which Opera? My 7.10 seems to ignore line breaks in TEXTAREAs up to
the first non-white space character. From what I can see, both
Internet Explorer 6.0 (somewhat surprisingly!) and Mozilla 1.3 don't.
Anyway, regardless, what you seem to be saying is that it is simply
IMPOSSIBLE for me to provide a multi-line input field in a form from
which I can accurately pick up what a user types in, if it's possible
for the user to start with a blank line.


No. I'm definitely not saying that. The "picking up" part should
work, and there's very little you can do about it if it doesn't: it's
a browser issue.

HTH.

--
Jock
Jul 17 '05 #10

P: n/a

"Shawn Wilson" <sh***@glassgiant.com> wrote in message
news:40***************@glassgiant.com...


dan glenn wrote:

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...
John Dunlop wrote:

> Line breaks immediately following start-tags, any start-tag, *must*
> be ignored. That means any line breaks after the TEXTAREA start-tag
> ought to be ignored.

No it doesn't John! I don't know what I'm saying.

A *single* line break following a start-tag must be ignored.

--
Jock
I'm just curious - WHY in all of creation MUST a linebreak immediately
following any start-tag be ignored??? This is not clear to me. First of
all, it doesn't make any sense to be talking about "linebreaks immediately following a start tag". The <textarea ...> </textarea> tags are in the php source merely to contain the starting value for the field and define
the size of the input box that the browser will create - the rows and
cols callouts define the size of the "box" that the user can type into.
When the user types in an initial linebreak, he is not typing it in
immediately after any start-tag! There are no tags at all at this point
- just the input fields that were created by tags when the page loaded.
That input box is dead empty when he starts - there's no reason the
initial linebreak should be ignored any more than any initial character,
that I can see.

I just tested my little testtextarea.php program in all my browsers,
and I find that in Opera the leading linebreak is NOT lost. Yea Opera!
In IE, NN, and Mozilla, it gets gobbled. Opera is behaving correctly,
the others are in error, in my opinion, as little good as that's worth.

Anyway, regardless, what you seem to be saying is that it is simply
IMPOSSIBLE for me to provide a multi-line input field in a form from which I can accurately pick up what a user types in, if it's possible for the
user to start with a blank line. Impossible! This sounds incredibly lame - surely there has to be a way of doing this. The nature of the fields I'm
prompting for are such that it is quite likely that occasionally a user
will want to put a blank line in at the top. I can't be ignoring it.

By the way, thanks so far for all your input. I do appreciate it, even
though it is going so frustratingly for me...


Actually,
<textarea>
//print stuff here
</textarea>

should work. Though that'll probably add an extra line on opera, unless

you check the useragent (which is unreliable due to user preferences) and adjust your HTML accordingly :(

Ignoring a line break after an opening tag allows more-readable HTML code.
You're not forced to put all code on a single line if you want to prevent extra spaces being added.

Regards,
Shawn
--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com


BINGO! Yes, you're right - in Opera alone this introduces a leading blank
line on each cycle (of my testtextarea.php program). Thanks for explaining
why the linebreak immediately after a start-tag is skipped by browser
parsers, too.

What I've decided to do is code it this way, and try to detect Opera and
take the extra inserted linebreak out for Opera users, plus maybe in tiny
print on the page put a note that Opera users who have configured their
browser to report themselves as something else are going to be in for
trouble.

-dg
Jul 17 '05 #11

P: n/a

"Justin" <ju***********@hotmail.com> wrote in message
news:db**************************@posting.google.c om...
"dan glenn" <da********@yahoo.com> wrote in message news:<9HT_b.29919
<form action="testtextarea.php" method="POST">
<textarea wrap="soft" cols=40 rows=12
name="t_textarea">$t_textarea</textarea>


change
name="t_textarea">$t_textarea</textarea>

to: Note the space.
name="t_textarea"> $t_textarea</textarea>

This fixed it in Konqueror and Mozilla.

Justin


no good, Justin. This way, each time there is a cycle of Post, reload, a
single space has to be inserted at the start of the field data. What if the
user does NOT have a blank line to lead off? - his text gets shoved over to
the right! (And this would definitely happen, because the nature of this
thing is such that there is a "preview" function, which the user previews
what he has typed in and returns).

But Shawn gave me a way that will work with all browsers except Opera.
Thanks for the input.
-dg
Jul 17 '05 #12

P: n/a

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...
dan glenn wrote:
First of all, it doesn't make any sense to be talking about "linebreaks
immediately following a start tag".


I think it does. This is all about your browser's presentation of
the data, not what is sent to the server. You'd be better off
discussing this in an HTML group (you'd be even better off reading
past discussions from an HTML group). And by that token, it's off-
topic here. But since we've made it this far...

I'm assuming the data is passed correctly to your PHP script. Check
the actual data to confirm this. By changing the method to GET,
you'll see what is passed in the query component. Line breaks will
be represented, in the default encoding, by %0D%0A (a CRLF pair).
You'll see something like:

http://domain.example/path?t_textare...this+is+a+line

The value of t_textarea is, unencoded: two line breaks and the string
"this is a line". Echoing this into a TEXTAREA:

<TEXTAREA rows=5 cols=20>$data</TEXTAREA>

results in the first line break being ignored. That's the theory at
least; whether mainstream browsers get this right is another matter.
If, however, you wrote:

<TEXTAREA rows=5 cols=20>
$data</TEXTAREA>

you've introduced a line break of your own, which ought to be
ignored, so the line breaks of the user's data won't get ignored.
I just tested my little testtextarea.php program in all my browsers,
and I find that in Opera the leading linebreak is NOT lost.


Which Opera? My 7.10 seems to ignore line breaks in TEXTAREAs up to
the first non-white space character. From what I can see, both
Internet Explorer 6.0 (somewhat surprisingly!) and Mozilla 1.3 don't.
Anyway, regardless, what you seem to be saying is that it is simply
IMPOSSIBLE for me to provide a multi-line input field in a form from
which I can accurately pick up what a user types in, if it's possible
for the user to start with a blank line.


No. I'm definitely not saying that. The "picking up" part should
work, and there's very little you can do about it if it doesn't: it's
a browser issue.

HTH.

--
Jock


Jock - NOW I understand what you were talking about. Sorry for the
obtuseness. It seemed to me that the PHP parser, as it processed the script,
should be able to tell the difference between a linebreak immediately
following a tag and a linebreak that happened to be at the start of a
following php variable. But evidently all variable substitutions are made
first and THEN it looks at what immediately follows the starting tag, not at
this point being able to tell that the linebreak that may be there came from
a variable or was mearly put there by the programmer for readability. Live
and learn.

My Opera is version 7.23. It gains a line each cycle with this code, but
I'll code around that for those Opera users who don't mess with their
Opera's brand reporting in the useragent string.

thanks for the discourse,
-dg
Jul 17 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.