Re: ルビと行間についてご意見ください

中野です。

On 2010/12/17 13:20, Miwako Ichijo wrote:
> 2.　【質問】　詳細指定ができるようになるまでは、line-heightの設定だけで切り替えられてしまう？
> 
> メールを読むうちにちょっと混乱していたのですが、
> 詳細指定の仕様ができる前、もしブラウザが実装してくれたら、line-heightの設定だけで、
> コンテンツ内にルビがある場合は、設定が自動で切り替わる、
> ということでしょうか？
> 行間を均等にするつもりがなくても、指定数値以上になったらなるのでしょうか？

rubyのボックスモデルを考えるのであれば、inline-blockを作って見ると分かり
やすいです。例えば、

data:text/html,<body style="line-height: 1.5;">first line<br>second
line<span style="display: inline-block; border: blue 1px solid;">here
is<br>inline block</span><br>third line</body>

このURLをIE以外で表示してみてください。

2行目が自動的に拡張され、明らかにfont-sizeの1.5倍以上の行高になっている
ことが分かるかと思います。inline-blockではなく、画像のようなinlineの置換
ボックスを置いた場合も同様です。

rubyを今のCSS仕様で素直に実装すれば、HTMLで言えば、ruby要素で生成される
CSSのボックスはinline-blockとよく似た挙動になります。つまり、rubyの実装
の有無にかかわらず、現在と何も変わりません。


> 3.　【質問】　複数の文字サイズが混在するコンテンツの場合、”均等な行間”のサイズはどうなるのでしょう？
> 
> 上の質問にも少し関連しています。
> 
> センテンスの強調でそこだけ、文字サイズを大きくする場合があります。
> 表示幅によっては、多くなった文字だけの行もあれば、混在する行がでてきます。
> この場合の”均等の行間”はどう決まるのでしょうか？

普通に考えるのであれば、全行の行高のうち、最も高いものを採用しなくては重
なる部分ができてしまいます。この場合、この全行の、という点が最大の問題です。

tableが表示が遅い、というのは誰しもが分かることですが、あれはセル同士で
通信しあってサイズを決めなくてはいけないため、左上から順番にレイアウトが
固まっていく通常のレイアウトよりも時間がかかってしまいます。

もし、全てのコンテンツから行高を計算するとなると、まずは全てを今まで通り
の配置で計算し、その上で一番大きな行を探さなくてはいけません。つまり、
tableと似たような(あそこまで複雑ではありませんが)が必要になります。当
然、その再計算はDOMツリーやスタイルがjsで書き換えられる度に発生します。

また、例えば一行だけインラインで画像を入れたりすると、かなり高い行が出現
することになります。このような行高も他の行に影響を及ぼすことになるでしょう。

果たしてこのような制限やパフォーマンスに影響のあるプロパティが必要なのか
疑問です。

> また、こういった場合、
> 現状のIE実装と同じように表示したい（そのほうが見やすいと判断された）のだけれど、
> 指定したいline-heightの数値は設定が切り替わる値のため、制作者側では制御できない
> という状況がありえますか？

specified value、computed valueは変わっていません。line-heightをblock
boxに指定した場合、単に最低値を指定しているだけなんです。inline boxに指
定した場合を無視して分かりやすい名前をつけるなら、min-line-heightプロパ
ティなんです。この件についてはline-heightプロパティの定義の最初の段落で
説明されています。
http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height

# 各valueの定義は仕様書にあります
# http://www.w3.org/TR/CSS21/cascade.html#value-stages

