W3C home > Mailing lists > Public > public-html-ig-jp@w3.org > January 2011

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Sun, 16 Jan 2011 00:42:09 -0500
To: Koji Ishii <kojiishi@gluesoft.co.jp>, MURAKAMI Shinyu <murakami@antenna.co.jp>
CC: "public-html-ig-jp@w3.org" <public-html-ig-jp@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AAF00986E@MAILR001.mail.lan>
違うかな。今のままでいいような気がしてきました。
  coloumns: 1;
でavailable-widthの段ができて、そこからoverflowすれば次の段が追加されるような仕様に見えます。合ってますかね?


-----Original Message-----
From: public-html-ig-jp-request@w3.org [mailto:public-html-ig-jp-request@w3.org] On Behalf Of Koji Ishii
Sent: Saturday, January 15, 2011 9:37 PM
To: MURAKAMI Shinyu
Cc: public-html-ig-jp@w3.org
Subject: RE: 縦横混在時の auto 値の解釈

Available-widthがない場合(親DIVにheightがない場合)に、100vhをそのまま使うのか、100vhを下限として現在位置からの残りを使うのか、というのは検討が必要そうですね。

行の途中で改ページされないこと、というのは、現状のCSS 2.1の仕様のままで保障されるだろう、という認識です。

横にあふれる場合に自動的に段組を入れる、というのはtoo muchだと思われるので、製作者が段組指示を入れていなければ切れてしまう、それを防ぎたいなら、製作者が段組指示を入れること、ということになると思われます。

が、今のmulti-colの仕様では、「残りを一段組、溢れたら二段目を作る」という指示はできなさそうにも見えますね。Multi-colの仕様変更をお願いするか、この時に特殊動作をするようにwriting modesに記述するか、あるいは自動的に段組みにフォールバックするようにするか、いずれかにしないといけなさそうな気がします。


-----Original Message-----
From: MURAKAMI Shinyu [mailto:murakami@antenna.co.jp] 
Sent: Saturday, January 15, 2011 8:52 PM
To: Koji Ishii
Cc: public-html-ig-jp@w3.org
Subject: Re: 縦横混在時の auto 値の解釈

> ●親Blockにheightがある場合、available-widthをそのheightではなくて、残りにする
> ●村上さんのご指摘通り、available-widthがない場合は100vh
> というのがよさそうではないか、というのが今のところの状況です。

私もそれがよさそうと思います。
残りの高さあるいはそれが得られない場合は100vhから、縦書きブロック自身の上下の margin/border/padding/スクロールバー(もしあれば)の分を引いたのを available logical width として扱うということですね。

以下、段組の場合とページメディアの場合について。

横書きの段組ブロックに height の指定があり、その中に縦書きブロックがあるときは、段の中での残りの高さを使うということになるかと思います。そうすると段の下のほうに配置される縦書きブロックは残りの高さが小さいので1行の文字数が少なくなり、その分、行数が多くなって、横方向にオーバーフローするリスクが大きくなります。
そのような場合に、オーバーフローが起きるようなら、その縦書きブロックをまるごと次の段に送って段のはじめから縦書きブロックを配置するとよさそうです。

ページメディア(電子書籍リーダーも該当)の場合で親Blockに height がない場合、100vh(ページの高さ)を使うということになるでしょうか(ページの残りの高さではなく)。
その場合、横書きのページの途中からはじまる縦書きブロックの高さが100vhだと、そのページには入りきらないことになるため、まるごと次のページに送られるということになります。(ページメディアの場合での段組で height の指定がない場合は、縦書きブロックは次の段に送られ)

あるいは、ページメディアでは親Blockに height の指定がなくてもページの高さの残りの高さを使うということになるでしょうか?
その場合は、(段組ブロックに height の指定があるのと同様)ページの下のほうに配置される縦書きブロックは残りの高さが小さいので1行の文字数が少なくなり、その分、行数が多くなって、横方向にオーバーフローしやすくなり、そのような場合にその縦書きブロックをまるごと次のページ(段組の場合は段)に送るということになるならよさそうです。


--
村上 真雄 (MURAKAMI Shinyu)
Twitter: http://twitter.com/MurakamiShinyu
Blog: http://blog.antenna.co.jp/CSSPage/
Antenna House Formatter:
http://www.antenna.co.jp/AHF/


Koji Ishii <kojiishi@gluesoft.co.jp> wrote on 2011/01/16 4:17:31
> 少し違いました。shrink-to-fitとavailable-widthの定義は村上さんのおっしゃる通りで、available-widthの定義を縦横混在時に少し変えましょう、という話でした。
> 
> ●親Blockにheightがある場合、available-widthをそのheightではなくて、残りにする
> ●村上さんのご指摘通り、available-widthがない場合は100vh
> というのがよさそうではないか、というのが今のところの状況です。
> 
> CSSのこの辺は難しいですね…
> 
> 
> -----Original Message-----
> From: public-html-ig-jp-request@w3.org [mailto:public-html-ig-jp-request@w3.org] On Behalf Of Koji Ishii
> Sent: Saturday, January 15, 2011 4:15 PM
> To: MURAKAMI Shinyu
> Cc: public-html-ig-jp@w3.org
> Subject: RE: 縦横混在時の auto 値の解釈
> 
> shrink-to-fitは、村上さんから説明を聞いた時にはoverflowする、という話だったので、私としては賛成できませんでしたが、Elikaからはoverflowしない、fit-to-contentと同じだ、という説明をしてもらいました。下で参照していただいた式を見る限り、overflowしない、が正しい解釈だと思われます。村上さんの誤解か、私が村上さんから聞き間違えたか、いずれかだと思います。
> 
> まだ仕様には反映していませんが、今のところはfit-to-contentが一番有力です。簡単に説明すると
> ●制約がない場合には、明示的な改行があるまで長い行になる
> ●制約があり、明示的な改行が制約内であれば、そのコンテンツの長さになる
> ●制約があり、明示的な改行が制約よりも長ければ、制約の場所によって改行が行われる
> 最初のケースとしては、橋本さんが以前ご指摘くださった「びっくり」になってしまうデメリットがありますが、それ以外のケースでは、他では実現できない挙動を実現でき、また想定されるユースケースにも一番合うと思います。
> 
> また、原則overflowはしない(行数が溢れるとする場合があります)ので、paged mediaの相性も良いと思います。
> 
> 
> -----Original Message-----
> From: MURAKAMI Shinyu [mailto:murakami@antenna.co.jp] 
> Sent: Friday, January 07, 2011 1:41 PM
> To: Koji Ishii
> Cc: public-html-ig-jp@w3.org
> Subject: Re: 縦横混在時の auto 値の解釈
> 
> 村上です。
> 
> 縦横混在時の 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/
> 
> 
Received on Sunday, 16 January 2011 05:42:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 January 2011 05:42:51 GMT