久々に『当たり』を引いてしまいました(涙)
とりあえず、http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-03-11-trunk/のビルドはこのバグがありません。 このバグがfixedとなるまでlatest-trunkのインストーラビルドを使わないようにしてください。
かなり悩んだがとりあえず目処はたったように思う。 アイデアをガシガシと書いていっているためここでまとめておく。 まず、私の考える理想的な0x5Cというバイナリデータの扱いは次の表となる。
| 文字コード | 内部データ | 表示文字 |
|---|---|---|
| Shift_JIS | U+5C(Back Slash) | U+A5(Yen Sign) |
| ISO-2022-JP(ASCII) | U+5C(Back Slash) | U+5C(Back Slash) |
| ISO-2022-JP(JIS X 0201) | U+A5(Yen Sign) | U+A5(Yen Sign) |
| EUC-JP | U+5C(Back Slash) | U+5C(Back Slash) |
まずはこの表に異論のある方は早くコメントをつけて欲しい。 そして次の表はMozillaの現状である。
| 文字コード | 内部データ | 表示文字 |
|---|---|---|
| Shift_JIS | U+5C(Back Slash) | U+A5(Yen Sign) |
| ISO-2022-JP(ASCII) | U+5C(Back Slash) | U+A5(Yen Sign) |
| ISO-2022-JP(JIS X 0201) | U+5C(Back Slash) | U+A5(Yen Sign) |
| EUC-JP | U+5C(Back Slash) | U+A5(Yen Sign) |
これを修正するためにはまず、日本語の場合、問答無用で0x5CをU+A5に変換しているソースコードをShift_JISの場合のみに絞れば良い。 これは、Shift_JISの場合、円記号がフォントに依存せずに表示されるべきであり、 クリップボード等での扱いはあくまで0x5Cのままでなくてはいけないことによる対応である。 この結果、上記の表は次のように変化すると考えられる。
| 文字コード | 内部データ | 表示文字 |
|---|---|---|
| Shift_JIS | U+5C(Back Slash) | U+A5(Yen Sign) |
| ISO-2022-JP(ASCII) | U+5C(Back Slash) | U+5C(Back Slash) |
| ISO-2022-JP(JIS X 0201) | U+5C(Back Slash) | U+5C(Back Slash) |
| EUC-JP | U+5C(Back Slash) | U+5C(Back Slash) |
これでISO-2022-JPのJIS X 0201時における問題のみが残る。 これは他の問題と違い、内部でもU+A5として扱われるべきものなので、 ISO-2022-JPの変換部分に修正を入れれば良さそうだ。
とりあえず私にはここまでしかできない。 誰かパッチを書いて欲しい。
あと、tildaとover lineの問題についても意見があれば欲しい。 こちらは正直なところ現状のままで良いのではないかと思う。
fixedとなった。 これで一気にSVGの実装が進むのだろうか。
まだまだ意見募集中!!
該当のページのobject要素はdata属性で置換すべきデータの指定が必要なのに、 その指定が無いのですが……(data属性でパスを指定すればきちんと表示されます)
この問題、結構あっちこっちで見かけますが、何のツールのバグなんでしょうか。
一応、今回問題になっているページは
<META name="GENERATOR" content="IBM WebSphere Homepage Builder Version 6.0.2.1 for Windows">
となっていますし、保健所さんでも、
<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 6.5.0.0 for Windows">
となっているんですよねぇ。
でもFlashにobject挿入用のソースジェネレータがついてて、それをコピペしただけ、という可能性もありますし。 誰か原因を知りませんかね。
そもそもツールを使っているのにどうしてobjectとembedで違うファイル指定となっているのか理解に苦しみますが。
まあ、上にはああ書いたものの、ありみかさんの指摘通り、必須属性じゃありません。
でもその理由はobject要素が多用な目的を持っている点にあるのでしょう。 例えば、img要素の代替として用いるなら次のようになるので一般的には必須なんですよね。
<object data="img/hiromi03_01.png" type="image/png">代替テキストですわ</object>
ただし、a要素のhref属性と一緒で、別の使用方法があるためにimpliedなんでしょうね。
そういえば、仕様書には以下のようなことが書かれています。
でも、以下のサンプルはMozillaやOpera7.23ではdata属性と同じようには機能していません。 はて?
<object classid="img/hiromi03_01.png" codetype="image/png">代替テキストですわ</object>
正直なところ、object要素周りはよくわかりません。 とりあえずブラウザ間の互換性を埋めるには、従来の記述プラス、data属性を書くというのがスマート……でもないか(笑)
とりあえずこの辺の問題、一度暇があればBuzillaで探してみましょう。
とりあえずメモ。
意見があればどうぞ。
とりあえず、著名なHTMLエディタではISO-2022-JPの扱いがおかしい(ASCIIを使わずにJIS X 0201を使う)ので、 ISO-2022-JPの件はBug 3610に分離した。
現在、内部コードのまま表示を行うように修正する、ということで話がまとまってきている。 つまりこれは0x5Cは常にU+005Cに対応し、フォントのグリフに依存してbackslashもしくは、 yen signで表示されることを意味する。
異論があれば手遅れになる前にどうぞ。
メモ。野嵜さんトコ経由。
内容は良いのに、Use <link>s in your document
なんか、自サイト内で実践していないのはどうかと……
ハングアップするバグが修正されている。
今のところ Mozilla では、
overflowプロパティの働きで表示されたスクロールバーはホイールスクロールでは動かすことができません。
一応、バグとして認識はされとります。
ひとことで言うなら、「うざい」ですな。
ふたことで言うなら、「ちょー、うざい」ですな。
個人的には日本語キーボードと、ATOK15の組み合わせなので何の問題にもなっていなかったのだが、 鬱陶しい人には鬱陶しかったであろうこのバグが修正されている。
一応、Bugzilla-jpにも登録。
15日のビルドでは問題なくなったが、本家に該当バグが無い。
別件でバックアウトされたBug-org 20022が関係あるのかも。
最近不調で良い感じ。
ﾄリビア。
詳しい解説はComment 6参照。
昔のWindows版Mozillaでは、背景画像を描画する直前になぜかその領域を黒で塗りつぶしていたという問題。
幸いなことに当時より手持ちのPCのスペックがあがり、回線も高速化しているが、 それでもこのバグがまだあるなら一瞬ぐらいは、「黒」が見えてもよさそうなものである。 つまり、私の環境では再現していないのだ。
他の環境ではどうだろうか? 追試してもらいたい。
Windows95かWindowsNT4.0でATOK10以降(?)もしくはWXG4.x(?)で再変換処理のテストをしてもらいたい。
Bug-org 234804がfixedとなった。
たまたまオペミスから見つけたバグ。
上記、Bug 3644の再現テスト中にオペミスから発見(笑)
手元のWinXP + ATOK15では再現しないので検証のしようがない……
2004022608-trunkビルドのインストーラで解決されていることを確認。 ようやくWindowsのNightlyも本格復活。
ちなみに、以前ここでちょっとだけ触れた Bug-org 233014 default install into windows\program files directory, erases files もfixedとなっている。
:lang()
Mozillaに引き続き、Operaも7.5からは:langセレクタに対応したのですね。
Safariはどうなんだろう……