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

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

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

2006年9月1日

セオリー・オブ・スタイルシート 初回投稿日時: 2006年09月01日02時58分06秒
最終更新日時: 2006年09月01日03時00分52秒
カテゴリ: CSS 雑談
固定リンク: id=2006090100
リンク元: 0件
SNS: (list)

発売時に買っていたのだが、先日、寝付けなかった時にようやく目を通すことができた。といっても神崎氏の部分だけだが。

内容はCSS2.1の仕様の解説といった感じ。ある意味で仕様に詳しい人は読む必要が無いと言えなくもないぐらい正確な内容。でも、補足してある点や、問題点として挙げているものは興味深いものも多々あるので、仕様に詳しい人でも、それを読むためだけに買うのも良いかと。

標準を謳っている本でも大抵ざっと目を通してるだけで突っ込みどころは多々あるのが普通だが、この本にざっと目を通した限りでは間違いは見つけられなかった。CSSを真剣に勉強したい人にとっては仕様書以外の資料としてはたぶん最も良いと思う。ただ、きちんと書かれている分、難しくて取っつきにくいと言えるかもしれない。この辺の両立というのはやはり難しいのか。デザイナが扱うものを理系的発想で仕様化されたものがスタイルシートだと私は思うので、理屈っぽくなるほどデザイナには取っつきにくいんではないかと思ってしまう。(逆にデザイナの書いたと思われる本はとっつきやすい感じではあるが、内容に間違いがあったり、説明すべきことが省かれていたりと、その品質に疑問を感じることが多い。)

一番評価したいのは、仕様がはっきりしていることに関してはあまりブラウザの実装状況について解説していないところ。仕様を理解する上でブラウザの挙動なんてのは無駄な情報でしか無いと私は思う。仕様を理解できたら、次にブラウザの挙動について研究して実際の運用に利用するというのが本来の手順だと私は思うので、そういった点でもこの本は好きだ。だが、overflowの問題とか、z-indexの問題等、アクセシビリティに関わる重大なものについてはブラウザの挙動も交えた解説が行われているので、全く触れていない訳でもない。この手法の使い分けは素晴らしいと思う。

私もMozilla Japanに入る前にスタイルシートの本を書きたいな、と考えていて、最近でも「いつかは……」と思っていたが、この本を見たら、色んな意味でその気は完全に無くなった。まあ、そのぐらいお勧め。

と、思いっきりべた褒めな記事になってしまったが、本当に勉強したい人は、やはり仕様書も読むを付けておくべきだ。私の発見できなかった間違いがあるかもしれない(別に間違い探しをするために読んだ訳ではないのだから)し、仕様は常に変化し続けるので新しい仕様を必要に応じて読む必要が出てくることもあるだろう。あくまで仕様書を読むための補足的な解説書という意味でこの本はお薦めできる。

ところで、この内容ぐらいはデザイナを自負している人には是非とも理解しておいてもらいたいものだが、そうでは無い人、多いんだろうなぁ……

2006年9月2日

Bug 5180 [Cairo][pango] pangoによるフォントスイッチングがデタラメ #5 初回投稿日時: 2006年09月02日02時41分07秒
最終更新日時: 2006年09月02日02時41分49秒
カテゴリ: Mozilla Core
固定リンク: id=2006090200
リンク元: 0件
SNS: (list)

おおむね問題無くなってきたが、IPAフォントでビットマップフォントとして表示される時に限り、空白以降がランダムに消えてしまうバグがある。

さざなみのビットマップフォントでは発生しないし、IPAフォントでもベクタで描画される大きさにすると(小、大ともに)、問題なくなる。

ぐぐってみたものの、類似の問題が見受けられないので、cairo_show_glyphsあたりのバグなんだろうか?

2006年9月7日

Bug 5295 Core一般のバグの一部のWeb表示への移し替え / Web表示の改名 初回投稿日時: 2006年09月07日03時38分51秒
カテゴリ: Bugzilla-jp
固定リンク: id=2006090700
リンク元: 0件
SNS: (list)

5分ぐらいで終わってしまった。

レイアウト/描画

レンダリングエンジン(Gecko)のバグを扱います。Webサイトの表示の崩れや、テキストや画像等の描画のバグを扱います。 本家(bugzilla.org)では"GFX"と、"Image"、そして"Layout"と"Style System (CSS)"にあたります。

2006年9月8日

2006年9月9日

