Re: [Spam]Re: 両側ルビをどうするか

石井さん、

ありがとうございます。W3CとWHATWG ではポリシーが180度違うのですね。長短ありそうですね。またインラインの件はそのようなバックグラウンドがあるのですね。難しく絡まっていますね…

> ただ、実務上から考えると、別スレッドで議論中の「長いグループルビ」の問題が少し絡んでいます。Natが指摘しているように、長いグループルビを適切に改行するのは、アルゴリズムの複雑さからも実行速度の面からも問題が大きい。

気になっているのはこれです。Nat さんにも解説してもらいましたが、問題のありかをまだちゃんと理解できていないんですよ。このままではルビを折り返し可能にしても絵に描いた餅になってしまいます。石井さんから見た、長いグループルビを適切に改行することの問題点を教えていただけるならとても助かります。そして、組版規則の方を変更することでそれを改善できるでしょうか？

木田

> 2022/09/23 17:31、Koji Ishii <kojii@chromium.org>のメール:
> 
> 木田さん
>>> まず、ルビにかかわらずすべての仕様の一般論として、要望があって仕様化可能なものは全て仕様に入れてあるので、各機能の重要性は実装者が判断してほしい、と仕様編者から聞いています。
>> 
>> それって、複数のブラウザが実装しないと規格にならないという規則との折り合いはどうなるんでしょう？　実装されたものだけを抽出して正式な規格にするんでしょうかね？
> 
> 私の理解では、W3CとWHATWGではポリシーが異なるようです。WHATWGは実装者の合意や予定、意思がないと仕様に入れませんが、W3Cが複数の実装を求めるのはPR/RECのみです。ED/WD/CRでは、実装の存在、予定、意思がなくても入れられるようです。Writing Modesでは、PR/RECに移行する際に実装者の合意がないものを削る、という作業をしました。とはいえ、CSSでも、Chrome以外に実装者がいないという理由でEDに入られないケースもあったので、W3C側の運用は柔軟なんだろうと理解しています。
> 
>>> Chrome/Safariは、WebKit実装当時のW3Cでの議論に基づき、ブロック扱い（DIVやPと同様）になっていますが、Firefoxはインライン扱い（SPANと同様）になっているようです。
>> 
>> 本来から言えばインライン要素であるべきですよね、きっと。
> 
> ルビ本来の用途を感覚的に理解すると、おっしゃる通りインラインだと思います。ただ、実務上から考えると、別スレッドで議論中の「長いグループルビ」の問題が少し絡んでいます。Natが指摘しているように、長いグループルビを適切に改行するのは、アルゴリズムの複雑さからも実行速度の面からも問題が大きい。とはいえ、改行できずにオーバーフローしてしまうと、電子書籍などでは画面外になってしまい、見切れてしまいます。これはコンテンツが見切れて読めないため、出版社から「致命的」「不可」レベルの問題であるとして指摘されています。このため、出版社と相談の上で、Blink/WebKitでは、ルビ内の改行をサポートしています。サンプルはこちら <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22width%3A%2010em%3B%20border%3A%201px%20solid%20blue%22%3E%0A%20%20%3Cruby%3E%0A%20%20%20%20%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E9%95%B7%E3%81%84%E6%96%87%0A%20%20%20%20%3Crt%3E%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E3%81%A8%E3%81%A6%E3%82%82%E9%95%B7%E3%81%84%E3%83%AB%E3%83%93%3C%2Frt%3E%0A%20%20%3C%2Fruby%3E%0A%3Cdiv%3E>。紙の印刷の既成概念からすればあり得ない組版だとは思うんですが、出版社からは、これなら「可」であると聞きました。これを実現するには、ブロックでないと技術的に難しい。実装当初はどちらでも大差ないと思われていましたが、現在では、ブロックの方がこういった柔軟性が高いと思っています。
> 
> また、HTML/CSSでは、インラインの要素は、すべて本文の流れ（フロー）に含まれると解釈されています。絶対座標指定やフロートなどの別のフローを作り出す要素はすべてブロック要素です。検索や読み上げなどで、本文の流れ（フロー）に含みたくないことを考えると、ブロックの方が相性が良いのでは、と思うこともあります。
> 
> もちろん、インラインであることによるメリットもあるのかもしれません。個人的にどちらであるべきかの強い意見を持っているわけではありませんが、こういった議論やメリット・デメリットの検証がないまま、歴史的経緯によって実装が分かれてしまったのが残念ですね。