Re: 二重ルビについて (was RE: 両側ルビの実例をご存知の方にお願い (was RE: HTML5 and ruby

NARUSEさん、

>> <rt> が二つあったときにどうするか、がモティベーションなら、三つ四つあったらどうするんでしょう？　単純に、無視する、でいいんじゃないでしょうか？

> 「無視する」は「単純」ではないように思います。


確かに単純ではありませんね。

ノードが一つだけ期待される場所に複数のノードが現れたらどうするかという問題の解決に、二重ルビを考える必要性は特にないのではないか。また、そうしたとして、一般的に N 個のノードが現れた時の解決にはならないのではないか。ということが言いたかったのでした。特定の解決方法の提案をしたいわけではないので二番目のセンテンスは蛇足ですね。

> 表示するならば勿論大変でしょうけれど、それは CSS での話ですよね。
> HTML の解釈や DOM の構築と言ったレイヤーの実装において、何が大変なのでしょうか。


私が話の根本を誤解しているのかもしれません。単に HTML のシンタックスから DOM をどう構築するかというところで終わる話なら、確かに <rt> がいくつ出て来ようが困らないように思えます。そうすると理屈では一般的に N 重ルビというものが存在することになりますね。話がそこで終わるなら、今想像がつく限りでは特に異論はありません。

> という実例解釈に由来していると思うんですが、その解釈は偏っていると思います。

確かにその通りで、最初のメールを出した後に実例を改めて見てみると、語義解説だけではなく、広くアノテーションと捉えた方が良いように思いました。ゆえ、多くが語義解説であろうとした最初のメールと、一般的なアノテーションの記述がどうあるべきかと書いた最後のメールの結論が少々食い違っているというわけです。

木田

On 2012/02/12, at 12:06, "NARUSE, Yui" <naruse@airemix.jp> wrote:

> 2012年2月13日4:01 Yasuo Kida <kida@apple.com>:
>> On 2012/02/12, at 10:16, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
>> 
>>>> セマンティック以前に、今コストと時間をかけて二重ルビをサポート
>>>> すべきなのか、今のプライオリティはそれなのか
>>> 
>>> これは分かります。ただ問題が絡んでいて、例えば
>>> <ruby>親文字<rt>a</rt><rt>b</rt></ruby>
>>> とか
>>> <ruby><rt>a</rt>親文字<rt>b</rt></ruby>
>>> とか書かれたらどう解釈するべきか、という議論を突き詰めていくと、二重ルビをどうするか、ということに一定の結論が出ないと、答えが出せなくなってしまっています。エラーとすればよい、としても、エラーケースの挙動も決めてあげないと実装ができないので、決めてくれ、というのがdev communityからの要望だと理解しています。rbの必要性もこれに絡んでいますし、現在のHTML5仕様がunder specifiedなので、それを完成させる意味で、検討が必要だと思っています。
>> 
>> <rt> が二つあったときにどうするか、がモティベーションなら、三つ四つあったらどうするんでしょう？　単純に、無視する、でいいんじゃないでしょうか？
> 
> 「無視する」は「単純」ではないように思います。
> 「無視する」に類する具体的な解釈方法はぱっと考えただけでも以下のようなものがあり得ます。
> 1. エラーとする
> 1.1. 文書全体をエラーにする
> 1.2. その ruby 要素をエラーにして親文字だけ残す
> 1.3. 複数の rt を全て DOM に含めない
> 1.4. 最初の rt だけ残して後は DOM に含めない (3.1 と同じ)
> 2. 複数の rt を一つのルビとみなす
> 2.1. 親文字全体に複数の rt が一体となってかかっているとみなす
> 2.2. 複数の要素であることを無視し、一つの rt にまとめて DOM にいれる
> 3. 複数の rt を複数のルビとみなす
> 3.1. テキスト上で最初に現れた rt を残して、残りは DOM から落とす
> 3.2. DOM には残し、CSS 上では display: none とする
> 
> 2. では、「<ruby>親文字<rt>a</rt><rt>b</rt></ruby>」は HTML の意味論としては、
> 「<ruby>親文字<rt>ab</rt></ruby>」と同じ意味ということになります。
> 
> 
> 木田さんは 3.2. を前提にして仰っているように聞こえるのですが、
> CSS 上での display: none って HTML のセマンティックス上は「無視」ではありませんよね。
> 木田さんの仰る「単純に、無視する」とは HTML においてどのような意味なのでしょうか。
> 
> 
> さておき、改めてこの複数 rt を考えていくと、上でのまとめで明らかなとおり、複数の rt 要素があったとき、
> それは意味的に 2. 一つのルビなのか、3. 複数のルビなのかという所に行きつきます。
> これが、石井さんの仰る「議論を突き詰めていくと、二重ルビをどうするか、ということに一定の結論が出ないと、
> 答えが出せなくなってしまっています」ということなのだと思いますがあっていますでしょうか。
> 
> 
>> 一つのルビでさえ、まともにやろうとするととても大変なんですよ。二重ルビの html 記述など決めたところで使い物になるレベルの実装はウルトラCだと思います。重要度を困難さで割って考えると、決めたところで実装されるかどうか疑問です。
> 
> 表示するならば勿論大変でしょうけれど、それは CSS での話ですよね。
> HTML の解釈や DOM の構築と言ったレイヤーの実装において、何が大変なのでしょうか。
> 
> なお、プレゼンテーションの話になってしまいますが、DOM レベルで 3.2. 複数のルビという扱いにさえなっていれば、
> ブラウザのデフォルトでは非表示だったとしても、やる気がある人は position:absolute などを駆使して、
> 複数のルビを思い通りに配置することも不可能ではありません。
> 3.2. 以外の場合、その情報が意味として残らないので、どう頑張っても不可能になります。
> 
>>>> 同じ目的を達成するのにより望ましいユーザーインターフェースは考えられるか、
>>>> などの検討は済んでいるんでしょうか？
>>> 
>>> これはほんとは個人的に一番興味がある部分なんですが、役割としては、製作者がCSSで、あるいはUAベンダーがUAの機能として実験し、追求していくものではないかと思います。例えばスクロールバーですらHTML/CSSには一言も書いておらず、UAベンダーが定めるものになります。それで例えば、タッチの時には表示しない、という自由度が生まれてきています。
>> 
>> そうなんですが、例を見ていると、ルビを流用した html の記述方法が良いのか、その基本の部分が疑問です。村田さんの言われたように、アノテーションと見ることができます。より一般的なアノテーションの記述がどうあるべきか、その中で考えてみるのは意味のあることだと思います。また、例を見ると語の説明が多いですね。つまりグロッサリーと見ることもできます。グロッサリーも IDPF でプロジェクトが始まるところです。
>> 
>> これらの見方の方がきちんと現象のセマンティックを捉えているように思えます。
> 
> この結論は、先に木田さんがまとめていらっしゃる、
> 
>>>> 今までに見つけていただいた例を見ると、こんな風にまとめられますかね。
>>>> ・ある程度の使用例が見つけられる。
>>>> ・ほとんどの場合が語義解説、つまりグロッサリーのいち表現形態。
>>>> ・その組版（語義のかかる範囲の示し方、左右の使い方など）の方法は様々で確立されたルールがあるわけではない。
>>>> 
>>>> 
>>>> これは両側ルビといった組版技術の問題としてではなく、グロッサリーとして表現形態を考える、というアプローチの方が実りがあるような気がします。電子媒体なら、マウスオーバーやタッチなどのジェスチャーで語義がポップアップするなど、紙にはできない表現が可能です。
>>>> 
>>>> 場合によっては難しい単語の読みもルビとして表さずに随時呼び出せるグロッサリーに任せてしまうという表現の仕方もありますね。
> 
> という実例解釈に由来していると思うんですが、その解釈は偏っていると思います。
> つまり、このまとめは間違っていると思います。
> 
> あらためて石井さんがまとめてくださった実例を眺めると、
> http://www.w3.org/International/wiki/Rb#Real_Examples
> 青空文庫の例、教科書の例、ハリーポッターの例、全て「語義解説」ではないように思います。
> これらはまごう事なく、専ら対象の語の読みを指示する「ルビ」でしょう。
> 
> これらの例を差し置いて、この意味から外れた試験や「21世紀版 少年少女文学館 シリーズ」といった、
> 語義の例に絞って議論するのはおかしいと思います。
> 
> -- 
> NARUSE, Yui  <naruse@airemix.jp>

Received on Monday, 13 February 2012 04:34:05 UTC