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

> 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 https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1863918994:

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


-- 
GitHub Notification of comment by MurakamiShinyu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9736#issuecomment-1865756168 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 07:30:15 UTC