Know your ISP.

breath-hyenas
User #289719   193 posts
Forum Regular

Hi Everyone ,

I have enter something from textarea to array but it doesn't reconise the "new line". Does anyone know how to maintain the "new line" in the array ?

at the moment it's treat new line as space

Example

---------
abc
123

--------
Array ( [0] => a [1] => b [2] => c [3] => [4] => 1 [5] => 2 [6] => 3 )

cheers,
Flora

reference: whrl.pl/RccyZ2
posted 2010-Mar-12, 10pm AEST
User #112549   1306 posts
Whirlpool Enthusiast

How are you assigning your textarea input into the array?

reference: whrl.pl/Rcczd8
posted 2010-Mar-13, 12am AEST
User #44690   20646 posts
Whirlpool Forums Addict

I am sure the problem here is not that of getting the newline into the array, nor getting the newline back out of the array, but that browsers must treat newlines identically to spaces when rendering most elements.

I think only <pre> and <textarea> elements preserve newlines. Any other element would require markup to describe the text layout (possibly in the form of <br> elements, possibly in some other manner).

reference: whrl.pl/Rccz3I
posted 2010-Mar-13, 11am AEST
edited 2010-Mar-13, 11am AEST
User #317306   783 posts
Whirlpool Enthusiast

PHP provides the convenience function nl2br to save you rolling your own.

reference: whrl.pl/Rccz8g
posted 2010-Mar-13, 12pm AEST
User #44690   20646 posts
Whirlpool Forums Addict

rrp writes...

PHP provides the convenience function nl2br to save you rolling your own.

Well, yes, but I didn't want to suggest <br> was the only answer. If your newlines separate paragraphs, for instance, <br> would be quite inappropriate.

reference: whrl.pl/RccBeM
posted 2010-Mar-13, 6pm AEST
User #166340   934 posts
Whirlpool Enthusiast

Foonly writes...

that browsers must treat newlines identically to spaces when rendering most elements.

i thought control characters usually weren't renderable?

reference: whrl.pl/RccBjl
posted 2010-Mar-13, 6pm AEST
User #44690   20646 posts
Whirlpool Forums Addict

ironheart writes...

i thought control characters usually weren't renderable?

That's a bit of a tautology. It's one of the defining characteristics of a "control character" for it to have no associated glyph to render. (As an aside, Unicode does specify some codepoints with glyphs so that control characters can be represented in text — ␀ ␤ ␍ ␊ etc. — but these are just regular "Symbol" characters in the "Control Pictures" Unicode block.)

What I specifically meant was how white space is defined by the HTML specification. In particular, the three standard kinds of newline sequence (CR, LF, CR+LF) are white space as well.

Then the spec goes on to say:

For all HTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.

...

Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space.

You can imagine that any kind of whitespace, and any amount of it, is converted into an abstract "inter-word space" token, and hence "newlines are treated identically to spaces".

Also, this seems to show that my earlier hunch about <textarea> was wrong.

reference: whrl.pl/RccByB
posted 2010-Mar-13, 7pm AEST
edited 2010-Mar-13, 8pm AEST
User #289719   193 posts
Forum Regular

Thanks , nl2br and str_replace seem to work quite well.

reference: whrl.pl/RccCqn
posted 2010-Mar-14, 1am AEST
Hosted by
Bulletproof Managed Hosting
Big numbers
1,668,885 threads
32,921,337 posts
3,365,328 whims sent
3,986 wiki topics
195 ISPs listed
10,178 broadband plans
1,268 modems & routers
59,837 features filled