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, 11 January 2012 09:27:13 UTC