RE: HTML 5 におけるルビの rb タグについて

> 極論とは言え、Unicodeの機能を使っちゃうとそもそもDOMの意味が無くなってし
> まうので問題外だとは思うのですが

ああ、なるほど、DOMは考えていませんでした。でも結果としては、結局どこまでのアプリケーションを想定するか、というのと、マークアップの複雑度を許容するか、というそのバランスをどこに置くべきか、というお話ですよね。
* ルビ文字を著作物として考えれば、タグが必要
* ルビ文字を振り仮名だけだと定義して、スタイリングを捨てれば属性でもいい
* さらにDOMも捨てればUnicode Ruby Annotationでもいい
という、三段階ある、ということでしょうか。


> 私は分岐を否定している訳ではなくて、HTMLを平文にしてみた場合に分岐してし
> まうことが問題だと思っています。つまり、タグを全部単純に除去した場合に平
> 文としておかしいケースが仕様上ありえます。属性値の場合はこの処理では絶対
> に削除されてしまうことになるので問題にはなりません。

想定するアプリケーションが変われば逆の結果が期待されるんです。ルビ＝振り仮名として捉えれば平文にしたら消えてほしくて、おしゃっている設計が正しくなります。ルビ＝著作物として考えれば、平文化で消えたら問題です。両方のニーズが存在するので、理想は両方できてほしい。でもルビのために二つの違う実装をする、というのも非論理的。そこが難しいところで、判断する前に、みんながこの「複数の応用用途があり、応用用途によってそれぞれ期待される結果が違う」ということにまず合意が必要だと思います。


> XPathはまったく知らないのですが、CSSの場合、属性値を任意のrubyのスタイル
> に変換できる仕様をruby moduleで提案する、ということが(理想的には)可能か
> と思います。

HTML WGが言っているのもそれですね。それはそれで分かりますが、HTMLからタグを一つ取り除いて、CSSに新しいルビ専用のセレクターを追加して、結果としてユーザーに対してもブラウザー実装者に対しても、まったくシンプルになっていませんよね。HTML WGにとってシンプルになっただけです。どちらかと言えば、タグが一つ減るよりも文法が一つ増える方が複雑です。その点があまり正しい最適化には見えません。


> 例えば、display: ruby;の定義を、通常のinline boxの他に、ruby-text boxを
> 生成するようにし、その内容をruby-contentプロパティで指定できるようにすれ
> ば、ruby-content: attr(reading); で実際のruby-textを生成でき、ruby-
> positionで(横書きの場合)上下や、後ろに付けることを指定することで少なくと
> も現在と同じ表現は可能になると思います。

確かにある程度はできそうですが、ルビ文字にspanをかませたい場合にはやはり従来の文法も必要で、それと並行でこれだけ複雑な仕組みを導入するメリットが私にはよくわかりません。上にも書いたように、HTMLのタグを一つ減らすために、全体の複雑度が上がっていませんか？　99%の人がHTML+CSSで使うのであれば、これはユーザーにとって本当に複雑度を減らす役に立っているのでしょうか？

> 現状のHTML5 rubyの仕様は後方互換に気を使って、古いUAでは"ruby-base(ruby-
> text)"という表示になるように考えられていますが、これはWebデザイナの良心
> に任せているので仕様としては良くないと思います。今後、各ブラウザがrubyを
> 実装してきた場合、<rp>を使わない人が増えて、結果的に非対応のブラウザでの
> 表示が酷くなっていくように思います。

それは私も感じます。一応 :before/:afterがCSSに導入されたので、CSS 2.1対応ブラウザーであれば、なくても対応できる、というのは一つ理由としてあるとは思いますが。

> # ちなみに、属性値の場合、ruby属性があれば良いだけで、ruby要素というもの
> 自体が不要なのではないかな、と思います

振り仮名とかTTS (Text to Speech) であれば、それでもいいと思います。著作物としてのルビ文字はそれでは弱い、という点は変わりないですよね。

Received on Wednesday, 12 January 2011 07:13:42 UTC