Meeting minutes
W3C Calendar
xfq: W3C developed our own calendar system
xfq: we need to make sure that the meetings of our group appear in the W3C calendar system
https://
[Discuss the profile in https://
[css-text-4] text-spacing needs to handle non-fullwidth punctuation also
https://
xfq: this issue was mentioned in the i18n/CSS joint meeting today
… it's about non-fullwidth punctuations and text-spacing
… how should we handle those punctuations?
{京都（日本）}
Eric: this is a complex issue
Zhengyu: We can treat these punctuation marks as Western text
Eric: We should not change the spacing around these characters
Zhengyu: If these characters appear and are used correctly, then they must be in the context of Western text
https://
xfq: see ^
… in some cases the jlreq folks do want to remove the extra spacing within the fullwidth character
[「
」]
。]
xfq: like ^
Bobby: But whether the same Chinese punctuation is in the center of the square space left for them or positioned in different directions is not certain, different fonts behave differently
Eric: In this case, if you want to reduce the spacing, it may make the text look worse
… might be wiser to not make any changes to the spacing
… In typesetting practice, if such a situation occurs, we will first change the Western punctuation into the correct Chinese one, and then handle it according to the Chinese rule to adjust the punctuation width
xfq: the jlreq folks have requested that the extra spacing need to be removed in some cases
Eric: but Chinese doesn’t need this
Eric: Are the parentheses in Taiwan all in the in the horizontal center of the square space?
Bobby: no, but Microsoft JhengHei is
Zhengyu: I think this is a separate issue
Zhengyu: Period and comma also have this problem, but it doesn't affect the punctuation width adjustment logic
Zhengyu: The issue we need to discuss is:
Zhengyu: If Western punctuation appears in Chinese or Japanese, should we incorporate it into the punctuation width adjustment logic?
Zhengyu: If so, then let's look at how to design algorithms and rules, as well as specific implementation methods
Bobby: 規格 [epub3]
… Should the square brackets above be considered part of Western text?
… if so, we should use the rule in https://
Zhengyu: Your case is clear and the square brackets should be treated as Western text, and 1/8 - 1/4 em spacing should be added
[Discuss the issue of the curly quotation marks as in https://
xfq: The single and double curly quotation marks are explicitly called out in the spec already, because of their usage in Chinese.
xfq: see https://
xfq: the issue is, if our consensus is that we shouldn't remove the spacing in those cases, there are at least two possible directions:
xfq: 1. ask the CSSWG to handle Chinese and Japanese differently
xfq: 2. convince CSSWG and/or jlreq not to handle this case
Yijun: in CSS, do we have one switch for all punctuation marks, or can we handle it more granularly, i.e., just handle a certain pair of punctuation marks or like the line-break 'loose', 'normal', and 'strict'?
xfq: currently, CSS has no way to achieve fine control, the only way is to add a span element to the pair of punctuation marks you want to control the behavior
xfq: IIUC this is about the default behavior of 'text-spacing: trim-adjacent'
xfq: CSSWG is redesigning text-spacing to a shorthand, but it's still not possible to handle it more granularly even in the new design
Eric: I agree with redesigning it into several longhands
Yijun: I think CSS should be like Adobe InDesign, to be able to change the spacing of a certain pair of punctuation marks
Yijun: We shouldn't be too smart to deal with these Western punctuations
Bobby: This may happen in programming books, unauthorized modification of spacing is not correct typography
Eric: the height and baseline of the proportional and fullwidth brackets are different
Eric: So I think we should not modify the spacing here
Bobby: for the '規格 [epub3]' example, ideally we shouldn't need a space character (U+0020) between '規格' and '[epub3]'
Bobby: the browser should see it as Chinese and Western mixed text and add the gap automatically
[Discuss the extra spacing Chinese and Western mixed text]
xfq: But the extra spacing Chinese and Western mixed text may not be applicable to all Western punctuation marks
xfq: For example, if it is a slash, a comma, or an asterisk, do we need to add the extra spacing?
Eric: We didn't categorize the characters like jlreq did
Eric: If we want to discuss the behaviour of these characters, we first need to classify all the characters
[Discuss the methodology of classification]
Zhengyu: There are many types of punctuation
Zhengyu: the logic in jlreq is based on character classes rather than scripts
Eric: https://
… Our classification may be different from theirs, and the classification for Simplified and Traditional Chinese may also be different
Zhengyu: it seems that the jlreq folks want to treat some Western brackets as Japanese punctuation marks
Zhengyu: but I hope we can classify them as Western punctuation
Yijun: I agree with Zhengyu
… except the single and double curly quotation marks
… Ken Lunde wrote a proposal for fullwidth punctuation many years ago
Bobby: is it https://
Yijun: probably
Zhengyu: it uses variation sequences
Yijun: If this proposal moves forward, we can also deal with the curly quotation marks in this way
Eric: But it is impossible to require all old web pages and files to add this variation sequence
Yijun: but we can use it for future documents
Yijun: I didn't hear any progress for this proposal, though
Eric: Source Han supports this feature, but it may be the only font that supports it
Bobby: yeah
Eric: so how should we reply to fantasai?
Bobby: for '規格[epub3]', i.e., Western characters appear in Chinese text, and there are brackets on both sides of the Western characters, the browser should add the extra spacing like 'text-spacing: ideograph-alpha'
Bobby: for other cases, like a proportional opening bracket before a fullwidth opening bracket, we don't remove the spacing
xfq: That is to say, our consensus is different from the jlreq TF, right?
xfq: should we ask the CSSWG to handle Chinese and Japanese differently
Eric: I think we should
Bobby: agreed, I don't want the spacing to be affected in this case
Yijun: I think CSS should handle this differently depending on the language, ja, zh-Hant, zh-Hans, etc.
xfq: I'll bring this to CSSWG and see what they say
Vertical Writing Support in QTI 3
https://
xfq: Murata-san asked us to have a look at "Vertical Writing Support in QTI 3" and make comments on it
https://
Zhengyu: What specific issues do they need us to discuss?
xfq: I'm not sure about the specific issues
Eric: in 3, the position of the dot should be on the right instead of on the left
Eric: in theory, it should use 読点（、）
Bobby: 2 is perfect
Zhengyu: I still don't understand what they're asking for
Zhengyu: they made a proprietary implementation, do they want this to be a standard?
Bobby: They didn't use HTML forms, they did it their own way
Eric: no comments from me
Yijun: I think it's good, but there's one problem
Yijun: in 16, the ✔️ in the select menu should be above the kanji characters
Yijun: in 17, if you select the leftmost menu in a narrow viewport it doesn't work well
Zhengyu: it's like https://
Bobby: and https://
xfq: I can ask them what exactly they want us to comment on
Go through the pull request list
https://
https://github.com/w3c/clreq/pull/515
xfq: looks good to me
All: OK to merge
https://github.com/w3c/clreq/pull/513
[xfq goes through the changes]
Bobby: re accessibility, please ask Roy Ran whether he has any idea
xfq: OK
All: OK to merge
https://github.com/w3c/clreq/pull/501
All: OK to merge
https://github.com/w3c/clreq/pull/492
https://
xfq: I discussed this with Richard. He suggested that we use "Latin, Greek, and Cyrillic" directly, or use a phrase like "simple alphabetic text" with a definition in the document.
[xfq talks about the background]
Zhengyu: I think neither of these two meets our requirements. If Richard objects to the word "European", let's change it back to "Western".
Eric: I agree with Zhengyu
Zhengyu: I'll update the PR
https://
Eric: "Western and/or Greek letters" in jlreq ^
Go through the issue list
https://github.com/w3c/clreq/issues/514
Eric: please send your comments
Next teleconference time
March 21 (Tuesday), 19:00-20:00 (UTC+8)