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
12  3246 
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
"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
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
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
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
"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
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
"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
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
"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
"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
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: \Dandy\ Randy |
last post by:
Hello everyone. I have been following misc posts, as well as reading several
FAQ's on this issue, unfortunatley I cannot locate a solution. I am hoping
that someone will be able to provide me with...
|
by: Scott Lyon |
last post by:
I'm maintaining (read: I didn't write it, nor do I have the time to spend to
rewrite it) an application that is suddenly giving me grief.
The reason I say suddenly, is because we're in the...
|
by: James |
last post by:
Session("UserName") is set when someone logs in. Get to a page that
displays a record where you can type a comment. The form has an onSubmit
event that calls a javascript function. That function...
|
by: steve |
last post by:
Well I've been working all morning and have finally found the source of
my "bus error (signal 10)" errors. The source is odd. The error
occurs in any function where I make the function call:
...
|
by: Dean Fields |
last post by:
Hello,
I am having some session problems wih an in-house (classic) asp application.
My developers have not been able to figure it out. I am more of a systems
admin type and much of this is over...
|
by: David |
last post by:
Hi,
using .NET 1.1 C#
I am trying to determine page generation time. I have
TimeSpan RenderTime = DateTime.Now - PageTime; (pagetime was set up in
oninit, Rendertime is in the render
I am...
|
by: GS |
last post by:
How can one avoid capturing leading empty or blank lines?
the data I deal with look like this
"will be paid on the dates you specified.
xyz supplier
amount: $100.52 when: September 07,...
|
by: jbaranski |
last post by:
Access 2003 on XP pro machine...
i'm running a crosstab query and an export to a 3rd party company showing different benefit plans for employees; specifically dental, vision and medical pulling...
|
by: joelkeepup |
last post by:
Hi, im trying to create a text email message using xslt template , the
transforms work great, but the newlines and whitespace in the xslt doc
are removed. Is there a setting somewhere I have...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