Bug-org 347481 Microsummaries are not picked up when the page is served/parsed as XML 初回投稿日時: 2006年09月09日18時11分41秒
最終更新日時: 2006年09月09日18時13分57秒
カテゴリ: Firefox
固定リンク: id=2006090900
リンク元: 0件
SNS: (list)

えむもじらの記事を参考にMicrosummaryを作ってみた。でも、なんでかうまくいかないと思ったらこんなバグが。

ところで、サーバ負荷を抑えるために、サマリの取得だけ専用のリソースにしようと目論んだが、どうにも無理っぽいので断念。

ちなみに、このもずはっく日記では、よく同じサマリの記事が並ぶので、分かりやすい様に連番を頭に表示させるために、meta要素を利用してみた。

Microsummaryは当該文書からしかサマリを生成できない、という仕様の方が好ましいのかもしれない 初回投稿日時: 2006年09月09日23時42分00秒
最終更新日時: 2006年09月10日03時05分15秒
カテゴリ: Firefox
固定リンク: id=2006090901
リンク元: 0件
SNS: (list)

よくよく考えてみると、オンライン上のgeneratorの指示で別のドキュメントのデータを見に行くということは、最初だけgeneratorで適切なものを表示できるようにしておいて、普及、安心させた後で改竄してしまう、なんていうことがあるかもしれない。(javascriptで追加したgeneratorはprofile内に保存されるので、最初に登録したgeneratorのまま変更される心配はなさそうだが。)

2006年9月10日

stable? 初回投稿日時: 2006年09月10日03時48分03秒
カテゴリ: WebStudio
固定リンク: id=2006091000
リンク元: 2件
SNS: (list)

そういえばこのサイトのアクセス解析によると圧倒的にFx1.5.0.6の人が多いんですが、このサイトで一番ダントツでアクセスの多いのも、このもずはっく日記なのです。

この状況は正直、当初は想定していなかったことで、今でも私が元々ターゲットとしていたnightlyユーザをメインターゲットにおいて書いてます。この認識のずれは、Mozilla関連製品のすそ野が広がっていると考えるなら、喜ばしいことかなぁとも思うのですが、nightlyを追いかけていない人は、ここに何を期待されているんでしょう? ほとんどの人がサマリだけ見て、中身を見ていないということの方が多いのではないかという気がします。もしそうならできるだけそのギャップを埋めたいなぁとは考えていますが、そもそも何故stableを使う人がここを見ているのかを私が理解できていないのが難儀なところです。

Linuxのテキストレンダリングの今後の予定 初回投稿日時: 2006年09月10日23時56分39秒
カテゴリ: Mozilla Core
固定リンク: id=2006091001
リンク元: 0件
SNS: (list)

今現在、pango_layout_*を使わないようにする、というかなり大きめのパッチがレビュー中だが、これが入ってもまだいくつか問題がある。

pango_layout_*が取り除いた状態ではフォント名のエイリアスが一部の環境で機能していないし、pango経由でのフォントの取得に結構無駄が多い。そこで、次の段階ではfontconfigを利用して、pangoフォントを生成する前に、一つのファミリ名から一つ以上のフォント名に解決してからフォントを生成することで、fontconfigの設定により忠実な表示にできるのではないかと考えている。

更にその次の段階では非complex scriptsではxftを利用したより高速な描画に取りかかりたい。pangoのshapingはどうも遅いようなので、これを利用せずにフォントからグリフを取得できれば高速化できるのではないかと考えている。

2006年9月12日

Bug-org 131456 Memory use does not go down after closing tabs (resources not released) 初回投稿日時: 2006年09月12日02時46分08秒
最終更新日時: 2006年09月12日04時30分16秒
カテゴリ: Firefox Opera
固定リンク: id=2006091200
リンク元: 0件
SNS: (list)

興味深い話が出ていた。 ちなみに、以下のテスト結果は私の環境(Win2k)でテストケースを実行した直後のWindowsからのメモリ割り当て量と、テストで開かれたタブ、もしくはウインドウを全て閉じた時の割り当て量、そして、そのテスト中の最大メモリ割り当て量。

browser Windowsから割り当てられたメモリ容量(テスト終了時) Windowsから割り当てられたメモリ容量(開かれたタブ/ウインドウを消した状態) 最大割り当て量
Firefox(2006091004) 136M88M143M
Firefox(2006091004)で、タブを使用しない設定 124M115M135M
Opera 9.01 131M123M142M

