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

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

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

https://drafts.csswg.org/css-text-4/#text-spacing-property

In the current draft, the `normal` value is defined as:

> Specifies the baseline behavior, equivalent to `space-start allow-end trim-adjacent`.

About the `space-start` value in this definition, I have proposed to change it to `space-first` in the following issue:

- https://github.com/w3c/csswg-drafts/issues/2462

Now, I add one more suggestion: change `allow-end` to `trim-end` in this definition. So the `normal` will be equivalent to `space-first trim-end trim-adjacent`.

I summarize the reason:

- `trim-end` is typographically better than `allow-end` in most cases
- `trim-end` behavior is simpler and needs less overhead than `allow-end`

### `trim-end` is typographically better than `allow-end` in most cases

In justified text, the end of lines should be aligned visually. The `trim-end` is fine for this purpose, and `allow-end` is not very fine because it makes punctuation at end of lines not alined visually.

Of course, there are cases where `allow-end` is preferable. Traditionally, in Japanese and Chinese typesetting, a grid-like arrangement with solid setting (no inter-character spacing) is preferable. The `trim-end` may add extra inter-character spacing when a fullwidth closing punctuation at end of line is trimmed to half-width. So `allow-end` may be better in this case. However, this will be a less usual case in Web, where the number of characters per line is usually not fixed, and the grid-like arrangement doesn't make much sense.

### `trim-end` processing is simpler and needs less overhead than `allow-end`

To implement the default behavior (`normal`), it is important that the processing needs less overhead.

The `trim-end` processing is simpler, because in this mode, fullwidth closing punctuation can be treated as half-width punctuation plus half-width space which is discarded at line end as like a normal space. On the other hand, `allow-end` is not so simple because processing needs to be changed depending on the position of the fullwidth closing punctuation in the line, and the processing overhead is not very small.

This is what I have found in my recent experience implementing the text-spacing property in [Vivliostyle.js](https://github.com/vivliostyle/vivliostyle.js).

----

FYI, a related blog post on Vivliostyle site: [Line end handling has been evolved to allow multiple typesetting options](https://vivliostyle.org/blog/2022/02/08/Improved-of-line-end-handling-and-support-for-page-progression-direction-in-PDF/)


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


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

Received on Tuesday, 15 February 2022 17:24:15 UTC