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

> On 10 Mar 2015, at 02:51, Robert O'Callahan <robert@ocallahan.org> wrote:
> 
>> On Tue, Mar 10, 2015 at 12:34 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> === 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.
> 
> If we were to change the behavior, we'd have to agree on what exactly the new behavior is, and that need to describe not just for how far you can scroll, but where the caret is positioned, what DOM geometry APIs return and where the backgrounds of spans are drawn.

Agreed.

> Currently in Chrome if you type a lot of spaces into a <textarea> you end up at the right-hand edge and nothing seems to happen as you type more spaces. It appears they're not just limiting the scrollable area, but also adjusting the caret position and span geometries.

Agreed.

> That seems odd to me, and confusing for users --- there's no way to tell if you're actually entering spaces or nothing is happening.

While I initially found it odd as well, if you try the same thing in MS word or Libreoffice or Apple Pages or Apple TextEdit, the same thing happens. Now, we don't have to imitate other software if they are lousy, but it is notable that they all do the same here.

Personally as long as you're not wrapping the collapsed space, I like the Firefox / IE / spec behavior just fine. However, the way Chrome & Safari deviate from the spec seems to be a careful match of the traditional word processor model rather than a random accident. Anyone from webkit or blink wants to chime in? If webkit & blink are happy to change to match the current spec, I'm all for putting this issue to rest, but if not I'd rather get interop, and if there's a strong argument for the webkit/blink behavior...

> Chrome also has the odd behavior that if any of the first space in a run of spaces partially fits at the end of the line, then all the spaces are truncated, but if the first space doesn't fit at all at the end of the line, all the spaces wrap to the next line. And apparently if the left edge of the first space is exactly at the element's right content-edge, the entire set of spaces is truncated.

That's definitely a webkit/blink peculiarity that isn't paralleled in word processors. My guess would be that this is an edge case falling out of how it is implemented, rather than intentional part of the behavior, but I don't actually know.

>> === 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...)
> 
> In Firefox this happens because <textarea> has word-wrap:break-word in the UA style sheet. Given that, I think our behavior is correct per spec.

Sorry I missed this, I should definitely have checked for that. Firefox (and IE) are indeed spec compliant here, once you take word-wrap into account.

But now that I have noticed and looked closer, it turns out that this behavior isn't exactly the same as the one you'd expect from traditional plain text editors. Given
"a  b  c" (spaces are doubled) and a box that can fit 4 characters, you get:
|a   |
|b  c|
This makes sense given the processing model, but a more traditional behavior would be
|a  b|
|  c |

Similarly, with "a b   c" (3 spaces after b)  and a box that can fit 4 characters, you get:
|a   |
|b   |
|c   |
rather than 
|a b |
|  c |

A simple way to describe the "correct" behavior would be for every space in a non collapsed white space run to be rendered as an &nbsp; preceded and followed by zero-width-spaces (U+200B).

Granted, the "white-space:pre-wrap;word-wrap:break-word" behavior isn't that far off in many cases, but it's still not quite as nice.

>> === Problem number 3
>> 
>> 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 &nbsp; 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.
> 
> I think this makes sense if the HTML editing spec encourages authors to use word-wrap:break-word in conjunction with white-space:pre-wrap.

It doesn't, and I agree that if we keep things as they are, it probably should. But as I said above, I don't think that the "white-space:pre-wrap;word-wrap:break-word" behavior  is quite as nice as the ideal white-space:preserve-and-really-wrap should be.

 - Florian

Received on Tuesday, 10 March 2015 20:40:07 UTC