Re: 縦横混在時の auto 値の解釈

一條です。

>　石井さん

以下のような、”制作時には注意してください”は全く問題ないと思います。（個人的意見ですけれども。。）

>> その場合に自動的に段組みを適用、というのも可能性として検討しましたが、いろいろと難しい部分があ>>りそうなので、縦横混在文書を作る方で、印刷・電子書籍を気にする方は、段組みの併用が前提となる可>>能性が今のところは高いです。

実際、今でもスクロール可能メディア（ブラウザ）のものを印刷してもらう時に、そのレイアウトはどうするか？というのは考えます。（印刷時に全情報が見えること、印刷に必要と思われる内容だけにすること、ページできれた時に、変な切れ方にならないようにすること、などを対応します。）
今までと全く違うステップが制作プロセスに入るわけではないので、制作者側の負担になることはないと推測しています。


蛇足ですが、
縦横混在と段組という点では、印刷用に設定するだけでなく、画面上の表示でも入れる可能性はあるものと思っています。

もともと、「読む時にはどれくらいの文字数/1行が読みやすいのか（目で追いやすいのか）」
　　　　　　→※現時点では横書きの1行で話題に。縦に関して話はしていません。
という問題があります。それが書き方向が入り組むレイアウトの場合は特に気をつけないと、読むにもストレスが溜まるはずです。その時の解決方法として段組の利用を検討するのではと思っています。



