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

すみません、もう一転しました。

おっしゃる通り、村上さんのケースと一條さんのケース、両方を一つの仕様でカバーすることができません。かといって、そのためにプロパティを足す、というほどまだニーズやケースとしての分析ができているとも思えません。

二つのケースを考えると、村上さんのケースの方がより一般的であり、かつpaged mediaでこれができないとそれはかなり致命的ではないかと思われるため、そちらを優先する、という方向に傾いています。

今また仕様を直しています[1]が、
●shrink-to-fitを素直にほぼそのまま使う。
●multicolでoverflow挙動に頼ってしまうと、そのブロックの後ろの文章にかぶってしまうので、よろしくない。村上さんの下図の結果を得られるようにmulticolの仕様を変えるよう働きかける
●さらに村上さんの下図で2ページ目と3ページ目に段組みをしたいケースもカバーしたい。これも今のmulticolではできないので、働きかける
●結果として、一條さんが挙げてくれたケース（親DIVに高さ指定があり、その中に横書きと縦書きのDIVを並べていっぱいにしたい）はカバーできなくなります。横書きと縦書きそれぞれのDIVの高さを指定してもらうことが必須になる、というイメージです。
●Continuous mediaではavailable heightの既定値はビューポートの高さなので、それをページに見立てた動きになる
というのが現況です。

何度も変わってすみませんが、このような仕様で、大事なケースがカバーできていないことがないかどうか、ご検討いただけるとすごく助かります。

よろしくお願いいたします。

[1] http://dev.w3.org/csswg/css3-writing-modes/

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

縦書きブロックの前で改ページしても次のページ１ページに収まりきらないという場合は次のようになることが望ましいと思います。

<body>
  <p>横書きのページ
  ...
  このあと縦書き</p>
  <div style="writing-mode: vertical-rl">
    <p>吾輩は猫である。名前はまだ無い。</p>
    <p>どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。</p>
  </div>
  横書きに戻る。
</body>

　１ページ目　　　　２ページ目
┏━━━━━━━┓┏━━━━━━━┓
┠横書きのページ┨┃と　　　前　　┃
┠───────┨┃見　ど　は　吾┃
┠───────┨┃当　こ　ま　輩┃
┠───────┨┃が　で　だ　は┃
┠───────┨┃つ　生　無　猫┃
┠───────┨┃か　れ　い　で┃
┠このあと縦書き┨┃ぬ　た　。　あ┃
┠───────┨┃。　か　　　る┃
┃　　　　　　　┃┃何　と　　　。┃
┃　　　　　　　┃┃で　ん　　　名┃
┗━━━━━━━┛┗━━━━━━━┛

　３ページ目　　　　４ページ目
┏━━━━━━━┓┏━━━━━━━┓
┃て　て　所　も┃┃横書きに戻る。┃
┃い　い　で　薄┃┃　　　　　　　┃
┃る　た　ニ　暗┃┃　　　　　　　┃
┃。　事　ャ　い┃┃　　　　　　　┃
┃　　だ　ー　じ┃┃　　　　　　　┃
┃　　け　ニ　め┃┃　　　　　　　┃
┃　　は　ャ　じ┃┃　　　　　　　┃
┃　　記　ー　め┃┃　　　　　　　┃
┃　　憶　泣　し┃┃　　　　　　　┃
┃　　し　い　た┃┃　　　　　　　┃
┗━━━━━━━┛┗━━━━━━━┛

このような結果になるように、縦書きブロックに段数1の段組の指定をするということは、考えられそうです。

石井さんwrote:
>   coloumns: 1;
> でavailable-widthの段ができて、そこからoverflowすれば次の段が追加されるような仕様に見えます。合ってますかね？

CSS Multi-column Layout Module
8.2. Pagination and overflow outside multicol elements http://dev.w3.org/csswg/css3-multicol/#pagination-and-overflow-outside-multicol

	A multicol element can have more columns than it has room for due to: 
	...
	* the size of the page. In this case, additional column boxes are moved to the next page(s). 

この決まりにより、coloumns: 1 の指定であっても、1ページに入りきらない場合には追加の段ができて次のページに移動する、この結果、横書き文書の中での複数ページに渡る縦書きのブロックというのが可能になるということですね。


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


