- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: Thu, 13 Jan 2011 13:43:11 +0900
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- CC: "public-html-ig-jp@w3.org" <public-html-ig-jp@w3.org>
On 2011/01/12 16:12, Koji Ishii wrote: >> 極論とは言え、Unicodeの機能を使っちゃうとそもそもDOMの意味が無くなってし >> まうので問題外だとは思うのですが > > ああ、なるほど、DOMは考えていませんでした。でも結果としては、結局どこまでのアプリケーションを想定するか、というのと、マークアップの複雑度を許容するか、というそのバランスをどこに置くべきか、というお話ですよね。 > * ルビ文字を著作物として考えれば、タグが必要 > * ルビ文字を振り仮名だけだと定義して、スタイリングを捨てれば属性でもいい > * さらにDOMも捨てればUnicode Ruby Annotationでもいい > という、三段階ある、ということでしょうか。 著作物、という発想がよく分かりませんが、title属性の中身等でも立派に著作 物ではないのでしょうか。別のメールで書かれているように、読みを示すための ルビと、別の意味等を与える、平文でも見えるべきコンテンツを同じrubyという 要素で表現しているところにそもそもの間違いがあるのかもしれません。 何しろ、意味の違う二つの「意味」を同じマークアップで表現しようとしている のが現状の仕様案で、そこに複雑なスタイル指定を可能にしようとしていますので…… # DOMを捨てる、は現実的にはあり得ないので上二つでしょうか。 >> 私は分岐を否定している訳ではなくて、HTMLを平文にしてみた場合に分岐してし >> まうことが問題だと思っています。つまり、タグを全部単純に除去した場合に平 >> 文としておかしいケースが仕様上ありえます。属性値の場合はこの処理では絶対 >> に削除されてしまうことになるので問題にはなりません。 > > 想定するアプリケーションが変われば逆の結果が期待されるんです。ルビ＝振り仮名として捉えれば平文にしたら消えてほしくて、おしゃっている設計が正しくなります。ルビ＝著作物として考えれば、平文化で消えたら問題です。両方のニーズが存在するので、理想は両方できてほしい。でもルビのために二つの違う実装をする、というのも非論理的。そこが難しいところで、判断する前に、みんながこの「複数の応用用途があり、応用用途によってそれぞれ期待される結果が違う」ということにまず合意が必要だと思います。 アプリケーションとはHTMLで書かれたドキュメント、という意味でしょうか。そ れなら分かります。 >> XPathはまったく知らないのですが、CSSの場合、属性値を任意のrubyのスタイル >> に変換できる仕様をruby moduleで提案する、ということが(理想的には)可能か >> と思います。 > > HTML WGが言っているのもそれですね。それはそれで分かりますが、HTMLからタグを一つ取り除いて、CSSに新しいルビ専用のセレクターを追加して、結果としてユーザーに対してもブラウザー実装者に対しても、まったくシンプルになっていませんよね。HTML WGにとってシンプルになっただけです。どちらかと言えば、タグが一つ減るよりも文法が一つ増える方が複雑です。その点があまり正しい最適化には見えません。 私はスタイルというのは少々複雑でも良いのではないかと思います。一般的にコ ンテンツを作成する場合にHTMLドキュメントはコンテンツごとにつくらなくても いけませんが、スタイルシートはサイト全体で共有するからです。 HTML上でシンプル、かつ十分な仕様であればそれが一番良いと私は思います。 # 論外にCSSが複雑化しても良いという話ではありませんが >> 例えば、display: ruby;の定義を、通常のinline boxの他に、ruby-text boxを >> 生成するようにし、その内容をruby-contentプロパティで指定できるようにすれ >> ば、ruby-content: attr(reading); で実際のruby-textを生成でき、ruby- >> positionで(横書きの場合)上下や、後ろに付けることを指定することで少なくと >> も現在と同じ表現は可能になると思います。 > > 確かにある程度はできそうですが、ルビ文字にspanをかませたい場合にはやはり従来の文法も必要で、それと並行でこれだけ複雑な仕組みを導入するメリットが私にはよくわかりません。上にも書いたように、HTMLのタグを一つ減らすために、全体の複雑度が上がっていませんか？ 99%の人がHTML+CSSで使うのであれば、これはユーザーにとって本当に複雑度を減らす役に立っているのでしょうか？ 私は現状のブラウザのCSSの実装状況からすると、さほど難しい話ではないと思 います。ほとんど、既存の機能の使い回しで実装できてしまうのではないでしょ うか。 rtに対してマークアップしたい、という要求には確かに属性値案では対応は不可 能です。ただ、これって本当に必要なのでしょうか? フリガナとして考えると、 その内容に対して他の意味を付加するのはなにか違和感を感じます。また、別の 意味のコンテンツを含めるので必要なのであれば、それはもはやinline-tableが 欲しいんじゃないのか? というようにも思えます。 >> 現状のHTML5 rubyの仕様は後方互換に気を使って、古いUAでは"ruby-base(ruby- >> text)"という表示になるように考えられていますが、これはWebデザイナの良心 >> に任せているので仕様としては良くないと思います。今後、各ブラウザがrubyを >> 実装してきた場合、<rp>を使わない人が増えて、結果的に非対応のブラウザでの >> 表示が酷くなっていくように思います。 > > それは私も感じます。一応 :before/:afterがCSSに導入されたので、CSS 2.1対応ブラウザーであれば、なくても対応できる、というのは一つ理由としてあるとは思いますが。 最大の問題は<rp>を使うと非常にマークアップが複雑というか、面倒なことなの で本当に深刻です、この問題は。 >> # ちなみに、属性値の場合、ruby属性があれば良いだけで、ruby要素というもの >> 自体が不要なのではないかな、と思います > > 振り仮名とかTTS (Text to Speech) であれば、それでもいいと思います。著作物としてのルビ文字はそれでは弱い、という点は変わりないですよね。 はい。ですが逆に、フリガナなら現状のruby仕様はオーバースペックであると言 えるのではないでしょうか。そしてそれが<rp>の問題の大きな原因になることを 懸念しています。 実際にrubyが使われる大半のケースは属性値で十分なのではないかと思います。 そう考えると、ruby要素もあり、属性値もある、という方がニーズにはあってそ うな感じもします。ただ、仕様としてはあまり綺麗ではありませんし、個人的に もどうかとは思いますが。 -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Thursday, 13 January 2011 04:43:42 UTC