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

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

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

2005年9月2日

Bug 4102 サブメニューが開く時に、そのメニューが消える 初回投稿日時: 2005年09月02日00時43分27秒
カテゴリ: Mozilla Core
固定リンク: id=2005090201
リンク元: 3件
SNS: (list)

人によっては非常に気になっていたのではないかと思われるこのバグ、修正が完了した。

どいういうバグかと言うと、サブメニューが開く瞬間に、そのサブメニューの親のメニューごと閉じられてしまうことがあるというバグ。詳しくはバグ内のコメントを参照。

詳しく、説明してみると、まず、これまであるメニューがハイライトされた時、そのポップアップの他のメニューアイテムがサブメニューを開いているなら、そのサブメニューを閉じるためのタイマーを起動していた。一定時間経過して、そのサブメニューが相変わらずアクティブなメニューではなかった場合にはそのメニューを閉じ、アクティブになっていたらサブメニューを開いたままにしていた。

このメニューがアクティブであるかは閉じようとしているメニューから、子孫メニューの方へ順に下っていき、最後までポップアップ内のどれかのアイテムがハイライトされていたらアクティブ、そうでなければ非アクティブ、という判定方法だった。

この方法は多くの場合に問題が無かったが、以下の場合に最も子孫のメニューがハイライトされていない、という問題を抱えていた。

  • サブフォルダを開いた直後
  • メニューセパレータの上にマウスカーソルを移動した時
  • メニュー内のスクロールボタンにマウスカーソルを移動した時
  • メニュー内がスクロール出来るときに、マウスホイールでスクロールした時

これらの問題を、現在のアプローチのまま解決することは実に難しい。メニューはマウスでもキーボードでも操作できるという事実が特にこれを困難にしている。そこで、閉じるメカニズムはそのままに、アプローチを完全に変えてみるとこにした。

新方式では、あるメニューアイテムがハイライトした時、その祖先のポップアップのサブメニューを閉じるためのタイマーを全てキャンセルし、サブメニューを開いているアイテムをハイライト状態に戻して行っている。逆に言うなら、タイマーがタイムアウトした場合、メニューの状態は非アクティブのままだったいう判定で、常に閉じるようになった。

もし、微妙にフィードバックに違和感を感じるなら、この祖先メニューのハイライト状態の変更が従来よりも素早くなっていることに対するものだろう。(従来は、タイムアウト時に、そのメニューがアクティブと判定された場合に、サブメニューを開いているメニューをハイライトしなおしていた。)

メニューの動作を大きく変更したパッチなので、どのようなregressionがあるか想像つかないため、1.8branchへの承認申請は行わないことに注意して欲しい。

All your <base> are belong to us 初回投稿日時: 2005年09月02日03時43分12秒
カテゴリ: HTML IE
固定リンク: id=2005090202
リンク元: 7件
SNS: (list)

IEのめちゃくちゃな処理方法が告白されている。

この話によると、IE6まででは、base要素が出現すると、空要素にも関わらず(しかもhead要素内にしか出現できないにも関わらず)、それを開始タグとして、終了タグを"適切に"補完し、そのbase要素の影響すべきリンク全体がbase要素の子孫要素となるようにし、リンクは、自分に最も近い祖先のbase要素を参照していたというのだ。(base要素がhead要素内にあった場合は、body要素の親をbase要素とするらしい。詳しくはCode-Only: BASE tag changes in IE 7 with Examplesを参照。)

こんなことは普通の人なら思いつかない。base要素の処理における使用頻度を考えると、こんな複雑で、奇怪なことをしなくても各documentオブジェクトにbase要素の情報を持たせれば簡単で、高速な処理ができるではないか。(base要素はhead要素内でも一度しか出現が許されていない、つまり複数のbase要素を処理する義理など何処にもない。)

こんな非常識なことをおそらく、様々な処理で行っているのだろう。IEのバグには不可解で、原因を推測できないものも多い。W3Cの仕様などより、IEの仕様に他のブラウザが仕様を合わせるべきだと主張することがいかに荒唐無稽なことであるか分かるというものだ。IEの仕様にあわせるには、IEと同じ処理、ひいてはIEと同じコードを使わなくては同じになどなろうはずがない。

2005年9月6日

……と、思ったら 初回投稿日時: 2005年09月06日08時04分58秒
カテゴリ: 雑談
固定リンク: id=2005090600
リンク元: 0件
SNS: (list)

