Clreq Editors' Call

15 April 2022


Bobby, Eric, huijing, xfq, Zhengyu

Meeting minutes

[Discuss the coronavirus]


xfq: JL-TF discussed a new proposal on English ruby terminology
… Murata-san, Kida-san, and Shimono-san will work on this area, and are now working on a Markdown document


xfq: they will seek feedback from the i18n WG and the CLReq TF

Bobby: Our terms are all from jlreq

xfq: No. We have terminology differences with jlreq and CSS.


xfq: Let's talk when they invite us to review

Make ideograph-alpha and ideograph-numeric part of text-spacing: normal


xfq: this CSSWG issue is about making ideograph-alpha/ideograph-numeric the default behaviour of the browser.

xfq: Do you think this meets the needs of Chinese text layout?

Eric: Apple's operating systems have 1/8em extra spacing by default
… This is what Apple has implemented

xfq: Some argue that this may cause compatibility issues, others argue that there are websites and print publications that do not add extra spacing.

Eric: print publications usually have extra spacing

xfq: Some examples in https://github.com/w3c/csswg-drafts/issues/6950 do not

Eric: the SingTao Daily example is not good typography

xfq: If we think the example is not good, we need to give a reasonable explanation

Bobby: The status quo of the web is that there are no extra spacing
… If we apply Apple's behaviour to the web, I think it's enough
… We don't need to use 1/4em, because most Chinese texts on the web are justified

Eric: First we need to answer of whether the default behaviour should be extra spacing or not. My opinion is that extra spacing is needed.

Eric: No extra spacing is a big problem for Chinese, although it might be bearable for Japanese

Eric: Because Chinese only has Chinese characters

Eric: There are both kana and kanji in the modern Japanese writing system

Eric: This situation can be tolerated in Japanese because the Japanese writing system uses a combination of a variety of scripts
… But Japanese print publications usually have extra spacing
… I've discussed the default value with many Japanese people, and many people think 1/4em extra spacing is too large
… The specific value can be discussed in the future, but there should be extra spacing by default
… we can have a relatively small default value like 1/8em

Bobby: I agree

xfq: Another issue is that non-ideographic letters and numerals may behave differently
… see the People's Daily example in https://github.com/w3c/csswg-drafts/issues/6950#issuecomment-1082638960
… in this example, there's extra spacing between runs of ideographs and non-ideographic numerals, but not letters

Eric: The layout of the People's Daily is also not very good. It is very simple.
… I think the default value should be extra spacing for both, and authors can adjust it by themselves

[Discuss the disadvantages of manually adding spaces]

huijing: Anyway, when manually adding spaces, everyone uses U+0020
… If the document is in Chinese (with lang=zh), can the browser automatically adjust the width of the manually added spaces?

xfq: I was about to say this

xfq: https://github.com/w3c/csswg-drafts/issues/7183

xfq: r12a proposes to separate autospace out, which makes it easier to toggle the behaviour, customize the width, and replace existing manually added spaces.

huijing: I think this is a good idea

Eric: There is another problem.

Eric: If the English text in Chinese is a phrase, then in many cases, the spacing between words in English is larger than that between Chinese and English.
… It depends on the font
… Anyway, in advanced Chinese and Japanese typesetting, this should be an adjustable value, not a fixed value.
… Let's discuss the default bahaviour first

Zhengyu: I think it's safest to set the default spacing to 0
… Because spacing conventions vary
… There is no universal optimum
… For example, when there are English phrases in Chinese
… We also need to consider the width of U+0020 built into the font
… So we can't calculate an optimal value in advance
… Although I think ideally there should be extra spacing
… the default spacing should be 0

Eric: But if the default is 0, it is equivalent to no extra spacing
… We need to choose an appropriate default value, even if the value is not universal.
… I don't think the default spacing should be 0
… 1/4em is too large
… 1/8em should be fine

Bobby: I agree

Eric: If the spacing is 1/4em, the user may think they have entered a space by mistake, or the text may overflow.
… Although jlreq and clreq say 1/4em is fine, and there are many print publications that use 1/4em
… for digital media, 1/4em value is too large
… I think there is consensus on this point

[Discuss the history of the autospace discussion]

Eric: we're off topic

Bobby: I think Apple's 1/8em is an acceptable default under digital media

Eric: I agree

Bobby: 1/4em is a historical value in the era of movable type
… the user should be able to customize the value

Eric: Let's discuss the default value first
… like 1/8em

xfq: see also https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-autospace

Eric: Too many values for the text-spacing property

Eric: and 'normal' and 'auto' are different, it's confusing

Zhengyu: CSS resets remove the margin in all browsers
… Because when the default value is 0, it is a more controllable state
… it's not easy to cause misunderstanding when the default value is 0