興味深いのはFirefoxとOperaはメモリ割り当て量が似ているところ。Operaも意外とメモリを使っている。だが、CSS2.1をまともなレベルでサポートする、ということはこれぐらいのメモリ容量が必要ということかもしれない。

もう一つ興味深いのは、タブを利用していないFirefoxとOperaのウインドウを閉じた後の結果が似ている点。Firefoxをタブブラウザとして使用している状態では、タブを閉じた段階で結構メモりをWindowsに回収されているが、ウインドウを開いていくモードでは、ほとんど保留されている。同じく、ウインドウを開くことでタブっぽい動作をしているOperaも同じだ(OperaはMDIアプリケーション)。この辺、Windowsのメモリ管理の癖なのかもしれない。

ちなみに、メモリ割り当て量を観察するツールとして、実に多くの人に信頼されている「Windows タスク マネージャ」を利用した。

Re: (9/12d) 原理主義者と、他もろもろ。 初回投稿日時: 2006年09月12日17時55分56秒
最終更新日時: 2006年09月12日18時10分34秒
カテゴリ: CSS Firefox HTML XHTML
固定リンク: id=2006091201
リンク元: 4件
SNS: (list)

意外と批判する人がいて、驚いた。あ、ちなみに私はこの件には参加できていない。

以前、私はBugzilla-jpのWeb標準化プロダクトと、そのドキュメント化のプロジェクトであるWeb標準普及プロジェクトに全力で取り組んでいたが、あのプロジェクトで得た経験や、Webデザイナ達の現状から考えると私は今回のような発想が出てくるのは至極当然だと思う。

私の実感では大多数のWebデザイナ(自覚無くても個人のblog等でCSSいじっている人も含む)は、好意的に考えても、標準仕様を知っていても理解はできていない。つまり、レベルが低い。レベルが低いサイトが未だに残っているのだから、それをなんとかしようと考えるのは当然だろう。そして、それに対するひとつの解がTouchUpWebの発想だ。私はこの考え方には初めて話を聞いた時から賛成していた。

Web標準に対する理解が昔よりは改善していることは事実だが、それでも私が期待していたよりも遥に低レベルなまま、そして概ね予想通りのレベルで、Web標準が定着してしまった(この件に関してはまた機会があれば書いてみたい)。しかし、TouchUpWebの扱うサイトは、その低レベルなWeb標準準拠サイトよりも、更に低レベルな訳だ。(現状で世界シェア第二位のブラウザでの表示確認すら怠っているというのは、標準云々以前のところに問題があるように思う。) そういう人に対して啓蒙していくことは理屈の上では正しいとしても、それがはたして効果的で、本当に利益のあることだろうか?

実際に啓蒙等の行動に移してみれば、それがいかに大変なことか分かるだろうし、どうにもならないことというのも見えてくる。(批判されている方は、自分でそういった活動はされたのだろうか?)もし、ほとんど啓蒙も行っていない段階でTouchUpWebが立ち上がっていたら、私も批判していたかもしれないが、Web標準が有志によって、ある程度啓蒙され、そして形はどうあれそれが浸透した現状において、実際にユーザが遭遇する問題への解の一つとしては、至極まっとうなものではないだろうか?

Web標準が何のためにあるかと言えば、結局のところユーザの利便性のためである。そのユーザの利便性よりも理論、理屈のみを重視しすぎて、肝心のユーザをおいてけぼりでは本末転倒だと私は思う。(GeckoやPrestoはそうじゃないのか、という意見もあるかもしれないが、エンジンにquirksを入れてしまうのは全然別次元の話である。Netscape4.xが実証し、今もTridentが実証し続けているが、エンジンの非標準な挙動は未来での長期的な不利益が、ユーザへの短期的な利益を圧倒的に上回ってしまう。)

ちなみに、

これがあるからってもう誰もでたらめなページを作るようになったらどうするのだろう.

という意見もあるが、これは自動化されたインテリジェンスなシステムではない。サイト毎に人が介入しているのだから、需要の多いページ( != サイト)から順に対応していくという運用になるのだろう(この辺、私も知らない)。そうであるなら、サイトの制作者側からすれば不確定極まりないシステムに自分のサイトを預けたいと思うだろうか? 私はそうは思わない。CSSやJavascriptを駆使しようとしたサイトは、レベルがどうであれ見せる(魅せる?)ことが目的のひとつのはずである。そういう意味ではわざわざ崩れてしまうサイトを作ってしまうという事態は考えにくい。

2006年9月13日

