You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-text-4] Rethinking 'text-space-collapse' and 'text-space-trim' #448
As far as I understand, text-space-collapse is meant to control the white space processing inside an element while text-space-trim is used to control the white space processing around (the edges of) an element.
Furthermore, it looks like text-space-trim: trim-inner overlaps with text-space-collapse: discard, because text-space-collapse: discard discards all white space within an element and text-space-trim: trim-inner discards all white space at the beginning and end within an element.
With the above in mind and also in regard of their shorthand white-space, I think it would be better to:
rename them to something like white-space-inner/white-space-inside/white-space-within and white-space-outer/white-space-outside/white-space-around (name bikeshedding welcome).
change text-space-trim to only affect white space outside of the element and use the same values as text-space-collapse.
So the syntaxes for them would then look something like this:
To avoid the long keywords and the complicated syntax on white-space-around a two-value syntax could be used instead, where the first value applies to the white space before the element and the second to the white space after the element, and if only one value is given, it applies to both. The syntax would then look like this:
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.)
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.
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.)
Activity
fantasai commentedon Sep 13, 2018
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.
SebastianZ commentedon Sep 13, 2018
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-trimshould have similar names, either all with the prefixtrim-or all withdiscard-(followingtext-space-collapse's wording).But the values were not the only thing of this proposal. What about the renaming?
discarddoesn't fit perfectly totext-space-collapse, which only indicates collapsing, not completely discarding. And aswhite-spaceis 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
discardfortext-space-trimcombiningdiscard-beforeanddiscard-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
fantasai commentedon Sep 13, 2018
Fair point. :) Leaning towards
discard-to match thetext-space-collapsevalue, anything else to consider?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.
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.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 adiscard-aroundkeyword, though. What are the use cases you had in mind?SebastianZ commentedon Sep 14, 2018
Then we agree on this. Nothing else to consider.
What about
white-space-insideor one of the other names I proposed in my initial comment?What was that issue exactly? And who could answer whether that's still a problem?
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
fantasai commentedon Sep 16, 2018
That's the
trim-innervalue.SebastianZ commentedon Sep 18, 2018
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
[css-text-4] Rename trim-inner to discard-inner for consistency #448
[css-text-4] Rename trim-inner to discard-inner for consistency w3c#448