来た台風の規模も洒落になっていない。

ちなみに、早明浦ダムの完全回復には台風三個必要と言われていたのだが、14号だけで40%まで回復する見込みの模様。

2005年9月8日

2005年9月9日

Nightlyでテスト協力してくれる方へ 初回投稿日時: 2005年09月09日00時56分55秒
最終更新日時: 2005年09月27日04時13分05秒
カテゴリ: Firefox Suite Thunderbird
固定リンク: id=2005090900
リンク元: 2件
SNS: (list)

Nightlyでテストに協力してくれる場合、ひとつだけ注意が。

差分アップデートは使わないでください。regressionがあった場合、いつのビルドから発生したのか調査する場合、古いビルドに戻してテスト、なんてことが必要になりますので差分アップデートしていると後から苦労することになります。(古いNightlyはサーバからも削除されるので、日々のビルドを自分で保存しておかなくてはテストできなくなります。)

春永さんより指摘が。

古いNightlyビルドはarchiveサーバからダウンロードできる模様。異様に重いですが。

情報ありがとうございます。

Bug 1540 IMEの未確定文字の反転はシステムカラー(選択色)を使うべき(エディタの背景色にあわせて、必要なら反転もさせるべき) #2 初回投稿日時: 2005年09月09日02時26分18秒
最終更新日時: 2005年09月09日03時41分01秒
カテゴリ: Mozilla Core
固定リンク: id=2005090901
リンク元: 0件
SNS: (list)

パッチを分割して提出して時間をかけている間にパッチの単純化方法を考慮中。

よくよく考えてみればDrawSelectionIterator::GetSelectionColorsと、これで必要としている各種色情報がDrawSelectionIteratorにあること自体がおかしいのではないかと言う感じがしてきた。

nsTextFrame内でDrawSelectionIteratorを利用していない場所でこのクラスの算出する色情報が必要になったのだが、このクラスを色取得のためだけに動的に生成するには無駄が多いし(一回の描画用の処理経路で数個、同じ内容のメンバを持つクラスを複製しなくてはいけなくなる)、数々の不足情報を補うために膨大な修正が必要になる。こういう場合(修正箇所が多岐にわたる場合)、経験上、設計そのものが悪いことがほとんどだ。

という方向で検討してみたところ、色の情報なんだからnsTextFrame::TextPaintStyleに持たせときゃいいんじゃないかという答えが見えてくる。そしてこの構造体を見てみれば、選択色情報を持っているではないか。しかもただ単にDrawSelectionIteratorに色情報を渡すのに使っているだけだ。ということは、最初にDrawSelectionIteratorにも色情報を分散させて保存させだした当たりから大きな間違いが始まっていたのだろう。前回の私の選択色反転のパッチもこの流れにのってしまっていた。反省。

2005年9月13日

とりあえずプリンタまわりのregressionが出たので 初回投稿日時: 2005年09月13日23時20分04秒
カテゴリ: Mozilla Core
固定リンク: id=2005091300
リンク元: 0件
SNS: (list)

二台以上プリンタがある状態じゃないとテストできないし、ネットワークプリンタが無くて困っていたので奮発してカラーレーザープリンタ購入。金が……

2005年9月14日

元日本代表のラモス氏が柏のコーチに就任 初回投稿日時: 2005年09月14日01時34分40秒
カテゴリ: 雑談
固定リンク: id=2005091400
リンク元: 1件
SNS: (list)

おおっ。S級ライセンスは持ってるようですし、そのうち監督にまでなるのでしょうか。柏も強くなるといいですね。 > 大島さん

徳島の試合は一度も見たことないですけど、カズが来る時は行きたいなー。

ATOK2005 初回投稿日時: 2005年09月14日14時23分28秒
カテゴリ: Software
固定リンク: id=2005091401
リンク元: 0件
SNS: (list)

ATOK17 ProfessionalからATOK2005 Professionalにアップグレードしたのだが、どうにも変換効率が悪くなっている。文節が思い通りのところで切られないことが多いし、漢字の優先順位もおかしい。ATOK17に戻した方が良いのか?というぐらいに不調だ。

2005年9月15日

バグをいつまで修正し続けられるのか 初回投稿日時: 2005年09月15日00時49分43秒
カテゴリ: 雑談
固定リンク: id=2005091500
リンク元: 0件
SNS: (list)

