[css-text] Line-end behavior of text-spacing-trim: space-first

[frivoal]

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:

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

[frivoal]

If we do adopt the change, it would look like this: #9737

[MurakamiShinyu]

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.

Whether this is a downside or not depends on personal preferences.

The allow-end style

 あ（い
 うえ）
 おかき

is often preferred over the trim-end style

 あ（い
 う え ）
 おかき

because it has no extra spacing between letters, even if the line length is not so short.

JLREQ https://www.w3.org/TR/jlreq/#positioning_of_closing_brackets_full_stops_commas_and_middle_dots_at_line_end says

In principle, closing brackets (cl-02), commas (cl-07) or full stops (cl-06) at the line end have half em spacing after them (see Figure 76). This half em spacing can be removed for line adjustment (for more about line adjustment, see § 3.8 Line Adjustment ).

This description seems to match the allow-end behavior.

Major Japanese publishers uses this style and Kindle also supports this as I mentioned in #9511 (comment):

The space-first proposal was made for compatibility with existing contents especially Japanese ebooks. The most popular ebook reader Kindle supports space-first trim-adjacent allow-end (with hanging-punctuation: allow-end) behavior implicitly.

To achieve this popular ebook reader's behavior, the space-first value which implies allow-end would be nice.

[frivoal]

The allow-end style
is often preferred over the trim-end style
because it has no extra spacing between letters, even if the line length is not so short.

I think that corresponds to figure 78 in JLREQ. But in that case, is it not simply a preference for start-alignment over justification? If we use start alignment, the result is exactly the same.

However, if we use justification, even the allow-end style doesn't guarantee no extra spacing between letters, even if the line length is an integer number of ems. Since space-first trims at the start of the line (except the first one), lines which begin with an opening parenthesis will have a non integer number worth of characters on the line, and will expand between the letters if you justify. The same is true for lines with adjacent punctuation getting trimmed in the middle of the line, or being off-grid for any other reason (text-autospace inserting some small gaps, some non CJK content with half-width or proportional characters, a different font size, some inline image…).So, if people don't want the line to expand between letters, they should not be using justification at all, in which case both approaches are equivalent.

But for people who are OK with space between letters being inserted by justification, the trim-end behavior gives more consistently flush edges.

Are there cases where people want justification, and are ok with space being inserted between letters, but only if the off-grid rhythm comes from trimming at the start of the line, or from trimming adjacent punctuation, or from non CJK content, or from using a different font size on part of the line, but not if it comes from trimming punctuation at the end of the line? That seems surprising to me.

This half em spacing can be removed for line adjustment (for more about line adjustment, see § 3.8 Line Adjustment).

This description seems to match the allow-end behavior.

It's not clear to me that it does. In my reading it (and 3.8) look like they're talking of the trim-end behavior: both trim-end and allow-end do remove the half em spacing for line end adjustment. But allow-end excludes a case (line end adjustment due to justification), and I don't see any part of the text discussing that exception. Did I miss something?

In #9511 (comment), talking about space-first with allow-end you said:

I think this setting is good enough for such Japanese contents.

I agree it is good enough: the difference is fairly small, and doesn't matter in many cases, so I will not object if that's the way we want to go. But it seems to me that the behavior with trim-end is the same if you don't want to justify, and a little bit better if you do, without any meaningful downside.

[MurakamiShinyu]

Are there cases where people want justification, and are ok with space being inserted between letters, but only if the off-grid rhythm comes from trimming at the start of the line, or from trimming adjacent punctuation, or from non CJK content, or from using a different font size on part of the line, but not if it comes from trimming punctuation at the end of the line? That seems surprising to me.

I understand your surprise. Once, I thought the same and wrote:

• [css-text-4] text-spacing: trim-end is better than allow-end for the normal value #7055

But now I agree that allow-end is the better default:

• [css-text][text-spacing] Propose to make allow-end as the default behavior for the line end #9521

This half em spacing can be removed for line adjustment (for more about line adjustment, see § 3.8 Line Adjustment).

This description seems to match the allow-end behavior.

It's not clear to me that it does. In my reading it (and 3.8) look like they're talking of the trim-end behavior: both trim-end and allow-end do remove the half em spacing for line end adjustment. But allow-end excludes a case (line end adjustment due to justification), and I don't see any part of the text discussing that exception. Did I miss something?

See §3.8.3 Procedures for Inter-Character Spacing Reduction:

b. The half em spacing after closing brackets (cl-02),commas (cl-07) and full stops (cl-06) at the end of a line, is removed and set solid.

I think this processing corresponds to the allow-end behavior (not to the trim-end). Note that this "spacing reduction" processing does not occur when the half em spacing fits in the line length.

In #9511 (comment), talking about space-first with allow-end you said:

I think this setting is good enough for such Japanese contents.

