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

Since we resolved on to take option 1 [1], here is a pull request:

https://github.com/w3c/csswg-drafts/pull/49

 - Florian

[1] https://lists.w3.org/Archives/Public/www-style/2015Sep/0040.html


> On 10 Jun 2015, at 18:57, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 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 Friday, 11 September 2015 08:41:24 UTC