Hi @SebastianZ , I don't mind bikeshedding the syntax of each property, but we can't move values around. The only reason there are two properties here rather than just one is that one set of values needs to inherit while the other one must not. :)

Let me know if you still think there should be some changes here.

Right, little detail, big difference. So that's the reason for trim-inner.

Though I'm still not happy with the naming of the value. I believe all values of text-space-trim should have similar names, either all with the prefix trim- or all with discard- (following text-space-collapse's wording).

But the values were not the only thing of this proposal. What about the renaming? discard doesn't fit perfectly to text-space-collapse, which only indicates collapsing, not completely discarding. And as white-space is meant to be a shorthand for them, they should rather have that as prefix. Also, "white space" is a known expression while "text space" sounds a bit odd.

Last point, my proposal included a keyword discard for text-space-trim combining discard-before and discard-after, as that's probably more common than only applying it to one side.
(It also included other keywords for how to handle white space around an element, though I guess there are no real use cases for them.)

Sebastian

I believe all values of text-space-trim should have similar names, either all with the prefix trim- or all with discard- (following text-space-collapse's wording).

Fair point. :) Leaning towards discard- to match the text-space-collapse value, anything else to consider?

What about the renaming? discard doesn't fit perfectly to text-space-collapse, which only indicates collapsing, not completely discarding.

If we end up preserving the line-breaking opportunities, then it's a type of collapsing really. Note that newlines collapse to nothing in CJK contexts, for example. Also I don't have a better name.

As white-space is meant to be a shorthand for them, they should rather have that as prefix.

There was some historical issue about not having the same name as an XSL:FO property. If that's no longer relevant, we could use white-space-collapse, sure.

Last point, my proposal included a keyword discard for text-space-trim combining discard-before and discard-after, as that's probably more common than only applying it to one side.

Actually one of the major use cases was inline notes like footnotes, which would warrant discard-before. E.g. suppose we had this markup: Here's a word <note>This is a note on the word.</note> in a sentence. If the note stays inline, we add parentheses and leave it with the white space. But if layout mechanism that pulls the note out of flow and leaves behind a marker, we want to delete the space between “word” and that marker -- but not the space after. I suppose we could add a discard-around keyword, though. What are the use cases you had in mind?

I believe all values of text-space-trim should have similar names, either all with the prefix trim- or all with discard- (following text-space-collapse's wording).

Fair point. :) Leaning towards discard- to match the text-space-collapse value, anything else to consider?

Then we agree on this. Nothing else to consider.

What about the renaming? discard doesn't fit perfectly to text-space-collapse, which only indicates collapsing, not completely discarding.

If we end up preserving the line-breaking opportunities, then it's a type of collapsing really. Note that newlines collapse to nothing in CJK contexts, for example. Also I don't have a better name.

What about white-space-inside or one of the other names I proposed in my initial comment?

As white-space is meant to be a shorthand for them, they should rather have that as prefix.

There was some historical issue about not having the same name as an XSL:FO property. If that's no longer relevant, we could use white-space-collapse, sure.

What was that issue exactly? And who could answer whether that's still a problem?

Last point, my proposal included a keyword discard for text-space-trim combining discard-before and discard-after, as that's probably more common than only applying it to one side.

Actually one of the major use cases was inline notes like footnotes, which would warrant discard-before. E.g. suppose we had this markup: Here's a word <note>This is a note on the word.</note> in a sentence. If the note stays inline, we add parentheses and leave it with the white space. But if layout mechanism that pulls the note out of flow and leaves behind a marker, we want to delete the space between “word” and that marker -- but not the space after. I suppose we could add a discard-around keyword, though. What are the use cases you had in mind?

I was thinking of code blocks. For them you normally want whitespace before and after the actual code to be discarded.
It also happend to me several times in the past that inline-block elements had unwanted whitespace between them causing layout issues.

Sebastian

I was thinking of code blocks. For them you normally want whitespace before and after the actual code to be discarded.

That's the trim-inner value.

I was thinking of code blocks. For them you normally want whitespace before and after the actual code to be discarded.

That's the trim-inner value.

Oh, right. Well, you actually want both sides trimmed, inside and outside, though the outer whitespace is already collapsed by default via the whitespace collapsing algorithm.

The inline-block use case is still valid, though, as in https://jsfiddle.net/SebastianZ/qLjh7wup/3/. (Though the use cases I am currently thinking of can be solved by using Flexbox or Grid layout, which automatically discard the white space around their items. As this logic somewhat conflicts with text-space-trim, I created #3124.)

Sebastian