[css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior

[MurakamiShinyu]

Ebook reader's default text-spacing behavior

The text-spacing is not yet implemented in web browsers, but some part of this feature is already seen in ebook readers.
I put here two example screenshots (Kindle for PC, and Kinoppy for PC):

Kindle for PC screenshot:

Kinoppy for PC screenshot:

In these examples, the trim-adjacent behavior is seen at "、『" in the middle of a line, and the trim-start behavior is seen in the lines starting with "「" or "『".

However, there is a difference between these two examples. In the Kindle case, all opening punctuations ("「" and "『") are set half-width at start of lines. On the other hand, in the Kinoppy case, only the opening punctuation ("『") after a soft wrap break is set half-width, and kept full-width at beginning of paragraphs.

While Kinoppy's behavior is a normal Japanese typesetting style, Kindle's behavior is not so. Setting opening punctuation half-width at beginning of a paragraph with no indent is hard to recognized as beginning of a paragraph. I know Japanese publishing people asking Kindle dev to fix it.

The preferable behavior not possible in current text-spacing spec

The problem here is that the Japanese ebook's preferable text-spacing behavior is not possible in the current text-spacing spec.

We need space-start at the first line (or after forced line breaks) and trim-start at the rest lines.

I suggest the new value keyword space-first for such behavior, and it would be included in the baseline behavior (normal):

normal
Specifies the baseline behavior, equivalent to ‘space-first allow-end trim-adjacent’.

space-first
Set fullwidth opening punctuation with full-width glyphs (spaced) at the start of the first line of each block container and each line after a forced line break, and set fullwidth opening punctuation with half-width glyphs (flush) at the start of other lines.

Value: normal | none | [ trim-start | space-start | space-first ] || [ trim-end | space-end | allow-end ] || [ trim-adjacent | space-adjacent ] || no-compress || ideograph-alpha || ideograph-numeric || punctuation

Rethinking “Japanese Paragraph-start Conventions in CSS”

There may be an opinion that the current text-spacing spec is sufficient because Japanese Paragraph-start Conventions in CSS shows the example that enables the preferable behavior:

• Brackets hang in indent, flush with other lines (third scheme):

p { /* Hanging alignment */
  margin: 0;
  text-indent: 1em;
  text-spacing: trim-start;
  hanging-punctuation: first;
}

Yes, it would be great if we can use this. But unfortunately, there is no way to apply this to the current Japanese ebooks (EPUB and Kindle formats).

Most Japanese publishers adopt the Japanese EPUB guideline, EBPAJ EPUB 3 File Creation Guide, that includes XHTML templates and CSS stylesheets, such as:

<p>　この文章はサンプルです。</p>
<p>「この文章はサンプルです」</p>

p {
    margin: 0;
    text-indent: 0;
}

That is, paragraphs start with an ideographic space (U+3000) unless starting with an opening punctuation such as "「".
Almost all Japanese EPUB (and Kindle) books are made with this way, and we must accept this reality even if using ideographic space instead of text-indent considered not very good.

The bigger concern with current spec is that the ebook reader implementation and the spec becoming inconsistent. The space-first (trim-start-except-first-line) behavior is implemented as default behavior in ebook readers, ignoring the CSS spec. So I believe the text-spacing normal should include the space-first behavior.

Also I believe the space-first behavior is good for general Web content, it improves readability and beauty of CJK text.

[frivoal]

First, thank you a lot for writing this, text-space and related behavior is an important piece for good Japanese typography, and we need to work more on it.

As for this specific example, I am a bit conflicted. I think we should have an easy way of authoring content that looks good, and we should take compatibility with existing content into account.

At the same time, the authoring practice of using a full width space instead of an indent is bad. The fact that they have no choice because hanging punctuation is not implemented is unfortunate, but when the root cause of an issue is "a feature is not implemented", specifying another feature-that-is-not-yet-implemented is rarely a good answer.

That said, if we do end up with a significant ecosystem of content and readers that rely on this, this may force our hand.

I do wonder though. You said:

Also, I believe the space-first behavior is good for general Web content, it improves readability and beauty of CJK text.

If both this space-first behavior AND the approach currently proposed by the spec (text-indent: 1em; text-spacing: trim-start; hanging-punctuation: first;) were supported, would there still be cases were using space-first is a good idea (other than compatibility with existing EPUB content)?

We may still want to do it for compat reasons if the answer is no (maybe), but if the answer is yes, that makes it much more compelling.

[MurakamiShinyu]

If both this space-first behavior AND the approach currently proposed by the spec (text-indent: 1em; text-spacing: trim-start; hanging-punctuation: first;) were supported, would there still be cases were using space-first is a good idea (other than compatibility with existing EPUB content)?

Yes, I think the space-first is the best default among [ trim-start | space-start | space-first ].

The current default space-start is not very good, the half blank of fullwidth opening punctuation after a soft wrap break is visually not good and may be mistaken for the beginning of a paragraph.

On the other hand, if we change the default to trim-start, it will change the appearance of a huge amount of existing web content, many will be improved visually, but some will be broken. People will be surprised if the fullwidth opening punctuation changes to half-width at every start of lines. I guess this is the reason why trim-start is not the default in current spec. The space-first (trim-start-except-first-line) behavior will cause less impact, similar to trim-adjacent and allow-end, and will make good readability and beauty of text.

In addition, we should recognize that in most Japanese web content the text-indent style is not used and margin between paragraphs style is dominant. I think space-first behavior will fit well with such modern Japanese web text style.

[css-meeting-bot]

The Working Group just discussed text-spacing: space-first, and agreed to the following resolutions:

• RESOLVED: Add this value, suggest it's the default in epubs and add a open issue wondering if should be in the web in general

The full IRC log of that discussion

<dael> Topic: text-spacing: space-first
<dael> github: https://github.com//issues/2462
<dael> florian: Kindle does this (shows image from github) Interesting thing to note is the opening corner bracket. These glyphs have whitespace in them and it's been trimmed. We have a property that allows this to be one or odd. But Kindle decided to just trim.
<dael> florian: Some amount of trimming is typically wanted by Japanese typographers and publishers which is likely why the default. But what it doesn't isn't want Japanese people want.
<dael> florian: Kinoopy does much closer. Inline in the middle of a paragraph trim, but at the beginning set full-width.
<dael> florian: This is what people in Japan mostly want.
<dael> Rossen: What's the significance?
<dael> fantasai: Indentation.
<dael> florian: Way we spec things if you want this effect you need to a 1em text intent and you want to hang opening punct. That would give you this but that's not how they do it.
<dael> florian: The brackets are a quotation mark.
<dael> myles: Not jsut af ull width character?
<dael> florian: They're not using text indent, they're putting a space character at the beginning of the line. Brackets at teh end are not trim but the one in the middle is trim. How they do it is dirty but the effect is what they want.
<dael> florian: Murakami-san suggests we add a value to text-space, I think called space-first. We have trim-start and space-start and he suggests a value that's space on the first line trim on the rest.
<dael> florian: It would allow being compat on this type of content. It's regrettable they do it this way but it might as well be compat. Even if you don't consider hacky-layouts this is prob a good default for Japanese in general.
<dael> florian: Because trimming at the start of lines except the first is really a good thing.
<dael> astearns: Otherwise you assume it's a paragraph.
<dael> florian: Trimming at the start of lines is good, but at the first line content...some paragraphs are visible because the first line has an indent.
<dael> astearns: Why not solve this by having you use trim-start and text-indent and hanging punct correct for Japanese...ah, because then the mid paragraph would hang.
<dael> fantasai: It wouldn't.
<dael> astearns: Why not use text-indent and trim start?
<dael> fantasai: We can't by default.
<dael> florian: Right, he's suggesting this exist and be on by default.
<dael> florian: This ideal cannot be on by default because it's not backwards compat. That's kind of redundant, but it can be on by default which is nice.
<dael> astearns: And he goes through why my suggeestion is wrong in the issue. He says you can't apply this to current Japanese ebooks because the epub guidelines.
<dael> florian: It's a combonation of defaults and legacy and having this value would work okay for all of these.
<dael> fantasai: Reasonable to me. Big issue is we have a standard for how ebooks are written which is incompat with...this would make them look good and not doing this would not.
<dael> florian: epubs would look better and the web as it is would start looking better as well. WE can do this by default.
<dael> astearns: And the current default is bad.
<dael> florian: Right.
<dael> koji: NO strong opinion. This is about...the paragraph starts with one idographic space?
<dael> florian: If you look at the example with an idographic space instead of an indent or an opening punct. If there's one that happens to wrpa in the middle of the line that should be trimmed. That's what epub authors assume. If we don't do it epub looks bad. It will helpt hte web too. Only slightly for the web at the firstp punct but given that trim-start isn't done currently it's bad.
<dael> koji: space-first has nothing to do with space?
<dael> florian: Name is strange it means trim on non-first-lines. Why it's called space-first we have trim-start and space-start and space-start means don't trim. This is space first trim the rest. THat's a bit long so it's called space-first
<dael> fantasai: I'm not convinced this is the right thing for the web in general. For flush paragraphs why would you have a space only if it begins with a bracket. but epub needs this so we should add.
<dael> florian: In general you want trimming on the web. Not trimming the first isn't desireable, it's just safer.
<dael> fantasai: If you're not using indentation of any form...?
<dael> florian: Maybe you're not.
<Joel> myles: So using @supports for color fonts formats yes (sorry for the delay!) I will open the issue on the GitHub asap
<Joel> Sure!
<dael> florian: You only do this on your block quotes. The argument is that it isn't always desired it's the removing the space is always bad.
<dael> fantasai: I think we should add the value. I think the correct default is trim everything and is there ontent that would break.
<dael> astearns: Murakami-san says it would. Many will improve visually but some will break.
<dael> koji: Apart form the default I understand the desire. But that makes me think maybe we can use first-line and we're done.
<dael> florian: It's only interesting if it's the default. If it's not default we have other opt-in ways.
<dael> fantasai: It needs to be the defualt in epubs. If it's the initial or it's in their default stlesheet I'm not sure of the answer. It seems clear it's needed
<dael> astearns: Prop: Add this value, suggest it's the default in epubs and add a open issue wondering if should be in the web in general
<dael> RESOLVED: Add this value, suggest it's the default in epubs and add a open issue wondering if should be in the web in general
<dael> fantasai: Does guide tell people to lang tag?
<dael> florian: We can check. So you apply based on lang tag.

[fantasai]

OK, I've added this to the spec, along with a note describing why we're adding it and how it should (and should not) be used. @MurakamiShinyu would you mind reviewing?

https://drafts.csswg.org/css-text-4/#valdef-text-spacing-space-first

[MurakamiShinyu]

ISSUE 24 Whether this value should also be part of the UA defaults for Web content is currently under discussion.

I strongly believe this value should be part of the defaults regardless of Web or ebooks, and the normal definition should be space-first allow-end trim-adjacent.

I think that the current normal definition with space-start is the worst choice between [trim-start | space-start | space-first] because full-width opening punctuation at start of a line that does not begin the paragraph visually looks like beginning of a paragraph with indent because of the half em space that the full-width opening punctuation glyph has, and it makes bad readability.

The remaining options are trim-start and space-first. I don't believe we can select trim-start as default because of web compatibility; it affects existing web contents that use intentionally full-width opening punctuation glyph at beginning of text blocks. So the only reasonable choice for default is space-first.

Also, I strongly oppose changing defaults on the Web and ebooks. The difference between Web and ebooks is not obvious. For example, I am working on Vivliostyle that can be used as an ebook viewer and also can display/print Web contents with pagination; not obvious the Web content viewing with Vivliostyle is ebook content or not. This is important issue for us because Support text-spacing is on our ToDo list (Update: implemented in vivliostyle/vivliostyle.js#814).

[xfq]

In terms of the typographic conventions in Mainland China, the special case of "fullwidth opening punctuation at the beginning of a paragraph" is not needed. Major publishing houses use half-width glyphs for opening punctuation characters at the beginning of a paragraph. (See related discussions in w3c/clreq#236)

Since we added an auto value in #4657, can we handle this as a locale-sensitive text-spacing rule using auto, even though auto is not the default value of text-spacing?

[kojiishi]

@xfq Can you clarify a bit more? If Chinese uses half-width glyphs for opening punctuation, trim-/space- does not matter at all. Can you point out what I missed?

[kojiishi]

^ nvm, I think I misunderstood "glyph" with "code points", I think it says major publishing houses expects half-width "glyphs" when using full-width "code point", so trim- behavior.

[xfq]

^ nvm, I think I misunderstood "glyph" with "code points", I think it says major publishing houses expects half-width "glyphs" when using full-width "code point", so trim- behavior.

Yes, sorry about the lack of clarity.

[MurakamiShinyu]

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

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.

[frivoal]

The value has been added, but the question of which of [trim-start | space-start | space-first] should be part of normal isn't settled.

Reminder: a typical Japanese paragraph starts with a 1em indent. If it starts with an opening punctuation (whose glyph is 1em wide, but only the later half contains ink), that punctuation can be:

• Hung in the 1em indent. (This is probably the most typical/desired look.)
• Set flush (trimmed by 1/2em) after the 1em indent.
• Set solid (yielding effectively a 1.5em indent) after the 1em indent.
      
  In styles 1 & 2, opening punctuation wrapped to the start of a line are ideally trimmed by 1/2em in order to set them flush.

Considerations:

• The ideal behavior for CJK is probably a combination of trim-start (for text-spacing), 1ic (for text-indent), and first (for hanging-punctuation). This formats the start of each paragraph as expected, when the paragraph is marked up to contain only its actual text and no indentation characters. This would suggest trim-start as the right initial value, but since it has not historically been implemented that would create a compat problem both on the Web and in eBooks:

  • trim-start breaks expectations on monospace preformatted content. We could maybe work around this with pre { text-spacing: none; }, but also...
  • Content authored with no consideration for typography would be improved by this, but content authored to mimic the effect of the above formatting would break.

  Because the properties needed for this to work properly haven't historically been available, typographically conscious content manages indentation by using ideographic spaces at the start of paragraphs that do not begin with (an essentially hanging) opening puctuation.

• Both space-start (current default) and space-first (Murakami-proposed default) work well with existing content that achieves the desired paragraph-start formatting by including an ideographic space in the markup for every paragraph that does not begin with an opening punctuation mark. The downside is that both these values encourage that markup practice, which gets in the way of text-indent and hanging-punctuation being able to control paragraph formatting.

• Between these two, space-first is a strict improvement: while it plays equally well with legacy content, and equally encourages problematic markup practices, it does have the advantage of avoiding the appearance of a paragraph start if a wrapped line happens to start with an opening punctuation.

I think my recommendation would be to:

1. Adopt space-first as the default behavior for normal, and
2. Modify hanging-punctuation: first to hang a paragraph-initial ideographic space as well.

[MurakamiShinyu]

I think my recommendation would be to:

1. Adopt space-first as the default behavior for normal, and
2. Modify hanging-punctuation: first to hang a paragraph-initial ideographic space as well.

That seems very reasonable. The space-first behavior would be the best for normal that must respect compatibility with existing content.

On the other hand, the auto value, defined as "The user agent chooses a set of typographically high quality spacing values", has no such requirement and it should include the trim-start behavior naturally. (I think this should be noted in the spec so that text-spacing: auto behavior will not look very different in multiple implementations.)

[xfq]

As I mentioned in #2462 (comment) , space-first does not meet the typographic conventions in Mainland China. If it is adopted as the default value, do Chinese authors need to change text-spacing to achieve the desired effect? I hope we can avoid this from happening.

[MurakamiShinyu]

trim-start will be the best for the typographic conventions, not only for Mainland Chinese but also for Japanese, but it cannot be the default behavior because of the compatibility problem with existing content. Do you think space-start is better than space-first? I cannot believe so.

When we want to achive the typographic conventions with CSS, we need to change property values from defaults. For example, the defaults text-indent: 0 and text-align: start do not meet the conventions for Japanese normal paragraphs, and we have to change these values to achive the conventions. The same would be the case for text-spacing. To achive the typographic conventions, we will use text-spacing: trim-start (or text-spacing: auto, and/or hanging-punctuation: first allow-end for Japanese book style).

[fantasai]

@xfq Does @MurakamiShinyu's response address your concerns?

[xfq]

@fantasai The Chinese Layout TF discussed this and agreed with @MurakamiShinyu's response. Thanks!

[css-meeting-bot]

The CSS Working Group just discussed [css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior, and agreed to the following:

• RESOLVED: Accept the proposal in the issue (initial value is space-first, and hanging-punctuation hangs ideographic space)

The full IRC log of that discussion

<TabAtkins> florian: With recognition that the property *overall* is too complex (that's another issue) we still have the initial-value bheavior issue
<fantasai> "text-spacing is too complicated" issue is https://github.com//issues/4246
<TabAtkins> florian: there's a tension between what is good typography in CJ, and what's compatible with historical beahvior
<TabAtkins> florian: There's a q about which of trim-start, space-start, or space-first should be the deafult value
<Rossen_> q?
<TabAtkins> florian: the short answer is, after discussion, we think space-first is a good compromise. Acceptable typography in most cases, and compatible with most markup. Also encourages good markup practices.
<TabAtkins> florian: depending on how many people are interested and haven't read the GH issue I can give more details as to why, but the proposal is to say that space-first is the initial behavior
<TabAtkins> florian: And part of that, change hanging-punctuation prop so that its "first" value also hangs paragraph-initial ideographic space
<TabAtkins> myles: Kneejerk is sounds like a good first step, but mostly concerned about compat
<TabAtkins> myles: And we won't solve compat by thinking hard. Starting with this and seeing what's wrong sounds useful.
<TabAtkins> florian: Agree, I'm not sue about compat but think it has a reasoanble chance, so we should try
<TabAtkins> myles: also, our native platforms have our own text-spacing beahvior that's not described entirely by any of the CSS props
<TabAtkins> myles: And we're interested in investigating if we can make "auto" default, reflecting that behavior
<TabAtkins> myles: So if it turns out that's compatible we'll come back and ask for that. Won't propose it yet, so okay with starting from florian's proposal.
<TabAtkins> fantasai: We had discussed allowing text-spacing to tkae effect by default
<Rossen_> ack fantasai
<TabAtkins> fantasai: Right now we ahve a resolution that "normal" is initial, and it corresponds to the trim values more or less *except* space-first, bc we believe there will be some unfortunate compat impacts from trimming first line
<florian> q+
<TabAtkins> fantasai: If WK wants to turn it on by default, it brings the question of if we want default spacing to be set by the platform, or be consistent and interoperable.
<TabAtkins> fantasai: We do have a keyword taht means "do what the platform wants" but the initial value is a separate q
<TabAtkins> myles: Yeah, I see a parallel between this and the override descriptors in @font-face
<TabAtkins> myles: By default the ascent/descent of all text is set by the platform, but if they really want it they can override those with specific values
<TabAtkins> myles: I think this is similar
<Rossen_> ack florian
<TabAtkins> myles: But again I'm not proposing "auto" as the initial yet. I'll need to do investigation
<TabAtkins> florian: Thanks for the heads up. Don't think that affects this current proposal.
<TabAtkins> florian: I think you might find that backwards compat is okay, but I'm concerned about forward compat with other platforms being forced to agree with it, but that's a future issue.
<TabAtkins> florian: So circling back, can we accept this proposal?
<fantasai> +1
<TabAtkins> Rossen_: Objections?
<TabAtkins> RESOLVED: Accept the proposal in the issue (initial value is space-first, and hanging-punctuation hangs ideographic space)
<fantasai> Also +1 to concerns around making 'auto' the initial value. I don't think this is a good idea

[fantasai]

Edits for this have been committed in 2966104 and should appear on /TR shortly!