膨大なMozillaのソースコードの中で特定のバグの原因を探し、確証が得られたら修正案を考える。いつもの手順。理解不能で放置していた問題も他のバグを修正したりする内に理解できるようになってくる。でも、いつまで新たな問題を理解し続けられるのか、修正し続けられるのか、年齢、技術、知識……それぞれの面から心配はつきない。

ひとつバグをつぶせば、ひとつの仕事が完了する。しかし、それと同時にひとつ仕事を失う。これが不安のタネである。

しかし、現実的にはいくつかのバグ修正の後、いくつかのパッチがひとつ以上のregressionを引き起こしたり、更に別の問題を浮き彫りしたりする。このように仕事が減ることは幸いにも無いようだ。しかし、自分で修正可能とは限らない。こうなると、私のできる仕事とは呼べなくなる。増えた仕事は全員で共通の仕事であって、私のものとは限らないということだ(regressionの場合、責任はあるが)。

多くのMozillaユーザにとって、私が修正できるバグが存在しなくなって私が職を失うことは(少なくとも現状よりは)良いことなのかもしれない。でも私としては嬉しくない。複雑なものである。

そんなこんなで今日もバグを修正しながら、30万個の仕事になるかもしれないネタを物色し続けている。

Bug-org 307545 CSS text-align: justify makes win32-based screen readers slow 初回投稿日時: 2005年09月15日01時15分21秒
カテゴリ: Mozilla Core
固定リンク: id=2005091501
リンク元: 0件
SNS: (list)

見た目のために、理屈と違うことをするとツールが混乱するよ、という良い例。勉強になるなぁ。

Windowsのスクリーンリーダはテキストを出力するAPIをフックして読み上げを行っているようなのだが、Geckoはsmallcaps、wordspacing、letterspacing、justificationの場合には、一文字ずつ(これは1.9で一グラフィームクラスタずつに改善される予定)位置調整してテキスト(というか文字)を出力する。つまり、文字数の分だけ問題のAPIが呼び出されるので期待通りにスクリーンリーダが動かない、ということだ(重くなるだけか? スペルとかは大丈夫なのか? スペースは出力されないぞ?)。

趣味や仕事で不特定多数の人が使う可能性のあるアプリケーションを書いている人は気をつけよう。

2005年9月16日

Bug 4601 最後に使ったプリンタが記憶されない 初回投稿日時: 2005年09月16日00時41分09秒
最終更新日時: 2005年09月16日01時25分05秒
カテゴリ: Firefox Mozilla Core Suite
固定リンク: id=2005091600
リンク元: 0件
SNS: (list)

Firefox/Suite/Javascriptによる印刷で印刷する際に、常にデフォルトのプリンタが選択されていたというregression。FirefoxとJavascriptによる印刷時のパッチのみ先行でチェックインした。

Linuxでは若干事情が違っているので、このパッチのみで機能するかどうかテストしたいのだが、Fedora Core等でGUIからプリンタを追加しても、Mozillaの印刷ダイアログでは追加したプリンタがリストアップされなかった。Linuxのことはさっぱり分からないのでテストができなくて困っている。早急にテストして(次のFirefoxベータ版までに)、問題があるなら修正しないといけないのだが、誰か協力してもらえないだろうか?

テストに協力してもらえるなら、CVSからTrunkのソースコードを引っ張ってきて、ビルドするか、明日以降のNightlyビルドでテストしてみて欲しい。なお、ビルドする場合は、パッチをあてることでSuiteでもテストできる。

Suiteでも修正完了。

The <?xml> prolog, strict mode, and XHTML in IE 初回投稿日時: 2005年09月16日17時37分11秒
最終更新日時: 2005年09月16日17時44分03秒
カテゴリ: IE XHTML XML
固定リンク: id=2005091603
リンク元: 7件
SNS: (list)

IE7ではXML宣言があっても、正しくDOCTYPEスイッチが機能するように修正するようだ。

しかし、XHTMLの厳密な取り扱い(application/xhtml+xmlの処理)は見送られるようだ。理由は、セキュリティ問題への取り組みと、CSSバグへの取り組みで時間が無い、ということと、現在のパーサを使うと、MozillaやOperaのように、InvalidなXHTML文書の場合、エラーを返すのではなく、HTMLとの互換性を重視してエラーを出さずにレンダリングしてしまうことが問題のようだ。

