I have a textarea. When I paste text with line breaks into it, the line breaks are automatically removed. But when I manually enter line breaks (hitting carraige return), they are preserved.
How do I force the textarea to preserve line breaks with pasted text?
Don't know if this applies to all browsers, but in Google Chrome (6 and 7), line breaks in pasted text gets removed if the textarea's style is set to white-space: nowrap;.
I used this style setting to prevent the default wrapping of long lines and experienced the same problem as yours. Later I realized that setting the textarea attribute wrap to off does a much better job. Be aware that wrap="off" is widely supported but not standardized.
The line breaks are always preserved when pasted on textarea.
Maybe the source have a different line break, you are copying from what program?
Related
A colleague had a text alignment issue on a screen I completed. I was shown the issue on a Win10 PC using Chrome, and some lines of text appeared like this:
Text line 1.
Text line 2 is much longer and wraps to two lines, but the second line
does not have the whitespace added.
Text line 3 does not wrap, and has the same alignment issue.
When I viewed it on my Mac using Chrome, I did not see the issue, so I ingeniously deduced it was most likely a Win-Chrome bug with some bootstrap class, etc.
But, after digging in, the problem ended up being the format of the <p> tag content:
<p>Text line 1.</p>
<p>
Text line 2 is much longer and wraps to two lines, but the second line does not have the whitespace added.
</p>
<p>
Text line 3 does not wrap, and has the whitespace.
</p>
I'm aware that a newline in the middle of a string will infer a space in most browsers (thank god), so that you don't have to add a trailing / leading space when writing multi-line content. However, I've never seen the initial return cause leading whitespace.
The point is that there may be a lot of code formatted this way, and the client will spot the alignment issues, as they test in Win10. Why does this happen, and is it most likely a Win/Chrome bug? Is it a conscious choice by some browser developers?
References would be greatly appreciated, but I personally could not find anything relevant on SO, CSS-Tricks, or Chrome browser documentation.
EDIT:
Another colleague has confirmed that adding a <br /> within the <p> tag (no trailing / leading spaces) also generates a single leading whitespace directly afterwards.
white-space: pre-wrap preserves whitespace, so on word wrap it will not add the extra space since its located at the start of the paragraph.
either try white-space: none; or add some padding/margin if you want the whole paragraph to have that extra space even after word wrapping.
The following snippet renders (assuming) correctly without trailing space underlined in Firefox 59, but in Chromium 65 the bogus space in the end of the line before the explicit line break is rendered:
<div style="width:100px">
This is long link, <br />with a line break
</div>
Screenshot from Chromium 65:
Screenshot from Firefox 59:
The obvious fix for this case is to remove the space in front of the line break, but it is unnatural.
Is not one of the rendering wrong? Is either of the behavior specified by HTML or CSS specification or is this really undefined?
Edit 1: The same behavior as in Firefox can be observed also in the IE, so it looks like the Chromium is the only one.
The problem isn't that Chrome is underlining the trailing space while Firefox isn't. The problem is that Chrome isn't removing the trailing space when wrapping the line (when the wrap originates from a hard <br /> wrap). The space is underlined because it is there, which is inconsistent with how Chrome handles trailing spaces when auto-wrapping text.
The CSS specification on handling trailing spaces on wrapped text states:
4.1.3. Phase II: Trimming and Positioning
As each line is laid out,
A sequence of collapsible spaces at the beginning of a line is removed.
If the tab size is zero, tabs are not rendered. Otherwise, each tab is rendered as a horizontal shift that lines up the start edge of the next glyph with the next tab stop. Tab stops occur at points that are multiples of the tab size from the block’s starting content edge. The tab size is given by the tab-size property.
A sequence of collapsible spaces at the end of a line is removed.
If spaces or tabs at the end of a line are non-collapsible but have white-space set to pre-wrap the UA must either hang the white space or visually collapse the character advance widths of any overflowing spaces such that they don’t take up space in the line. However, if overflow-wrap is set to break-spaces, collapsing their advance width is not allowed, as this would prevent the preserved spaces from wrapping.
The CSS Working Group has discussed the inconsistent handling of trailing white-space on their github repo, specifically mentioning that Firefox's handling of trailing whitespace is the most ideal:
And lastly there's the point that trailing spaces just look bad, and that having a space just inside the closing tag of an inline or before a <br> is a reasonably common unintentional markup pattern that shouldn't have a bad effect on rendering. The preserved trailing space becomes noticeable both when the inline is styled, as in the example given by #palemieux, and also when we chose text alignments other than start. This gives a real-world use case indicating a preference for Firefox's behavior.
From this discussion, the earlier mentioned CSS spec has been updated (in the github repo, but not apparently published yet) to match the Firefox (Gecko) behavior. Specifically updating points 1 and 3 from above to :
A sequence of collapsible spaces at the beginning of a line (ignoring any intervening inline box boundaries) is removed.
A sequence of collapsible spaces at the end of a line (ignoring any intervening inline box boundaries) is removed.
Emphasis on changes added by me.
If we check the specification we can read this:
Underlines, overlines, and line-throughs are applied only to text
(including white space, letter spacing, and word spacing): margins,
borders, and padding are skipped.
I have an HTML textarea with a "placeholder" attribute that includes the code for a line break, &\#10;. It works fine on Chrome, but the line break is ignored on other browsers. What is causing this inconsistency, and how do I work around it?
Include the line break naturally with the keyboard enter? Like it is shown in this image, click to see it.
If it does not work, try inserting your place holder text via javascript?
See Insert line break inside placeholder attribute of a textarea?
I am trying to enable manual line breaks in <td> tag in HTML.
Content is coming from a file which consists of ENTER or manual line breaks, but while displaying this data in HTML table, data is being displayed continuously. Means it is ignoring manual line breaks.
Is there any way to make <td> tag to consider manual line breaks or ENTER you can say?
For example:
Text coming from DataBase:
Line 1.
Line 2.
Line 3.
(with ENTER after each line)
Data displayed in table cell:
Line 1.Line 2.Line 3.
(not considering ENTER after each line)
Tried different ways but failed. Please suggest some solution.
Please try this
str = str.replace(/(?:\r\n|\r|\n)/g, '<br />');
this will covert all enter key pressed to line break
OR
You can use 'pre' tag.
Reference
The best solution is to put your text inside a span tag with white-space: pre-wrap style, and even more if you are working with Bootstrap (where pre tag is styled).
CSS white-space Property (relevant) options:
pre: Whitespace is preserved by the browser. Text will only wrap on line breaks. Acts like the tag in HTML.
pre-line: Sequences of whitespace will collapse into a single whitespace. Text will wrap when necessary, and on line breaks.
pre-wrap: Whitespace is preserved by the browser. Text will wrap when necessary, and on line breaks.
It seems that IE starting from IE7 to IE10 wraps text in the textarea control incorrectly when using \n (or \r\n - doesn't matter - results are the same). Is this a bug in IE or they treat the html standard differently than other browsers - who is right? I have defined:
<textarea id="TextArea1" runat="server" style="width: 190px; height: 390px; white-space: normal; word-wrap: normal; overflow: scroll" ></textarea>
When I try to add long string like "VeryLongStringEndingWithNewLine\n" by using JavaScript code (obj.value += text;) the text is shown in one line with scroll (this is ok) but added with an additional empty line (\r\n) - why?
When I try to add short string like "Short\n" multiple times, again via JavaScript code the text is on the same line (should be on the separate lines because normal wrapping should be applied).
Moreover when I do postback then all \r\n's are replaced with spaces (why?) and then text parsed correctly (assuming if I used spaces instead of crlf normal wraping with space only wraps when does not fit in the area).
When using FF or Chrome same control behaves correctly - long lines are shown without an additional empty next line, short lines are on the different lines, no replacement with spaces when doing postback.
I know I could probably use other options or white space characters, but I feel that above is not correct about IE. Any comments?
Under normal circumstances, textareas treat whitespace literally and wrap as needed.
But because you're overriding it with CSS, the result is potentially unstable.
In this case, whitespace (\n) is collapsing to a single space, since that's what white-space:normal does.
I'm not entirely sure what you're trying to achieve here, since I'm fairly sure the default behaviour for textareas is perfectly fine. If you don't want that behaviour, you shouldn't be using a textarea.