[csswg-drafts] [css-text-4] Split text-spacing-trim into different values (#13789)

r12a has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text-4] Split text-spacing-trim into different values ==
The current definition of text-spacing-trim is hard for content authors to get their head around, because each value affects several aspects of text-spacing at a time.  There may also be combinations that authors want to apply that can't be done.  The current definition is:

```
text-spacing-trim: auto | 
        [ normal | trim-both | trim-start | space-first | trim-all | space-all]
```

Each keyword has an effect on:
1. the width of a paragraph-initial punctuation
2. the width of punctuation internal to a paragraph that is wrapped to the start of a line
3. the width of punctuation alongside other punctuation marks
4. the width of punctuation at the end of a line

I think `text-spacing-trim` would be much more intuitive and easy to use if each of those four behaviours could be handled separately.  For example, the keyword `trim-start` could be written:

`text-spacing-trim: trim-initial trim-line-start  trim-sequence allow-end-trim;`

while `trim-both` would be 

`text-spacing-trim: trim-initial trim-line-start trim-sequence trim-end;`

and `space-first` would be 

`text-spacing-trim: trim-line-start trim-sequence allow-end-trim;`

It would probably be ok to retain the trim-all and space-all keywords as an alternative to the lists.

This would give content authors more control over the way the text is styled, and make it easier for them to remember which keywords to choose.  For example, they would be able, if they wanted to style the content so that brackets are not reduced at paragraph-start or line-end, but are reduced for sequences of punctuation, using:

`text-spacing-trim: trim-sequence;`

Currently uptake by browsers of text-spacing-trim is very low and patchy, so this is unlikely to be a major breaking change if we discarded the current keywords, but i suppose that we could also keep those as alternatives if needed. (See the **early draft in development** at https://w3c.github.io/i18n-drafts/articles/styling/inline-space.en.html for more information.)

Another possibility would be to pull out the handling of width reduction in sequences of punctuation into a completely separate property, since it's not really the same as the other behaviour, because it's not related to position in lines in the same way as the other values.

Sorry to be late to advance these ideas, but to be honest, i didn't have sufficient time to pick apart and understand the complexity of what is currently specced until now (part of the reason i wrote the article).


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13789 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 10 April 2026 08:33:51 UTC