Whitespace in Wrapped Form Element

Height of input with white-space:pre-wrap in Firefox Android is bigger than Chrome in Android

It seems you found an interesting bug in Firefox.

A. First of all a suggested(!) solution

SIMPLY: Don't use whitespace: pre-wrap to <input type="date"> or <input type="time">. You still do not need this ... and obviously the browser developer don't expect anyone doing so that that behavior has not been not found yet by the developers.

It is really hard to imagine any reason or scenario why the property whitespace: pre-wrap needed to be used to that element. The date do not flow to next line on its own.

B. The background (the why you asked for)

Elements with included functionality like date-/time-picker have additional hidden inner elements. For <input type="date" the normally not seen structure is as follow:

<div id="input-box-wrapper" class="datetime-input-box-wrapper">
    <span id="edit-wrapper" class="datetime-input-edit-wrapper"></span>
    <button id="reset-button" class="datetime-reset-button"></button>
</div>

// you can see this normally hidden structure in Firefox using the developer tools
// when 'white-space: pre-wrap' is set to the element ...

The CSS for that elements is placed in the browser integrated styles you normally cannot access/overwrite by css/js. Especially it is not possible in Firefox as there is no by the developers intendend way to remove the date/time behavior in Firefox at all.

If you don't want to use the browser integrated mechanic in firefox use a text field and add a date picker extension i.e. by jQuery. (Could be a workarround for you as well!?)

As further information here is the browser integrated CSS for the integrated hidden elements:

// file: datetimebox.css
// you may have a look on them using Firefox dev tools as well

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

@namespace url("http://www.w3.org/1999/xhtml");
@namespace svg url("http://www.w3.org/2000/svg");

.datetimebox {
  display: flex;
  /* TODO: Enable selection once bug 1455893 is fixed */
  user-select: none;
}

.datetime-input-box-wrapper {
  display: inline-flex;
  flex: 1;
  background-color: inherit;
  min-width: 0;
  justify-content: space-between;
  align-items: center;
}

.datetime-input-edit-wrapper {
  overflow: hidden;
  white-space: nowrap;
  flex-grow: 1;
}

.datetime-edit-field {
  display: inline;
  text-align: center;
  padding: 1px 3px;
  border: 0;
  margin: 0;
  ime-mode: disabled;
  outline: none;
}

.datetime-edit-field:not([disabled="true"]):focus {
  background-color: Highlight;
  color: HighlightText;
  outline: none;
}

.datetime-edit-field[disabled="true"],
.datetime-edit-field[readonly="true"] {
  user-select: none;
}

.datetime-reset-button {
  color: inherit;
  fill: currentColor;
  opacity: .5;
  background-color: transparent;
  border: none;
  flex: none;
  padding-inline: 2px;
}

svg|svg.datetime-reset-button-svg {
  pointer-events: none;
}

Bringing all together:

The real problem is the integrated element .datetime-reset-button. Prove it on your own: using white-space: pre-wrap for the input let 'grow' that reset button wrapper element to the however given height. If you now add a display: none (in Firefox direct) in the browser integrated style to that element the behavior of the input the element is removed and the size of the input changes back to normal state.

So, - white-space: pre-wrap changes the behavior for the field and preserves place for sequences of white space (more details: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space). Normal behaviour is, that the property display: inline-flex from the parent element of the reset-button-container let the container flow inline and flow to the next line. If you set white-space: wrap you can see the button in the next line below the input field. (Seeing this seems to be a bug as well.) But with pre-wrap the flow is not longer possible and the button is pressed in the field ... and let grow it higher.

CSS show all whitespace and break word wrap

You need white-space: break-spaces

.readout {
  font-family: "Lucida Console", "Courier New", monospace;
  border: 1px solid;
  padding: 0 0 0 10px;
  margin: 5px;
  font-size: 1em;
  width: calc((1ch + 10px) * 7);  
  letter-spacing:10px;
  white-space: break-spaces;
  word-break: break-all;
}

<div class="readout">hello world     biiiig hi
there</div>

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.

Is it possible to redefine white-space css property in child elements?

Of course you can set white-space: normal for them.

But I'd suggest you to use css:

.block{
    white-space: nowrap;
}
.block li{
    white-space: normal;
}

Also you can use the simpler note:

.block p{
    white-space: nowrap;
}

Note that in my example you should add class block to your root div.

CSS white-space cut the end of the text input value

You gave fixed height 24px for .menu_description_no

try adding:

.menu_description_no {
    background:url(/sigap/web/images/with-shadows/badge-square-cross-24.png) left no-repeat;
    background-color: #bbe0ea;
    min-height: 24px;
    padding: 0px 180px 0px 30px;
    cursor: pointer;
    //border-top-color: #1d384f;
    border-bottom-color: #1d384f;
    color: #284a71;
    font-weight: bold;
    text-align: left;
    white-space:normal;
}

Prevent a white space in the beginning of a input

You can try the RegEx /^\s/ to match white space at the start of the string. Then simply set the input value to blank ('') if the condition is true:

function validate(input){  if(/^\s/.test(input.value))    input.value = '';}

<input id='noWhiteSpaceAtTheStart' oninput="validate(this)" type='text'/>

CSS How to wrap text before last whitespace

Put the dates into span elements with white-space set to pre.

<span style="white-space: pre;">(10/10/1900)</span>

(Note that, if the date is wider than the container's 170px width, it will continue to extend past the box without wrapping.)

---

Related Topics