IEのapplication/xhtml+xmlの中途半端なサポートによって、他のブラウザではパースエラーの出るXHTMLの怪文書が世の中に出回る、という最悪な事態は避けられるようである。私はこの決断に大いに賛成だ。

しかし、IE6以降、MSは何をやっていたんだという批判は避けられない話ではある。全く何もやってなかったからこうなった訳で、夏休みの宿題を8月末から大あわてでやり始めた、という光景が目に浮かぶ。

2005年9月17日

Bug 4606 Firefoxのタブが閉じれない 初回投稿日時: 2005年09月17日04時49分57秒
最終更新日時: 2005年09月17日05時03分38秒
カテゴリ: Firefox Mozilla Core
固定リンク: id=2005091700
リンク元: 0件
SNS: (list)

tabbrowser.xmlでエラーが出ているのでbug 4539のregressionかと思ったけど、DocShellの方にも修正が入ってるので、そっちの可能性の方が高そう。

修正パッチが入った模様。DocShell側の問題だったようだ。

2005年9月18日

Bug-org 306209 Should fire NS_FOCUSCONTENT event on nsPluginInstanceOwner by clicking plugin's content 初回投稿日時: 2005年09月18日23時59分37秒
カテゴリ: Mozilla Core
固定リンク: id=2005091801
リンク元: 0件
SNS: (list)

Flash等、一部のプラグインにフォーカスが移っても、フォーカスイベントが発生していなかった問題。VYV03354さんが対応してくれた。

これでIME無効化に向けてのブロッカーは無くなった。

2005年9月19日

Bug 3474 リンクが画面上で複数行に分割された場合、先頭行が表示されない状態でクリックすると、先頭行に移動するだけで、リンクに飛ばない 初回投稿日時: 2005年09月19日00時02分56秒
最終更新日時: 2005年09月19日00時21分31秒
カテゴリ: Mozilla Core
固定リンク: id=2005091900
リンク元: 0件
SNS: (list)

昨日、ソースを見ていてたまたま思いついた修正方法が当たりだったバグ。既に修正完了している。

これと同じ問題の、サーバサイドイメージマップの場合の問題も同時に修正できている。

Blogの見出しのアンカー 初回投稿日時: 2005年09月19日00時48分48秒
最終更新日時: 2005年09月19日00時51分21秒
カテゴリ: HTML
固定リンク: id=2005091901
リンク元: 5件
SNS: (list)

見出しをアンカーにしてゐるサイトでありがちなのが、「他所の『ブログ』の人がURLをコピーし易いやうに設けてあるアンカー」。

私もこれには反対。リンクだけを抽出して、見出しを並べてみたとして、確かにその見出しの記事へのリンクであり、内容は間違ってはいないわけだが、単に、コンテンツを見に来た人がクリックすると、騙されたと思わないだろうか。記事を内容込みの一覧で見ていて、そこから、その記事のみを表示させるリンクを誰が利用するのか、と考えたときにコンテンツを見に来ただけの人は絶対利用しないと思う。

自身(というか、同内容の別URL)へのリンクは基本的に利用者に混乱を与えるものだと思う。だから、うちでは目立たないようにしているつもり。

「ここ」とか、「ここをクリック」並に批判があっても良いように思えるのだが。

2005年9月20日

も゛ー 初回投稿日時: 2005年09月20日04時09分27秒
カテゴリ: 雑談
固定リンク: id=2005092000
リンク元: 0件
SNS: (list)

regressionやら、取りこぼしやら多すぎ。

大規模修正を入れることができるalpha期間と、リリース間際のregression対応とが重なるのはどうにかならんのか。

Bug-org 270079 Mozilla can not print the URL in the header and footer. 初回投稿日時: 2005年09月20日07時20分22秒
最終更新日時: 2005年09月20日07時21分32秒
カテゴリ: Mozilla Core
固定リンク: id=2005092001
リンク元: 0件
SNS: (list)

Mozillaの1.0以降のプリンタ周りのregressionはこいつが原因だ。やっと見つけた。なんでこんなめちゃくちゃなパッチが通ってるんだ。

これに気づかずに、修正したために、最後に印刷したプリンタとその設定が、再起動後も設定を持ち越すように変更してしまっているが良いんだろうか。もう、知らない。

