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

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

もずはっく日記(2005年2月)

2005年2月1日

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #6 初回投稿日時: 2005年02月01日04時01分33秒
最終更新日時: 2005年02月01日04時26分59秒
カテゴリ: Mozilla Core
固定リンク: id=2005020100
SNS: (list)

まだまだ微調整の真っ最中。 どうにもIEに比べて選択色が反転しすぎる。 GとBに関して、単色では良い感じなのだが、それ以外ではかえって不具合の出るページがある。 一番顕著なのが、文字色がオレンジの場合で、この場合、背景が白というページをいくつか見つけているのだが、この場合にIEでは反転無し、私のパッチでは反転して表示される。 Gに対する感度が高いのが裏目に出ている感じだ。

実に悩ましい。

2005年2月2日

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #7 初回投稿日時: 2005年02月02日03時21分04秒
カテゴリ: Mozilla Core
固定リンク: id=2005020200
SNS: (list)

ようやくパッチ完成。RGBの各軸に対する感度の差がIEより若干、人間の感覚に近いものとなっている。 しかし、実際に様々なイラストサイトを回ってテストしてみたが(何故、イラストサイトかと言うとテキストの色を変更している確立が通常のメジャーサイトよりも高いし、原色ではなく、処理の難しい中間色を使っているところが多いからだ)、IEとの差は比べなくては分からない程度にしか出ない。

だが、それでも選択色がかえって見にくくなるサイトも多数みられた。 そういうサイトはIEでも同様の結果だったので、サイト作者は知った上でやってることだと思う。 また、そういうサイトは多くの場合、コントラストが不十分、つまり見にくいサイトだった。 ただし、一部、十分なコントラストがあるものの、期待通りにいかないサイトもあった。 だが、そのような色は背景を白にも、黒にも使えるような文字色だったので、あちらを立てればこちらが立たずということで、仕方ないことのようだ。例えば、#00DCC2だ。この色は、背景が黒でも大丈夫である。このように

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #8 初回投稿日時: 2005年02月02日05時12分12秒
カテゴリ: Mozilla Core
固定リンク: id=2005020201
SNS: (list)

Borisからいろいろとダメだしが出たので、早速修正。

MacOS Xや、他のプラットフォームでも、デフォルトの選択色が黒のテキストに対して反転してしまう場合、反転処理を行わないようにする。詳しくは検証していないが、Windowsでも一部の配色で反転しないという問題が出ると思うがそれは現状では対応策を思いつかない。

ロードマップ 初回投稿日時: 2005年02月02日21時50分33秒
カテゴリ: Mozilla Core Suite
固定リンク: id=2005020202
SNS: (list)

世間様一般ではFirefoxのロードマップばかりが取りあげられていますが、開発の主流は相変わらずSuiteという訳で、Suiteのロードマップを載せておきます。

Suiteのロードマップ

現在のTrunkが不安定なためか、1.8b2が追加されています。

2005年2月3日

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #9 初回投稿日時: 2005年02月03日14時06分10秒
カテゴリ: Mozilla Core
固定リンク: id=2005020301
SNS: (list)

さらにアルゴリズムを修正。よりシンプルに、選択文字色と、選択される文字色との関係だけで反転するかどうかを決定するようにした。WinIEでは選択背景色を判断材料に使っているので選択背景色が薄くなるほどIEの結果とは異なった結果になる。

この結果で私は良いと思う。できる限り正確な疑似背景色を求め、それと選択背景色から判断する方が正解は得やすいのだが、疑似背景色の取得失敗は結果の失敗を意味し、また、疑似背景色の算出は困難なのだ(一度、HSL色空間に変換してから疑似背景色を算出することも試してみたが、いまいちうまくいかなかった)。推測失敗のリスクを冒すよりも、確実な要素同士で算出する方が失敗しにくく、多くの場合において、よりよい結果を得られた。

なお、この処理方法にはひとつの前提条件がある。選択背景色と選択文字色は十分なコントラストがとられている、また、Webページの背景色と文字色も十分なコントラストがとられている、というものだ。そうでなくては読みにくいはずだからである。この前提が成り立つと仮定する限り、選択文字色と、ページの文字色が似た色なら背景色も似ている可能性があり、逆に似ていないのであれば、背景は似ていないという可能性が高くなる。

なお、今のところWinIEよりも反転しやすいアルゴリズムになっている(Windowsのデフォルトの選択色、背景がrgb(10, 36, 106)、文字が白での比較)。

現在のアルゴリズムでは、コントラストが十分かどうかの判断基準はW3Cのアクセシビリティの指標にあるものなので、選択文字色を白にして文字を選択し、背景色が期待通りになれば(暗いページでうまく反転すれば)、その配色は十分にコントラストがとれているという簡易チェックに使える。

MozillaでMacの選択色をテストする方法 初回投稿日時: 2005年02月03日14時30分11秒
カテゴリ: Mozilla Core
固定リンク: id=2005020302
SNS: (list)

背景色はrgb(159, 213, 255)に設定し、文字色をrgb(1, 1, 1)に設定する。