2011年1月15日16:04 Koji Ishii <kojiishi@gluesoft.co.jp>:
> 昨夜もこの問題についてElikaと議論しました。
>
> やはり複数の方向に伸びていく、というのは、スクロール可能なメディアではサポートできますが、Paged Mediaでは難しいだろう、というのが今のところの結論です。つまり、そのHTMLをEPUBやiBookに持っていった場合、あるいはそのHTMLを印刷した場合には、スクロール部分はすべてカットされて見られなくなる可能性が高いです。
>
> 量が可変な部分、あるいはユーザーがフォントサイズを変えたら文書の主方向とは違う方向にあふれることが想定される場合、一段組でもいいので段組みのプロパティを入れておいて、あふれたら二段になるようにしておかない限り、切れてしまう可能性がある、というのが制作側への注意となりそうです。
>
> その場合に自動的に段組みを適用、というのも可能性として検討しましたが、いろいろと難しい部分がありそうなので、縦横混在文書を作る方で、印刷・電子書籍を気にする方は、段組みの併用が前提となる可能性が今のところは高いです。
>
> 幸いCSS3 Multi Columnも進んできて実装も入ってきているので、縦組みが使えるころには、段組みも使える可能性が高いと思われます。
>
>
> -----Original Message-----
> From: public-html-ig-jp-request@w3.org [mailto:public-html-ig-jp-request@w3.org] On Behalf Of Miwako Ichijo
> Sent: Friday, January 14, 2011 5:58 PM
> To: public-html-ig-jp@w3.org
> Subject: Re: 縦横混在時の auto 値の解釈
>
> 一條です。お疲れ様です。
>
> ＞　石井さん
>
> 自分で書いておきながら、overflowも含めて解説されると、
> 混在させること自体が難しいことなんだなと溜め息を付きつつ、
>
>>> ユースケースで一條さんが考えてくれたケースを元に考えると、width/heightを両方指定した場合は問題>>ないとして、どちらか片方の場合でも、オプションがいくつかあります。
>
> 以下の分を読んでいます。
> PCを含めた、広げようと思えば縦・横ともにコンテンツを乗せる範囲を広げられる環境相手に考えることと、
> 「ページ」の範囲で考えることの違いも考慮しないといけないんですね。
> 自分で書いた部分を含めて、もっと考えて見ます。
>
> なお、oveflowの設定、サイズ決定してるところで容量が増える可能性がある場合、
>
> 1)　読み物系はauto
> 2)　内容物が欠けても、許容範囲としてくれる部分はhidden
>
> をもともと入れることが多いです。
> ブラウザ依存ではありますが、autoだとオーバーする時にスクロールバーを表示するものをターゲットにして考えていることが多いので（PC上のブラウザです）、scrollではなく、autoにしています。
>
> 何も設定しないで「あらら」という現象、Web制作者だと身にしみている人も多いでしょうね。
>
>
>
>
> 2011年1月13日11:04 Koji Ishii <kojiishi@gluesoft.co.jp>:
>> この問題は、おそらく当初考えていた以上に厄介です。Specに提示されている三つの選択肢はどれも正解ではない気がしてきています。
>>
>> Overflowとなるケースについて、縦スクロールでもいいや、と割と考えていましたが、村上さんと話して、overflow[1]の仕様を再度読んでみて、どうもそれほど単純でない気がしてきました。
>>
>> というのは、「溢れたらスクロール」というのはウィンドウ全体として既定の動作として実装されているので自然に見えますが
>> ●overflowの既定値はvisibleであるため、親divを溢れた場合、下（縦書きの場合は左）にある文章に重なって表示される。スクロールしたい場合にはoverflow:scrollを設定しないといけない。
>> ●Paged media（印刷時、電子書籍など）ではスクロールできない、あるいは非常に不便（タッチパネルもマウスもないなど）な場合がある。
>> この二つを考えると、あまりoverflowしやすい仕様は使いにくい可能性があります。
>>
>> ユースケースで一條さんが考えてくれたケースを元に考えると、width/heightを両方指定した場合は問題ないとして、どちらか片方の場合でも、オプションがいくつかあります。
>>
>> ●横書き中の縦書きでheightだけを指定された場合
>> これは簡単そうに見えます。行数に合わせて幅が増えていく。でも幅がページ幅を超えたらどうしましょうか。
>> PCなら横にどんどん伸びていってもいいかもしれませんが、最初の行がずっとスクロールした一番右にある、というのも使いづらそう。
>> 印刷時や電子書籍ではどうしましょうか。紙幅で区切って、自動的に段組みに切り替えるんでしょうか？
>>
>> ●横書き中の縦書きでwidthだけを指定された場合
>> これはそもそも厄介そうです。その幅に行が入るように行帳を調整する、なんてのはとても大変です。横書きではデフォルトで横幅の挙動が決まっていますから、それに合わせて改行し、高さは固定。収まらなければoverflow挙動になります。なので、やはり指定幅にかかわらず、なんらかのauto挙動を定めなければいけません。なので、これはwidthのありなしにかかわらず、auto挙動を決めなければいけないユースケースだと思います。
>>
>> ●高さが長くなってページ高さを超えた場合
>> 高さが長くなってページ高さを超えた場合も考えなければいけません。村上さんのshrink-to-fitだと、改行指定がなければ縦書きの行は延々としたに伸びていきます。Paged Mediaの下に到達したら？　そもそも紙の高さよりも高くなったら？　印刷時に切っちゃうとその内容は失われてしまうので、やはり自動的に段組みに切り替えるのが一番よさそうですが、実装は大変かもしれないですね。
>>
>> まだ結論を出せていませんが、いろいろ読ませていただいているうちに、少しずつイメージが出てきている気はしますね。
>>
>>
>> [1] http://www.w3.org/TR/CSS2/visufx.html#overflow
>>
>> -----Original Message-----
>> From: Miwako Ichijo [mailto:usa132006@gmail.com]
>> Sent: Wednesday, January 12, 2011 5:44 PM
>> To: MURAKAMI Shinyu; Koji Ishii; public-html-ig-jp@w3.org
>> Subject: Re: 縦横混在時の auto 値の解釈
>>
>> 一條です。
>> 今年もよろしくお願いします。
>>
>> ＞　石井さん、村上さん
>>
>> 解説ありがとうございます。反応が遅れてすみません。
>> 改めて"shrink-to-fit width"のあたりを確認していたら、力不足でなかなか読み進まず（苦笑）
>>
>> 石井さん、村上さんのメールを繋げて、順にコメントを送ります。
>> 流れるようなコメントになりますが、その中で
>>
>> ・　親のdivにheight指定があったらケースの問い合わせを考えた時の背景
>> ・　先に挙げたケースは有効ケースかどうか
>> ・　村上さん提示の"shrink-to-fit width"を元に考える案の感想
>> ・　石井さん提示の3択なら、どの指定が分かりやすいと思うか
>>
>> が分かるように書けていれば幸いです。
>>
>> 1. 塩澤さんのタグ例でauto=100vh　のイメージ
>>
>> 「結果としてスクロール」のイメージで違いがなさそうで、了解です。
>>
>> 2.　親のdivにheight指定があったらケースが思いついた背景
>>
>> 実は、このスレッドの最初の3択をイメージする時に、ふと思い浮かんだのが
>> float指定とwidth指定の関係でした。村上さんがメールで指摘されている"shrink-to-fit width" です。
>> 縦横混在のレイアウトのCSSを設計する時のイメージが"shrink-to-fit width"を念頭にfloat段組をしている時に近いなと感じました。
>>
>> そこからの連想で、heightだったらどうなるんだろう？？という程度で、実際に使うシーンが浮かんでいたわけではないです。
>>
>> #　思いつき程度でタグを考えたせいか、出来上がりイメージが、真ん中divがあまっている領域をカバーするためにストレッチするようなイメージ（子要素divの内容が少なめのため）のケースになっているような。。。今頃、そう思っています。
>>
>> 3.　2.のケースは有効か？
>>
>> 改めて問われて、うーん・・・と考えたのですが、
>>
>> (1)　読み物系のコンテンツ（例えばニュース）では親要素でwidthとheight両方指定はしないかも。（前提として、内容量が一定していない）
>>
>> (2)　広告パーツ、ブログパーツというような表示領域だけは固定指定の場合はありえます。が、発生しないかも？
>>
>> という感想です。結論から言うと、私が取り扱っているコンテンツでは、有効なユースケースとは言い難いかと。
>>
>> (1)　の場合はだったら、作るときは
>>
>> ・　子要素にwidth　or　heightサイズ指定して、各子要素の内容が可変しても、
>> 横または縦方向に領域を広げて内容が隠れない、他の要素にかぶらないようにする
>>
>> ・　親はデザイン内容により、width　or　height
>> のいずれかはきちんと設定して、子要素群のサイズが可変しても領域オーバーさせない、または親はいずれもautoにしている
>>
>> ・　レイアウト全体を見て、子要素のサイズが可変させるとレイアウト崩れが発生する（例えば他要素とかぶる可能性が発生する）と分かる場合は、子要素にheight、widthの両方を指定する
>>
>> と思いました。内容量がCSS組み上げ時に固定ではないので、内容量がCSS組み上げで使っているサンプルデータより少なくても、多くても破綻しないようにしないようにすると
>> widthとheight、いずれか一方はautoか100%にしていることが多いですね。
>>
>> ただ、縦・横混在となると、縦のものは横方向へ伸びる、横は縦方向へ伸びる
>> とすることになるかと思います。その時、どちらかしか伸ばせないケースで、伸ばせない方向の
>> サイズの指定を追加することになりそうです。
>>
>>
>> (2)　の場合は、どの位置にどの範囲で表示することが運営上決まっていて、
>> その中はビジュアルデザイナー任せだったりする場合があります。
>> その場合、その中に表示する要素のサイズが可変だったりすると、上記のように指定したくなるかもしれません。
>>
>> が、今までの実体験上、表示する要素が可変でも最大サイズを元に要素のサイズをがっつり決めて、
>> 運用を依頼することが多いです。広告原稿を作るほうに頑張ってもらってました。
>> というのも、表示できる範囲のサイズを必ず守るために、反対に可変する要素があると見た目のコントロールがしにくい、という理由です。
>>
>> #　今、自分が係わる広告パーツ制作の場合、一見の見た目を画像イメージで提示されたのと同じように作ることが多いです。
>>
>> ----
>> #　親サイズは決まるけど・・・の事例は他の方の意見が知りたいです。。
>>
>> 4.　村上さん提示の"shrink-to-fit width"を元に考える案について
>>
>> CSSの仕様として自然、といえるほどの力はないので、個人の感想レベルにて。
>>
>> 私は、分かりやすいルールになるのではないかと思います。
>> 今回のMLのテーマを読んでいる時、連想ゲームで浮かんだ（上記参照）ぐらいです。
>>
>> 内容が可変といっても、上から下への単純なレイアウトでない限り、
>> 内容を含んだ要素にサイズ指定をしてレイアウトするのは通常行なわれていることだと思います。
>> そうした作業の中で、サイズ指定をきちんとしないと思った通りにならないケースは、
>> floatでイヤというほど身にしみており、
>> 「縦・横混在はサイズを指定しないと、思ったようにレイアウトされないケースがある」
>> と説明されても、すごく困ることはないです。
>> その症状を
>>
>> →　例：floatで並べる時を参考にしてみると、概要が分かります
>> →　"shrink-to-fit width"という考え方がありまして
>> →　それと同じように、XXXXX（高さのautoに関するルールの名称）というルールがあるので
>>
>> の流れで解説できるなら、「そういうものか」と納得しやすそうです。
>> 今まであった考え方と類似性が高いと、なじみやすいのではないでしょうか。
>>
>>
>> 5.　石井さん提示の3択
>>
>> 4.まで考えての提示の3択、いずれかに票を入れるならを考えたました。
>>
>>> 1. max-content sizeを使う
>>> 2. 100vh[1]を使う
>>> 3. その時点でのwidthを使う
>>> の三つがあります。
>>
>> 1.か2.でどちらか選べません（笑）
>> 100vhの件、イメージ通りだったこともあり、直感的に分かる算出値であることにも賛成なのですが、
>> 「うまくいかない！」を認知させるには、1.のほうがパンチが効くかと思いまして。
>>
>> 個人的にも、1.で発生する状態を3回くらい繰り返したら、漸く最初から指定を忘れないようになるような気がします。（表示時のショックを3回受けて覚える。）
>> 飴と鞭みたいな感じです。（鞭のほう、このケースで飴は・・・ない、ですかね（苦笑））
>>
>>
>> 長くなりました。よろしくお願いします。
>>
>> 2011年1月7日13:41 MURAKAMI Shinyu <murakami@antenna.co.jp>:
>>> 村上です。
>>>
>>> 縦横混在時の width/height の auto 値の解釈ですが、CSS2.1 仕様での float や inline-block の width の auto 値の解釈方法である "shrink-to-fit width" を元にして考えるのが CSS 仕様として自然ではないかと思っています。
>>>
>>> http://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and_margins
>>> 10.3 Calculating widths and margins
>>> ...
>>>  10.3.5 Floating, non-replaced elements ...
>>>   If 'width' is computed as 'auto', the used value is the "shrink-to-fit"
>>>   width.
>>>
>>>   Calculation of the shrink-to-fit width is similar to calculating the
>>>   width of a table cell using the automatic table layout algorithm.
>>>   Roughly: calculate the preferred width by formatting the content
>>>   without breaking lines other than where explicit line breaks occur, and
>>>   also calculate the preferred minimum width, e.g., by trying all
>>>   possible line breaks. CSS 2.1 does not define the exact algorithm.
>>>   Thirdly, find the available width: in this case, this is the width of
>>>   the containing block minus the used values of 'margin-left',
>>>   'border-left-width', 'padding-left', 'padding-right',
>>>   'border-right-width', 'margin-right', and the widths of any relevant
>>>   scroll bars.
>>>
>>>   Then the shrink-to-fit width is: min(max(preferred minimum width,
>>>   available width), preferred width).
>>> ...
>>>  10.3.9 'Inline-block', non-replaced elements in normal flow
>>>
>>>   If 'width' is 'auto', the used value is the shrink-to-fit width as for
>>>   floating elements.
>>> ...
>>>
>>> この shrink-to-fit width の計算式が、縦横混在時の logical width の auto の解釈に使えるだろうと思います。
>>>
>>> 正確を期するため、width を logical width に直して計算式を書きます：
>>>
>>> shrink-to-fit logical width =
>>>           min(max(preferred minimum logical width,
>>>                   available logical width),
>>>               preferred logical width)
>>>
>>> この式での preferred logical width と preferred minimum logical width については、上記 CSS2.1 に書かれているとおりでよいと思います。
>>> preferred logical width は、強制改行以外で改行しない場合に必要な寸法、
>>> preferred minimum logical width は、改行可能なすべての箇所で改行した場合に必要な寸法。（長い分割不可能な単語があればその長さになる）
>>>
>>> 問題は available logical width をどう定義するかということになります。
>>> これも CSS2.1 の inline-block の場合を考えると参考になると思います。
>>>
>>> <p>
>>>  AAA
>>>  <span style="display: inline-block">
>>>    BBB<br/>
>>>    BBBBBBBBBBBBBB<br/>
>>>    BBBBBB BBBBBB BBBBBB
>>>  </span>
>>>  CCC
>>> </p>
>>>
>>> CSS2.1 の定義ではこの場合の available width は containing block の幅から、inline-block の margin、border、padding、scroll bar（もしあれば）の分の幅を引いた幅です。
>>> この例では containing block の幅とは p のブロックの幅ということになります。（"AAA" や "CCC" の存在は無関係）
>>>
>>> 横書きの中の縦書きのブロックの available logical width は、inline-block の場合と同様に考えた場合、containing block の height から margin/border/paddingなどの分を引いた大きさということになります。
>>>
>>> <div style='height: 200px; width: 300px; writing-mode:
>>> horizontal-tb;'>  AAA  <div style='writing-mode: vertical-rl;'>
>>>    BBB<br/>
>>>    BBBBBBBBBBB<br/>
>>>    BBBBBB BBBBBB BBBBBB
>>>  </div>
>>>  CCC
>>> </div>
>>>
>>> この例のように、height が明示的に指定されていれば、それを使うので問題ないと思います。
>>> 問題は、containing block の height が明示的に指定されていない場合です。その場合は、containing block の height の代わりに、viewport height (100vh) を使うということにすると良いのではないでしょうか。
>>> （基本となる書字方向が縦書きで、縦書きの中の横書きのブロックが問題になる場合は、width と height が逆であり viewport width (100vw）を使う）
>>>
>>> ページ媒体の場合、viewport の大きさというのは、ページのマージン領域を除いた本文領域の大きさということになるので、この大きさを使うようにすれば、縦書き／横書きが切り替わったブロックが複数ページに渡るときも問題がありません。
>>>
>>> いかがでしょうか。
>>>
>>> --
>>> 村上 真雄 (MURAKAMI Shinyu)
>>> Twitter: http://twitter.com/MurakamiShinyu
>>> Blog: http://blog.antenna.co.jp/CSSPage/
>>> Antenna House Formatter:
>>> http://www.antenna.co.jp/AHF/
>>>
>>>
>>>
>>
>>
>>
>> --
>> ----------------------------------------------------
>> Miwako Ichijo(usa132006@gmail.com)
>> *****************************************
>> 一條　美和子(ichijo.miwako@sankei.co.jp)
>>
>
>
>
> --
> --------------------------------------------------------
> Miwako Ichijo @ sankei-digital
> (usa132006@gmail.com)
> email:ichijo.miwako@sankei.co.jp
>



-- 
--------------------------------------------------------
Miwako Ichijo @ sankei-digital
(usa132006@gmail.com)
email:ichijo.miwako@sankei.co.jp

Received on Monday, 17 January 2011 04:01:19 UTC