- From: Koji Ishii <kojii@chromium.org>
- Date: Tue, 20 Sep 2022 17:34:03 +0900
- To: Yasuo Kida <kida@mac.com>
- Cc: Makoto MURATA <eb2m-mrt@asahi-net.or.jp>, Kobayashi Toshi <binn@k.email.ne.jp>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-ID: <CAHe_1dJjTdC6Tky2vsyEO-iCSiDhJJzpO1uMHTMN_snaBmN-gg@mail.gmail.com>
ルビは残念ながら複雑な状況になってしまい、当事者に近いので発言が難しいのですが、非当事者からの一般論としてお読みいただければ幸いです。 まず、ルビにかかわらずすべての仕様の一般論として、要望があって仕様化可能なものは全て仕様に入れてあるので、各機能の重要性は実装者が判断してほしい、と仕様編者から聞いています。このため、「この仕様のすべてを実装する」という判断を実装者がすることは、稀だと思われます。個別の機能について、この機能はこういう理由で重要である、という声を実装者に向けて、可能なら制作当事者から発信することが良いかと思います。あくまで一般論ですが、実際に制作に関わる方々から、困っている、回避策もない、あるいは非常に困難、という声が多くあがれば、優先度が上がる可能性は高くなると思います。 次にルビについてですが、木田さんがご指摘のように、現在のCSS RubyはW3C版を前提に書かれているため、WHATWG版を実装している実装者にとっては読解が困難になっています。両仕様の差異に関わらない部分については分離するなり、WHATWG版のCSS Rubyがあれば、理解は進みやすくなると思います。 最後に、村田さんご指摘の親文字とルビの間を空ける機能についてですが、Chromiumのルビ関連issue <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ELayout%3ERuby&can=2> で探すと、おそらくこれ <https://bugs.chromium.org/p/chromium/issues/detail?id=1233420> が該当するかと思います。ここではline-heightを使いたいと書いてありますが、line-heightはFirefox含めどのブラウザーでも動作しませんでした。 現状の回避策としては、Firefoxはpaddingあるいはmarginが使えて、Chrome/Safariではtransformが使えるようです。逆にFirefoxはtransformを無視して、Chrome/Safariをpadding/marginを無視するようなので、両方指定すれば全部のブラウザーで動作するようです。 サンプルはこちら <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%20font-size%3A%2020px%3B%20margin-top%3A%2030px%3B%20%7D%0Aruby%20%3E%20ruby%20%7B%0A%20%20ruby-position%3A%20under%3B%0A%20%20-webkit-ruby-position%3A%20after%3B%0A%7D%0Aruby%20%3E%20rt%20%7B%0A%20%20padding-bottom%3A%2010px%3B%0A%20%20transform%3A%20translate(0%2C%20-10px)%3B%0A%7D%0Aruby%20%3E%20ruby%20%3E%20rt%20%7B%0A%20%20padding-top%3A%2010px%3B%0A%20%20transform%3A%20translate(0%2C%2010px)%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Cruby%3E%0A%20%20%3Cruby%3E%0A%20%20%20%20%E4%BA%94%E7%B5%8C%0A%20%20%20%20%3Crt%3E%E3%81%94%E3%81%8D%E3%82%87%E3%81%86%3C%2Frt%3E%0A%20%20%3C%2Fruby%3E%0A%20%20%3Crt%3E%E3%81%94%E3%81%91%E3%81%84%3C%2Frt%3E%0A%3C%2Fruby%3E> 。Chrome/Safariは、WebKit実装当時のW3Cでの議論に基づき、ブロック扱い(DIVやPと同様)になっていますが、Firefoxはインライン扱い(SPANと同様)になっているようです。transformはインラインには適用されないので、このような違いが生まれているのではないかと推測されます。 ...ちなみに、このトピックは「JLREQにおいて両側ルビをどうするか」ですよね? 私の発言は、そのトピックに限定して返信したもので、私個人として、W3C版、WHATWG版いずれの仕様を推すものでもないものとしてご理解いただければ幸いです。 On Tue, Sep 20, 2022 at 2:11 PM Yasuo Kida <kida@mac.com> wrote: > もし ruby の入れ子を認めるなら、それに合わせて css を変えなくてはではないですか? > > 2022/09/20 12:56、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール: > > もう一点気になるのはCSS ruby > との親和性です。ルビと親文字の > 間隔を空けるのは一部のディスレクシア > 対策として必要ですが、これには > CSS Rubyが必要になります。 > > ruby要素のネストは、 > CSS rubyで扱えるでしょうか? > > 村田真 > > 2022年9月19日(月) 13:38 Yasuo Kida <kida@mac.com>: > >> おお、なるほど。入れ子とはコンピューターっぽい。構造としては ruby タグが入れ子にできるならそれはそれでいいのではない?(だめ? > 村田さん) >> >> # 32、じゃない、三重にしたら何が起こるんだろう? 三次元目を使って画面の上に浮き出る? >> >> 木田 >> >> 2022/09/18 21:13、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール: >> >> >> >> 2022年9月13日(火) 14:15 Koji Ishii <kojii@chromium.org>: >> >>> 古いスレッドへのレスですみませんが >>> >>> > ブラウザベンダは嫌がっているのが現状だと思います。Firefoxだけが例外です >>> >>> 両側ルビは、全ブラウザで対応していますよ。サンプルはこちら >>> <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aruby%20%3E%20ruby%20%7B%20ruby-position%3A%20under%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cruby%3E%0A%20%20%3Cruby%3E%0A%20%20%20%20%E4%BA%94%E7%B5%8C%0A%20%20%20%20%3Crt%3E%E3%81%94%E3%81%8D%E3%82%87%E3%81%86%3C%2Frt%3E%0A%20%20%3C%2Fruby%3E%0A%20%20%3Crt%3E%E3%81%94%E3%81%91%E3%81%84%3C%2Frt%3E%0A%3C%2Fruby%3E> >>> 。 >>> >> >> これは一つのruby要素内に両側ルビが入るのではなく、ruby要素 >> のネストですね?。W3C HTML Ruby Markup Extensionsのやり方 >> とは違いますね?また、CSS Rubyは未対応ですね? >> >> 村田 真 >> >> >> >>> >>> On Fri, Jul 29, 2022 at 11:48 AM Kobayashi Toshi <binn@k.email.ne.jp> >>> wrote: >>> >>>> 木田泰夫 様 >>>> みんさま >>>> >>>> 小林 敏 です. >>>> >>>> 以下の扱いでいいのではないかな. >>>> つまり,こうした場合に使っているケースが実際にあるが,例は多くない,…みたいに >>>> >>>> いずれにしろ,時間をみてというか,本を読むついでにということですが,例を集めてみます. >>>> >>>> 木田泰夫 さんwrote >>>> >>>> >では… まだ使われているものをここの判断で要らないなどと言えないですよね。 >>>> > >>>> >jlreq-d では、まずは片側のルビについて説明して、それとは分けて高度な組版を説 >>>> >明するセクションで説明しますかね。極力シンプルな形で。また頻度の低いことは説 >>>> >明しても良いでしょう。どうでしょう。 >>>> > >>>> >木田 >>>> >>>> >> >> -- >> Regards, >> Makoto >> >> >> >
Received on Tuesday, 20 September 2022 08:34:28 UTC