W3C

– DRAFT –
Clreq Editors' Call

06 February 2020

Attendees

Present
Eric, huijing, xfq, xidorn, yijun
Regrets
-
Chair
xfq
Scribe
xfq

Meeting minutes

Infoshare

xfq: we have a gap-analysis document

https://‌w3c.github.io/‌clreq/‌gap-analysis/

xfq: Richard sent an email

https://‌lists.w3.org/‌Archives/‌Public/‌public-clreq-admin/‌2020JanMar/‌0001.html

xfq: we are experimenting with a new approach for gap-analysis documents
… including the clreq one
… previously we used HTML to write the document
… r12a converted the document to automatically retrieve content from the GH issues, using JS
… changes to the GH issues will be immediately visible in the document
… let me know if you encounter any issue

xidorn: using GitHub API?

xfq: not sure if it uses GitHub API
… haven't looked at the JS code yet

https://‌github.com/‌w3c/‌i18n-activity/‌blob/‌gh-pages/‌textlayout/‌resources/‌gap-analysis-github.js

https://‌github.com/‌w3c/‌clreq/‌issues

xfq: there are many new issues in the w3c/clreq repo (#237 - #250)
… with the label 'gap'

xidorn: what's the relationship between the gap-analysis document and clreq?

xfq: the gap-analysis document describes and prioritizes gaps for the support of a particular language, like Chinese, for the Web

xidorn: is it in the clreq document?

xfq: no, it's a separate document

xidorn: why are the gap-analysis issues in the clreq repo?

xfq: both documents are produced by the Chinese text layout task force
… and w3c/clreq is the repo of the task force

xidorn: so we don't need to look into these issues during the teleconference

xfq: for the current issues, I think so
… there may be issues that require discussions in the future

Review of CSS definition status

xfq: huijing made a framework for the review of CSS definition status

huijing: no content for now

xfq: we can add content in the future

huijing: https://‌github.com/‌huijing/‌clreq-css

huijing: https://‌clreq-css.netlify.com/
… made by VuePress
… I added the section titles in https://‌clreq-css.netlify.com/‌analysis.html

xfq: after knowing the CSS definition status of a particular section, we can move forward more efficiently
… what's the source format of this document?
… .md?

huijing: yes

xfq: seems to be a markdown table
… we can go through these sections when we have time in future meetings
… after going through this, we can even consider writing a CSS library to implement the implementable parts of clreq
… but that's a future thing
… any comment on this document?

huijing: we can use https://‌clreq-css.netlify.com/‌analysis.html as a ToC
… a large table doesn't look good
… each section can be in a separate page

xfq: I agree

xidorn: re section levels, should we consider x.x.x level sections?
… it only covers x.x level sections currently
… the necessity may depend on the specific section

Eric: I think so
… x.x is too rough

xfq: I suggest we use the x.x.x level first, and if it ’s not enough, we can refine it

huijing: I'll add x.x.x level subsection titles to the table

Eric: we can start filling in the table after you add the x.x.x level
… can we just modify the markdown file?

huijing: you can use https://‌www.tablesgenerator.com/‌markdown_tables to edit markdown tables
… click 'File > Load table...' and load https://‌github.com/‌huijing/‌clreq-css/‌blob/‌master/‌clreq.tgn
… then edit the table and generate the markdown

Go through the issue and pull request list

https://‌github.com/‌w3c/‌clreq/‌pulls

https://‌github.com/‌w3c/‌clreq/‌pull/‌234

xfq: this issue fixes https://‌github.com/‌w3c/‌clreq/‌issues/‌206
… we should address r12a's comments in https://‌github.com/‌w3c/‌clreq/‌issues/‌206
… Richard doesn't think that's punctuation
… it's a kind of text decoration

Eric: for example, we usually consider 专名号 (proper noun mark) a kind of punctuation in Chinese
… but it is a kind of text decoration per CSS
… and that's understandable

xidorn: it looks like text decoration, but still considered a kind of punctuation in Chinese

Eric: we need to add an example to the paragraph

xfq: we can add an illustration
… and mention that it is a solid black border outside the character frame of a person's name

huijing: I'll update the PR

xfq: thanks huijing

https://‌github.com/‌w3c/‌clreq/‌issues

https://‌github.com/‌w3c/‌clreq/‌issues/‌236

Eric: I think this is a CSS issue
… about whether space-first should be the default text-spacing behavior

xfq: major Chinese publishing houses uses half-width glyphs for opening punctuation characters at the beginning of a paragraph
… different from Japanese
… do we have this requirement in clreq?
… if so, I think we can close this issue now
… if not, we can add it

Eric: in 3.1.6.2 Compression of punctuation marks at line start or line end
https://‌w3c.github.io/‌clreq/#id101
… "For the case of line head indent, if an opening bracket is set at the beginning of the first line of the paragraph, half a character space can be reduced ahead of the bracket."
… with 'text-spacing: space-first', the "can be reduced" will become "must not be reduced", and that's not correct for Chinese

xfq: I'll comment on #236

https://‌github.com/‌w3c/‌clreq/‌issues/‌235

xfq: re #235, I'll discuss with r12a

https://‌github.com/‌w3c/‌clreq/‌issues/‌232

xfq: a horizontal audio control takes up a lot of space in a page in vertical writing mode
… we discussed this in an i18n teleconference, but no conclusion yet

yijun: I feel that typography is generally based on convention, but now there is no convention and there is no need to invent one

xidorn: I don't think we should write this in clreq if there's no convention yet
… if the CSS working group needs our suggestions, we can give suggestions, but I don't think this needs to be written in clreq

Eric: I agree

xidorn: I remember there is a CSS module that specifies whether a specific HTML element should be rotated when it is in vertical writing mode, and how to rotate it

xfq: I'm not aware of such CSS module...

[scribe's connection dropped, missed some conversation]

xfq: I can mark this issue as 'future'

https://‌github.com/‌w3c/‌clreq/‌issues/‌230

xfq: there's an 'auto' value in text-spacing now

yijun: why is the behavior of 'auto' UA-dependent?

xidorn: a UA-dependent 'auto' value allows faster iteration for browser vendors
… after we have a consensus on the behavior of 'auto', we can specify it in the CSS standard

xfq: specifying the behavior of 'auto' prematurely in the standard may be a source of interop issues

https://‌github.com/‌w3c/‌clreq/‌issues/‌221

Eric: I will continue to edit the text in #221
… we can discuss it in future teleconferences
… especially the thrid point in https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-508055215

[discuss xidorn's comment https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-520100093]

Next telecon time

xfq: March 5 (Thursday), 19:00-20:00 (UTC+8)

Minutes manually created (not a transcript), formatted by scribe.perl version 107 (Tue Feb 4 12:47:25 2020 UTC).