IE Tab 1.1.0以前のデフォルト設定に脆弱性 初回投稿日時: 2006年09月13日15時35分33秒
カテゴリ: Software
固定リンク: id=2006091300
リンク元: 10件
SNS: (list)

二番目のサイトは有名なセキュリティ関係のblogらしいので、この脆弱性はその手の方々には有名なのかもしれない。

要するに、以前のデフォルト設定ではupdate.microsoft.com/がURLのどこに含まれていても—例えば、クエリやディレクトリ名として含まれていても—そのURLをIEで開いてしまうというもの。つまり、攻撃者は任意のページをIEで開かせることができるので、IE Tabを入れて、デフォルト設定を確認せずにそのまま使ってると、IEの持つ脆弱性はそのままそのユーザのFirefoxの脆弱性にもなってしまう。

Firefox使ってるから、ということで安心しているユーザはIEユーザよりも危険かもしれない。

最新の1.1.0.2では修正されている模様。(修正内容がfix the site filter minor bug.というのはいかがなものか。)

自主的に拡張を入れた人ならこういった問題に多少気を配っている可能性はあるが(おそらく大部分はそうではなさそうだが。私もそうだし。)、他人から勧められて入れてしまった人、というのが危ない気がする。もし、他人にこの拡張の導入を勧めた人が居るなら、その面倒も責任持って対処してほしい。

2006年9月17日

2006年9月19日

2006年9月21日

CSS3 Values and Units 初回投稿日時: 2006年09月21日04時40分55秒
最終更新日時: 2006年09月21日04時49分31秒
カテゴリ: CSS
固定リンク: id=2006092100
リンク元: 3件
SNS: (list)

ようやく待望の機能が二つ、Working Draftに出てきた。

ひとつは相対単位のch。これは1ch0の幅とする模様。

今までのemexは文字の高さを基準としていたため、width等、水平方向へのプロパティと親和性の高い単位が初めて誕生することになる。

ただ、何故、0が基準なのかという疑問はある。0が無い場合、平均文字幅で代替するということになっているが、平均文字幅の算出方法はどうするか未定のようだし、何より、PC用OSではフォントの平均文字幅を普通に取得、利用できる、というかしているので、算出方法は実装依存として、最初から平均文字幅を利用しちゃう方が良いと思うのだが。(0が含まれていないフォントを一つ目に指定してなかったら、次のフォントを調査しないといけない、というのはどう考えても実用的じゃない。)

もうひとつはcalc関数。これは便利。ようやく、100% - 15emなんていう幅指定とかが可能になる訳だ。ただ、実装に際してはそれなりに注意しておかないと、桁あふれで問題が発生したりするかもしれない。

2006年9月22日

Re: 「小泉」をクリックすると「ブッシュ」が表示されるFirefoxのバグ 初回投稿日時: 2006年09月22日01時59分56秒
最終更新日時: 2006年09月22日02時03分54秒
カテゴリ: Firefox
固定リンク: id=2006092200
リンク元: 2件
SNS: (list)

IRCで話題になったこの話。どうにもうさんくさい。

後で調べてわかったことだが、Firefox(私は1.5.0.7で確認)は、アドレスボックスにキーワードを入れると、Googleで最初にヒットしたページを表示するようになっている(試して欲しい)。

と書かれているが、デフォルトで利用しているのはGoogleのI'm Feeling Luckyだと思う。で、実際にページで例示されているテストを試してみてもwikipediaには飛ばない。まだ問題の記事が書かれてから1日ちょっとしか経っていないが、それで結果が変わってしまうという不安定極まりないシステムで、そんなに効果的な攻撃ができるのだろうか?

URLでフィルタリングやブラックリスト制限をしているセキュリティソフトをくぐり抜けられるかも?

なんてことを書かれてるものの、その理屈が理解できない。どんなザルなセキュリティソフト?

色々と考えられるパターンを試してみたが、これといって、直接そのジャンプ先のURLを記述した場合に比べて、迂回させられたリンクによるリスクの増加というのが全く思いつかなかった。これってただの、結果が不安定なリダイレクトじゃないかなと思う。

どうしてもこの機能が気持ち悪い、気になるというならkeyword.enabledを無効にしておいた方が良いが、私はこれによるセキュリティ的なリスクは今のところ無いと思う。(もちろん、もし発見したら、blogなんかで書かずに、まずは報告して欲しい。)

なんか、ただのFUDかなという気もしてきた。

2006年9月30日

