Meeting minutes
[Discuss the coronavirus]
Infoshare
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
https://
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.
https://
xfq: Let's talk when they invite us to review
Make ideograph-alpha and ideograph-numeric part of text-spacing: normal
https://
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://
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://
… 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://
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://
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://
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
https://
https://github.com/w3c/clreq/pull/449
[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?
https://
huijing: I think so
Eric: agreed
https://github.com/w3c/clreq/pull/445
[xfq introduces the PR]
huijing: looks good to me
Eric: looks good to me
xfq: I'll merge it then
https://github.com/w3c/clreq/pull/437
xfq: I updated the PR per https://
Bobby: looks good to me
xfq: I'll merge it then
Go through the issue list
https://
https://github.com/w3c/clreq/issues/408
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
https://
Zhengyu: we should make our font stacks begin with Latin fonts
xfq: For the problem with quotes, we can consider using unicode-range
https://
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)