Bobby: The current default value can be understood as 0

huijing: I think Zhengyu is right
… "Don't break the web"
… authors can modify the values themselves

Eric: At least we support r12a's proposal in https://github.com/w3c/csswg-drafts/issues/7183

xfq: Do we have a conclusion on the default behaviour?
… 0 or >0?

Bobby: 0

huijing: 0

xfq: Do you have a different opinion, Eric?

Eric: I won't object
… for web compatibility

Bobby: I would also love to have a >0 default value

Bobby: But because of web compatibility, we can't

Eric: We can recommend that authors use a >0 value

Bobby: I agree

xfq: we have 'text-spacing: auto'

Bobby: the autospace behaviour for Microsoft Word on Windows and Mac behave differently

Eric: yes

xfq: I just checked and it's the same now

Bobby: May be they modified this behaviour

Eric: back to the original topic
… If you don't want to break the existing content, the default spacing can only be 0, but the existing content is not beautiful.
… autospace is an important feature

huijing: I agree extra spacing looks better
… If even Microsoft can change the defaults, maybe we can too

Zhengyu: Our consensus is of course that there should be extra spacing, but it is up to the browsers to decide how the standard is specified.
… Suppose one day browsers implement this, with a >0 default behaviour
… After the user upgrades the browser, they will find that the design of the web page has changed
… They'll think there's something wrong with the browser
… Browser vendors need some public relations resources and enough rationale to explain this

Eric: I personally think users in the Chinese community will applaud if the behaviour is >0

Zhengyu: it may not be true

Zhengyu: Because the width of many components in Chinese web applications is a fixed value
… and because the width of Chinese characters is fixed
… if there are many non-ideographic numerals in a line, the change of the default behaviour will be very destructive to the overall layout.

Eric: We should assess the impact of this, of how many web pages are affected.

Zhengyu: So this matter should be left to the browser vendors to decide because they have more data
… they can manage the expectations of their users

Eric: We can invite browser vendors to discuss this with us

huijing: agreed

xfq: I think we need to make an appeal, that is, we want extra spacing as the default.
… How CSSWG and browser vendors deal with compatibility issues is not something we (the CLReq TF) should think about.

Eric: because we only document the text composition *requirements* in the Chinese writing system

huijing: agreed

xfq: Okay, I'll summarize everyone's views and give feedback to r12a and the CSSWG.

Eric: this is an important feature

Eric: I think this is a good step for Apple

Go through the pull request list



[xfq introduces the PR]

Eric: looks good to me

huijing: as long as it's consistent it's fine

Bobby: there's something wrong with the Preview link

xfq: there's garbled text like � �

xfq: It seems that it has nothing to do with the PR itself, it may have something to do with the tooling

huijing: yeah

xfq: Never had this problem before

xfq: I will investigate

Eric: weird

huijing: why does PR Preview use Amazon S3?

xfq: I'm not sure

xfq: I think it's just like Netlify Deploy Previews

huijing: Not only this PR has this problem, other PRs also have this problem
… the content of this PR is fine

Eric: we can merge it

xfq: should I reflect this in our editorial guidelines?


huijing: I think so

Eric: agreed


[xfq introduces the PR]

huijing: looks good to me

Eric: looks good to me

xfq: I'll merge it then


xfq: I updated the PR per https://www.w3.org/2022/03/04-clreq-minutes.html#t05

Bobby: looks good to me

xfq: I'll merge it then

Go through the issue list



Zhengyu: Chinese fonts are better optimized for Chinese punctuation marks
… generally font stacks begin with Latin typefaces
… but it will result in incorrect rendering of quotes, especially for Simplified Chinese

Eric: But our font stacks begin with Chinese fonts

Zhengyu: Putting Chinese first is not a good practice
… Because some Latin glyphs in Chinese fonts are ugly


Zhengyu: we should make our font stacks begin with Latin fonts

xfq: For the problem with quotes, we can consider using unicode-range


Eric: In theory it is possible

xfq: We can assign specific fonts to specific characters

huijing: I think it's a good idea
… I'll send a pull request

xfq: Another problem is that the Noto CJK fonts have been renamed

huijing: I will add the new font names to the stack

Zhengyu: Old font names should not be removed, at least for now

xfq: agreed

xfq: it might be useful if we can add the source of each font in the comments of the CSS file

Zhengyu: yeah
… Latin fonts are only for Windows, not for macOS and other operating systems

<huijing> -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"

huijing: this font stack above doesn't seem to consider Android fonts

Eric: looks complicated
… Hopefully one day we can use system-ui directly

Next teleconference time

May 17 (Tuesday), 19:00-20:00 (UTC+8)

Minutes manually created (not a transcript), formatted by scribe.perl version 188 (Sat Jan 8 18:27:23 2022 UTC).