- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Mon, 13 Feb 2012 01:29:34 -0500
- To: Yasuo Kida <kida@apple.com>, "NARUSE, Yui" <naruse@airemix.jp>
- CC: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, "public-html-ig-jp@w3.org" <public-html-ig-jp@w3.org>
NARUSEさんがよいコメントをくださったので、ちょっと脱線になるかもしれませんが。
私は、Devが細かい質問や将来の質問を投げてきた場合、それに相手が満足するまで答えを提供するのが仕様策定者の義務だと思っています。この辺は仕様とDevの役割分担が会社やプロジェクトによって異なるでしょうし、人によっても意見が違うのは承知していますが、少なくとも私は、Devの生産性を最大限に高めてあげることはboth-winなのでそれでいいと思いますし、自分がコードを書いていても「これ、誰かきちんと調べてくれないかな、そうすればいいコード書けるのに」と思うことは多いので、それを満たしてあげたい。そういう質問を投げる時と言うのは、それがマーケット要件として重要でなくても、それがないとコードのある部分が進まないとか、それによって設計が大きく変わる時とかです。
W3Cでのルビのいろいろな問題の話を聞くようになって、この領域にはDevの質問に答える人がいないんだな、というのは実はずっと思っていました。誰かやってくれれば、と思ったのが一昨年の10月。でも誰もいないままだし、ルビ欲しいと思ってるのは私だし、ということで、少し身を入れることにしました。
そういう意味で、木田さんのおっしゃられる「それは今やらなければいけないことか」という疑問に対しては、木田さんに合意です。でもDevが聞いてきていて、その答えによって現在の単純なルビの実装が変わるかもしれない、ということであれば、マーケット要件的なプライオリティは別にして、仕様策定の優先度を変えなければいけないと思っています。
なので、村田さんのおっしゃる理由のうち
> 1)難しすぎる
> 2)より一般化したアノテーションとして扱うべきである
> 3)基本版面の設計をする作り手から取り上げる(リフロー)のに、
満足できるレイアウトを要求しても無理ではないか。逆に言えば、
両側ルビまで欲しいという人はリフローに満足できるのか。
1はDevからの要望によって考えていますので、私にとっては理由になりません。3もCSSの話なので、セマンティクスとは別の話だと思っています。
2は「セマンティクスとしてやるべきでない」というお話なので、これが強いと困るんですけどね。私としては、これもNARUSEさんのおっしゃる通り、「21世紀版 少年少女文学館 シリーズ」のような例は特殊であり、これはアノテーションでもいいと思いますが、一般的なふりがなやルビは、一般的なアノテーションとは別扱いするに十分な差分と理由を持っていると私は思っています。
-----Original Message-----
From: Yasuo Kida [mailto:kida@apple.com]
Sent: Monday, February 13, 2012 1:34 PM
To: NARUSE, Yui
Cc: Koji Ishii; MURATA Makoto; public-html-ig-jp@w3.org
Subject: 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 06:33:12 UTC