[css-text-4] variants of pre-wrap and longhands of the white-space property

At the New York F2F we resolved to add pre-wrap-auto to the white-space
property in level 3, and pre-wrap-trim to the same property in level 4 [1].

Adding pre-wrap-auto to level 3 isn't a big issue (I've sent a Pull
Request for it[2]).

However, in level 4, the white-space property becomes a shorthand to
text-space-collapse and text-wrap. Maybe text-space-trim is also part of this,
the spec isn't clear.

The question of how pre-wrap-auto and pre-wrap-trim get expressed in terms of
these two properties hasn't been discussed, and it isn't entirely obvious,
since these value arguably affect both collapsing and wrapping.

Here's how I think it could work, but I'd like feedback:

=== Option #1
white-space: pre-wrap-auto;
=>
text-space-collapse: preserve-auto;
text-wrap: normal;

As defined in my level 3 PR for pre-wrap-auto, preserve-auto is the same as
preserve, with 2 differences:
 a - The UA *may* visually collapse the advance widths of preserved white space
 that occur at the end of a line.

 b - Whether or not there are soft wrap opportunities in preserved sequences of
 white space, and if yes where and under what condition, is up to the UA

white-space: pre-wrap-trim;
=>
text-space-collapse: preserve-trim;
text-wrap: normal;

Similarly, preserve-trim is the same as preserve, with 1 difference:
 a' - The UA *must* visually collapse to 0 the advance widths of all preserved
 white space that occur at the end of a line.

=== Option #2
An alternative would be to leave text-space-collapse as it is, and work
through the text-wrap property, maybe along these lines:
text-wrap: auto | [ normal | nowrap | blanace ] trim?
or maybe
text-wrap: auto | [ [ normal | nowrap ] trim? ] | blanace 

Here as well, ''auto'' gives you (a) and (b) as defined above, while ''trim''
gets you (a').

This has some intuitive appeal to me as this property seems to be at the right
stage of the whitespace processing pipeline. However ''auto'' and ''trim''
would have no effect when 'text-space-collapse' is anything other than
''preserve''. Not sure if that matters.

=== Option #3
Finally, If we consider that text-space-trim is also part of the white-space
shorthand, using it to express point (a) / (a') of the two definitions above may
also be an option, but I don't think this is actually a good idea.
text-space-trim is currently defined in terms of its effects at the beginning and
end of the block, and therefore has no knowledge of lines. Also, text-space-trim
actually discards whitespace, rather than reduce their advance width, which has
different (and in this case undesirable) effects in the case of editable text.
It really feels that this property affects an earlier step in the pipeline, and
would be the wrong tool for the job.

Thoughts?

 - Florian

[1] https://lists.w3.org/Archives/Public/www-style/2015May/0281.html
[2] https://github.com/w3c/csswg-drafts/pull/27

Received on Wednesday, 10 June 2015 09:58:25 UTC