- From: Shinyu Murakami via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Dec 2023 07:30:13 +0000
- To: public-css-archive@w3.org
> 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