改行関係のバグ、第二陣 #2
初回投稿日時: 2007年08月07日04時30分37秒
カテゴリ: Bugzilla-jp Mozilla Core
固定リンク: id=2007080700
SNS:
Tweet (list)
一応最新の経過を。
一応、本家では様々な副作用が指摘されていて対策パッチをアップデートし続けている状態。対策は基本的には「Westernな文字っぽい開き括弧クラス」と、「Westernな文字っぽい閉じ括弧クラス」をでっちあげて(JIS X 4051にそんなクラスは無い)、「Westernな文字クラス」とそれらのクラスが隣接した場合は改行しないようにしている。つまり、改行される箇所は徐々に減らしている。
現在の見通しでは、基本的にURLに含まれない記号類とバックスラッシュ以外はそのようになると思われる(というか私が音を上げた)。
ただし、あくまで文字との組み合わせで改行を抑えるだけなので例えば(_ _)(_ _)のような場合、)(の間では改行される。
また逆に単語内にある最初のスラッシュとバックスラッシュは改行されない。これは、これらの文字を「Westernな文字っぽい開き括弧クラス」にするためだ。現状のtrunkではこれらの後ろで改行するが、「開き括弧」になるので、前で改行するように変更することになる。つまり、どいういう結果が得られるかというと、http://example.com/foo/bar/のような絶対URLは最初のスラッシュがまずは改行対象から外れ、その次のスラッシュも、前が「開き括弧」のスラッシュなので(イメージとしてはhttp:((これと同義)、二つ目のスラッシュも改行されない。ドメイン名の後ろに来るスラッシュで初めて改行が発生する。つまり、幅がとことん狭い場合、以下のようにレンダリングされる。
http://example.com /foo /bar/
1行目を見ると若干違和感があるかもしれないが、それも計算の内である。ディスカッションしていて思い知ったのだが、とにかくWesternな言語の人はハイフン以外で単語が分割されるという発想が無い。つまり、スラッシュで自然に終わると単語がそこで終了していると判断しかねない。
2行目に注目すると、スラッシュで始まっている。このため、これはパスの一部であることが、パスを知っている人にとっては一目で分かる。
3行目にも注目して欲しい。最後の文字がスラッシュの場合、特例措置として改行は発生させない。これによってスラッシュのみの行の生成を抑制できる。
Unixのパスで考えてみると、絶対パスの場合、/home/fooは、/homeと/fooになる。また、ホームを基準とした場合にも~/foo/barは、~/fooと/barとなる。一つ目のスラッシュで改行が発生しないので~のみの行ができることはない。相対パスでもfoo/bar/foo2はfoo/barと/foo2となるので、必ずスラッシュが含まれている。../../fooの場合、../..と/fooとなる(最新のパッチでは、これはバグっているかも……)。似たような処理はバックスラッシュにも適用されているのでWindows形式のパスでも大丈夫だ。
またハイフンも引き続き、いくつかの特殊ルールが適用される予定だ。例えば日付の表示等のために。
将来的にはもう少しまともな処理が必要だが、今はとりあえずURLとパスの改行に的を絞ろうとしている。もし、これら以外に日本ではこういうパターンは改行されないとまずい、というのがあったら是非フィードバックが欲しい(bugzilla-jpに日本語で良いので)。
私が考えている日本にとって必要な最低限の改行すべき文字はスラッシュ、バックスラッシュ、パーセント、イコールの四つ。この四つに関してはなんとかしたいと考えている。(アンパサンドではなくイコールで改行するのは、アンパサンドだと欧米での望まれざる改行が多々発生する上、HTMLの仕様上、セミコロンでの改行も必要になってしまうためだ。)