- From: Miwako Ichijo <usa132006@gmail.com>
- Date: Thu, 6 May 2010 13:10:09 +0900
- To: public-html-ig-jp@w3.org
一條です。 村上さん、回答ありがとうございます。 回答を読みつつ、 ・ Webブラウザで縦書きをコンテンツの一部に利用する場合（基本は横書き表示のコンテンツ） ・ ページ内のコンテンツ配置の意味がある場合 には気を付けることも多いと思いました。 （こういう企画のサイトもそうそうないのかもしれませんが、現職の関係で縦・横混在表示がつい浮かんでいます。） > 1. Media Queriesを利用した縦書き・横書き判断 Media Queriesの利用についてはCSSWG内で合意ができなくて残念です。 これが使えると、 縦で表示ができる場合に適用したいスタイルと通常表示での基本スタイルといった分離がしやすいと考えていました。 スタイルシートレベルでの分離がしにくいとなると > 3.2. 擬似クラス があると便利ですね。縦モードが有効になっていたら、必要な指定を擬似クラスを利用して追加適用することで、 指定間違いを防げそうです。ぜひ欲しい擬似クラスですね。 Webブラウザでの表示を考えた時、classセレクタだけではレンダリングされている状態が把握できず、制作者側もclassだけでコントロールするのは難しいです。 > 3.1. 相対プロパティ あ、右と左問題が残るんですね、logical。。 どうも視野が狭くなっていたようです。納得です。 そうなると、相対プロパティを指定しているブロック要素で、コンテンツ配置を重要視する場合は注意が必要ですね。 全部が同じモードで行けば問題は出なさそうですが、 混在している場合はスタイルのコーディングで今まで以上にレンダリング結果のパターンをイメージしないと 思わぬところで、閲覧し難い結果をユーザーに出してしまいそうです。 例えばpositonを使って、ブロック要素を動かし、テキストの先頭を見せようという場合、 1) 日本語の横書きはtop=0、left=0 2) 日本語の縦書きはtop=0、right=0 のようにする必要が出てくるかもしれません。ブロック要素自体は相対プロパティ指定ですっきりいきますが、 positonの値を設定するには何らかの判断をして、処理分岐する必要がありますね。 モードとそれにまつわる気になる点・気にしないといけない点は地道に集めて考えて見ます。 > 2. block-progressionのプロパティ名の混乱について block-flowになった経緯、ありがとうございます。意外と早くに決まっていたんですね。 今後は自分自身がflowと他の名前が混在しないように注意します。 2010年5月6日5:32 MURAKAMI Shinyu <murakami@antenna.co.jp>: > 村上(@MurakamiShinyu)です。 > > MURAKAMI Shinyu <murakami@antenna.co.jp> wrote on 2010/04/28 11:26:22 >> >> CSS Text Layout Module Level 3 >> Editor's Draft 25 April 2010 >> http://dev.w3.org/csswg/css3-text-layout/ >> 公開されました。 > > このあと次のところが更新されています(Editor's Draft 5 May 2010)： > > 2. Writing Modes and Terminology > > 4. Block Flow Direction: the ‘block-flow’ property > > 以前の block-progression は block-flow と改められて、それに伴ない > writing mode 関係の用語の説明が修正されています。 > > > 以下、一條さんに未回答だったこと： > > Miwako Ichijo <usa132006@gmail.com> wrote on 2010/04/13 13:17:34 >> こんにちは、一條と申します。 >> CSS3のテキストレイアウトで投稿された内容、じっくり読ませていただきました。 >> >> 私は仕様に関する議論等々に参加したことがなく、仕様を利用するマークアップ担当者の立場ですので、 >> レベルが低い内容になっていると思いますが、ご容赦ください。 >> （さらに、私はずっとWebサイト専門で、電子書籍に関する情報は最近勉強し始めた初心者なので、検討する視点が違っているかもしれません。） >> >> 1. Media Queriesを利用した縦書き・横書き判断 >> >> 実際に制作する立場から見ると、この提案内容は分かりやすいと考えます。 >> CSSでもHTML上でも物理的な環境（デバイス、アプリ）を区別して制作する設定としては現状、Media Queriesの部分のみだと考えています。 >> 物理的な環境を複数箇所で指定しなくてはいけないということは、制作上のトラブルを起こしやすくなるので、1ヶ所にまとまっているほうが >> 利用しやすいです。 >> >> 拡張するとしたら、指定できるメディア特性を増やす方向になるのかと個人的には思ったのですが、 >> そうなっても利用する側に特に問題はないと考えます。 >> Media Queriesで現在指定できる特性がデバイス由来ばかりが見えていますが、media typeで指定するタイプ自体が >> デバイスだけなく、一般的にはアプリといってもいいタイプ（例：音声リーダー向けにspeech）を含めているので、 >> 「閲覧環境に応じた設定をまとめて行なえる」とういスタンスで理解できます。 >> > > 私もそう思います。 > しかし、このようなMedia Queriesの利用についてはCSSWG内で合意ができず、 > それよりも 縦書き・横書き共通に使える margin-before/after/start/end など > のプロパティがあるほうが便利であるということで、それが CSS3 Text Layout > に入りました。 > >> ところで、この拡張がされた場合、縦・横共に対応可能なUAであった場合の対応はどうのような想定をされているのでしょうか。 >> > > まず、すべてのvisual media向けUAは、横書きに対応するということが前提です。 > 縦書きはCSS3 Text Layoutで追加される機能です（writing-mode プロパティ）。 > その機能の有無を Media Queries で判定できるようにしようという提案でした。 > > UAによっては、すべてのテキストを縦書きで表示する機能（横書きの指定が > あっても無視）というというのはありえますが、このMedia Queriesを使う > 機能判定の提案においては想定してません。 > > >> 2. block-progressionのプロパティ名の混乱について >> >> 提示されたEditor's Draftのドキュメントを読むと、”より理解しやすいように”用語を検討している最中なだけで、混乱して使っているようには見えませんでした。（他の文書に反映されていないのは検討中だからではないでしょうか？） >> >> block-flowに変更しようとした経緯は他のところにあるのでしょうか。どちらが分かりやすいかを判断する前にその経緯が分かれば、 >> 検討しやすいですね。（他の単語もvsで列挙しているようですが） >> >> 個人的な感想を言うと、プロパティで設定できる内容の「方向」を強調するなら、block-progressionがいいと思います。 >> （文字数を考えると block-directionがさらにいいです。文字の少なさはCSSファイルの軽量への貢献のため。） >> なお、列挙された単語で構成した時に、block-orientationも候補にあるようですが、 >> 今ではiPhoneのorientation関係の指定と紛らわしい感があります。 >> > > > この時点で公開されていた Editor's Draft 8 October 2008 で、 > block-progression の名前を block-flow にするか他の名前にするか > 検討中というような状態でした。そのため、プロパティの定義では > block-flow の名前だけれども、Exampleやほかの説明のところでは > block-progression の名前が使われているままで、仕様がはっきりしない > のがまずいということで、それなら前の block-progression に戻したほうが > 良いのではないかというのが私の提案でした。 > > block-flowに変更しようとした経緯なのですが、私もそのあとで調べたところ > 次のところに見つかりました： > > [CSSWG] Minutes F2F 2008-08-21 > http://lists.w3.org/Archives/Public/www-style/2008Sep/0074.html > [CSSWG] Minutes F2F 2008-08-22 > http://lists.w3.org/Archives/Public/www-style/2008Sep/0075.html > [CSSWG] Resolutions August F2F: CSS3 Etc. > http://lists.w3.org/Archives/Public/www-style/2008Sep/0078.html > > このときの議論で、'block-progression' から 'block-flow' に名前を > 変更するということが決定されていました。 > (RESOLVED: Rename 'block-progression' to 'block-flow'.) > > 'block-flow' に決定しているということなら、そのように仕様書すべて > 直せばよいということで、最新 Editor's Draft (5 May 2010)ではそうなりました。 > > >> 3. writing-modeに関する相対プロパティ、擬似クラス >> >> 3.1. 相対プロパティ >> >> 相対プロパティのところででた論理プロパティが標準にすべき、という点は利用する側としては戸惑います。 >> （他のマークアップ担当の方はどうなのでしょうか。色々お伺いしたいところです。） >> >> margin、padding、widht、heightについては、自分がマークアップしているドキュメントが視覚的にどのように見せるか、を平面上で表示領域を「上下左右」を基にして把握し、設定内容をはじき出しています。表示領域をどのようにデザインするかがポイントなので、内部に含まれる要素の表示の流れで「上下左右」をstart等々に読み替えるのは分かりにくいと感じています。 >> >> 提案内容だと、height、widthにはlogical- を付けられています。 >> marginやpaddingなども logical-margin-topとかではまずいのでしょうか。 >> > > logical-margin-top のような名前だと、右から左(RTL)に書くアラビア語や > ヘブライ語では logical-margin-left が right 側ということになり、RTLを > 中心に使う人達にとっては理解しにくいものになります。それよりも > before, after, start, end の表記が、どの書字方向を使う人にも > 同じように理解しやすいと思います。 > > ブロックの前 before > ブロックの後 after > 行の始め start > 行の終わり end > > >> 3.2. 擬似クラス >> >> あると便利かな、というところなのですが、利用シーンはどんなもの内容のドキュメントがあるのでしょうか。 >> 自分自身が、テキストの出力方向が混在するような対応に迫られて事がないので、少々イメージがしにくいです。> 分かりやすい事例があれば、教えていただければ幸いです。 >> > > margin, border, padding については、margin-before/after/start/end など > 論理的プロパティが使えるようになれば、縦書き・横書きの両方に対応する > スタイルの指定が一応はできるようになりますが、もっと複雑なプロパティ > （例えば box-shadow で影を付けるとき、縦書き・横書きで影の向きを変え > たいとか）や背景画像と組み合わせる場合や、縦書き・横書きのそれぞれに > より適切な指定をしたい場合などに、あると便利という提案でした。 > > これがなくても、classセレクタで縦書きの部分と横書きの部分が分けられれば、 > それぞれに適切なスタイルの指定ができます。しかし、電子書籍ビューワー > などでは、本文テキストの書字方向をユーザーの好みで変更できるのが > 望ましく、そのような場合にも、ひとつのスタイルシートで両方のモード > に対応できるためには、書字方向を表す擬似クラスが必要と考えました。 > > > -- > 村上 真雄 (MURAKAMI Shinyu) > http://twitter.com/MurakamiShinyu > Antenna House Formatter: > http://www.antenna.co.jp/AHF/ > http://www.antennahouse.com > > > -- ---------------------------------------------------- Miwako Ichijo(usa132006@gmail.com) ***************************************** 一條 美和子(ichijo.miwako@sankei.co.jp) 株式会社産経デジタル 情報システム部 tel 03-3275-8169 fax 03-3275-8862
Received on Thursday, 6 May 2010 04:10:43 UTC