Re: css-ruby関連項目

 shimonoです

 返信内容は一番下にあります＆前半はCSS ruby (level 1)関係の(把握している限りの)議論点
の追加などのアップデートです。(仕様の文言の明確化などのissueは省いています。)
 リストは全て、コメントくださいというものはなく、こういう議論がありますという情報共有
ですが、何かここでコメント・議論ありましたら必要でしたら転載などは行います。これ以外に
いくつかbopomofo特有の議論はありますが入れてません。


1. ルビ文字の領域に適用されるorされないCSS属性 (css-rubyのではなく一般的な)の確定関係

https://github.com/w3c/csswg-drafts/issues/6005
   What properties apply to annotation containers?
https://github.com/w3c/csswg-drafts/issues/5999
   Applicability of box properties on base containers and annotation containers

 一つ目が全般的な、二つ目がbox関係(背景色やアウトラインとか)についてです。特にCJK特有
の何かがあるわけではないとは思います。


2. 長いルビがついたときにruby-merge:mergeは親文字をどう処理するか
https://github.com/w3c/csswg-drafts/issues/6004

 長い親文字に短いルビがついた場合についての論点が先般のメールではいくつかありましたが、
その逆の場合です。ruby-mergeを親文字にもつけられるようにするのか、もしくはしない場合は
以下の２パターンのうちどちらにすべきなのかというような意見募集です。
> |[This is a long merged annotation]| <- no extra space, nothing to align
> |[ Base 1  ]|[ Base 2 ]|[ Base 3  ]| <- uses ruby-align on each base like for a spanner?
>              ?or maybe?
> |[      Base 1 Base 2 Base 3      ]| <- treats the bases as merged as well?

 個人的にはstart (とcenter?)以外のjustify-では適宜空白が振られてみた感じ変わらない結果
になるんじゃないかという気はしますが、、。


3. ルビ文字の先頭・末尾の空白除去 (それぞれのrt/rtcでのという話です)
https://github.com/w3c/csswg-drafts/issues/6002

 日本語だと関係ないですが、、non-CJが載ってるときにcss-textの行頭・行末の空白削除規則を
適用するかどうかという点、です。


4. 下線位置 / https://github.com/w3c/csswg-drafts/issues/5996

 CJKに限った話というよりはnon-CJKの方が影響でかい話ではありますが、ルビ全体のコンテナで
なく、親文字・ルビ文字に下線の指示がついたときにskipなどをどう取り扱うか、という話題出し
です。


5. 存在するが表示しないルビ / https://github.com/w3c/csswg-drafts/issues/5927

 display: noneだとコンテナ自体が消えてrubyの中のrb/rt対応処理の中でずれる(noneがついた
rtが存在しないものとなってずれる)ということで、一部の漢字のルビだけ消すようなユースケー
スに対してvisibility: collapseというのを追加しようという提案です。
 callでの議論でDAISYとかの事例も出てますので、必要性は認識されている状態だと思っていま
す。
# 関連? : https://github.com/w3c/csswg-drafts/issues/3972



On 2021/02/17 08:45, Kobayashi Toshi wrote:
> 以下の
> 
>> いろいろと考えないといけないという点のリストなどの複雑なポイントはスコープ外
>> とした理由として追記してもいいのかな？
> 
> ちょっと意味がよくわからないのですが，ルビ文字列に複数の単語，つまり語間
> がある文字列の場合，スコープ外としたのは，親文字列とルビ文字列を揃える方
> 法がいくつかあり，複雑だからスコープ外にしたということですか？
> 
> ここをスコープ外にしたのは，そうした事情もあるのですが，実際の経過として
> はちょっと違っていて，最初の原稿では，複数の単語がつく場合は，親文字列と
> ルビ文字列の長さは揃えないで，JIS X 4051の規定した方法，つまり語間は標準
> 的なアキにして処理する方法だけを書いたのですが，村田さんの取材の結果，揃
> える方法も希望があったので，スコープ外としたものです．

 あ、、すっかりこの点を忘れてました、、。単純に具体的記述の複雑性から省いたの
かと思い込んでしまってました。

> 揃える方法と揃えない方法を記述するとなれば，揃える方法を具体的に記述する
> 必要がでてきます．ただ，私としては，揃える必要はあるのか？という疑問は，
> 今でもあります．複数の単語をルビ文字列にする場合は，親文字も長くなり，ル
> ビ文字列と親文字列の長さに極端に違いがでるケースがけっこうあり，そもそも
> 揃えるなんてことが無理な要求ではないかとも思っているのです．（無理して語
> 間を極端に空け，場合によっては，字間も空ける必要性は，どこにあるのか？ 
> そこまでして揃える必要性はあるのか？ という疑問です．）
> 
> 別な言い方をすれば，複数の単語をルビ文字列とすることは，行間注に近くなり，
> この行間注を親文字の長さと揃える必要性は，私はないと思っています．行間注
> では，そもそも参照する箇所，対応する箇所は，親文字列ということもあります
> が，文末とか，用語とかであり，注の合印を考えてもらえばいいように，ある1
> 点が示されればいいものです．ルビとはその点で違います．それを無理してルビ
> のように考える必要性はあるのかと，私は思っています．
> 
> もちろん長さを揃える方法を考える，その規定を作ることは，それはそれでよい
> のではとも思いますが，……
> 
> ということで，下農さんの提案の意味が揃える方法がいくつかあり，ということ
> でスコープ外としたということ，それを追記してはということであれば，追記し
> てもよいが，あまり気持はそそられない感じです．

 方法がいくつかある、というよりは、方法を考えるにしても複雑な要検討点がたく
さんある(あって収拾がつかない)ので省いたが、問題点として少なくともxxxのよう
な点は上げられる、というような表記の提案のつもりでした。
 ただ、実際に複数の既定値の希望が見受けられたので、というのもあると、一切書
かない方が座りは良さそうですね。。