この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2009年6月)

2009年6月11日

Bug-org 178324 refactor focus handling 初回投稿日時: 2009年06月11日11時25分16秒
最終更新日時: 2009年06月11日17時12分55秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009061100
リンク元: 0件
SNS: (list)

超大物修正がついにチェックインされました。

Geckoのフォーカスまわりのコードはなかなかにカオスでしたが、これでかなりすっきりしたのではないでしょうか。

regressionは多々あるのではないかと思うので、見つけたらガンガン報告してください。

2009年6月20日

2009年6月21日

<WBR>ハックと決別を 初回投稿日時: 2009年06月21日18時14分56秒
最終更新日時: 2009年06月21日18時18分48秒
カテゴリ: CSS Firefox Google Chrome HTML Mozilla Core Safari
固定リンク: id=2009062100
リンク元: 1件
SNS: (list)

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>ハックは、

  1. 転送容量が肥大化する
  2. W3Cで合意の得られなかったレガシーな要素なので、階層の深い、滅茶苦茶なDOMツリーが構築される可能性がある
  3. 各WBR要素毎に要素ノードが作られる
  4. 分断されたURLの欠片それぞれが独立したテキストノードになってしまう

等、問題が非常に大きいので是非、Webデザイナの方は<WBR>ハックの除去を(可能なら)検討してみてください。

2009年6月30日

IMEはWebアプリからどの程度制御可能であるべきなのか 初回投稿日時: 2009年06月30日14時30分33秒
カテゴリ: Javascript Software
固定リンク: id=2009063000
リンク元: 1件
SNS: (list)

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に意見をもらえれれば助かります。

IMM32
  • ImmSetCandidateWindowで位置は指定可能
  • WM_IME_SETCONTEXTのハンドリング時なら、非表示にすることも可能、ただし、任意のタイミングでの非表示はできない?
TSF
  • UIlessモードじゃなければ、位置指定も非表示もできない
  • UIlessモードなら、表示しようとしたときに抑制はできるっぽい
  • UIlessモードでも、位置の指定はできないっぽい
  • UIlessモードで非表示にしてしまって、候補ウインドウを自前で描画すれば位置指定も可能になるけど、補足説明等の候補ウインドウの本来の基本機能以外は失われる可能性大
  • そもそも、UIlessモードをサポートしないTIPが存在する可能性があるのではなかろうか
GTK2
  • gtk_im_context_set_cursor_locationで位置指定は可能
  • 非表示にすることができそうなAPIは見あたらない
Cocoa (10.5以降のIMKを考慮に入れて)
  • 位置も非表示も指定できないっぽい

IMEの仕様によっては、候補ウインドウって必ず必要であってもおかしくない代物ではあるので(例えば中国語のIME等)、これを非表示にしよう、という発想はやっぱり無しなのではないかと私は思います。位置の指定に関しても、スクリーンとキャレットの位置関係等から、それなりに色々と考慮して位置決めが行われるので、なかなか直接的な指定は難しいのではないかな、という印象があります。

及川さんの文面を見る限りでは、候補ウインドウが表示された位置とサイズが分かれば、別のアプローチも可能なのではないかな、と思うのですが、全プラットフォーム共通でサイズは取得できないっぽいのでこのアイデアもボツ。

この辺の担当としての個人的な意見としては、IMEで未確定文字列がある状態というのは、文字通り「未確定」、つまり入力している真っ最中なので、その時に他から色々と割り込まないで欲しい、というのが本音ではあるのですが、逆の立場なら確かに当然の要求なんだよなぁと思うところもあって悩ましいです。