How to deal with newlines inserted when pasting into a textarea on the Mac
August 24, 2006 5:35 AM Subscribe
Pasting text into an HTML textarea on a Mac inserts newlines where the lines wrap, but this doesn't happen on Windows. It's messing up my very basic content management.
Our website has a php data entry feature to allow the loading of articles into a database. We are posting a lot of existing data, so we're cut-and-pasting it into a text area to be loaded into a MySQL database.
I'm searching for newlines (/n) in the text in the textarea, and replacing with paragraph tags so the articles display nicely in HTML. The newlines already exist in the source file. Users just select an article to enter, then copy it, and paste it into the textarea on the data entry page.
(NOTE: We are not hitting return inside the textarea, so this is not simply the common problem of Windows and Macs using different control characters for a Return. We are only pasting into the texarea.)
The process works if you use a Windows machine to do the copy-and-pasting. In that case the newlines are replaced with paragraph tags. But on a Mac, newlines are added at every point the text wraps in the textarea box.
For example, imagine that the following is text that you have just entered into a textarea in a browser on your (Windows) screen. Most of the wrapping you see would be because of the width of the textarea box. But after the "entering.", there is actually a return (/n).
Here is the first
paragraph of some
text that I am
entering.
This is the second
paragraph.
When I replace /n with a paragraph tag, the resulting field in my database contains just the text, with a paragraph tag between the word "entering." and before the word "This". The other line wraps are only a function of the width of the textarea box and have nothing to do with the source data, so no paragraph tags are inserted there. This is what I want.
But if you do the data entry on a Mac, using Safari, the result is a newline (that is, a /n) inserted everywhere the text wraps in the text area. The result of this is that my search and replace for newlines inserts a paragraph at the end of every line in the textarea, instead of at the end of every paragraph.
This is not because I'm opening the source data file on a Mac - I say this because in every case the newlines are inserted exactly where the text wraps in the textarea, so it's something to do with the way the browser works on a Mac, or something to do with Safari, or... something.
I can get around this by changing the data - by inserting the tags I want directly into the textarea and skipping the replace, or by inserting an additional newline in the source file and searching and replacing any instance of 2 adjacent newlines with a paragraph tag.
Is there a way to get around this without changing my data?
Our website has a php data entry feature to allow the loading of articles into a database. We are posting a lot of existing data, so we're cut-and-pasting it into a text area to be loaded into a MySQL database.
I'm searching for newlines (/n) in the text in the textarea, and replacing with paragraph tags so the articles display nicely in HTML. The newlines already exist in the source file. Users just select an article to enter, then copy it, and paste it into the textarea on the data entry page.
(NOTE: We are not hitting return inside the textarea, so this is not simply the common problem of Windows and Macs using different control characters for a Return. We are only pasting into the texarea.)
The process works if you use a Windows machine to do the copy-and-pasting. In that case the newlines are replaced with paragraph tags. But on a Mac, newlines are added at every point the text wraps in the textarea box.
For example, imagine that the following is text that you have just entered into a textarea in a browser on your (Windows) screen. Most of the wrapping you see would be because of the width of the textarea box. But after the "entering.", there is actually a return (/n).
Here is the first
paragraph of some
text that I am
entering.
This is the second
paragraph.
When I replace /n with a paragraph tag, the resulting field in my database contains just the text, with a paragraph tag between the word "entering." and before the word "This". The other line wraps are only a function of the width of the textarea box and have nothing to do with the source data, so no paragraph tags are inserted there. This is what I want.
But if you do the data entry on a Mac, using Safari, the result is a newline (that is, a /n) inserted everywhere the text wraps in the text area. The result of this is that my search and replace for newlines inserts a paragraph at the end of every line in the textarea, instead of at the end of every paragraph.
This is not because I'm opening the source data file on a Mac - I say this because in every case the newlines are inserted exactly where the text wraps in the textarea, so it's something to do with the way the browser works on a Mac, or something to do with Safari, or... something.
I can get around this by changing the data - by inserting the tags I want directly into the textarea and skipping the replace, or by inserting an additional newline in the source file and searching and replacing any instance of 2 adjacent newlines with a paragraph tag.
Is there a way to get around this without changing my data?
Could you modify your replacement code so it replaced .\n (a period followed by a new line), then removed all the line breaks? That should keep your paragraphs. (It wouldn't catch line breaks within paragraphs that happened after a period, but it'd get most of them.)
posted by kirkaracha at 7:28 AM on August 24, 2006
posted by kirkaracha at 7:28 AM on August 24, 2006
Best answer: According to the Safari HTML reference, you should be able to use <textarea wrap="soft"> in your HTML to make Safari behave correctly.
posted by mbrubeck at 8:44 AM on August 24, 2006
wrap:I'm not sure why your page is defaulting to the "hard" wrapping behavior...
Not part of the HTML 4.01 standard. Defines the wrap style for a textarea. Can be set to “soft” to wrap without outputting carriage returns to the field, “hard” to wrap with outputting carriage returns, and “off” to not wrap at all.
posted by mbrubeck at 8:44 AM on August 24, 2006
Response by poster: mbrubeck,
Very cool - that sounds like it! I'll test and respond.
kirkaracha,
Not a bad idea - I could extend it by also checking for colons and other possible endings that I'd want to catch - but it would miss cases where the textarea wraps at an abbreviation including a period, and I don't think I could test for that.
bcwinters,
The source file is identical for Mac and Windows users - they retrieve and use the exact same file via ftp. The file was saved by Wordpad in Windows text format. If mbrubeck's idea doesn't do the trick I'll try Firefox.
I'll reply with results at about 8:00 PM EDT tonight.
Thanks all for the ideas.
posted by lockedroomguy at 9:49 AM on August 24, 2006
Very cool - that sounds like it! I'll test and respond.
kirkaracha,
Not a bad idea - I could extend it by also checking for colons and other possible endings that I'd want to catch - but it would miss cases where the textarea wraps at an abbreviation including a period, and I don't think I could test for that.
bcwinters,
The source file is identical for Mac and Windows users - they retrieve and use the exact same file via ftp. The file was saved by Wordpad in Windows text format. If mbrubeck's idea doesn't do the trick I'll try Firefox.
I'll reply with results at about 8:00 PM EDT tonight.
Thanks all for the ideas.
posted by lockedroomguy at 9:49 AM on August 24, 2006
I don't see this at all with a simple test case. And if it were true, every Safari poster to MetaFilter would have screwed up comments (MeFi inserts <br> for every "\n").
Is it possible your documents contain "\r"? I could see how Safari would translate this into a "\n" where other browsers wouldn't. "\r" is the traditional new line character in Classic.
posted by sbutler at 9:55 AM on August 24, 2006
Is it possible your documents contain "\r"? I could see how Safari would translate this into a "\n" where other browsers wouldn't. "\r" is the traditional new line character in Classic.
posted by sbutler at 9:55 AM on August 24, 2006
lockedroomguy, the reason I asked about the text file is that many text editors on Macs have different behaviors when they encounter text files with PC line endings. BBEdit, for instance, maintains the PC style \n while I'm sure there are others that think "hey, this file is for Mac people now! let's use \r instead!"
FTP programs can fiddle with those bits, too, can't they? I feel like old versions of Transmit had a setting for deciding if you wanted text files changed so they had Mac line endings.
posted by bcwinters at 10:21 AM on August 24, 2006
FTP programs can fiddle with those bits, too, can't they? I feel like old versions of Transmit had a setting for deciding if you wanted text files changed so they had Mac line endings.
posted by bcwinters at 10:21 AM on August 24, 2006
the PC style \n
Actually, that's UNIX (and OS X) style. PC is \r\n (CR LF), isn't it? Or has that changed in the last few years too?
Most OS X apps do \n (LF) these days, by default -- certainly any Cocoa app. Many of them will in fact adapt to whatever you've got, or try to. The only holdouts are old Carbon apps.
posted by xil at 11:26 AM on August 24, 2006
Actually, that's UNIX (and OS X) style. PC is \r\n (CR LF), isn't it? Or has that changed in the last few years too?
Most OS X apps do \n (LF) these days, by default -- certainly any Cocoa app. Many of them will in fact adapt to whatever you've got, or try to. The only holdouts are old Carbon apps.
posted by xil at 11:26 AM on August 24, 2006
Response by poster: mbrubeck,
Thanks, it worked! I added wrap="soft" and it solved the problem on Safari without changing the behavior on Windows.
I appreciate everyone's help!
posted by lockedroomguy at 7:03 PM on August 24, 2006
Thanks, it worked! I added wrap="soft" and it solved the problem on Safari without changing the behavior on Windows.
I appreciate everyone's help!
posted by lockedroomguy at 7:03 PM on August 24, 2006
Response by poster: sbutler,
By the way I did a View Source, and it looks like MeFi is using wrap="virtual", which is the same as wrap="soft" - both are not part of the HTML standard, but they both ensure that line endings are not transmitted to the server.
bcwinters,
I wasn't ignoring your line of reasoning, but I was figuring that if the line breaks were only appearing at exactly the point where the text wrapped in the textarea box, then it couldn't be related to any of the linefeeds in the original file.
Thanks again all.
posted by lockedroomguy at 8:38 PM on August 24, 2006
By the way I did a View Source, and it looks like MeFi is using wrap="virtual", which is the same as wrap="soft" - both are not part of the HTML standard, but they both ensure that line endings are not transmitted to the server.
bcwinters,
I wasn't ignoring your line of reasoning, but I was figuring that if the line breaks were only appearing at exactly the point where the text wrapped in the textarea box, then it couldn't be related to any of the linefeeds in the original file.
Thanks again all.
posted by lockedroomguy at 8:38 PM on August 24, 2006
This thread is closed to new comments.
What happens if you make your Mac users use Firefox instead of Safari? You can't test Safari on another platform but you CAN test an alternate browser on the same platform.
posted by bcwinters at 6:20 AM on August 24, 2006