- From: 木田泰夫 <kida@mac.com>
- Date: Thu, 28 Jul 2022 07:57:17 +0900
- To: "Atsushi Shimono (W3C Team)" <atsushi@w3.org>
- Cc: public-i18n-japanese@w3.org
> いまのWHATWG/htmlとしては、 > <ruby>親文字1<rt>ルビ1</rt>親文字2<rt>ルビ2</rt></ruby> > というマークアップで構造化できるという解釈なのだと思っていて、 確かにそれでも全然いいですね。とすると rb は必須ではないようです。 > この観点からいうと、<ruby></ruby>で囲われた一つのブロックの中でグループルビ・熟語ルビにしても閉じていて、間に何もなく二つの<ruby></ruby>が繋がっていたとしてもその間ではつなげたりする処理は一切すべきでない、という解釈にすべきなのではないか、とか思っていたりはします 同意。別れていたら別ルビでしょう。 木田 > 2022/07/28 2:07、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール: > > shimonoです > >> On 2022/07/27 21:54, MURATA Makoto wrote: >> とすると、rb の復活は、親文字がはっきりしないという理由に対しては、論拠が弱いように思えます。下の文章を読みましたが、説得力のある論拠は見つけられませんでした。どれもスクリーンリーダーのバグのように思えますが… >> 一般論だと、木田さんのご意見の通りだと思います。 >> DAISY租界(DAISY教科書とDAISYリーダだけ考え、ルビには必ずrbが >> ある)で考えると別なんですけどね。 >> ただ、rb は熟語ルビや、私のグループルビの提案には必要との理解をしています。 >> これだけでrbの復活には十分ですね。 > > これの論拠がいまいち弱いんじゃないか、という懸念が個人的にぬぐえなくていろいろと悩んでい > るところです。。 > いまのWHATWG/htmlとしては、 > <ruby>親文字1<rt>ルビ1</rt>親文字2<rt>ルビ2</rt></ruby> > というマークアップで構造化できるという解釈なのだと思っていて、単純に親文字について何も弄ら > ないのであれば、先頭から親・ルビの対応関係でピックアップしていけばrb/rt/rtcなどルビ関連タ > グ以外が入っても親文字ははっきりする、というスタンスなのかな、と解釈しています。 > # この観点からいうと、<ruby></ruby>で囲われた一つのブロックの中でグループルビ・熟語ルビに > しても閉じていて、間に何もなく二つの<ruby></ruby>が繋がっていたとしてもその間ではつなげた > りする処理は一切すべきでない、という解釈にすべきなのではないか、とか思っていたりはします > が、前にこのあたりのマークアップと構造的なところの対応の話を出そうとしたときはスルーになっ > たような記憶も、、、? > さすがに、rbが復活したとしても、rb/rt/rb/rtとrb/rb/rt/rtの並び順で構造解釈が異なる、とい > うような話はないと認識しているので、ここの部分は変わらないのかな、と。 > # 議論を見ていると、上記のわたしの認識そのものが何かずれているような気もしてますが・・・>< > > > という点から思うと、"フルスペックの"rb復活の意味としては > ・rb/rt/rb/rtだけでなく、rb/rb/rt/rtのような表記もできる (弱い?) > ・DOMツリーを生成した際に、単なるテキストのエレメントでなくrbというオブジェクトになる > ・CSSOMと合わさるときにエレメントへのスタイル適用という形で自由度が広がる > (rb部分消すとかそういう処理はrbがないと無理ですよね?) > (spanで囲めばスタイル選択できるよ、みたいな反論は来ないと思いたい、、) > ・DAISY界隈としてはアクセシビリティーの処理に渡るツリー構造が変わる(いわゆるアクセシビリティーツリー or AOM) > (いまもchromiumはrbはエレメントとしては捉えられているはずなのでそこまで変わらない??) > ・rtcを入れる場合、でかつ、rbの区切りを弄りたいとき(複数に一つのrtc)にどうしようもなくなる??(ほんとか?) > 位しかひねられないのがわたしの現状の思考の限界なのですが、、考え落とし、勘違いなどなど、ど > んな点がありそうでしょうか。。 > > > AOM: https://developer.mozilla.org/ja/docs/Glossary/Accessibility_tree
Received on Wednesday, 27 July 2022 22:57:43 UTC