個人的にIE7に求めるもの 初回投稿日時: 2005年09月20日07時33分25秒
カテゴリ: IE 雑談
固定リンク: id=2005092002
リンク元: 0件
SNS: (list)

IEのレンダリングエンジンに密着した、Mozillaのものと同程度のDOM Inspectorが欲しい。CSSのIEによる不可思議な表示結果の原因を調べるには、現在公開されているDOM Inspectorでは物足りない。

2005年9月21日

Bug 1302 [CSS2.0][CSS3] text-shadowプロパティが未実装 初回投稿日時: 2005年09月21日02時32分39秒
最終更新日時: 2005年09月21日02時42分11秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2005092100
リンク元: 1件
SNS: (list)

パッチが出た。パッチ中に記述があるように、blur radius(ぼかし半径)を無視するようになっている(nsTextFrame.cppの部分を参照)。Cairoに切り替えて、ぼかしをつけれるのなら良いのだが、中途半端な実装なので慎重にやって欲しいなぁ。

User agents MAY only implement only part of this property by ignoring blur effects. Such user agents should consider declarations that specify the blur radius to be parser errors, as described in the Syntax module [link TBD].

一つ前のCSS3テキストモジュールではこのように書かれているので、一応、仕様の範囲内の実装ではあるのか。(ちなみに、最新のテキストモジュールではtext-shadowは更新されていない)

overflowの解釈、間違ってませんか? 初回投稿日時: 2005年09月21日03時46分22秒
最終更新日時: 2005年09月21日03時48分41秒
カテゴリ: CSS
固定リンク: id=2005092101
リンク元: 19件
SNS: (list)

今日、ふと思い出して、この話題をまだ書いたこと無いことに気づいたので簡単に。

CSSハックだとか、SEOだとかで、text-indentに大きなマイナスの値を指定したり、position: absolute;で、lefttopに大きなマイナスの値を指定して、要するに、ブラウザがスクロールできない場所にテキストを持って行く、という手法を聞いたことがある。

CSSの仕様書を見たことあれば、こんな手法は不自然に感じると思う。そして、その疑念は正しい。CSSのoverflowauto値の説明を見てみると、

The behavior of the 'auto' value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes.

とある。つまり、理想的なブラウザでは、負の座標に追いやられたボックスもスクロールすることで表示可能と考えるべきである。

さらに、ブラウザのルート要素に指定されたoverflow: visible;(初期値)はCSSのauto値に読み替えることになっているので、ブラウザはその内容を全てスクロールで表示可能とするべきであるということになる。

Mozillaでも古くからこの問題はとりあげられており、修正パッチが無いので修正されていないだけで、そのうち改善されることになるかもしれない。その時に、とんでもない表示になるサイトが少ないことを祈るばかりだ。

2005年9月22日

Re: マイナスのtext-indentを使って文字を画面外にふっとばすテクニックの妥当性 初回投稿日時: 2005年09月22日04時44分57秒
最終更新日時: 2005年09月22日04時45分38秒
カテゴリ: CSS
固定リンク: id=2005092200
リンク元: 2件
SNS: (list)

「h1の文字列をふっとばして背景画像だけ使いたいような場合なら、h1 { overflow: hidden; text-indent: -100em; }でええんでないの?」と。

確かに。overflow: hidden;を使うと良いかもしれない。(ただし、Mozillaの場合、適切な動作かどうかはさておいて、hiddenでクリッピングされたコンテンツにもマウスでスクロール可能なことに注意)

position: absoulte;の場合、もし、負の方向に配置するボックス以外に、絶対配置のボックスがないのであれば、XHTMLなら次のようにすれば解決できる(かもしれない)。

html{
  overflow: hidden;
  height: 100%;
  border: none;
  padding: 0;
}
body{
  position: static !important;
  overflow: auto;
  height: 100%;
  border: none;
  margin-top: 0; margin-bottom: 0;
  padding-top: 0; padding-bottom: 0;
}

2005年9月23日

Bug 4603 日本語を含む添付ファイルをdetachすると、元のメッセージから開けない 初回投稿日時: 2005年09月23日01時49分39秒
最終更新日時: 2005年09月23日01時50分23秒
カテゴリ: Thunderbird
固定リンク: id=2005092300
リンク元: 0件
SNS: (list)

修正完了。

開こうとした時のダイアログ(Toolkit: Unknown Content Type Didalog/XPFE: Helper Application Dialog)でファイル名がURLエンコードされたままになる問題は残っている。