> 
> 
> 認識不足の点もあるかと思いますが、
> よろしくお願いします。
> 
> 2010年12月17日8:59 Koji Ishii<kojiishi@gluesoft.co.jp>:
>>> line-heightプロパティの仕様からすると、何を議論しようとされているのか理
>>> 解しかねます。
>>
>> すみません、おっしゃる通りちょっと脱線が過ぎました。塩澤さんご個人に返信すればよかったと反省しています。
>>
>> 本題は、ruby line height
>> http://dev.w3.org/csswg/css3-ruby/#ruby-line-height
>> に対して、現在提案されているinclude-rubyとexclude-rubyの他にauto値を定義しましょう、というご提案でした。
>>
>> 釈迦に説法で恐縮ですが、include-rubyはご教示くださったとおり、ルビを通常のboxとして扱うものですが、exclude-rubyは少し違う動きをします。これを自動的に切り替える値を導入したい、とういのが趣旨です。
>>
>> 脱線が過ぎましたこと、およびそれにより不快な思いをされた方には、重ねてお詫び申し上げます。
>>
>>
>> -----Original Message-----
>> From: public-html-ig-jp-request@w3.org [mailto:public-html-ig-jp-request@w3.org] On Behalf Of Masayuki Nakano
>> Sent: Friday, December 17, 2010 3:24 AM
>> To: public-html-ig-jp@w3.org
>> Subject: Re: ルビと行間についてご意見ください
>>
>> 中野です。
>> # 石井さん個人に返信してしまったので再送します
>>
>> line-heightプロパティの仕様からすると、何を議論しようとされているのか理
>> 解しかねます。line-heightプロパティの仕様はご存知でしょうか?
>>
>> もし、inline boxにline-heightがnormal以外で指定されたのであればそれはそ
>> ういう固定値として扱われるべきで、重なり合うのも制作者の意図としか解釈は
>> できません。逆に、block boxにline-heightがnormal以外で指定されているので
>> あれば、それは行の最低高を示す訳ですから、ruby boxをinline-blockと同等の
>> ものと考えるのであれば(それが自然だと思いますが)高さが足りない場合に自動
>> 的にその行だけ行高が拡張されることになります。
>>
>> ですので、現行の仕様で何も問題が無いように思えます。
>>
>> # 均等な行送り、というのは問題が多いと思います。画像等のオブジェクトが挿
>> 入されている段落では洒落にならないことになります。各デザイナが自分のド
>> キュメントの自分のスタイルに対して十分な高さの行高をblock boxに対して指
>> 定しておく、というのが現実的でしょう。予定外の行があれば、そこだけ行高が
>> 自動的に拡張されますが、その予定外のことがある時点でデザインとしては失敗
>> なんじゃないでしょうか。
>>
>> ちなみに、line-heightの初期値はnormalですが、これはブラウザの実装に(今ま
>> で通り)依存すべきでしょう。日本語だけの都合でごちゃごちゃと定義すべきで
>> はありません。ブラウザは印刷物等とは異なり、実行時のパフォーマンス等の問
>> 題もありますので、できるだけ逐次計算結果を確定できるほうが望ましいと言え
>> ます。
>>
>> そもそも、日本の印刷業界の慣習をもとに議論するのはナンセンスだと思いま
>> す。あらゆるドキュメントに適切にlang属性が指定されているのであればブラウ
>> ザも言語ごとに動作を切り替えられますが、現実のwebはそうではありませんの
>> で日本の印刷慣習を仕様に盛り込んでしまうと、それは日本の文化の押しつけに
>> 他ならないと思います。
>>
>> On 2010/12/09 0:49, Koji Ishii wrote:
>>> こんにちは、W3C CSS WGのメンバーの石井です。
>>>
>>> 英語MLも見られている方はお気づきかもしれませんが、今CSSの方でルビと行間についての議論が続いています。日本に影響がある部分なので、簡単にまとめます。ちょっと長いですが、できればお読みいただいて、ご意見があれば、ここでも構いませんし、英語ML www-style@w3.org でも構いませんので、いただけると助かります。
>>>
>>> 元はこのスレッド
>>> http://lists.w3.org/Archives/Public/www-style/2010Nov/0482.html
>>> で、ルビが入った行がIEでは等間隔に並べられない問題に関するものです。ルビばかりでなく圏点にも影響します。
>>>
>>> ご存知とは思いますが、IEでルビを使うと、行送りが一定になりません。これは携帯など、画面が非常に小さい場合などは有用な仕様であったりもするのですが、小説サイトのようなより本格的なページを作る時には、ルビの有り無しにかかわらず、一定のピッチで行を表示したい、という要望があります。IEではそれが実現できないため、tableタグを使っているサイトを見たことがあります。
>>>
>>> これに対して、今CSS3 line boxで提案されているline-stacking-rubyプロパティの「include-ruby」と「exclude-ruby」を定義して、「exclude-ruby」を指定すれば重なってもいいから行を等間隔に並べる、という指定をする案がありますが、これに「auto」があった方がいいのではないか、という提案です。「auto」は、原則を「exclude-ruby」にして、行高計算にルビは影響しない、とする。ただし、前の行に重なってしまう場合には、その分だけずらす、という案を出しました。
>>>
>>> これに対し、AppleのDavid Hyattから賛同を得られたのですが、今の彼の考えを聞いていくと、ブロックをまたぐケースなど、いくつか制限があり、それを解決するのが技術的に難しい、という返事が得られました。難しいけど、できないことはない、という返事で、きちんと仕様を固めればできそうでもあるのですが、構造的にあまり難しいものを入れてしまうと、HTML製作者にとって却って結果を予測しづらくなったり、仕様としてもうまく動かないケースの混入が心配されます。
>>>
>>> そこで、長期的視野では上記CSS3 line boxやCSS3 line gridなどの充実によりより細かい動作を指定できるプロパティを作っていく仮定の上で、まずデフォルトの「auto」挙動として、より簡単なルールを考えてみました。それは
>>>
>>> * line-heightが150%以上だったら、ルビを行送りに影響させず、行を一定間隔で表示できるようにする
>>> * それ未満だったら、ルビの重なりを防ぐため、現行IEと同様の挙動とする
>>> http://lists.w3.org/Archives/Public/www-style/2010Dec/0185.html
>>>
>>> という案です。正直この案だと、line-heightが150%〜160%くらいの時には、前のブロックのフォントが小さい時など、それでも重なってしまうケースが出てしまうと思いますが、
>>> * 十分な行高さがある時には、書籍のような一定の行送り
>>> * 十分な行高さがない時には、ルビのある行だけを高くする（現行IE挙動）
>>> という切替をカバーし、重なってしまうケースは現実にはそれほど多くないのではないかと思っています。
>>>
>>> CSS3 line box仕様が今後進めば、この挙動をautoとして定義し、製作者がより厳密に定めたい時にはinclude-rubyあるいはexclude-rubyを指定すれば切り替えることが可能になりますし、それまでの間、および製作者が指定しない時にはline-heightが切り替えのスイッチになる、ということになります。この案で実装してくれるブラウザーが出て、それでルビが重なってしまった場合、CSS3 line boxが完成するまで切替はできないので、line-heightを増やすか、marginを入れて回避するか、ということになってしまいますが、それでも書籍のような一定の行送りのページがブラウザで実現できる、というのは大きなメリットになるのではないかと思います。
>>>
>>> この案について、例えば
>>> * line-heightで切り替える、というのは妥当かどうか。
>>> * 150%という数字は妥当かどうか。ルビ付きの文章は普通150%なんて狭い行間は使いません、ということでしたら、より大きい数字にすれば重なるリスクを減らせます。
>>> といった点が特に気になっていますが、それ以外でもどんなことでもいいので、ご質問、ご意見、お気づきになられたことがありましたら、フィードバックいただけると助かります。
>>>
>>> よろしくお願いいたします。
>>>
>>>
>>> グルーソフトウェア株式会社
>>> 石井宏治
>>>
>>
>>
>> --
>> Masayuki Nakano<masayuki@d-toybox.com>
>> Manager, Internationalization, Mozilla Japan.
>>
>>
>>
> 


-- 
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Saturday, 18 December 2010 21:15:53 UTC