<xfq_> Bobby: I've been busy with a lot of things
<xfq_> ... haven't started reviewing clreq & CSS definition status yet
<xfq_> ... just saw the fangsong & non-Chinese mapping issue
<xfq_> ... reminds me of cursive & Kai
<xfq_> ... https://bobbytung.github.io/cursiveaskaifont/
<xfq_> ... I'll be less busy this month, and start to work on the CSS definition status
<xfq_> xfq: jlreq is also working on this
<xfq_> ... although I haven't seen the results yet
xfq: https://w3c.github.io/jlreq/gap-analysis/#vertical
… ^ this is Japanese Gap Analysis
… what about Chinese?
… do we have these requirements?
… if so, are they important enough to be mentioned in the gap analysis?
… let's go through these items
… 2.1.1 Vertical form controls
… like input field, text area, selection options etc.
Bobby: this is interesting
… this has a great impact on some web pages
… what do you think, huijing?
… vertical input field might be an issue in web design
huijing: there is no interop on this currently
xfq: currently only Firefox supports vertical text in forms
huijing: I guess only Japan and Taiwan need this feature
… not Mainland China
Bobby: in vertical writing mode, if you have a table and the text in it is in horizontal, the table may overflow, especially in a paginated context
… some forms can be resized
… so it's less an issue comparing with table
huijing: from a web designer's point of view
… if the text and table is vertical
… there should be an option to make the form vertical too
Bobby: video and audio elements in vertical writing mode is a bigger problem, especially for audio elements
… the audio control should be vertical
… a horizontal audio control takes up a lot of space in a page in vertical writing mode
xfq: we can mention this in the gap analysis if it is an issue
Bobby: yes
… we can also discuss this in i18n meetings
huijing: in Arabic, the progress bar is often ltr instead of rtl
… initially it was because the lack of good bidi support
… but now many people already got used to it
… this case might be similar to our case
Bobby: I don't think so
… the volume, seeking, pause, resume controls have minimum widths
… doesn't look good in vertical writing mode if they're horizontal
… so the layout of the controls should be different in vertical writing mode
xfq: we can use 'transform: rotate(90deg)' ;)
huijing: this is a new issue in the digital age
… we can give recommendations, although there is no precedent about this kind of issues
Bobby: we can ask people the question first
… about vertical forms, examination paper in vertical writing mode might have something similar
xfq: let's go to the next item
… 2.1.2 Upright text orientation
… only Firefox has good support of it
… I think we have similar requirements in Chinese
… 2.1.3 Tate-chu-yoko
… I also think we have similar requirements in Chinese
Bobby: agreed
… many Japanese people use text-combine-upright rather than text-orientation to implement upright-oriented text
… because of the support for text-orientation is not good enough
xfq: unfortunately, yes
Bobby: Classical Chinese didn't have Tate-chu-yoko
… some Taiwan publishers use Tate-chu-yoko because it is used in Japan
xfq: yeah, so we have requirements for it now
Bobby: 2.1.4 Lists
… the illustration is correct for Chinese, but wrong for Japanese
… in Japanese, I think it should be "1．" (European numeral followed by a full-width full stop)
xfq: or use "一"
Bobby: or "一、" / "一 "
… I think 2.1.4 Lists is a very important feature
… unfortunately browsers don't support it
xfq: CSS Writing Modes L3 will be a REC next week
… 2.1.5 Table cells and 2.1.6 Logical properties
… I think we have similar requirements
Bobby: logical properties is a very important feature
… Amazon is quitting China market
… their work on Traditional Chinese is moving to the HQ
… targeting international users, thus using horizontal instead of vertical writing mode
… if you use right, left, top, and bottom, it is difficult to switch from a writing mode to another
… for line head indent etc.
xfq: https://w3c.github.io/clreq/gap-analysis/#vertical
… for Chinese, vertical text is currently marked as need work for advanced level support
… should we change it to need work for basic features, like Japanese?
Bobby: I agree
… I think Lists is the most important feature
… and Logical properties is the second most important one
https://github.com/w3c/clreq/pull/231
xfq: can we merge this?
[All: agreed]
https://github.com/w3c/clreq/issues/229
xfq: we discussed this once
… it's about the classification for 'cjk-earthly-branch' and 'cjk-heavenly-stem
huijing: currently they're alphabetic
… 甲甲, 甲乙
… doesn't sound correct to me
Bobby: they should be fixed
huijing: should it be cyclic?
Bobby: I think it is fixed
xfq: I also think fixed makes sense
… let's provide this feedback to the CSS working group first
… if there are other usages, we can discuss it later
… at least our consensus is that alphatic is incorrect
… if we use Earthly Branches to represent Chinese zodiac, it can be cyclic
… but we can design a new counter style for that, if needed
… I'll comment on relevant issues
https://github.com/w3c/clreq/issues/228
[xfq introduces the issue]
xfq: cjk-tally-mark looks good to me
… it is additive
… I think cjk-stem-branch should be cyclic
… that's what it is designed for
Bobby: I agree
… https://w3c.github.io/predefined-counter-styles/ looks like something similar to what Florian described in https://github.com/w3c/csswg-drafts/issues/4566
xfq: I'll publish a new WD of clreq
Bobby: https://github.com/w3c/clreq/issues/206
huijing: I can translate the text into English
Bobby: Thank you!
xfq: jlreq will also publish a new version
… integrate the errata
Tentative: January 8 (Wednesday), 19:00-20:00 (UTC+8)
xfq: I'll ask other editors
Succeeded: s/it is because/it was because
No scribenick or scribe found. Guessed: xfq
Maybe present: [All, Tentative