This is a follow up to #9511, where we reworked the value space and initial value of the 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:
trim-auto), except the first linetrim-auto or normal)trim-auto)@MurakamiShinyu 's proposal kept the two first point the same, but changed the third one to:
normal)So, with both the current and proposed definitions, 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 than the first and third, 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3