CSS white-space: pre not working as expected
Instead of white-space: pre
use white-space: pre-line
.
From MDN:
The
white-space
propertyThe
white-space
property is used to describe how whitespace inside
the element is handled.normal Sequences of whitespace are collapsed. Newline characters in the source are handled as other whitespace. Breaks lines as
necessary to fill line boxes.nowrap Collapses whitespace as for
normal
, but suppresses line breaks (text wrapping) within text.pre Sequences of whitespace are preserved. Lines are only broken at newline characters in the source and at
<br>
elements.pre-wrap Sequences of whitespace are preserved. Lines are broken at newline characters, at
<br>
, and as necessary to fill line boxes.pre-line Sequences of whitespace are collapsed. Lines are broken at newline characters, at
<br>
, and as necessary to fill line boxes.
Also, the padding-top
issue you mention isn't really padding. In looking at your code there appears to be at least one line break at the start of the line.
white-space: pre; CSS style does not seem to work according to W3C spec in textarea HTML element - it always wraps, not just on newlines
The textarea
element has always had special implementations with variation across browsers. The original idea in HTML 2.0 was that the user can enter arbitrarily long lines, with horizontal scrollbars provided by the browser as needed, and only line break actually entered by the user would produce new lines. Implementations introduced both “soft” and “hard” wrapping, however, and gradually made “soft” wrapping (lines are wrapped visually but not internally – submitted data still has only user-entered line breaks) the default. The attribute wrap=hard
was introduced as a nonstandard way of getting “hard” wrapping (wrapping also adds actual line breaks to the element’s value), and for quite some time, the nonstandard attribute wrap=off
was the only way to achieve the behavior that was then standard!
HTML 4 then partly retrofitted the specification to implementations; it says: “Users should be able to enter longer lines than [the value of the cols
attribute], so user agents should provide some means to scroll through the contents of the control when the contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible without the need for scrolling.” It does not define any way for authors to specify whether “soft” wrapping takes place (or to ask for “hard” wrapping).
In HTML5 drafts, as noted, there is the wrap
attribute, but with only two conforming values hard
and soft
, and the latter really means “no hard wrapping” – the text may or may not visually wrap, and this is apparently left to be handled in CSS. There is some logic here, since the attribute is now for functional control only (whether wrapping causes line breaks to be added to the actual value).
But although wrap=off
is declared nonconforming (forbidden, obsolete), the HTML5 drafts describe its effect. As noted here in comments, the description is in the “Rendering” section and as “suggested rendering” and as affecting via CSS. This means that the drafts do not require browsers to support wrap=off
, just “expects” it, and only as part of the CSS cascade, i.e. only when CSS is enabled and there is no CSS rule that overrides it.
Thus, although wrap=off
works well and there is little reason to expect it to stop working, it is not conforming and it is not “guaranteed” to work (i.e., HTML5 drafts do not impose a requirement on browsers).
The varying support to white-space
for textarea
in browsers makes it an unreliable tool here.
As a workaround, you might consider creating a simulation of textarea
with an editable block, e.g. with
<div class=textarea contenteditable=true>...</div>
and CSS code like
.textarea {
font-family: Consolas, monospace;
white-space: pre;
word-wrap: normal;
padding: 0.1em 0.3em;
border: solid thin;
overflow: auto;
width: 25em; /* fallback for browsers not supporting ch */
width: 60ch;
}
And if the data is to be submitted as part of form data, you would need to copy it to a hidden field before submission.
This would work reasonably (even old versions of IE support contenteditable
), except that it is too powerful: browsers typically let users enter “rich text” in an editable element. Moreover, they tend to generate markup (tags) like <br>
rather than newline chaacters when the user hits Enter, so your JavaScript code would need to do some cleanup to turn the content to plain text.
So the workaround isn’t particularly good, but it’s probably the best approach if you need to conform to HTML5 drafts and still get the functionality.
White-space:pre-wrap not aligned on first line
Remove the space...
Change
<p class="test"> This
to
<p class="test">This
p.test {
width: 11em;
border: 1px solid #000000;
word-wrap: break-word;
white-space: pre-wrap;
}
<p class="test">This paragraph contains a very long word: thisisaveryveryveryveryveryverylongword. The long word will break and wrap to the next line.</p>
Related Topics
How to Make an Input Element Occupy All Remaining Horizontal Space
Why Does Width Apply to a Button with Display Inline
How to Have HTML Text or Cdata Inside an Xml Attribute
Cross-Browser Embedded Font in Svg Image
Border with a Transparent Centred Arrow
If an HTML Form Has Two <Input Type="Submit"> Buttons, How to Know Which Got Clicked
Why Is "" Being Injected into My HTML
How to Use the Same Meta Tag for Opengraph and Schema.Org
Failed to Load Resource, Plugin Handled Load on iOS
Different CSS for Each Browser
Table Headers Position:Sticky and Border Issue
How to Move an Element That's on the Top to the Bottom in Responsive Design
Unwanted Auto-Scrolling to Top on Input Focus, with Safari