Re: (9/30) 別ページ 初回投稿日時: 2006年09月30日00時28分47秒
最終更新日時: 2006年09月30日00時30分33秒
カテゴリ: HTML
固定リンク: id=2006093000
リンク元: 0件
SNS: (list)

ところでこの target="任意の文字" というのはどういうことなのでしょうね.どこかにその説明はないかと思って探してみましたが見つかりません.

普通に仕様書に書かれてますが……

ちょっと気になったのですが、UAの挙動を語るなら、Web標準仕様の最低限の知識は必要ですので勉強された方が良いと思います。

Bug 5180 [Cairo][pango] pangoによるフォントスイッチングがデタラメ #6 初回投稿日時: 2006年09月30日00時38分54秒
カテゴリ: Mozilla Core
固定リンク: id=2006093001
リンク元: 0件
SNS: (list)

盆ぐらいからかかりっきりだったこのバグがようやく修正完了。

この修正で、pango_layout_*によるフォントの選択等が無くなったので、パフォーマンスが全体的に上がっている。pangoに対する依存度が減ったのは非常に良いことで、これは大きな勝利の一つ。今後も非complex scriptではpangoに対する依存をより減らして行く方針。これによって、かなりコストの削減ができることを見込んでいる。

ただし、まだまだ無駄や不完全な点が多いコードなので今後も改良が必要。

このバグ修正で以下のバグも修正されている。

開発機をWindows2000からWinXP Proに移行 初回投稿日時: 2006年09月30日00時47分00秒
カテゴリ: 雑談
固定リンク: id=2006093003
リンク元: 0件
SNS: (list)

長い間使い続けてきたWindows2000だったが、近頃はアプリケーション側での非対応とかUPnPがサポートされていないことから色々と不便が多かったのでアップグレードしたいとは常々思っていた。

しかし、WinVistaの発売まで粘ろうと我慢していたが、発売が遅れ続けるわ、RC1で移行のためのテストをしてみるとあまりにも常用しているアプリケーションが対応できていないわと、WinVistaへのアップグレードには時間が必要と判断して、購入に踏み切った。

なんで他社のブランド、トレードマークにそんなにこだわるんだろう 初回投稿日時: 2006年09月30日17時33分12秒
最終更新日時: 2006年10月01日00時25分21秒
カテゴリ: Firefox Thunderbird
固定リンク: id=2006093004
リンク元: 20件
SNS: (list)

事実確認はほとんど行っていません。takenさんからの情報を基に理解した内容で記述しているので誤解があるかもしれません。

saitonさんのところより

どうせだれかその界隈の人が解説してくれるだろうと期待していたが、上記 taken.s101 の他を不幸にして未だ知らない。

なんで、DebianのようなLinuxのディストロコミュニティが他社のトレードマークにそんなにこだわるんでしょう。 嫌ならFirefoxとしてではなく、名もないブラウザとしてビルド、バンドルすれば良いんですよ。 それも嫌なら、KHTMLという代替もある訳ですし。

Mozilla Corporationは普通に、自社の財産としてブランディングの保護を行っている訳で、社会的には普通のことです。Firefoxという名前は使いたいけど、アイコンとかは使いたくない、というDebianの主張はただのワガママだと思いますが、間違っているのでしょうか? しかもFirefoxの場合、Firefoxとして出荷されるバイナリにはパートナーとの契約に基づいたコードが入ってる訳ですが、オフィシャルブランディングを使用しない場合、これも無効になってしまいます。これでは、パートナーからすれば話が違うという話になるでしょう。つまり、Debianのやってた事というのは、Mozilla Corporationの権利を既に侵害していた訳ですよね。

あげくに、プロダクトを馬鹿にするような名前を付けようというのでは、ただの子供です。そのくせ、Debianは自分たちのブランドを守ることには必死なようで、理解に苦しみます。自分達の権利は守りたいけど、他社の権利はどうでも良い、そういうことなんでしょう、今回の話は。つまり、コメントするのもばかばかしいぐらい幼稚なので何も書いてなかっただけです。

誤解されると嫌なのでちょっと追記。

私は別に、Debianや他のLinuxがFirefoxという名前を使わないことを(立場もありますし、また純粋に一ファンとしても)残念とは思っても、別に不満は無いです。その自由さこそが、フリーソフト、OSSの魅力ではないかと思うわけですし。

今回の件は、今のところ、Debianが自分たちの思い通りにならないことに対して、不満を言ってるようにしか見えません。そこが非常に不愉快なだけです。