- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Wed, 4 Apr 2012 07:25:07 -0400
- To: "'public-html-ig-jp@w3.org'" <public-html-ig-jp@w3.org>
その後英語MLで数人から意見をいただき、自分でも検証して、私がちょっと早とちりしていたことが判明しました。すみません。 やっぱり「全角空白は通常の文字と同じ」ではブラウザーはまずいです。具体的には、段落頭と行末ばかりに目が行っていましたが、行頭を十分に考えていませんでした。 「株式会社ほげほげ□開発部」という文字列が空白の前で行末に来た場合 ……株式会社ほげほげ □開発部…… となります。これはユーザーの期待する挙動ではないのではないでしょうか。 ほかにも感嘆符の後の全角空白（これは入れる、入れないの議論があるようですが、入れている例のほうが主流に見えます） これはびっくり！ □次の文章。 この行頭の空白も好ましくありません。段落が変わっているように見えます。 ということで、新しい意見を英語MLにポストしました[1]。 1. 段落頭ではそのまま、行末ではなし、全角空白前では改行しない（ので行頭は存在しない） 2. 段落頭ではそのまま、行末でもそのまま、全角空白前で改行あり、行頭でもそのまま 3. 段落頭ではそのまま、行末でもそのまま、全角空白前で改行あり、行頭ではなし 1はWordの挙動。2はInDesignの挙動。3はJLTFのご意見を基に考えてみた新しい挙動です。各ブラウザーの挙動は以下の通り。 現行のCSS Text Level 3: #2 IE9: #1 FF11: IEに似ていますが、改行挙動や両端揃えに違いあり Chrome18/Safari5/Opera: #2 以上を基に、#3が最もよく、#1が次点、という意見をポストしました。 また、現行CSS Text Level 3は、U+0020（ASCII空白）を英文空白と定義し、それ以外の空白類をすべて同じ挙動としています。これはおそらく、 ●全角空白は上記いずれかの挙動 ●#1以外の場合（全角空白とU+0020の挙動が異なる場合）それ以外の空白類はU+0020に合わせる が正しいと思われます。 ご意見ありましたら、いただけると幸いです。 [1] http://lists.w3.org/Archives/Public/www-style/2012Apr/0047.html -----Original Message----- From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp] Sent: Sunday, April 01, 2012 5:23 AM To: 'public-html-ig-jp@w3.org' Subject: RE: [css3-text] 行末における全角空白の扱い (was FW: [css3-text] scoping line break controls, characters that disappear at the end of lines この件に関して結論が出ないまましばらく空いてしまいましたが、中野さんのおっしゃられていた > どちらにしろ、デフォルトの動作は変えず、今のブラウザの動作にあわせた方が > 無難です。新しい表現は新しいプロパティなり、値なりで実現する方が現実的です。 について調べたところ、全ブラウザーで異なる挙動となりました[1]。 中野さんのご意見 > 日本語の文章に全角スペースが > 挿入されている場合はそれも表現しようとしているコンテンツの一部、と考えた > 方が良いように思います。 と、下記のJLTFのご意見、各ブラウザーの挙動、WordやInDesignの挙動も確認して考えた結果、私も中野さんのご意見に賛成することにしました。 英語MLにも投げました[2]が、これでWGが合意できれば、Chrome/Safariと同じ挙動になることになります。JLTFのご意見そのままの結果ではありませんが、いただいたユースケースはサポートすることができます。 ご意見ありましたら、いただけると幸いです。よろしくお願いいたします。 [1] http://lists.w3.org/Archives/Public/www-archive/2012Mar/0058.html [2] http://lists.w3.org/Archives/Public/www-style/2012Mar/0730.html -----Original Message----- From: Koji Ishii Sent: Wednesday, January 11, 2012 6:22 PM To: public-html-ig-jp@w3.org Subject: RE: [css3-text] 行末における全角空白の扱い (was FW: [css3-text] scoping line break controls, characters that disappear at the end of lines W3C i18n WG JLTF (Japanese Layout Task Force)の方からオフラインでご意見いただきました。 ブラウザーで、という話ではなく、あくまで日本語組版の正しい組み方としてのお話ではありますが、参考になる部分があると思ったので共有しておきます。 <p>疑問符や感嘆符！□の後は全角空白を入れる</p> が行末にかかった場合。 ■1行10字 疑問符や感嘆符！□の 後は全角空白を入れる ■1行9字 疑問符や感嘆符！□ の後は全角空白を入 ■1行8字 疑問符や感嘆符！ の後は全角空白を 行末で食われる、という観点からは半角空白と同じだけど、両端揃えのルールを少し変えられるのが理想的。あるいはwrap後の先頭の全角空白を消す、というルールでも実現可能。ただ、それをブラウザーでやる必要があるかどうかについては別の議論ではありますが。 というお話でした。 普通、と思ってたことでも、話してみると気づきがありますね。 -----Original Message----- From: Masayuki Nakano [mailto:masayuki@d-toybox.com] Sent: Wednesday, January 11, 2012 5:59 PM To: Koji Ishii Cc: public-html-ig-jp@w3.org Subject: Re: [css3-text] 行末における全角空白の扱い (was FW: [css3-text] scoping line break controls, characters that disappear at the end of lines もともとこういったやり方がナンセンスですが、安易にやっているページが存在 するというのは十分にあり得ますので、強制改行を含まず一行だけでやっている 可能性もあると思います。 text-align: justify; を除き、alignされた方とは逆の全角スペースなら詰めて もあまり問題ないかもしれないですが、コピー目的で文字列を選択しようとする ケースとかでは問題かもしれません。 どちらにしろ、デフォルトの動作は変えず、今のブラウザの動作にあわせた方が 無難です。新しい表現は新しいプロパティなり、値なりで実現する方が現実的です。 そもそも日本語の文章内に全角半角問わず、空白が出現することはほとんどない ですし、現在のブラウザの表示結果からすると、日本語の文章に全角スペースが 挿入されている場合はそれも表現しようとしているコンテンツの一部、と考えた 方が良いように思います。 On 2012/01/10 23:53, Koji Ishii wrote: > 中野さん、ありがとうございます、それはいい指摘ですね、気が付きませんでしたが、おっしゃる通りだと思います。 > > 明確に書いてないので確認が必要ですが、意図としては、強制改行を含まない場合の話だと思います。つまり行長が長くなって、「あ い」が行末にかかってwrapが発生した場合に、その全角スペースを次の行頭に送るか、消すか、という質問だと私は理解しました。 > > <p>あ□いうえおかき</p> > > というソースに対し、 > > ……あ□ > いうえ > おかき > > となるか、 > > ……あ > □いう > えおか > > となるか、という質問だと思います。 > > この場合には問題ないですよね？ > > 同じ理解であれば、強制改行を含む場合は除くよね、という確認と共に返答しておきます。 > > > -----Original Message----- > From: Masayuki Nakano [mailto:masayuki@d-toybox.com] > Sent: Tuesday, January 10, 2012 10:56 PM > To: Koji Ishii > Cc: public-html-ig-jp@w3.org > Subject: Re: [css3-text] 行末における全角空白の扱い (was FW: [css3-text] scoping line break controls, characters that disappear at the end of lines > > 全角スペースを利用して右から字下げをしているようなサイトがあるなら、その > レイアウトを壊してしまうので駄目だと思います。 > > 例えば、 > > <p style="text-align: right;"> > ああああ <br>↓ > いいいい↓ > </p> > > このような場合に、 > > +-------------------------+ > | ああああ | > | いいいい| > +-------------------------+ > > となるべきではありませんか? > > On 2012/01/10 13:25, Koji Ishii wrote: >> CSS3 Textで、行末における全角空白の扱いをどうするべきか、ご意見いただけますでしょうか？ >> >> 半角空白同様に、行末の全角空白は右マージンを超えて、ないものとしてレイアウトされる、で正しいと思いますが、ご意見いただけましたら幸いです。 >> >> よろしくお願いいたします。 >> >> >> -----Original Message----- >> From: fantasai [mailto:fantasai.lists@inkedblade.net] >> Sent: Tuesday, January 10, 2012 10:37 AM >> To: www-style@w3.org; 'WWW International' >> Subject: [css3-text] scoping line break controls, characters that disappear at the end of lines >> >> In 2008 roc outlined some principles for how line breaking controls (i.e. 'white-space', at the time) are scoped to line-breaking opportunities: >> >> In<http://lists.w3.org/Archives/Public/www-style/2008Dec/0043.html> Robert O'Callahan wrote: >>> >>> 1) Break opportunities induced by white space are entirely governed by the >>> value of the 'white-space' property on the enclosing element. So, spaces >>> that are white-space:nowrap never create break opportunities. >>> 2) When a break opportunity exists between two non-white-space >>> characters, e.g. between two Kanji characters, we consult the value of >>> 'white-space' for the nearest common ancestor element of the two characters >>> to decide if the break is allowed. >> >> I'm trying to encode this into the spec. My question is, are spaces (U+0020) the only characters that fall into category #1? What about the other characters in General Category Zs? >> http://www.fileformat.info/info/unicode/category/Zs/list.htm >> >> In particular, U+1680 is, like U+0020, expected to disappear at the end of a line. >> >> Which brings up another issue: which characters should disappear at the end of a line? Right now we keep around all those fixed-width spaces. >> >> ~fantasai >> >> > > -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Wednesday, 4 April 2012 11:25:51 UTC