[css-text] pre-wrap and white space processing

TL;DR: there is not full interop on what happens to longer-than-the-line sequences of white space under "white-space: pre-wrap", nor is it obvious that there is a single desirable behavior. There's probably 2, both different from what the spec currently says, and I want a switch.

=== Intro
"white-space:pre-wrap;" (or equivalently with level 4 properties "text-space-collapse: preserve; text-wrap: normal;") prevents runs of white space from being collapsed into a single space character. It does so based on the white space processing rules (http://dev.w3.org/csswg/css-text-3/#white-space-rules), which state:

  If white-space is set to pre-wrap,
  any sequence of spaces is treated
  as a sequence of non-breaking spaces.
  However, a soft wrap opportunity
  exists at the end of the sequence.

While this generally works, one effect is that a sequence of white space longer than the line will overflow the line, rather than wrap.

=== Problem number 1:
Chrome & Safari do something slightly different. Compare this in IE/Firefox vs Chrome/Safari:
http://jsbin.com/hakalu/1/watch?html,css,output

All agree that the long sequence of white space should not wrap to the next line. However, only IE & Firefox do what the spec say and let the line overflow. Chrome & Safari truncate excess white space instead of overflowing.

While this seems to be a spec violation, it matches the behavior of traditional word processors / rich text editors like MS Word, Apple TextEdit (in rich text mode), LibreOffice, KWrite, Kate... So I wouldn't be to quick to call it a bug.

=== Problem number 2
While Chrome/Safari follow the same behavior on a div with "white-space:pre-wrap" and a text-area with "white-space:pre-wrap", Firefox and IE don't:

http://jsbin.com/zulote/1/watch?html,css,output

Here, Firefox and IE behave differently in the textarea, electing to wrap the excess spaces to the following line. While this also seems to be in disagreement with the spec, it does match another set of traditional software: plain text editors (vim, emacs, notepad, sublime...)

=== Problem number 3
If users press space multiple times in a row in a contenteditable area, it would be most unexpected if these spaces collapsed, even under "white-space:normal". To work around that, html editing requires that UAs to create a hodgepodge mix of spaces and   to guarantee both that they will not collapse and they will wrap, giving an approximation of what Firefox and IE do in a textarea with "white-space:pre-wrap". I strongly recommend reading the note about this in the spec:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#canonical-space-sequences

As far as I can tell, This is mostly what happens (other than IE which collapses the original spaces and insert the user's spaces as  . This and other minor implementation differences between other browsers is out of scope for this discussion about pre-wrap).

When a contenteditable area is under white-space:pre-wrap, this workaround based on   and spaces is disabled. I cannot quite figure out what IE does (so I'll claim it's just a bug), but everyone else seems to comply, which brings us back to a long sequence of   which don't collapse but also don't wrap, even when the user keeps inputting additional spaces.

http://jsbin.com/hivete/3/watch?html,css,output

However, the note in html editing seems to expect that pre-wrap would cause them to wrap, as they do in a text-area in firefox and IE. The whole reason it introduces the   and space mix is so that spaces wouldn't collapse but still wrap, and then it encourages authors to "opt-out of the insanity" by using pre-wrap, which won't do what html editing says it will.

=== Conclusion
For runs of spaces longer than a line, we have several behaviors, all called "pre-wrap":

1 - Don't collapse but do wrap, like Firefox & IE in textareas. Similar to plain text editors.

2 - Don't collapse, don't wrap, and truncate, like Chrome & Safari. Similar to rich text editors.

3 - Don't collapse, don't wrap, and overflow. Firefox & IE on regular elements (not textareas). Conforming to the css-text spec, but without equivalent (afaict) outside of the web platform.

Even though it is a fairly natural way to spec things, I am not so convinced behavior 3 is at all desirable. However, both 1 and 2 are; at least when the content can be edited by the user. I suggest we spec both and introduce a switch, so that depending on their application, authors can choose between the plain text editor or the rich text editor behaviors.

The switch could be an additional value to the white-space property, with pre-wrap being the chrome/safari behavior, and the new value being the firefox/IE behavior on textareas. Alternatively, it could be accessible only through a new value of text-space-collapse or of text-wrap, or even a new property if we think both behaviors should still be called white-space:pre-wrap.

 - Florian

Received on Monday, 9 March 2015 23:34:26 UTC