- From: Miwako Ichijo <usa132006@gmail.com>
- Date: Fri, 9 Jul 2010 00:17:52 +0900
- To: Ishii Koji <kojiishi@gluesoft.co.jp>
- Cc: MURAKAMI Shinyu <murakami@antenna.co.jp>, "public-html-ig-jp@w3.org" <public-html-ig-jp@w3.org>
一條と申します。 仕様提案や解決策提示のコメントではないのですが、 実際にマークアップ作業をする立場として、今回上げられている ・ 論理プロパティと物理プロパティ ・ モード切替のプロパティ が確立された場合、 ・ 論理プロパティと物理プロパティの使い分け ・ 論理プロパティができることに対する考え方 ・ モード切替のプロパティがあったら、どういう場面で使用するか というのを、自分だったらどうするか、と考えて見ました。 個人レベルの考えなので、現状はこんな作業者もいるというサンプルで見ていただければ幸いです。 1) 論理プロパティと物理プロパティの使い分け 現状、論理プロパティと物理プロパティを使う場合 物理プロパティ => 物理的に決まっている一方向に対して、指定した値が設定される。 論理プロパティ => 指定した値は設定される。但し、方向に関しては、フローの方向に依存して決まるので、 レンダリング時に適切な方向に変換されて、指定した値を設定する。 と認識しています。そのため、 ・ 見せ方が、フローに関係なく決まっている部分は物理プロパティ ・ フローによって変更したい部分は論理プロパティ という使い分けにもなると考えています。 そして、こうした混在の記述をあえて行なうサイトも出てくるものと考えています。 どういうサイトを想定しているかというと、 1. 横書きと縦書きが混在 2. レイアウトはかなり自由な配置で、レイアウトも重要に考えている ものです。キーになるのは2.で、”かなり自由”としているレイアウト例としては ◎ 紙媒体雑誌のようなコンテンツ配置がpositonでHTMLの記述に関係なく、見栄え等を考慮した配置 ◎ 新聞紙面のように、入り組んだボックス配置 ◎ ユーザーのアクションに従って、前面にコンテンツを表示したり、非表示にしたりする配置 のようなものをイメージしています。表示するエリアのサイズと位置、周りのコンテンツとの余白などがテキストがどのような流れで表示されていても、確定しているというケースです。 この場合、例えば、表示エリアのwidthとheigthは変換されたくないが、文字の修飾（下線表示とかですね）でborderなどを使っているなら変換してほしいということになります。 縦書きコンテンツといっても、全面の場合、一部だけの場合でフロー方向の変化に対応して、変更する必要があるプロパティは違ってくるのではないでしょうか。 2) 論理プロパティができることに対する考え方 1)のように考えているので、 物理プロパティと論理プロパティは共存状態で、どちらか一方によっていくような状況には 必ずしもなれないのではないかと思っています。 今回のメールのなかで、 > 今回モードも入れてあれば、見過ごさ > れても、正しく修正されるまでの間モードを指定することで回避 > できる可能性が高くなります。論理的に正しいこともやりつつ、 > 移行期間や移行したくない人もサポートした方がよくないです > か、という提案です。あるソフトが、プラグインの仕様が正しく > なかったので変更した、今までのプラグインは全部使えない、と > 言ったら困る人もいるので、互換インターフェイスも残します、 > というアップグレードをするのと同じなのではないかと思っています。 とあり、これを読んで、 どちらか一方（できれば論理プロパティ利用の方向）に寄せていくことを推進されていると感じましたが、 ・縦書きと横書きを同時にコントロールできる便利なプロパティが増えるので、 求められるコンテンツ表現に従って、必要な部分にそのプロパティを使用を推奨する という緩いスタンスというのもありではないでしょうか。 一方に寄せようという動きが強いと、その一方に対して違和感がある側はどうしてもアレルギー反応がでます。 ちょっと緩いスタンスで、今回のような内容の議論を進める仕方もあるのではないかと、思います。 3) モード切替のプロパティがあったら、どういう場面で使用するか 1)と2)のような考えを持っている状況、今回提示されたようなモード切替は必要か、どこで使うかを考えた時、 ・ 全面縦書き、または全面横書きに切り替えるようなコンテンツの場合は使いたい。 現状、過去資産がないせいか、過去互換性よりも非対応UAへのサポートが一番念頭にあり、 1. モード切替に対応していないUA（縦書きに対応していないUAも含まれてる可能性が高かいと思いますが）、 に既存の値でデータそのまま設定できる。 2. ショートハンドで書かれた値も正しく変換されるのであれば、CSSのファイル縮小化もしやすいのでメリットがある。 といったことであれば、移行時の利用というより、恒常的な利用をしたいと考えます。 ・ 混在型の場合は論理プロパティ、物理プロパティ、各プロパティの適用順を考慮して作業して、モード切替は使用しない というような作業イメージを持っています。 必ずしもあって欲しいとは現段階では言えませんが、 今回のメールのなかで、選択肢を増やそうとおっしゃるとおり 、実作業のケースに合わせてやり方が検討できるモード切替のようなプロパティがあると、 縦書きコンテンツの制作に取り組みやすくなると考えています。 感想文的なゆるいコメントになって申し訳ないです。 現在、メインがWebサイト向けコンテンツ制作なので、このような考えになっていますが、 他のサイト制作者や、EPUBでの電子書籍作成を行っていてCSSを触る制作者の方々の 論理プロパティ、物理プロパティというものができることに関しての考え、どのように使っていこうかというケースなどを、私自身も今後の参考にぜひ聞いてみたいです。 ただ、今回の問題提起に対して、今回のメールも含めてそぐわないレベルのやりとりと判断されるよう、 別メールでやり取りしてもよいかもしれませんね。 2010年7月7日14:49 Ishii Koji <kojiishi@gluesoft.co.jp>: > 村上さん、ありがとうございます。英語MLで「あってもいいかな」レベルまで来たのに、日本で賛成が0だったので、ちょっとめげていたところで、非常に心強いです。 > > 実装者にとっては慣れ親しんだ方法ですので、実例は多いと思います。また、text-align:leftの「left」とmargin-leftの「left」が同じ方向を指すので、わかりやすいと思う人は一定数はいると思っています。 > > もちろん逆の方もいらっしゃるので、あくまでモード切替ではありますが、複数の正解があって、人によって支持する解が違う場合には、オプションとする、というのは、正しい方向性だと思っています。 > > > -----Original Message----- > From: MURAKAMI Shinyu [mailto:murakami@antenna.co.jp] > Sent: Wednesday, July 07, 2010 2:14 PM > To: Ishii Koji > Cc: public-html-ig-jp@w3.org > Subject: Re: CSS の left/right/top/bottom と縦書きの関係について > > 村上です。 > Ishii Kojiさん、MLにお誘いしておいて、コメントしないでいてすみません。 > > いくつかのHTML/CSSを縦書きで表示する実装では、スタイルを90度回転する方式 > がとられていて、Ishiiさんの提案していることと共通しています。 > > 影鷹 - 縦書きブラウザ > http://www.kagetaka.org/ > > ブログ出版局 - 縦書きのスタイル > http://blog.print.cssj.jp/?itemid=197 > > 竹取Web、 > http://taketori.org/ > 竹取JS - ウェブにも縦書きを！ > http://cmonos.jp/blog/2010070500/1.shtml > > このような方式について標準化をしようという議論があってもよいと思います。 > Ishiiの案のように、topの意味を右縦書きでは右に変えるというプロパティが > あると、確かに便利かもしれないと思います。 > > Name: directional-mode > Value: physical | logical > Initial: physical > Applies to: all elements > Inherited: yes > > directional-mode: logical を指定すると、絶対方向を示すプロパティの意味が > 次のように論理的なものになる： > > top = before (ブロックの前側) > bottom = after (ブロックの後側) > left = start (行頭側) > right = end (行末側) > width = logical-width (文字進行方向の寸法) > height = logical-height (ブロック進行方向の寸法) > > > -- > 村上 真雄 (MURAKAMI Shinyu) > http://twitter.com/MurakamiShinyu > Antenna House Formatter: > http://www.antenna.co.jp/AHF/ > http://www.antennahouse.com > > > Ishii Koji <kojiishi@gluesoft.co.jp> wrote on 2010/07/07 12:58:16 >> 解決策もないけど、そもそもWebデザイナーが抱える問題を議論する場所ではない、という感じですかね。 >> >> 失礼いたしました。このMLにどういう話題を持ってきていいかわかっていない初心者、ということでご容赦ください。この問題は別の方向にもっていきます。 >> >> >> -----Original Message----- >> From: Ishii Koji >> Sent: Monday, July 05, 2010 1:58 AM >> To: Ishii Koji; public-html-ig-jp@w3.org >> Subject: RE: CSS の left/right/top/bottom と縦書きの関係について >> >> まだご意見があるかもしれませんが、とりあえず賛成0、反対2、ですね。 >> >> 提案しておきながらで申し訳ないですが、提案から問題提起に代えさせてください。もともと実装方法にこだわりはなく、問題が何とかならないかと思っておりましたので。 >> >> 今のままで仕様が確定すると、新規にゼロから作成する場合はよいのですが、既存のものを流用したり、一部に縦書きを入れたい場合に、横書きで使っていたスタイルを流用するのが難しい、というのはご理解いただいていると思います。 >> >> テキストエディタで一括変換できる部分もあるかもしれませんが、CSS 2ブラウザでは横書きで対応しよう、という場合にはさらに複雑になってしまいます。 >> >> こういったシナリオは仕様確定後に対応ブラウザがリリースされれば実際の現場で発生してくると思われるのですが、Webデザイナーさんがなるべく楽に縦書きを導入できるようにするにはどうすればいいでしょうか？ 現在検討されている案の中で、こうすればいい、というものはあるのでしょうか？ CSSのドラフトは数が多いので、全部把握しきれていないため、もしあるのであれば教えていただけると幸いです。 >> >> よろしくお願いいたします。 >> >> >> -----Original Message----- >> From: public-html-ig-jp-request@w3.org [mailto:public-html-ig-jp-request@w3.org] On Behalf Of Ishii Koji >> Sent: Thursday, July 01, 2010 3:57 AM >> To: public-html-ig-jp@w3.org >> Subject: FW: CSS の left/right/top/bottom と縦書きの関係について >> >> nisin@mac.com さんからご意見いただきました。ご許可いただいたのでMLに流させていただきます。ご参考まで。 >> >> >> -----Original Message----- >> From: nisin [mailto:nisin@mac.com] >> Sent: Thursday, July 01, 2010 3:46 AM >> To: Ishii Koji >> Subject: Re: CSS の left/right/top/bottom と縦書きの関係について >> >> うっかり、直メなのでどーぞ >> >> On 2010/07/01, at 0:55, Ishii Koji wrote: >> >> > ご意見、ありがとうございます。大変参考になりました。 >> > >> > まず最初にきちんと書き損ねたことをお詫びしたいのですが、私 >> > が提案しているのは、「start/end/...の代わりに」ではな >> > くて、「追加で」これも入れてはどうか、という話で >> > す。Nishinさんのように縦書きで字下げする時にleft >> > が不自然と感じられる方もいれば、startって不自然、と感 >> > じられる方もいるので、今までのやり方を良しとしてきた人に価 >> > 値観を強制するのではなく、選択の自由を与えませんか、という >> > のが趣旨です。 >> > >> > 例えば今「字下げ」と書きましたが、これは「下げ」という言葉 >> > の通り、縦書きの時にできた言葉です。しかし、横書きでも「字 >> > 下げ」と言いませんか？ それは論理的におかしいから、今日か >> > ら「字ずらし」と言おう、と言っても、賛成の人もいれば、反対 >> > の人もいると思います。 >> > >> > 「並べやすい」というのも主観で、人や場面によって異なりま >> > す。プログラマーの方は論理的思考に慣れていらっしゃるでしょ >> > うから、「進行方向」と言えば分るかもしれませんが、デザイ >> > ナーの方は「横書きの時の思考方法で言う上」という方がわかり >> > やすい、という方もいらっしゃいます。 >> > >> > こういった用語の使い方や、論理的思考に慣れていない方も対象 >> > に広く考えれば、将来も含めて、互換指定というのは有効ではな >> > いでしょうか？ >> > >> > また、直近部分についても、双方がある限り、直近も将来も楽で >> > あるほうがよくはないですか？ つまり、互換も残しつつ、新し >> > い書き方も提供する、ということです。Start/end/...と >> > モード切替の双方を実現すれば、徐々に移行しつつ、新しい方式 >> > を好む方は新しい部分については新しい書き方を導入することが >> > できます。ソフトでも、過去互換性をバッサリ、というものより >> > は、新しいのものあるけど、過去も使えて、徐々に移行できる方 >> > が受け入れやすいですよね？ >> > >> > 最初のメールには書きませんでしたが、実はもう一つ懸念がありま >> > す。HTMLやCSSは日々進化しています。将来におい >> > て、きっとleft/right/top/bottom/width/heightという名 >> > 前の付いたプロパティが導入されてしまうでしょう。それは特に >> > 欧米人にとってはその方が自然だからです。今日現在でも、例え >> > ば段組みにおいてcolumn-widthというプロパティが提案さ >> > れています。すごく長い目で見れば、なるべくウォッチして、見 >> > 過ごされてしまったものは修正し、さらにブラウザーメーカーが >> > 修正してくれるのを待ち、とすればいいのかもしれませんが、そ >> > の数年の間日本では使えない技術というのが生まれてしまう可能 >> > 性があると思っています。今回モードも入れてあれば、見過ごさ >> > れても、正しく修正されるまでの間モードを指定することで回避 >> > できる可能性が高くなります。論理的に正しいこともやりつつ、 >> > 移行期間や移行したくない人もサポートした方がよくないです >> > か、という提案です。あるソフトが、プラグインの仕様が正しく >> > なかったので変更した、今までのプラグインは全部使えない、と >> > 言ったら困る人もいるので、互換インターフェイスも残します、 >> > というアップグレードをするのと同じなのではないかと思っています。 >> > >> > まあ、お互い主観の主張なので、頭で理解はできても、受け入れ >> > るのは難しい人もいるのだろうな、とも思っています。可能であ >> > れば、主観が異なる人間も世の中にはいるので、選択肢を提供し >> > てほしい、というのが私の願いです。 >> > >> > いかがでしょうか？ >> > >> > ところでこのメールは、私に直接ご返信いただいたのです >> > ね。MLにもきっと同じ疑問を持たれた方はいらっしゃると >> > 思いますので、nishinさんさえよろしければこのまま転送 >> > させていただきたいのですが、よろしいでしょうか？ もしそれ >> > はあまり好まれないようでしたら、このまま一対一でのやり取り >> > でも構いませんが、他の方の参考になるかもしれないと少し思い >> > まして。もしよろしければその旨お知らせいただけますか？ >> > >> > >> > -----Original Message----- >> > From: nisin [mailto:nisin@mac.com] >> > Sent: Wednesday, June 30, 2010 9:18 PM >> > To: Ishii Koji >> > Subject: Re: CSS の left/right/top/bottom と縦書きの >> > 関係について >> > >> > >> > nisinと申します。 >> > >> >> 一番大きいのは、過去互換性です。CSS 2で書かれた >> >> HTMLを縦書きに変換する場合や、縦書きで表示するブラウザーの >> >> 機能を開発する場合、すべての「left/right/top/bottom/width/ >> >> height」を「start/end/before/after/before-width /after- >> >> width」に書き換えなければなりません。また、将来のドキュメン >> >> トについても、ツールの対応や慣れの問題から、left/right/top/ >> >> bottom/width/heightを使ってしまった場合、それは縦書きに変換 >> >> するのが困難になります。 >> > >> > 自動変換や、手間に基づいた過去互換性は新規の世界観導入には >> > 最低限の配慮に抑える事が息の長い、また、未来の人間に苦労の少 >> > ない結論を得るためのコツなんじゃないかと思います。 >> > >> >> そもそもフローがなかったところに新規策定しようとしているの >> >> で、フローが縦書きの場合にtopをどう解釈するか、という >> >> のは決めの問題ではないかとは思うのですが、とにか >> > >> > 箱を並べる概念だと思うので、上下左右と進行方向に対しての前 >> > 後左右は、別に指定できた方が並べやすいかなと思います。 >> > 気持ちで世界をゆがめるのは(黒を赤というのは)避 >> > けて通りたい結論です。 >> > >> > また、縦書きが今日まで対応されなかったために変な癖が付いて >> > しまった、我々縦書き文化圏の歪みが出ているような問題だけど、 >> > ゆがんでいない結論を今回は出したい。そう思います。 >> > >> >> が、規格策定後の将来に開発者やWebデザイナーの方への大 >> >> きな負担にならないか、とい >> > >> > 直近の将来では負担のある向きもあるかもですが、長い目で見た >> > 時はどうなんでしょう。 >> >> > > > > -- ---------------------------------------------------- Miwako Ichijo(usa132006@gmail.com) ***************************************** 一條 美和子(ichijo.miwako@sankei.co.jp) 株式会社産経デジタル 情報システム部 tel 03-3275-8169 fax 03-3275-8862
Received on Thursday, 8 July 2010 15:18:27 UTC