<xfq_> scribenick: xfq_

Progress of our 2018 roadmap

https://www.w3.org/2018/03/01-clreq-minutes.html#item01

<bobbytung> https://bobbytung.github.io/Bopomofo_on_Web/case07/index.html

Bobby: I've been busy with Bopomofo

<xfq> scribenick: xfq

Eric: haven't had the time to look into compression of adjacent punctuation marks yet

GitHub issues

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

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

Yijun: https://github.com/w3c/clreq/issues/170#issuecomment-377196683

Eric: I replied to #168/#169/#149

xidorn: about #169, IIRC it was discussed in CSSWG, the image in https://github.com/w3c/clreq/issues/169#issuecomment-382223698 was the consensus.

Eric: As I said in the issue, designer usually just avoid pinyin and emphasis marks appearing on the same side of base characters...
... about #168, we usually put the decoration under the character (and above the pinyin)

xidorn: #168 was also discussed in CSSWG. There wasn't consensus because it has some implementation implications.
... CSS engines can't give more space for text decoration
... we can mention that it's a rare case

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

Eric: if most of the text is Chinese, the punctuation system should be Chinese-style
... even if we have text in other languages / writing systems

<bobbytung> http://w3c.github.io/i18n-drafts/questions/qa-the-q-element.en

https://w3c.github.io/i18n-tests/results/the-q-element.html

Eric: About the handling of q element, it seems that we need to wrap the text with lang= elements...

xidorn: if using the side that is normal for the surrounding language, there're implementation issues
... implementations don't know if it's the "most of the text is Chinese" case or not

Bobby: I agree with Eric that we should use the side that is normal for the surrounding language

<angel> Bobby and Eric ++ :)

<angel> the event organized by Bill Mc?

<bobbytung> https://bobbytung.github.io/Bopomofo_on_Web/case07/index.html

xidorn: there're lots of Chromium bugs about ruby

Bobby: there's also the issue about whether reading ruby or not in text-to-speech systems
... VoiceOver can read ruby

xidorn: I think it should be handled by WAI-ARIA

Next Meeting

May 14, Mon, 18:00-19:00 (UTC+8)

All: Agreed.

<xfq> Thanks everyone!

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/I agree with Eric./I agree with Eric that we should use the side that is normal for the surrounding language/
Succeeded: s/Ruby/ruby/
Succeeded: s/Thanks everyone!/<xfq> Thanks everyone!/
Present: Angel Bobby Xidorn Fuqiao Yijun
Found ScribeNick: xfq_
Found ScribeNick: xfq
Inferring Scribes: xfq_, xfq
Scribes: xfq_, xfq
ScribeNicks: xfq_, xfq

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items:

WARNING: IRC log location not specified!  (You can ignore this
warning if you do not want the generated minutes to contain
a link to the original IRC log.)