I suspect we should (re)design text-spacing as if it had several longhands (and possibly add them, in a later extension). One (or 2?) are about line start and end, one about inter character spacing… So, on the short hand, if you specify a value for one of the longhands but not the others, the others go back to their initial value. Not sure we need the longhands now, but we should design so that we can have them.

One oddity of the current value spaces is that some topics have an explicit no-op value, while other are just part of the global none.

• space-start is the no-op of trim-start and space-first
• space-end is the no-op of trim-end and allow-end
• space-adjacent is the no-op of trim-adjacent

but

• ideograph-alpha and ideograph-numeric and punctuation don't have an explicit no-op
• no-compress is the no-op operation, and the "auto" value is implied

So, the implied behavior is:

• if you specify none of space-start, trim-start, or space-first, behave as normal, i.e. space-first
• if you specify none of space-end, allow-end, or trim-end, behave as normal, i.e. trim-end
• if you specify neither space-adjacent nor trim-adjacent, behave as normal, i.e. trim-adjacent

So far so good, and that would map pretty well to longhand-like behavior. But how do we group the rest?

ideograph-alpha and ideograph-numeric probably belong in the same group, and if you specify neither you should get default/normal behavior, which is both of them, not none. So we need a none-like value (which @MurakamiShinyu proposed as no-interscript-space).

I suspect punctuation is a separate group on its own. Since it is default off, we don't have to have an explicit off value, but if everything else does, maybe it should too.

Maybe same thing for no-compress, though I am less sure, it's it's kind of flipped.

This gives the following longhands (maybe exposed to authors, maybe conceptual only):

• text-spacing-start: auto | space-start | trim-start | space-first with initial value space-first
• text-spacing-end: auto | space-end | allow-end | trim-end with initial value trim-end
• text-spacing-adjacent: auto | space-adjacent | trim-adjacent with initial value trim-adjacent
• text-spacing-interscript: auto | no-interscript-space | [ideograph-alpha || ideograph-numeric] with initial value ideograph-alpha ideograph-numeric
• text-spacing-punctionation: auto | no-punctuation | punctuation with initial value no-punctuation
• text-spacing-compression: auto | no-compress with initial value auto

On top of that, we can have the following shorthand:

text-spacing: normal | auto | none |
              no-compress ||
              [space-start | trim-start | space-first] ||
              [space-end | allow-end | trim-end] ||
              [space-adjacent | trim-adjacent] ||
              [no-interscript-space | [ideograph-alpha || ideograph-numeric]] ||
              [no-punctuation | punctuation]

In this set up:

• auto on text-spacing maps to auto on every longhand
• normal on text-spacing sets each longhand to its initial value: space-first, trim-end, trim-adjacent, ideograph-alpha ideograph-numeric, no-punctuation, and auto (on text-spacing-compression)
• none on text-spacing maps to space-start, space-end, space-adjacent, no-interscript-space, no-punctuation, and no-compress on the respective longhands
• When some other combination of values is specified on text-spacing, those that map to a longhand property get set, and other longhands get reset to their initial value.

Possibly with some bikeshedding on the value names, I think this would be a pretty reasonable design.

A few notes:

• I think we should consider shifting no-compress over to text-justify.
• For the various trim/space- values, I'm wondering which combinations of values are actually useful, and if there's need for them to be cascaded independently.
• I'm also a little unsure about how punctuation should fit in.

Note to anyone reading this issue who hasn't seen #4246: I suggest reading #4246 (comment), as that's effectively a continuation of the suggestion above, simplified to cover only the (most) useful combinations.

I believe this has been fixed by the refactoring in #4246. @frivoal please close out if you agree. :)