I agree it is good enough: the difference is fairly small, and doesn't matter in many cases, so I will not object if that's the way we want to go. But it seems to me that the behavior with trim-end is the same if you don't want to justify, and a little bit better if you do, without any meaningful downside.

There will be some downside. The trim-end behavior is less safe than the allow-end on compatibility. Although space-first is no longer the default value, it is still useful to improve existing web pages just adding body { text-spacing: space-first; }. The same problem with #9521 happens. Also the following example:

<p>あああ<span style="display: inline-block">「いいい」</span>ううう</p>

This is displayed as the following currently:

あああ「いいい」ううう

but with the trim-end behavior, this will be:

あああ「いいい｣ううう

Unbalanced.

[frivoal]

Interesting. The problem of trimming at the end of inline-blocks could indeed be a motivation to use the allow-end behavior, but alternatively, maybe this could be a reason to make trim-end smarter. Maybe trim-end should not trim the last character in an inline block, or maybe it should not trim the last character of an inline block if there's only one line.

Editing is more annoying, because we want the layout while editing to be as close as possible to the layout while not editing, so having a condition like "don't trim the last character if the content is editable" helps while you type, but it also means that when you save, the layout may change (only a little, since it's only about the last character, but still). Maybe we can do something more subtle. However, I am not fully convinced by this argument: if the inability to know if you typed the correct full width character, or mistakenly typed a half width character, is a problem, then I'm not sure why it's a problem only at the end of the line. You'd have the same issue when typing （ at the start of the line, or when typing ） then （ in the middle of the line, no? That seems to suggest that while typing, people might either prefer a mode that matches how layout will work when they're not editing (with no particular preference for allow-end), or they might prefer space-all, to make it easier to check every individual character that they are typing.

[MurakamiShinyu]

The problem of trimming at the end of inline-blocks could indeed be a motivation to use the allow-end behavior, but alternatively, maybe this could be a reason to make trim-end smarter. Maybe trim-end should not trim the last character in an inline block, or maybe it should not trim the last character of an inline block if there's only one line.

The problem is not just on inline-block. It affects floating box, absolutely positioned box, etc., with auto width, that contains single line text starting and ending with fullwidth brackets. In such cases, it looks unbalanced if only the closing bracket is trimed while the opening one is spaced. So I think the allow-end behavior matches best with space-first.

[css-meeting-bot]

The CSS Working Group just discussed [css-text] Line-end behavior of text-spacing-trim: space-first, and agreed to the following:

• RESOLVED: The definition of space-first uses allow-end on the end side.

The full IRC log of that discussion

<frances> Alan: Then we have text-spacing-trim
<frances> Florian: implied in this included in the resolution, what should be the line ending behavior of text-space first? Choice between force trimming and allow trimming
<frances> Florian: If we always allow trimming at the end, could be a little strange about left edge and slightly moved right edge. If inline block and force trim the end, with a single line space first, trim and then inline might look weird, possibly floats
<astearns> ack fantasai
<frances> Florian: Special case for inline and special case for floats. Could be improved by force-trimming on the end, will be a compromise. We had resolve to change, need to be deliberate.
<frances> fantasai: Awkward lack of symmetry trimming with forced trimming on any text, any positioning. If space first, allow trimming on the other side.
<fantasai> s/any text/any text that's a single line/
<fantasai> s/any positioning/e.g. abspos, floats, etc./
<frances> Alan: Happy to differ, is this something that we can define and change in the future?
<astearns> s/differ/defer/
<frances> fantasai: possibly shouldn't define it, already making some choice to the initial value, some tweaking that can be done, decide today what can be done.
<frances> Florian: If exceptional handling for floats and inline blocks, might be cases where it is better for force-end, this is safer.
<frances> Alan: The definition of space-first is to allow the style on the end side.
<fantasai> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
<frances> florian: An alternative would be to trim on the end side,.
<frances> Alan: Have not read everything in the issue, should we do anything for the last line?
<astearns> Proposed: The definition of space-first uses allow-end on the end side.
<frances> Alan: did not raise it in GitHub, should we have a separate issue?
<frances> Florian: Could have issues in combat, should we only do it for last line or all of the lines?
<frances> Alan: Any objections?
<astearns> RESOLVED: The definition of space-first uses allow-end on the end side.
<bkardell_> s/combat/compat ?

[frivoal]

I was wondering about whether it would work to do allow-end on the last line, and trim-end on all other lines (if any). This would give us the allow-end behavior on single line elements, which I think deals with the problems @MurakamiShinyu raised about inline-blocks and floats, while also giving better alignment in justified paragraphs.

[MurakamiShinyu]

I was wondering about whether it would work to do allow-end on the last line, and trim-end on all other lines (if any).

Sounds an interesting idea, but it complicates the spec. There is no such Japanese text layout convention and it will be hard to be acceptable. The resolution "space-first uses allow-end" is fine.

[frivoal]

fixed in 5b06862.