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

@MurakamiShinyu

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.

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

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

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.

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.

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.

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.

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.

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.

[text-spacing-trim] Implement line-end logic

Bug 1874611 [wpt PR 43987] - [text-spacing-trim] Implement line-end l…

Bug 1874611 [wpt PR 43987] - [text-spacing-trim] Implement line-end l…

Bug 1874611 [wpt PR 43987] - [text-spacing-trim] Implement line-end l…

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

fixed in 5b06862.

[text-spacing-trim] Implement line-end logic

Bug 1874611 [wpt PR 43987] - [text-spacing-trim] Implement line-end l…

Navigation Menu

Repository navigation

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

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

frivoal commented on Dec 21, 2023

MurakamiShinyu commented on Dec 21, 2023

frivoal commented on Dec 21, 2023

MurakamiShinyu commented on Dec 21, 2023

frivoal commented on Dec 22, 2023

MurakamiShinyu commented on Dec 22, 2023

5 remaining items

MurakamiShinyu commented on Jan 11, 2024

frivoal commented on Feb 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions