Repository navigation
[css-text-4] text-spacing: trim-end is better than allow-end for the normal value #7055
Description
https://drafts.csswg.org/css-text-4/#text-spacing-property
In the current draft, the normal value is defined as:
Specifies the baseline behavior, equivalent to
space-start allow-end trim-adjacent.
About the space-start value in this definition, I have proposed to change it to space-first in the following issue:
Now, I add one more suggestion: change allow-end to trim-end in this definition. So the normal will be equivalent to space-first trim-end trim-adjacent.
I summarize the reason:
trim-endis typographically better thanallow-endin most casestrim-endbehavior is simpler and needs less overhead thanallow-end
trim-end is typographically better than allow-end in most cases
In justified text, the end of lines should be aligned visually. The trim-end is fine for this purpose, and allow-end is not very fine because it makes punctuation at end of lines not alined visually.
Of course, there are cases where allow-end is preferable. Traditionally, in Japanese and Chinese typesetting, a grid-like arrangement with solid setting (no inter-character spacing) is preferable. The trim-end may add extra inter-character spacing when a fullwidth closing punctuation at end of line is trimmed to half-width. So allow-end may be better in this case. However, this will be a less usual case in Web, where the number of characters per line is usually not fixed, and the grid-like arrangement doesn't make much sense.
trim-end processing is simpler and needs less overhead than allow-end
To implement the default behavior (normal), it is important that the processing needs less overhead.
The trim-end processing is simpler, because in this mode, fullwidth closing punctuation can be treated as half-width punctuation plus half-width space which is discarded at line end as like a normal space. On the other hand, allow-end is not so simple because processing needs to be changed depending on the position of the fullwidth closing punctuation in the line, and the processing overhead is not very small.
This is what I have found in my recent experience implementing the text-spacing property in Vivliostyle.js.
FYI, a related blog post on Vivliostyle site: Line end handling has been evolved to allow multiple typesetting options
Activity
fantasai commentedon Feb 17, 2022
CC @kojiishi @jfkthame @litherum @r12a
r12a commentedon Feb 22, 2022
Seems reasonable to me. I was indeed wondering when you'd need to reduce space after brackets at in-paragraph line ends but not paragraph last lines - i'm not sure that grid-based character layout is a candidate for that.
I'm beginning to lose track: we used to have a CSS property that imposes a character grid layout for CJK text. Is that still a thing? (Sorry for asking rather than searching, but i'm sure grid layout will swamp my search results, and i can never remember which module to look in these days...) If so, i'm assuming that it would disable all text-spacing if applied.
An observation: allow-end seems to be the inverse equivalent of space-first.
fantasai commentedon Mar 11, 2022
@r12a We no longer have a character grid proposal. Might consider reviving it someday, but there's a lot more fundamental stuff to solve for inline layout first, and my impression is CJK typesetting is moving away from that style rather than towards it.
fantasai commentedon Sep 13, 2022
Internationalization WG recommends adopting this proposal (TPAC 2022-09-13).
aphillips commentedon Sep 13, 2022
I18N recommends that trim-end be the default. See about here
css-meeting-bot commentedon Oct 12, 2022
The CSS Working Group just discussed
trim-end better than allow-end, and agreed to the following:RESOLVED: Incorporate trim-end behavior into the normal keywordThe full IRC log of that discussion
<TabAtkins> Topic: trim-end better than allow-end<TabAtkins> fantasai: about text-spacing
<TabAtkins> fantasai: ONe of its fucntions is to handle the blank hash(sp?) of CJK font spacing
<TabAtkins> fantasai: a couple of values of how to handle it at start or end of th eline, trim or not
<TabAtkins> fantasai: proposal from murakami-san is incorporate the trim-end behavior into the 'normal' value
<TabAtkins> fantasai: review from i18n is to recommend adopting this
<fantasai> https://www.w3.org/TR/css-text-4/#text-spacing-property
<fantasai> s/hash(sp?)/half/
<fantasai> s/CJK font spacing/CJK punctuation/
<TabAtkins> Rossen_: Objections?
<TabAtkins> [none]
<TabAtkins> RESOLVED: Incorporate trim-end behavior into the normal keyword
MurakamiShinyu commentedon Nov 15, 2022
It's good. Please also incorporate space-first behavior into the normal keyword:
In justified paragraph, it is very bad if the line end edge is visually aligned by trim-end but the line start edge is not. The combination of space-start and trim-end looks very unbalanced.
[css-text-4] Switch 'text-spacing: normal' to 'trim-end' #7055
[css-text-4] Switch 'text-spacing: normal' to 'trim-end' w3c#7055