[css-text-4] The `text-spacing: auto` behavior should be made more predictable

[MurakamiShinyu]

To improve typography with CSS, I would encourage people to use text-spacing: auto, because other text-spacing (or text-spacing-trim and text-autospace properties) values such as trim-auto ideograph-alpha ideograph-numeric punctuation will be difficult to learn. However, if the auto behavior varies significantly by UA/platform, it cannot be used with confidence.

The current auto behavior is defined as:

The user agent chooses a set of typographically high quality spacing values. Different user agents running on different platforms may pick different values.

NOTE: These spacing values may or may not match OS platform conventions.

(https://drafts.csswg.org/css-text-4/#valdef-text-spacing-trim-auto, https://drafts.csswg.org/css-text-4/#valdef-text-autospace-auto)

I think we should add descriptions of the recommended auto behavior to make it more predictable. For example:

• The text-spacing-trim: auto behavior should be the same as text-spacing-trim: trim-auto or typographically higher quality defined by UA/platform.

• The text-autospace: auto behavior should be the same as text-autospace: ideograph-alpha ideograph-numeric punctuation or typographically higher quality defined by UA/platform.

[fantasai]

The intention of auto was to align with the platform conventions, whatever they are. So I don't think we can dictate what that is. Is there a reason not to use either normal or an explicit keyword?

[MurakamiShinyu]

The intention of auto was to align with the platform conventions, whatever they are. So I don't think we can dictate what that is.

As far as I know, Apple's platforms (macOS, iOS) have such conventions, but Windows and Linux do not. I understand that Apple's WebKit needs the auto value to align with their platform conventions, which are nearly the same as text-spacing-trim: trim-auto and text-autospace: ideograph-alpha ideograph-numeric, it's OK. But what behavior should be expected on other platforms?

I am concerned about a situation that the auto value only works well on WebKit, and other UAs do not support it or treat it as same as normal.

Is there a reason not to use either normal or an explicit keyword?

The text-spacing-trim's initial value normal is a suboptimal value that is a compromise to avoid negative impact on existing content. I want to recommend to use better settings in most cases. The trim-auto value will be good, but if auto may have higher quality settings, it may be a better choice.

[MurakamiShinyu]

I noticed that the upcoming Chrome release will support the text-spacing-trim property but not support the auto value. The chromium issue https://issues.chromium.org/issues/40275400#comment64 says:

[text-spacing-trim] Enable for stable

Supported values: normal, trim-start, space-all, space-first

I understand that implementors implement only a subset of the spec at first, possibly dropping trim-auto because less necessary if trim-start which is nearly the same is supported (the difference only appears in justified text, which is subtle). But it's a pity that the auto value is not supported. I think the auto should be the same as trim-start if trim-auto is not supported.

WebKit seems to implement the value auto first. The WebKit Bugzilla https://bugs.webkit.org/show_bug.cgi?id=252068 says:

Implement a parser with longhands support for:
text-spacing: auto | none | <text-autospace> || <text-spacing-trim>

text-autospace: auto | no-autospace
text-spacing-trim: auto | space-all

We can then iterate from here adding support for 'normal' in the shorthand and for the remaining values in the longhands.

If WebKit supports auto but not trim-auto and trim-start while Chromium supports trim-start but not auto and trim-auto, (and Firefox may support another subset), it will be difficult for authors to decide which value to use when they want typographically better setting than normal. It will be too bad if authors have to write multiple text-spacing-trim properties for different UAs, e.g.:

html {
  text-spacing-trim: trim-start; /* for Chromium */
  text-spacing-trim: auto;       /* for WebKit   */
  text-spacing-trim: trim-auto;  /* for other    */
}

I am not opposed to the auto value being UA-dependent typographically high quality settings, but I think it is better to have descriptions (maybe as a note) of recommended settings so that implementors can implement it, and authors can use it with confidence. The recommended settings will be like:

• The auto value of text-spacing-trim should be the same as trim-auto (or trim-start if trim-auto is not supported), or typographically higher quality settings defined by UA/platform.

• The auto value of text-autospace should be the same as ideograph-alpha ideograph-numeric punctuation (or ideograph-alpha ideograph-numeric if punctuation is not supported) or typographically higher quality settings defined by UA/platform.

What are the implementers' opinions?
@kojiishi, @litherum, @masayuki-nakano ?

[frivoal]

The text-spacing-trim's initial value normal is a suboptimal value that is a compromise to avoid negative impact on existing content. I want to recommend to use better settings in most cases. The trim-auto value will be good, but if auto may have higher quality settings, it may be a better choice.

I think trim-auto is a good value to recommend to authors for general use. auto is too unpredictable. Now we "just" need everyone one to implement it.

[masayuki-nakano]

In my understanding, auto value is used for platform and/or implementation dependent. And in this case, it's proposed for a pardon of partial implementation. However, implementing the property will change the default layout result even within web pages/apps in the wild. It may break the web if web pages/apps layout in tight spaces, e.g., buttons. So, the property is a risky feature (even though for better Japanese text rendering) and the change should occur only once per browser in the ideal scenario. Therefore, I think the auto keyword is not a proper value for the properties.

[fantasai]

My thoughts on this are:

• The auto value definitely shouldn't be the initial value (and isn't).
• If it's about matching platform conventions, it maybe should be named system-ui or something else more obvious that it's about matching platform conventions or preferences.
• It definitely isn't the core part of the feature, so while supporting only values other than auto is reasonable, supporting only auto is inadequate. Values like trim-auto are important to support.

[litherum]

(Disclaimer: I am an independent observer now)

I think it’s a useful feature even if it isn’t used on websites trying to make their content look like native content. Text already lays out so differently on all platforms and all browsers that I don’t think rigorously defining the feature for interoperability is necessary.

The way I see it, it’s a flag similar to optimizeLegibility or optimizeSpeed, where an author can defer judgement about exactly what operations the browser will do to implement it. It allows an author to say “just make it good, and use your existing (platform) expertise to do so.” Something like “text-autospace: ideograph-alpha ideograph-numeric” doesn’t fit the bill for this use case.