Skip to content
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

[css-text-4] text-spacing: trim-end is better than allow-end for the normal value #7055

Closed
MurakamiShinyu opened this issue Feb 15, 2022 · 7 comments
Labels
Closed Accepted by CSSWG Resolution css-text-4 i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.

Comments

@MurakamiShinyu
Copy link
Collaborator

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-end is typographically better than allow-end in most cases
  • trim-end behavior is simpler and needs less overhead than allow-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

@xfq xfq added css-text-4 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement labels Feb 17, 2022
@fantasai
Copy link
Collaborator

CC @kojiishi @jfkthame @litherum @r12a

@r12a
Copy link
Contributor

r12a commented 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
Copy link
Collaborator

@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.

@astearns astearns added this to 10:30-11:30 i18n in TPAC Friday 2022 Sep 13, 2022
@fantasai
Copy link
Collaborator

Internationalization WG recommends adopting this proposal (TPAC 2022-09-13).

@aphillips
Copy link
Contributor

I18N recommends that trim-end be the default. See about here

@css-meeting-bot
Copy link
Member

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 keyword
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

@MurakamiShinyu
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution css-text-4 i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.
Projects
No open projects
TPAC Friday 2022
10:30-11:30 i18n
Development

No branches or pull requests

6 participants