[css-text][text-spacing] Visual regressions of line-start at portals and news sites

[kojiishi]

The current initial value of the text-spacing-trim property is space-first. This was chosen because the ideal value trim-auto turned out to break novel sites at #2462.

From dogfooding a prototype, the space-first turned out to regresss portal sites and news sites. The regressions were found at MSN Japan and Google News, occuring multiple times a day. Some consider this a minor visual regression, while others consider a critically blocking regression.

To summairze a long Japanese discussion at JLTF:

• Most think trim-auto is the ideal value for body text and headlines. Note, iOS 17/macOS Sonoma applies this style by default to their native controls.
• trim-auto still breaks documents using a style used by some novels, as reported at [css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior #2462, while space-first doesn't.
• For other sites, trim-auto is ideal. space-first is a) less ideal for body text, b) quite strange for headlines, and c) critically regresses headline lists seen in portal top pages, news sites, blog sites, etc. (note the criticalness is controversial, some people consider it's minor in all cases, while others think critically blocking.)

From the feedback so far to the CSS prorotype, Android, and iOS, I think users/authors are particular about:

• Line start >>>> autospace >> adjuscent > line end

At this point, I can't find options other than defining a new value that doesn't trim line-start at all, and make it initial.

/cc @fantasai @frivoal @nt1m @vitorroriz @Clqsin45 @MurakamiShinyu @himorin @kidayasuo

[frivoal]

@kojiishi Thanks for reporting this. Real world experience here is very useful.

At this point, I can't find options other than defining a new value that doesn't trim line-start at all, and make it initial.

I am not sure I follow, as you also said that most people though that trim-auto was the ideal value. Is it because not trimming at all gives results that are more consistent than space-first, even if they're not great?

Maybe we do need a new value, but I wonder how much of this problem we can address using UA stylesheets, for example by setting text-spacing: trim-auto on h1, h2… and maybe also on dt, dd, li… even if the initial value remains space-first?

[nt1m]

@frivoal's idea of augmenting the UA stylesheet to have fine-tuned defaults balancing compat and ideal rendering taken in account seems reasonable to me. Might be hard, but worth experimenting.

[kojiishi]

@frivoal

Is it because not trimming at all gives results that are more consistent than space-first, even if they're not great?

Yes, it's acceptable, though not great. It doesn't change the visual of line-start from without the feature implemented, so no improvements on line-start, but it doesn't regress. In these examples screenshot of space-first (1, 2), a) trimming both open parenthesis at line 1 and line 2 is ideal, b) not triming both is acceptable, and c) trimming only one of them is quite bad, especially for headlines. It's the desired behavior for some styles of novel body text though, and hence space-first is defined so.

Maybe we do need a new value, but I wonder how much of this problem we can address using UA stylesheets, for example by setting text-spacing: trim-auto on h1, h2… and maybe also on dt, dd, li… even if the initial value remains space-first?

Good idea. This is not easy though, as the problem is about web-compat of existing sites, and they use <div> quite often.

• If we were to make trim-auto as the default, Aozorabunko for example uses <div> and <br>.
• If we were to make space-first as the default, MSN Japan, Google News Japan for examples use <div>.

[kojiishi]

I mean, adding UA stylesheet can't help improving the initial value due to web-compat, but adding trim-auto to h1, h2, li, etc. is a great idea.

[kidayasuo]

Thank you @kojiishi for summarizing the discussion on the JLReq TF mailing list.

I agree with @nt1m that @frivoal’s idea is worth pursuing as it can apply the ideal trim-auto on headings and lists while maintaining compatibility.

[kojiishi]

The criticalness of regressions for existing content by changing the initial behavior vary by who you ask, this table shows the "worst - best" personal opinion range for each case from the Japanese discussion:

	trim-auto	space-first	No trimming at line-start
e-Books (incl. sites)	Critical - Better	Matches one of common publishers' styles	Fine (No changes)
Headline lists (portals, news, etc.)	Ideal	Critical - Better	Fine (No changes)
Headings	Fine - Ideal	Regress - Better	Fine - Ideal (No changes)
Lists	Fine - Ideal	Critical - Better	Fine - Ideal (No changes)
Body without first-line indent (common on the web)	Ideal	Regress - Better	Fine (No changes)
Body with space-indented (common in novels)	Ideal	Ideal	Fine (No changes)
Body with text-indented (rare)	Ideal	Regress - Better	Fine (No changes)

The "no trimming" option was more favored decades ago, but I think the trend is gradually moving towards trim-auto.

Kobayashi-sensei said he will give more thoughts on each use cases, so this is preliminary.

[MurakamiShinyu]

Thanks for summarizing the criticalness on each case. I'd like to add my opinion.

I think the "Headline lists" with space-first will be "Regress or Okay" rather than "Critical" and it won't be a show-stopper for us. (As I wrote in the Japanese ML, I feel space-first is better than "No trimming at line-start" in this case, but I understand some people may feel this is a regression.)

Also the "Body with text-indented" with space-first will be "Okay" rather than "Regress". See the example below:

<style>
p { margin: 0; text-indent: 1em; }
</style>
<p>「あいうえお」かきくけこさしすせそ「たちつてとなにぬねの」はひふへほまみむめもやゆよ。</p>

The result of "No trimming at line-start" will be:

　「あいうえお」かきくけこさしすせそ
「たちつてとなにぬねの」はひふへほま
みむめもやゆよ。

And the result of "space-first" will be:

　「あいうえお」かきくけこさしすせそ
｢たちつてとなにぬねの」はひふへほま
みむめもやゆよ。

I feel the result of "space-first" is much better than "No trimming at line-start".

And I think there are more cases where trim-auto will be "Critical" or "Regress". Some web pages with elaborate visual design may use positioning properties for span with fullwidth opening brackets (e.g. <span style="position: …">「</span>) to adjust the spacing or to achieve a hanging opening punctuation effect or some special effect. In such cases, the layout will be broken if trim-auto becomes the default.

[kidayasuo]

Thank you @kojiishi for the summary.

(update: I will take back the following part, as this is the style EBPAJ EPUB 3 File Creation Guide recommends)
One comment. I am not sure if the “Novel” row can be generalized as a novel in general. The text data mentioned in #2462 is created in a specific way to workaround missing functionalities in CSS. To achieve half-width space before the opening bracket in the full-width indentation style, it inserts a full-width space except when the first character of the paragraph is an opening bracket. The first row is representing text data prepared in this specific way.

[kidayasuo]

Related to my previous comment, is there a way to achieve the “one full-width” indentation style? The text-indent property in the Text Module Level 4 does not seem to support it but it might be just my misunderstanding.

[kojiishi]

I feel the result of "space-first" is much better than "No trimming at line-start".

I personally don't agree, the table in #9511 (comment) is to pick up all voices, so updated. It was "the worst case list" but now updated to "the worst - best range list". I hope this looks better.

[kojiishi]

One comment. I am not sure if the “Novel” row can be generalized as a novel in general.

How about e-Books? Or if you have suggestion, that helps. I agree the style sometimes happens in non-novels or non-e-Books sites, but IIUC it's considered "critical" for e-Books sites, no?

[MurakamiShinyu]

@kojiishi

I personally don't agree, the table in #9511 (comment) is to pick up all voices, so updated. It was "the worst case list" but now updated to "the worst - best range list". I hope this looks better.

Thanks! Now this table looks very good and interesting. In my feeling, all "Ok"s in the space-first column will be "Better", as I commented before ("I feel space-first is better than "No trimming at line-start" in this case, but I understand some people may feel this is a regression.").

[kojiishi]

Done.

[kidayasuo]

One comment. I am not sure if the “Novel” row can be generalized as a novel in general.

How about e-Books? Or if you have suggestion, that helps. I agree the style sometimes happens in non-novels or non-e-Books sites, but IIUC it's considered "critical" for e-Books sites, no?

Sorry, I will take back my original comment. As EBPAJ EPUB 3 File Creation Guide recommends using fullwidth character to indent, and removing it when the first character is a fullwidth bracket, I agree it will represent major part of novels.

[frivoal]

is there a way to achieve the “one full-width” indentation style?

The "proper" way (clean separation of content and style) would be:

text-spacing: trim-auto;
text-intent: 1em; /* or 1ic */
hanging-punctuation: first;

browser support for hanging-punctuation is however incomplete, which is why authors that want to use this style commonly use the trick you mentioned:

inserts a full-width space except when the first character of the paragraph is an opening bracket. The first row is representing text data prepared in this specific way.

[frivoal]

I am not sure if the “Novel” row can be generalized as a novel in general. The text data mentioned in #2462 is created in a specific way to workaround missing functionalities in CSS.

My understanding is that the effect achieved by this style is not specific to novels in theory, and could be desired by anyone. However, in practice, many novel EPUBs (and publications of the same content on the web) use this style because they are particular enough to try and work around the historical deficiencies of CSS (so they are prepared according to http://ebpaj.jp/counsel/guide), while other content that use this style is quite rare. But it does happen. Here is an example:

https://www.mofa.go.jp/mofaj/press/kaiken/kaiken6_000123.html

For content prepared in this style, regardless of whether it is a novel or not, applying trim-auto can be a fairly serious problem, as we may not reliably see the start of any paragraph starting with an opening bracket.

[frivoal]

In the table of #9511 (comment), I'd say that for e-Books (incl. sites) + trim-auto, the answer would be:

• "ideal" for new content once hanging-punctuation is supported
• "regression" otherwise

[kojiishi]

@frivoal Thanks for the feedback. In this issue, I think I'd like to focus on how much each value can improve/regress if we change the initial value, so that we can reach a consensus on the initial value. IIUC, your point is about updating the CSS to get the desired results, is that right? It's a great discussion point and I wasn't aware of the need for hanging-punctuation, but I hope this issue focuses on the initial value. Added the clarification to the table "The criticalness of regressions by changing the initial behavior for existing content."

Or if I'm mistaken, and it's relevant for changing the initial value behavior and how it improves/breaks existing content, can you clarify?

[frivoal]

I mentioned this here because @kidayasuo asked, and because I find it relevant to what is / isn't "ideal": once hanging-punctuation is widely supported, all "ideal" layouts can be achieved with auto-trim, but as long as it is missing, space-first used together with U+3000 is needed for some layouts (which are popular in novels). I don't think it changes anything to what we can do with regards to compatibility, but it could be relevant to people's preferences for various options.

[MurakamiShinyu]

@kojiishi
In the "No trimming at line-start" column in the table, I feel they are "Poor" rather than "Fine". So they should be corrected to "Poor - Fine" or "Poor - Ideal".

About "Existing implementations" of space-first, we can take up ebook readers Kindle and Kinoppy. I wrote about these implementations in #2462:

The text-spacing is not yet implemented in web browsers, but some part of this feature is already seen in ebook readers.
I put here two example screenshots (Kindle for PC, and Kinoppy for PC): …

… In the Kindle case, all opening punctuations ("「" and "『") are set half-width at start of lines. On the other hand, in the Kinoppy case, only the opening punctuation ("『") after a soft wrap break is set half-width, and kept full-width at beginning of paragraphs.
While Kinoppy's behavior is a normal Japanese typesetting style, Kindle's behavior is not so. Setting opening punctuation half-width at beginning of a paragraph with no indent is hard to recognized as beginning of a paragraph. I know Japanese publishing people asking Kindle dev to fix it.

That is, at that time (in 2018), Kinoppy already had implemented space-first as the default behavior, and Kindle had implemented trim-auto. And after that, Kindle changed the behavior to space-first.
So now at least Kindle and Kinoppy are existing implementations of space-first.

[kojiishi]

@frivoal Right, agree. The comparison table for "what each value can achieve" is very important for choosing the initial value. We want to choose the initial value that provides the best results in the widest use cases. Your and @kidayasuo's comments are very helpful for that.

Another table is needed for choosing the initial value, to ensure "which value is safe to ship for existing content." With your comment, I started thinking about creating one table that contains both, but that'll likely be very complex, as we'll want to add comments a lot more to all other cells too. As you might agree, so many people have words to say for their favorite styles.

When comparing "valuable" and "safe", I think we want to choose the one that is "the most valuable value within the safe values." If there's a consensus here, it will be 2 step process; filter by safety, then filter by valuableness.

I created this table for the first step, because currently proposed initial value turned out to break portal sites in Japan, and the risk is beyond what our team can ship.

So, to all, I'd like to suggest us to focus on the safety and web-compat first. If we find multiple safe values, we can discuss which value is the most appropriate for the initial value.

[MurakamiShinyu]

I made a test file to compare trim-auto, space-first, and space-start (= no trimming at line-start) values of the text-spacing-trim property.

HTML: text-spacing-trim-space-first-test.html
Source (GitHub Gist): https://gist.github.com/MurakamiShinyu/ea7fdd45e655f97fb64545c444db9099

You can test it with Vivliostyle which fully supports text-spacing-trim current spec.

View with Vivliostyle Viewer: https://vivliostyle.org/viewer/#src=https://gist.github.com/MurakamiShinyu/ea7fdd45e655f97fb64545c444db9099

PDF (created with Vivliostyle CLI): text-spacing-trim-space-first-test.pdf

Screenshots:

[MurakamiShinyu]

I made a twitter poll on preference for default of line-start punctuation handling on CSS text-spacing.
https://twitter.com/MurakamiShinyu/status/1717837335382094127

So far, the most preferred is A (trim at all line-start), the second is C (no trim at line-start), and the least preferred (about 20%) is B (trim at line-start except first line).

Also some people gave comments saying:

I think the default should be A, not for now, but for the broad impact in the future.
Or perhaps we could default to C, which is the same as the current situation. If we wanted to make it better, we could set text-spacing.

I understood that it will be difficult to reach consensus on space-first (trim at line-start except first line) as default. So changing the default to space-start (no trim at line-start) is fine to me.

If we change the line-start default to space-start, we should also change the line-end default because the combination space-start and trim-end would look unbalanced. Just related issue:

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

[chrishtr]

It sounds like we have a possible resolution to this issue, after finding web compat problems with changing the default rendering to trim-auto or space-first. My proposed resolution is:

• Add a new space-start value to text-spacing-trim, which would mean "no trimming at line start for any line", and is the same behavior as Chromium currently has
• Set the default value of text-spacing-trim to space-start allow-end

This will resolve this issue and #9521.

The reason to make this resolution is that:

For space-start:

• Setting the default to trim-auto would have too much web compat risk for Japanese novel sites (which are quite popular in Japan)
• Setting the default to space-first would have too much web compat risk for major Japanese sites like Nikkei and Yahoo Japan
• space-start rendering is an established style for not just the web but also some print cases (e.g. it's the default for Microsoft Word)

For allow-end:

• trim-end would break editing use cases (see [css-text][text-spacing] Propose to make allow-end as the default behavior for the line end #9521) (Note: we could also just remove trim-end, that would also be fine.)