MURAKAMI Shinyu <murakami@antenna.co.jp> wrote on 2011/01/16 17:13:55
> 石井さんwrote:
> > 横にあふれる場合に自動的に段組を入れる、というのはtoo muchだと思われるので、製作者が段組指示を入れていなければ切れてしまう、それを防ぎたいなら、製作者が段組指示を入れること、ということになると思われます。
> > 
> 
> いえ、私が意図してるのは、自動的に段組を入れるというのではなくて、次のようなことです：
> 
> I wrote:
> > あるいは、ページメディアでは親Blockに height の指定がなくてもページの高さの残りの高さを使うということになるでしょうか？
> > その場合は、（段組ブロックに height の指定があるのと同様）ページの下のほうに配置される縦書きブロックは残りの高さが小さいので1行の文字数が少なくなり、その分、行数が多くなって、横方向にオーバーフローしやすくなり、そのような場合にその縦書きブロックをまるごと次のページ（段組の場合は段）に送るということになるならよさそうです。
> 
> これを図示すると、次のようになります：
> 
> 横書きのページの途中から縦書きのブロック（内容：「吾輩猫である。名前はまだ無い。」）がある場合、まずページの残りの高さを使ってレイアウト：
> 
> ┏━━━━━━━━┓
> ┠横書きのページ─┨
> ┠────────┨
> ┠────────┨
> ┠────────┨
> ┠────────┨
> ┠────────┨
> ┠─このあと縦書き┨（↓横にオーバーフロー）
> ┠────────┨
> ┃い　だ　は　名　る　で　は　吾
> ┃。　無　ま　前　。　あ　猫　輩
> ┗━━━━━━━━┛
> 
> このように残りの高さが小さいと１行の文字数が少なくなって、そのぶん行数は多くなるので横にオーバーフローしやすい。
> そこで、この問題を解決するために、このようにオーバーフローが発生する場合には、縦書きブロックを丸ごと次のページに追い出す。次のようになる：
> 
>   １ページ目　　　　　　２ページ目
> ┏━━━━━━━━┓┏━━━━━━━━┓
> ┠横書きのページ─┨┃は　吾　　　　　┃
> ┠────────┨┃ま　輩　　　　　┃
> ┠────────┨┃だ　は　　　　　┃
> ┠────────┨┃無　猫　　　　　┃
> ┠────────┨┃い　で　　　　　┃
> ┠────────┨┃。　あ　　　　　┃
> ┠─このあと縦書き┨┃　　る　　　　　┃
> ┠────────┨┃　　。　　　　　┃
> ┃（この部分アキ）┃┃　　名　　　　　┃
> ┃　　　　　　　　┃┃　　前　　　　　┃
> ┗━━━━━━━━┛┗━━━━━━━━┛
> 
> もうひとつ考えられる解決方法としては、残りの高さで組まれる縦書きブロックが横にオーバーフローするような場合は、横にはオーバーフローしないように高さをより大きくする。その結果として下にはみ出すことになるが、この場合は通常の改ページ処理により次のページに送られる。結果は次のようになる。
> 
>   １ページ目　　　　　　２ページ目
> ┏━━━━━━━━┓┏━━━━━━━━┓
> ┠横書きのページ─┨┃だ　名　で　吾　┃
> ┠────────┨┃無　前　あ　輩　┃
> ┠────────┨┃い　は　る　は　┃
> ┠────────┨┃。　ま　。　猫　┃
> ┠────────┨┠────────┨
> ┠────────┨┃　　　　　　　　┃
> ┠─このあと縦書き┨┃　　　　　　　　┃
> ┠────────┨┃　　　　　　　　┃
> ┃（この部分アキ）┃┃　　　　　　　　┃
> ┃　　　　　　　　┃┃　　　　　　　　┃
> ┗━━━━━━━━┛┗━━━━━━━━┛
> 
> 以上、ページメディアにおいてページの残りの高さを使う場合に、1行の文字数が少なくなる分、行数が多くなって、横方向にオーバーフローするという問題を解決する方法を考えたのですが、おそらく、このような処理はUAの実装に任されるということになるかと思います。
> 
> 
> 
> --
> 村上 真雄 (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 14:42:09
> > 違うかな。今のままでいいような気がしてきました。
> >   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_margin
> > > s
> > > 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 Tuesday, 18 January 2011 07:28:23 UTC