2005年9月24日

Bug 4402 カラーデバイスの場合、選択色の反転で色そのものの違いに従ったアルゴリズムにすべき 初回投稿日時: 2005年09月24日04時31分41秒
最終更新日時: 2005年09月25日13時07分26秒
カテゴリ: Memo Mozilla Core
固定リンク: id=2005092401
リンク元: 0件
SNS: (list)

人間にとって違う色に見えるとはどういうことだろうか? RGB色空間の二点間における距離が一定以上ある、ということでは無いと思う。RGB色空間は人間の色覚にあわせて作られた空間とは思えない。RGB各方向への重み付けが必要になるからだ。

では単純に明度を求めるための重み付けを利用して、R:G:B = 289:587:114から、(R / 289, G / 587, B / 114)の点同士の距離を考えれば良いのだろうか??

人間の目は緑に鈍感なので、逆に少ない変化で明るく見えているのか。画像圧縮に書かれている次の言葉が気になるなぁ。

人間の目は、明るさに関しては、微妙な違いに敏感であるが、色の違いには敏感ではない。そのため、色の信号の画素数は、明るさ信号の、さらに半分の大きさの情報で良い。

色覚に障害のあるユーザーにとって適切であることを示すには、グレー スケールに変更して色選択が適切に動作することを確認するだけで十分だと考える人がいるかもしれませんが、全く根拠がありません。

この下に実例もあるが、確かにそうだ。Mozillaの選択色交換ではグレースケール時のコントラストを元にしているので、グレースケール上ではまともに機能するが、色覚に障害のある方には、見分けがついてないことがあるのか。ということは、このバグの優先順位を引き上げないとまずいな。

だが、全ての色覚障害とグレースケールを意識して、常にコントラストを保つにはどうすれば良いのだろう? 単純に現在の明度差による検証と、4つの色空間でそれぞれコントラストがあるか検査するしか無いのか?

Firefoxをビルドする時 初回投稿日時: 2005年09月24日06時07分14秒
カテゴリ: Firefox 雑談
固定リンク: id=2005092402
リンク元: 0件
SNS: (list)

Firefoxをビルドするとき、メモリがlink.exeに600MB以上奪われて、めちゃくちゃ重くなるのだが、2GBぐらい積めば軽くなるのだろうか。Windows(32bit)でアプリが使えるメモリ容量は実メモリの半分と聞いたことあるので(半分は強制的にカーネルが予約してしまうらしい)、1GBじゃ足らんわなぁ。

CSSレイアウト最大の欠点 初回投稿日時: 2005年09月24日07時44分39秒
最終更新日時: 2005年09月24日07時52分43秒
カテゴリ: CSS
固定リンク: id=2005092403
リンク元: 6件
SNS: (list)

文書ソースの前後関係と、ボックスの位置関係に何の関連性も無いことがあるのがCSSレイアウトの最大の欠点だ。このため、キーボード等で、従来通りの設計のUA上で文書ソース順にフォーカスを移動させると、ユーザにはフォーカスの移動先の予測がつかないこともありうる。

もちろんこれはCSS仕様の欠点ではなく、CSS仕様に本当の意味で適合できていないUAに問題がある。UAの使命はユーザにとって使いやすいものを提供することなのだから。この問題に取り組んでいるのは、Mozillaの空間ナビゲーションしか知らないが、他の家電向けブラウザ等ではどうなのだろうか。

しかし、「現実派」な人には深刻だ。シェア世界一位のIEユーザには不便をかけるのだから。(マウスの無い、PCなんて、と考えるかもしれないが、仕事でノートPCを持ち歩く場合にはマウスが使えないことが多いので、意外とキーボードによるナビゲーションは需要がある。)

これを「改善」できるのはタブ順指定だが、これは文書ソースで行うしか無いため、矛盾がある。CSSを処理しなかった場合、タブ順が無茶苦茶になるからだ。当然、これはお勧めできない。

アクセスキーは論外だろう。誰がいちいち、一時的に訪れたサイトのアクセスキー規則を覚えるだろうか? そんなもの、覚えてもそのサイトでしか使えない。また、ブラウザのアクセスキーとのバッティングの問題もある。