これで背景色は水色、文字色は元の文字色になる。

2005年2月6日

Bug 4250 [Win9x Only] グローバルIMEが利用できない 初回投稿日時: 2005年02月06日23時41分18秒
カテゴリ: Mozilla Core
固定リンク: id=2005020601
SNS: (list)

Win9xでグローバルIMEが利用できなくなっているというバグ。

Mozillaのウインドウクラス名を変更したのが原因の様だが、なぜそうなるのか分かっていない。 Mozilla1.8、Firefox1.1に向けてのコードフリーズまであまり時間が無いので、原因が分かる方、是非情報を。

2005年2月7日

Bug 4255 IMEの未確定文字列の文節の区切り目が分からない #2 初回投稿日時: 2005年02月07日12時46分18秒
カテゴリ: Mozilla Core
固定リンク: id=2005020700
SNS: (list)

Jokerさんからよく見てみると区切りがある、とのツッコミが。 色がアレなので無茶苦茶見難いものの、確かにアンダーラインは分割されている。

ソースコードを読み直すと確かに対策が入っている。 CVSの履歴で調査してみると、かなり昔に別のバグを修正する際に、ついでに対策が入れられていた。

というわけで、解決。

最近のお買い物 初回投稿日時: 2005年02月07日20時39分46秒
最終更新日時: 2005年02月07日20時40分07秒
カテゴリ: 雑談
固定リンク: id=2005020701
SNS: (list)

キーボードとスピーカーを新調。

スピーカーはカウボーイビバップのDVDを見るために5.1チャンネルのものが欲しくて購入。そうすると、PowerDVDもDVDドライブにバンドルされていたものでは2チャンネルに合成されてしまうことが発覚。仕方ないのでPowerDVDも購入するはめに……。おまけに、その後、サウンドカードも5.1チャンネルで出力すると壊れていたことが発覚。サウンドカードまで買い直すはめに……。結局、安いスピーカーを買ったにもかかわらず、総額では結構な値段になってしまった。

ちなみにスピーカーはJuster Multimediaの6D-208で、3600円ぐらいでした。

キーボードは、夜中に作業することが多いので静かなものを、と思い、ノートPCと同じパンタグラフのものを探してました。でも、条件としてフルキーボードで、通常のキーボードと同じキー配置のもの。特に、HomeEndはよく使うのでこれらが正位置にあるものを探したところ、ひとつだけ発見。

サンワサプライのSKB-SL05UHWです。これは高いんですが、かなりお勧め。

2005年2月19日

Bug 4253 [WXG] テキストボックスへの入力が確定後も未確定文字として表示が残る #2 初回投稿日時: 2005年02月19日19時58分16秒
カテゴリ: Mozilla Core
固定リンク: id=2005021900
SNS: (list)

WXGで再現していたこのバグも1.8b1に修正が間に合った。

IMEのcomposition windowを利用せずに、独自描画のやり方を改めて調査してみたところ、その方法には二つのステップがあり、

  1. WM_IME_SETCONTEXTで、lParamからISC_SHOWUICOMPOSITIONWINDOWを取り除く
  2. WM_IME_COMPOSITIONを適切に処理し、デフォルトウインドウプロシージャへ渡さない

ということのようだ。

要するに、IMEの未確定文字列が何らかの変更を受けるときに、デフォルトウインドウプロシージャに処理を任せてしまうと、その時点でcomposition windowが表示されてしまうし、それを消すこともできない。(ひょっとするとそのウインドウハンドルを取得していじれるのかもしれないが、やり方が分からない)

そのため、WXGの様に他のIMEとは異なり、勝手にcompsition windowを表示されてしまうと、手が付けられないし、元々、WM_IME_COMPOSITIONWM_IME_ENDCOMPOSITIONもデフォルトウインドウプロシージャに渡していないので、それを消すタイミングをWXGの方もつかめなくなっていたわけだ。(でも、現在の挙動だと、フローティングウインドウ上に同じ内容が出て、適切に消えるのでWXGの単なるバグのような気もする。)

とりあえず、今回の件により、WXGのナビキャレットをキャレット位置に表示する、ということはできなくなってしまった。

2005年2月22日

なんでもかんでもオープンなんてありえない 初回投稿日時: 2005年02月22日01時55分18秒
カテゴリ: 雑談
固定リンク: id=2005022200
SNS: (list)

ふと、思い出したので。

掲示板等で昔見たのですが、もじら組かMozilla Japanか、どっちか忘れたのですが、これらをバッシングするために、オープンじゃないのはけしからん、と声高に叫んでいる人がいましたが、オープンなことはスバラシイと言う人に限って外野で、何もしない人の様な気がします。

実際に作業していればオープンにすべきではないことも出てくるし、オープンにすることで効率が下がることもあります。

外野の野次馬としての、オープンであって欲しい、という気持ちは分からなくは無いですが、本当にある事柄に関してオープンであるべきかどうかは、それを批判する前に、一歩踏み込んで考えてみることも必要です。

2005年2月24日