[csswg-drafts] [css-text] Line-end behavior of text-spacing-trim: space-first (#9736)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text] Line-end behavior of text-spacing-trim: space-first ==
This is a follow up to #9511, where we reworked the value space and initial value of the [`text-spacing-trim` property](https://drafts.csswg.org/css-text-4/#text-spacing-trim-property) to be `space-all | normal | trim-auto | trim-start | space-first | trim-all | auto`

I have made all the changes that we had discussed in the spec, except one. In #9511, we resolved to adapt @MurakamiShinyu 's proposal, but in addition to the various aspect of this proposal on which we had explicit agreement, there is one aspect which barely got discussed in GitHub and not at all during the call, and which is a change from the current spec.

This issue is to determine whether we want to adopt that too, or if we want to keep that aspect of the spec unchanged.

Currently, the spec defines that `space-first` value:
* trims at the start of lines (like `trim-auto`), except the first line 
* trims adjacent pairs (like `trim-auto` or `normal`)
* trims at the end of lines (like `trim-auto`)

@MurakamiShinyu 's proposal kept the two first point the same, but changed the third one to:
* trims at the end of lines **if it would not otherwise fit prior to justification** (like `normal`)

So, with both the current and proposed defitions, when rendered with a line length of 3em, `あいう（えお）かきく` will result in:
>  あいう 
>（えお）
>  かきく

Note that both the start and end edges are flush, as the opening and closing parentheses on the second line get trimmed, enabling them to fit in the line where they otherwise couldn't, due to their blank halves.

Also, in both cases, when rendered with a line length of 3em, `あ（いうえ）おかき` will result in:
>  あ（い 
>  うえ）
>  おかき

The second line is shorter, but this is unavoidable, as nothing else could fit, regardless of whether you trim the closing parenthesis or not.

However, the difference appears if we justify the previous example. With @MurakamiShinyu 's proposal, nothing changes, but the current spec would lead to:
>  あ（い 
>  う え ）
>  おかき

Note that the second line has been stretched by justification, and its end-edge aligns with the first and third. If we adopt the proposal, it would no longer do that, because the closing parenthesis on the second line would not get trimmed, since the “if it would not otherwise fit prior to justification” condition is not met, and therefore its blank right-half takes space at the end of the line.

The upside of this proposed change, is that it is less of a change from the legacy value of `space-all`, and therefore is likely to cause less compatibility issues, while still bringing some improvements over `space-all`: it does do trimming of adjacent pairs in the middle of the line (not shown in the examples above), trims the start end of non-first lines, and trims at the end of the line *some of the time*.

The downside of this proposed change is that it is less of an improvement over the legacy value of `space-all` than what it is currently specified, as it will continue to force ragged right-edges when justifying, in some situations where it could have been avoided.

Personally, I would prefer to keep the spec as it is, to get the typographically better behavior, because I am skeptical that the difference will actually matter in terms of compatibility. It seems to me that any content which could have an issue with that (which I believe to be rare already) would not be content where you'd chose to apply `space-first` and justification in the first place.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9736 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 21 December 2023 04:57:28 UTC