この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
超大物修正がついにチェックインされました。
Geckoのフォーカスまわりのコードはなかなかにカオスでしたが、これでかなりすっきりしたのではないでしょうか。
regressionは多々あるのではないかと思うので、見つけたらガンガン報告してください。
コードを読んでるときにたまたま見つけたバグを即座に修正しました。
IMM32関連コードは先日、一つのモジュールに移動しましたが、漏れているものがあった、というだけです。
東京ウォーカーにFennec (実物)に関する記事が出ていたので紹介しておきます。
考えてみたら写真すら見たことなかったので。
<WBR>ハックと決別を
初回投稿日時: 2009年06月21日18時14分56秒Fx2.0(Gecko 1.8.1)まではURL等の長い文字列が一つの単語として認識され、改行されずにブロックからはみ出す、という問題がありましたが、Fx3.0(Gecko1.9)で解決されました。そして、現在、Fx2.0系列は既にサポートを終了し、セキュリティアップデートを提供していません。また、Fx2.0系のユーザにはメジャーアップデートの案内も通知済みです。
特殊なURLを表示するケース(例えば、ドメイン名やパス内のディレクトリ名やファイル名が異常に長い、異様に幅の狭いところに表示しようとしている)を除いて、URLがブロックからはみ出す心配は現役のGecko系ブラウザでは問題なくなっています。
ですが、その後で勢力を伸ばしてきたWebKitではURLの改行が駄目駄目なようです。-や、?で改行する程度のみのようです。しかし、幸運にもWebKitは既にword-breakプロパティをサポートしているので、word-break: break-all;を利用すれば問題無くなりそうです。
そう、現役のメジャーなブラウザでは既に<WBR>ハックを使う必要は既に無くなっています。動的なコンテンツであれば、対WebKit用に、URLな文字列を自動リンクする際に、
<a href="http://example.com/" style="word-break: break-all;">http://example.com/</a>
としておけば、醜い<WBR>ハックと決別することができます(決して、全文には指定しないでください。日本語の禁則処理も行われなくなるので、読みにくくなるだけです)。
<WBR>ハックは、
等、問題が非常に大きいので是非、Webデザイナの方は<WBR>ハックの除去を(可能なら)検討してみてください。
W3CのDOMのメーリングリストのIME events以下や、それ以前にもDaniel氏と直接メールでやりとりをしていましたが、確かに現状、IMEまわりの挙動についてあまりにもW3Cで定義していないために、JavascriptでIMEの入力中に何かアクションをとろうとしてもWebアプリはブラウザごとの挙動の違いを意識しまくらないといけない、という問題があります。
これらの議論の直接のきっかけは、Google Waveによる入力中のテキストを複数のクライアント間で同期をとろうとしたことのようですが、この、ユーザ以外の人が同じコンテキストのテキストを変更してしまう、というのをインテリな日本のIMEは想定していないところがあります(もちろん、実際にGoogle Waveがそういう使われ方をするのか、という話になると、そんなことはほとんど無いんではないと思うのですが、ソフトウェアのデザインというのはそういうアレなケースでも動かないといけないわけで)。
で、今及川さんとの間でディスカッションしているのが、IMEの候補ウインドウ(candidate window)をJavascriptからどうにか制御したりできないのか、というもの。私個人の意見としては、IMEってのはシステムの一部であって、ユーザはそのIMEの使い方を既に学習している訳ですし、その機能をフルに使えてしかるべきだと思うので、アプリケーションがその挙動に介入してしまうのは良くないと思うのですが、それでもアプリ側で制御したいという要望があるのも理解できるところです。
で、IMEの候補ウインドウに関するAPI等をざっとながめてみた感じでは、PCのメジャーなプラットフォームでは以下のような感じかな、と思って上記のスレッドにポストしています。間違い等あれば、www-domに意見をもらえれれば助かります。
ImmSetCandidateWindowで位置は指定可能WM_IME_SETCONTEXTのハンドリング時なら、非表示にすることも可能、ただし、任意のタイミングでの非表示はできない?gtk_im_context_set_cursor_locationで位置指定は可能IMEの仕様によっては、候補ウインドウって必ず必要であってもおかしくない代物ではあるので(例えば中国語のIME等)、これを非表示にしよう、という発想はやっぱり無しなのではないかと私は思います。位置の指定に関しても、スクリーンとキャレットの位置関係等から、それなりに色々と考慮して位置決めが行われるので、なかなか直接的な指定は難しいのではないかな、という印象があります。
及川さんの文面を見る限りでは、候補ウインドウが表示された位置とサイズが分かれば、別のアプローチも可能なのではないかな、と思うのですが、全プラットフォーム共通でサイズは取得できないっぽいのでこのアイデアもボツ。
この辺の担当としての個人的な意見としては、IMEで未確定文字列がある状態というのは、文字通り「未確定」、つまり入力している真っ最中なので、その時に他から色々と割り込まないで欲しい、というのが本音ではあるのですが、逆の立場なら確かに当然の要求なんだよなぁと思うところもあって悩ましいです。