positionfloatを使うなというのは極論すぎるが、あまりにトリッキーなことをしすぎると、訪問者に混乱を与えることになりうるということを知っておくべきだろう。(これを全く知らずに作ったサイトの良い(?)例は、何も知らずにホームページビルダーのどこでも配置モードでデザインされたサイトだ。)

一番良いのは、文書ソース内で、ユーザが使わなさそうなリンクをできるだけ削減し、訪問者がよく利用しそうなリンクを優先的に配置することかもしれない。当然、CSSが適用されない場合には不自然にならないようにしなければいけないので、文書の構成能力が問われると言える。

こういう意味ではタブレットPCというのは、モバイル端末としてアリかもしれない。

Bug 1561 [INVA] COL要素、COLGROUP要素からtext-alignが継承されない 初回投稿日時: 2005年09月24日23時06分28秒
カテゴリ: CSS HTML Mozilla Core
固定リンク: id=2005092405
リンク元: 0件
SNS: (list)

そういえばもうひとつ。こちらもdbaronが動き出している。Ianと協議の結果、このCSSに準拠しない挙動をどのように実装すべきかを決めたということだが、果たしてどのようになるのか。

私も早く、Geckoのソースを理解できるようにならねば。

2005年9月26日

Seamonkeyが起動しない 初回投稿日時: 2005年09月26日06時44分41秒
最終更新日時: 2005年09月26日06時49分37秒
カテゴリ: Suite
固定リンク: id=2005092600
リンク元: 0件
SNS: (list)

24、25日共に起動しない。profileも消したし、アンインストールもしてみたけど駄目。何故??

Bug-org 308838か。

Ask.jpはapplication/xhtml+xmlに対応? 初回投稿日時: 2005年09月26日06時56分41秒
カテゴリ: XHTML
固定リンク: id=2005092601
リンク元: 0件
SNS: (list)

ask.jpで検索してみると、この日記の目次がひっかかり、内容も表示されている。この、今見てくれている日記本体は.phpという拡張子のためか、データベースにも入って無さそうだが、静的なapplication/xhtml+xmlには対応しているのかもしれない。Yahoo!とGoogleは相変わらず駄目。

2005年9月27日

Bug-org 308755 Change in behavior with type-to-find for non-link text and pressing TAB 初回投稿日時: 2005年09月27日05時38分54秒
カテゴリ: Firefox
固定リンク: id=2005092700
リンク元: 0件
SNS: (list)

/でFAYTを開始して、リンクでは無いテキストを発見している状態で、タブキーを押しても、そのテキストの前後のリンクにフォーカスが移らないという問題。これも私自身のregression。

修正は完了した。1.8 branchには承認申請中。

このバグの修正で、FAYT中にでツールバーを閉じても、元の位置にフォーカスが戻らない問題が修正可能になっていると思う。ただし、これはregressionではないので1.8 branchでは修正しない予定。

Bug-org 92217 [reflow] text doesn't rewrap after becoming small enough to wrap 初回投稿日時: 2005年09月27日05時55分39秒
カテゴリ: Mozilla Core
固定リンク: id=2005092701
リンク元: 0件
SNS: (list)

動的擬似クラスによる再reflow時に再度、折り返し処理をやりなおしていなかったバグ。

斉藤さんにより修正された。感謝。

ちなみに、仕様通りの動作だと言えるはずだが、テストケースの挙動が愉快。position: relative;をリンク等で使ってるサイトでよく見かけるループと原理は同じ。

Bug-org 97023 Search/Find in page UI: toolbar instead of dialog 初回投稿日時: 2005年09月27日06時03分50秒
カテゴリ: Suite
固定リンク: id=2005092702
リンク元: 0件
SNS: (list)

SuiteにもFind Toolbarを、というリクエスト。

FAYTのUIは明らかにFirefoxの方がわかりやすいし、コードもシンプルなので、なんとかしたいけど、頭が痛い。ちなみに、SuiteのFAYTのソースは全てC++で、フロントエンドとバックエンドをソース上で分離できていないのでなかなかに混沌としている。

IME無効化のパッチを見直してみると 初回投稿日時: 2005年09月27日06時20分14秒
カテゴリ: 雑談
固定リンク: id=2005092704
リンク元: 0件
SNS: (list)

IME無効化のパッチを見直してみると、いくつか拡張性に問題のあるコードがある。何でコードを書いていてもよくある自分の欠点なのだが、最適化というか、ケチって書きすぎなんだろうか。