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

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. 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. 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.

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.

=== 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.

=== 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 &nbsp; 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 &nbsp;. 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 &nbsp; 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 &nbsp; 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 &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.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.