-
Notifications
You must be signed in to change notification settings - Fork 707
[css-text-4] text-spacing: trim-end is better than allow-end for the normal value #7055
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
@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. |
Internationalization WG recommends adopting this proposal (TPAC 2022-09-13). |
I18N recommends that trim-end be the default. See about here |
The CSS Working Group just discussed
The 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 |
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. |
https://drafts.csswg.org/css-text-4/#text-spacing-property
In the current draft, the
normal
value is defined as:About the
space-start
value in this definition, I have proposed to change it tospace-first
in the following issue:Now, I add one more suggestion: change
allow-end
totrim-end
in this definition. So thenormal
will be equivalent tospace-first trim-end trim-adjacent
.I summarize the reason:
trim-end
is typographically better thanallow-end
in most casestrim-end
behavior is simpler and needs less overhead thanallow-end
trim-end
is typographically better thanallow-end
in most casesIn justified text, the end of lines should be aligned visually. The
trim-end
is fine for this purpose, andallow-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. Thetrim-end
may add extra inter-character spacing when a fullwidth closing punctuation at end of line is trimmed to half-width. Soallow-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 thanallow-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
The text was updated successfully, but these errors were encountered: