- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Thu, 6 Jan 2011 22:30:58 -0500
- To: Miwako Ichijo <usa132006@gmail.com>, "public-html-ig-jp@w3.org" <public-html-ig-jp@w3.org>
- Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA8B1C392@MAILR001.mail.lan>
一條さん、いつもながら的確なご指摘、ありがとうございます。 >この時、auto=100vhだった場合の表示イメージがうまくつかめませんでした。 >「結果としてスクロールで隠される領域が常に発生する」のかなと。 そうなると私も理解しています。 >また、 >------------------------------- ><div style='height: 200px;width: 300px; writing-mode: horizontal-tb;'> AAA <div style='writing-mode: >vertical-rl;'>BBB</div> CCC </div> >------------------------------- >のように、親要素に高さ設定、子要素がautoの場合は、 >親要素のpadding領域を除いた領域内の高さ − 「AAA」「CCC」が必要とする高さの合計 = 子要素divの高さ >なるのでしょうか? 正直このケースは考えていませんでした。 この問題は、そもそもページを作る時に、縦横混在であれば、その論理幅は指定するだろう、指定漏れは原則指定忘れと思われるので、最も望ましいエラー表示、という観点で考えていましたが、もしかしたら、実用用途があり、そのユースケースを考えなければいけないのかもしれない、という気がしてきました。 一條さんのタグを元に作った添付のHTMLで、TOP+MID+BOTTOMの高さを200pxにしたい場合、今のオプションではどれを取っても実現できない気がします。 これって有効なユースケースなんでしょうか? ●そもそもそんな使い方は存在するか? ●横書きでも3列に並べて真ん中を自動調整、というのは難しい(できない? CSSボックスモデルに強い方、教えてください)なら、CSSにそぐわないとして、縦横混在でもできなくていいのでは? といったあたりが疑問として浮かんできます。 -----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 07, 2011 11:06 AM To: public-html-ig-jp@w3.org Subject: Re: 縦横混在時の auto 値の解釈 石井さん お疲れ様です。一條です。 塩澤さんが最初に記述してくださった参考タグ例の細かい表示イメージが浮かばなかったので、 お問い合わせです。 ■ 塩澤さんの例 ------------------------------- <div style='width: 300px; writing-mode: horizontal-tb;'> AAA <div style='writing-mode: vertical-rl;'>BBB</div> CCC </div> ------------------------------- の場合、縦書きboxの上下に「AAA」テキストと「CCC」テキストが表示されるかと思います。 この時、auto=100vhだった場合の表示イメージがうまくつかめませんでした。 viewport's height → コンテンツ表示領域(ウィンドウの内側)の高さ とすると、 auto=100vhでした場合、 -------------------------------------------- ■ 「AAA」の下から、コンテンツ表示領域の高さ相当の「BBB」が配置される。 ■ 「BBB」の下に「CCC」が表示さる。この時「CCC」は実質、コンテンツ表示領域外になり、縦スクロールが発生する。 ------------------------------------------ という表示イメージでよろしいのでしょうか。 横書きだけの場合(現状、一般的なテキストコンテンツの場合ですね) * ボックスを記述していくと、何もしなければ上から下に表示が伸びるだけ、 * 横幅に関してはauto指定でもよっぽど狭くしない限りはwindowリサイズしてもスクロールは発生せずに横全体が見える (ボックスの横にボックスを置く設定を自力でいれない限り、横は1ボックスになっているため) となるかと思います。width:autoは「表示領域内の幅に関してはめいっぱい使うだけでスクロールで隠れない」な表示イメージがあるので、今回の例のような場合、ちょっとだけ?が浮かびました。 「結果としてスクロールで隠される領域が常に発生する」のかなと。 また、 ------------------------------- <div style='height: 200px;width: 300px; writing-mode: horizontal-tb;'> AAA <div style='writing-mode: vertical-rl;'>BBB</div> CCC </div> ------------------------------- のように、親要素に高さ設定、子要素がautoの場合は、 親要素のpadding領域を除いた領域内の高さ − 「AAA」「CCC」が必要とする高さの合計 = 子要素divの高さ なるのでしょうか? 2010年12月23日17:29 塩澤 元 (Shiozawa, Hajime) <hajime.shiozawa@gmail.com>: > ご返信ありがとうございます。 > >>2は便利ですが、HTMLエディタやプレビューでそこそこ希望の高さになってしまった時に、 >>そのまま気が付かずにサーバーにアップロードしてしまい、例えば縦長1200x1600の画面の人がページを開くと驚く、 >>という結果につながるリスクがあります。 > > その驚きは、多くの Web ページ製作者はすでに経験していると思うので、そこまで気にしなくてもいいのではないでしょうか。 > そして、たとえその状態だけであっても『そこそこ希望の高さ』になるのであれば、autoという値であることの価値が十分あると思います。 > 2の挙動であれば、レイアウトは崩れますが、最低限、縦書き部分の文章自体は読めると思います。 > しかし、1の挙動では auto 値ではほとんどの場合、縦書き部分の文章が読めないことになってしまいます。 > > auto というプロパティ値は「自動的にある程度適切な表示をする」という目的をもっていると思います。 > そのプロパティ値で、高さを指定することを促すためだけに、1のような挙動にするのは乱暴かなと思います。 > > >>ちなみにspecには書いてありませんが、通常マージンなどがあるので、 >>100vhだとほぼ常に縦スクロールが必要になると思われます。それを避けるため、 >>90vhなどの案もあることはあるのですが、90である根拠が薄いので、結局そういうのを気にする人は高さを指定するだろうから、 >>計算は単純でいいのではないか、ということで100vhなんだと私は理解しています。 > > そうですねほとんどの場合スクロールが必要になると思いますが、それでかまわないと思います。 > 『viewport の高さと同じ』というのはすごく直感的だと思います。 > > >>他の方のご意見もぜひお聞かせください。 >>赤字について議論することは、仕様がより速いタイミングで完成に近づくことへの助けになりますので、みなさんの助けをお待ちしています。 > > 私もぜひ他の方の意見を聞いてみたいです。 > Web は、編集者や職人がレイアウトをそのつど決めることが出来る出版物と違い、ブラウザがある仕様に沿って動的にレイアウトを決定する必要があります。 > 実際にはあまり使われないようなケースであっても規定する必要があり、この縦横混在レイアウトの議論は css3-writing-mode > の仕様が進む上でかなり重要な議論だと個人的には思っています。 > > > 塩澤 > > > -- > # 青山学院大学大学院 > # 理工学研究科 知能情報コース > # 塩澤 元 (Shiozawa, Hajime) > # mail: hajime.shiozawa@gmail.com > -- ---------------------------------------------------- Miwako Ichijo(usa132006@gmail.com) ***************************************** 一條 美和子(ichijo.miwako@sankei.co.jp) 株式会社産経デジタル 情報システム部 tel 03-3275-8169 fax 03-3275-8862
Attachments
- text/html attachment: auto-width-v.htm
Received on Friday, 7 January 2011 03:29:35 UTC