CSS White-Space: Pre Not Working as Expected

CSS white-space: pre not working as expected

Instead of white-space: pre use white-space: pre-line.

From MDN:

The white-space
property

The 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



Leave a reply



Submit