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

Mozilla Developer Meeting 初回投稿日時: 2006年03月05日02時22分07秒
最終更新日時: 2006年03月05日02時24分43秒
カテゴリ: Firefox
固定リンク: id=2006030500
SNS: Tweet (list)

Mozilla Developer Meetingにお越し頂いた方、ありがとうございました。 できるだけペースを上げてまた開きたいですね。

それはさておき、Piroさん、本当にすいませんでした。

そしてそうこうするうちに時間が終わってしまい、僕が呼ばれた理由だったはずの拡張機能関係の話は全く話題に上らなかった。これならセミナーが終わった段階でその日のうちに帰ってもよかったかなあと思ったりして切なかった。

今後はこんなことが無いように問題として挙げておきます。Piroさんの話を聞くために来ていた方にもお詫びします。本当にすみませんでした。

拡張機能なんて仕組みがあるせいで、開発者が本家に貢献しなくなってるんじゃないのか

これも言いながら「ヤバ」と思ったんですが、気分を害されてたらすみません。本心ではありますが、別に拡張作者を責めているつもりはないのでそこだけ誤解なきようお願いします。(だって、私もボランティアで機能追加したかったら本体への組み込みよりも何の制約も無い拡張を選択しますから。)

ただ、拡張というFxとTbの最大のウリが皮肉にも本体への貢献者を減らしているのは事実だと考えています。要するに私たちは拡張の作者と密に連携して(当然、拡張作者が拒否しなければ)特に人気の高い拡張は本体に組み込んで行くべきなんでしょうね。まだまだ努力が足りていないとは思いますが。

で、ちょっと気になったのが、これじゃ勝てんぞ!!で書かれてた、

Firefox のシェアをどう増やしていくのかと言う話の下りでですね、何故か開発者が不足しているからシェアが延びないという話になって、いかにプログラマをうぬんかんぬんという話題にうつったのだけどね。

って、そんな話になりましたっけ? 私がとりあげた開発者不足の問題は全般的なことと、日本人が困るバグの修正速度が遅いこと、これに対する提起のつもりでシェアの話とは関係ないつもりだったのですが……

ただ、ゆきちさんがコメントつけられているように、下手にシェアが急増したとして、その時に開発者不足から不信感を多くのユーザに与えてしまうのではないかという懸念は確かに持っています。

あと、もじら組との関係は別に悪く無いですよ。そもそもMozilla Japanは、任意団体のもじら組ではできないことを担当するために設立されたという側面も非常に大きいのでお互いに無いと困るというのが現状ですし。ちなみに、人材、マンパワーといった面から見ると、Mozilla Japanよりももじら組の方が遙かに大きな組織だったりします。

それから、えむもじらより。

以下の記事のバグがそれらに該当するものでしょうか。

その通りです。リリースが近づいたら、再度全ての情報をここにまとめるつもりです。

最後に、いつもお世話になってる小池さんより。

このミーティングには正直なところ私は苛立ってしまった。日本でのFirefoxのシェアはなぜ伸びないのか、開発への貢献をどうやって増やしていくか、といった議論が中心で、技術的な中身がほとんどなかったからだ。

期待を裏切ったようでごめんなさい。技術的な中身としては何を期待されていたのかできればメールでも、blogでも良いので具体的にお聞かせ願えますか、次への参考とさせて頂きます。

Bugzilla-jpにはLinuxユーザーが少ない、とも話していたが、私の頃にはLinuxユーザーが多数派だったような気がする。

そうだったはずです。私がBugzilla-jpに本格的に参加する時に、ようやくWindowsのテスタが確保できた、みたいな話になってましたから。このへんの古参で現在も活動されてるのは大島さんだけなので昔のメンバーはほとんど消えてしまったと言えますね。それ以降、Linuxユーザが参加するよりもWindowsやMacのユーザの方がより多く増えたということだと思います。このへんは単純に母数の問題なのかもしれません。

中野さんはフルタイムの開発者なので私とは違うだろうが、Bugzilla-jpの運用に関わりすぎると私と同じ穴に落ちてしまいかねない。気をつけてほしいと思う。といっても代わりがいなければどうしようもないのだが。

この辺は身にしみて分かっているつもりです。ただ、バグ修正の方法というか、ネタというか、それを考えるのにかなり時間がかかるのでハックモードと、トラッキングモードとでもいうか、パッチ作成ばっかりやってる時期と、運営やバグ管理ばっかりやってる時とが交互にあるので、まあそれなりにバランスはとれているつもりです。(何より、パッチばかり書いてても気が滅入ってくるので、良い気晴らしにもなります。)

何はともあれ、色々と反応があって嬉しく思います。本当にありがとうございました。 そして、重ね重ね、Piroさんの時間が無くなってしまった件については、Piroさんと、参加者の方々にお詫びいたします。本当にすみませんでした。

シェアについて 初回投稿日時: 2006年03月05日03時28分08秒
カテゴリ: Firefox
固定リンク: id=2006030501
SNS: Tweet (list)

あくまで個人的な意見です。念のため。

とりあえず、日本ではFirefoxよりもThunderbirdの方が人気があって、欧米とは対照的らしいです。このへん、かけてる労力と人気の食い違いに内心複雑ではありますが。

ただ、このことから私が思うのは、やはり日本という市場は大きくて、Firefoxのシェアがまだまだ上がる余地はあるのだということ。もちろん、様々な要因があってシェアが伸びていないとは思いますが、あえて最大の原因を挙げろと言われると、私は「日本ではブラウザという市場自体が消え去っている」を挙げます。MUAに関しては、OEの以前のボロボロさ加減から、Becky等の対抗馬が一般化していたため、メーラーという市場があるからThunderbirdは多少注目されているのではないかと思います。

私も親戚とかと話していて仕事の話になっても、何をやっているのかいつも説明に苦しみます。何しろブラウザという単語そのものを知らないから話にならない。これが日本の現実なんでしょう。もちろん、弊社の商売を抜きにしてもこの状況は決して良いことではありません(だからこそボランティアで活動していた訳です)。何故こんなことになったのかと言えば、やはりMicrosoftの強引な戦略のせいであることは明白でしょう。(ただ、PCのユーザの裾野を広める戦略としてはこのやり方は利口だったとも思いますが。)

そして最も良くない状況なのがMicrosoftがIEは商売にはならないと考えている(であろう)点です。これは推測ですが、IEが長年バージョンアップできなかった理由は他に思いつきません。同じく独占状態のWindowsやOfficeに関しては、商売になるので、過去の自社製品をライバルとして製品の改善に努める必要がありますが、IEの場合、これが当てはまらないのでバージョンアップをサボればサボるほど「無駄な」出費をせずに済む、という状況なのでしょう。

そして不幸なことに、このときにまともな他の選択肢がなかったのも現在の状況を作り上げるのに一役買ったと思います。

このような状況下で「インターネット」というものに触れたなら、ブラウザを知らないのが当然のことで、長い間進化しない青いeのアイコンで開くウインドウで「ホームページ」を見る、これが多くの人にとっての「インターネット」になってしまったのだと思います。

では、こんな私の考える状況下でどうやれば打破できるのかと言えばメーカー製PCへのバンドル(しかもデフォルトブラウザに設定してもらう)しか私には思いつきません。もちろん、サポート等の面からメーカーが素直に応じてくれるなどとは思ってもいませんが……

ただ、多くの面でIEよりもFirefoxは優れていると私は確信していますが、まだまだ日本人の利用に際しては原始的な問題が残っている、つまりIEよりも劣っている部分があることも事実です。こういった問題の大半はFirefox3で解決される予定なので、開発現場の本音としては今はむしろ急激にシェアが伸びられると困るとも言えます。まだ、日本でシェアが一般の人にまで拡大していないのはそういう意味では幸せなのかもしれません。なぜなら一度失った信用を取り返すのは、私たちの現在のミッションよりもはるかに難しいと思うからです。(スラッシュドットを読んでいると、Fx1.0以前で失った信用、例えばデフォルトフォントがSerifだったりとか、セキュリティリリースが日本語版だけ遅れるとか、Fx1.5で改善された問題を未だに引きずっている人がいることからも明かだと思います。)

以上、マーケティング担当でも何でもない技術屋の意見でしたが、以下、スラッシュドットを読んでて明らかに間違ってるだろうということだけ突っ込み。

Sleipnirがあるからだ、なんていう意見は明らかにおかしいです。フェンリルの牧野氏がシェアについて発言されていますが、『インターネット白書2005』によると、国内におけるシェアは、IE6、IE5、Netscapeの次にSleipnirが入っています。全体の3.8％だそうです。とあります。

Fxはそれよりも下だったそうですが、たとえSleipnirのシェアが丸ごとFxに移っても10%なんていかないんですよ。つまり、Sleipnirのシェアなんて関係無いんですよね。それにSleipnirのユーザの大半はPCに関してそれなりの知識を持ち、他のブラウザとのメリット、デメリットを一度は秤にかけた、「自分でブラウザを選択した」ユーザだと思うのです。こういうユーザがFxに乗り換えるには、IEに対して相当なアドバンテージをGeckoが持たない限りはあり得ないでしょう。つまり、私たちが獲得を狙うべきユーザでも無いと思います。

この理屈で考えるなら、拡張を探すのが面倒とかを理由に挙げている人の意見も的外れになります。IEに比べてFirefoxが極端にシンプルなことはありません。むしろ多機能なぐらいです。つまり、そう言ってる人たちは多機能さがウリのSleipnirやOperaのユーザとしか思えません。つまり、これも私たちが獲得を狙うべきユーザでは無いのです。

マニア受けと、シェアは関係ありません。いかにライトユーザを取り込むか、これがどの業界でも共通のシェア獲得の原則です。つまり、ブラウザ市場の場合、パソコンに入っていたIEをそのまま意識せずに使っている大多数のユーザ、ここを狙わなくてはいけないと思います。(この件に関しては、32bitゲーム機のPlayStationとSEGA Saturnのシェア争いが私の記憶に鮮明にあります。結果はみなさんご存じのように、FF7で圧倒的なライトユーザの獲得に成功したPlayStationの圧勝でした。)

ただし、一つだけ気をつけなくてはいけないのは、オープンソースで開発を行っている以上、開発貢献者の機嫌を損ねては将来に暗雲が立ちこめてしまうところです。ライトユーザに媚びを売るために非標準への妥協を増やしたりして従来の方針をねじ曲げてしまうと開発者不足がより深刻になって破綻することになります。この点だけは絶対に忘れないように心がけなくてはいけません。

書き込んでる最中にクラッシュ 初回投稿日時: 2006年03月06日01時21分49秒
カテゴリ: 雑談
固定リンク: id=2006030600
SNS: Tweet (list)

長文書いてる時に例のバグでクラッシュしてやる気無くなったので寝ます。

あまり詳細な内容の本にはならないのかな? 初回投稿日時: 2006年03月07日00時17分14秒
カテゴリ: CSS
固定リンク: id=2006030700
SNS: Tweet (list)

神崎氏がCSS2.1の本を出すようですが、正直、何で今? なんて思ったけど、見出しを見る限りではそんなに詳細な内容の本ではないのかな。 ここ最近はCSSに関するバグ修正をやってないけど、結構まだまだ曖昧な点が多くてCSS3やCSS2.1の内容に影響を及ぼすディスカッションになることもあるので、まだちょっと本を書くには早いのではないかと思うわけだが。 ただ、A2.2 CSS2-98からの変更点なんてあるのでやっぱり細かいことも書かれるのかなと、少し心配。(Appendix C程度の雑な内容なら良いのだが……)

Bug 4449 word-spacingが に描画時のみ適用される 初回投稿日時: 2006年03月10日01時15分36秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2006031000
SNS: Tweet (list)

修正完了。このバグでディスカッションした結果、word-spacingは以下のように仕様変更となる。

• 単語の区切り文字一文字ごとにword-spacing値分、空白の幅を追加する
• 単語の区切り文字は、U+0020(半角スペース)、U+00A0(NBSP)、U+3000(全角スペース)の三文字

CSS3では前者の定義が覆されかけたが、結局この仕様に落ち着いている。前者の仕様の明確化により<length>値の基準となる文字の大きさは、word-spacing指定時のfont-sizeが参照されることになる。 例えば以下のような例を考えてみる。

<ol style="font-size: 20px; word-spacing: 0.1em;">
<li>word word</li>
<li style="font-size: 2em;">word word</li>
<li style="font-size: 2em; word-spacing: 0.1em;">word word</li>
</ol>

この場合、ol要素のword-spacingの算出値は2ピクセルとなるので、一つ目のリストアイテムの空白に追加される幅は2ピクセルとなる。また、二つめのリストアイテムの文字の大きさは倍の40ピクセルになっているが、word-spacingは計算結果を継承するので、このリストアイテム内で空白に追加される幅は2ピクセルのままである。最後のみword-spacingが再度指定されているのでその文字の大きさから計算され、20ピクセル × 2 × 0.1 = 4ピクセルとなる。

まあ、おそらくCSS2の仕様をきちんと理解していればここは明文化されただけなので違和感は何もないと思うが、整形済みテキストで出現する可能性のある空白文字の連続はCSS2でどう対処すれば良いのか定義されてなかったのでこの明文化には意味があることに注意して欲しい。

ただし、(今回修正するコードの問題ではなかったため)今回は踏み込まなかったが、次のような例は非現実的ではあるが問題が残っている。

word<span style="word-spacing: 1px;"> </span><span style="word-spacing: 2px;"> </span>word

この例でどちらの値を採用するかは今のところ実装依存である。(最も、この問題はword-spacingに限った話ではなく、background等でもどうなるのかという問題がある。)

その次は完全に新しい情報。まだCSS2.1の仕様書にも反映されていないが、概ね本決まりの模様。CSS2では単語の区切りとなる文字に関して明確な定義が行われていなかったが、上記の三文字と定義するということで話が落ち着いている。これ以外の空白(例えば、enスペースや、emスペース、ゼロ幅スペース等)はword-spacingの適用される語の区切り文字とはならない。

ただし、今回の修正では全角スペースには対応していない。これは仕様書に明文化されてから作業することになっているためで、現在は半角スペースと、NBSPのみが区切り文字として認識される。

次はletter-spacingについて作業しようかと考えている。これの仕様の曖昧さは実に酷い。

プラグイン表記問題雑感 初回投稿日時: 2006年03月13日21時07分37秒
カテゴリ: Mozilla Core 雑談
固定リンク: id=2006031300
SNS: Tweet (list)

例によって個人的な見解でMozilla Japanの公式見解ではありません。そもそも私は技術屋で、マーケティングとかパートナー連携の担当では無いので、そのへん理解して読んでください。

rgression連発とletter-spacingのリファクタリングのためのディスカッションであんまりこんなことに首をつっこんでる場合でも無いんですけど、あまりに騒ぎが大きくなってるようなのでコメント出しておきます。とりあえずアラビア語圏とヘブライ語圏の人すいませんでした。(ってここで書いても影響のある人は一人いるかいないかでしょうけど。)

結論から言うと私も用語の混同には閉口してます。オリジナルでもpluginとextensionと用語を使い分けていて、MJの和訳スタッフ、そして日本語化(L10N)の人達も「プラグイン」と「拡張機能」とやはり訳語のレベルでも使い分けているので、(企業としてではなく、ボランティアも含めた翻訳団体としての)MJの総意は使い分けるべき、と取るのが普通だと思います(MJの企業としての主張は私も知りません)。

そもそも結果として用語の混同を推奨している某サイトの考え方は理解することができません。公式で使い分けている用語をわざわざ別の用語で置き換えるというのは滅茶苦茶な話で、Firefoxユーザは「プラグイン」という用語から、操作に必要な「Extensions」というメニューを発見することはできませんし、Mozilla Updateにない拡張を検索エンジンで検索しても「プラグイン」では期待通りに検索結果は得られないでしょうし、もじら組フォーラムのような公の場で質問を書き込もうにも間違えた用語で書き込んでも話が混乱したりして、多くの人間にとって不利益が発生する可能性もあります。某サイトの主張するユーザの利益よりも、ユーザとその周囲に与えている不利益の方が圧倒的に大きいので賢明な選択とは言えません。

で、更に滅茶苦茶なのがこのポリシーすら中途半端な点です。ユーザのために用語の統一運動を行うのなら、何故プラグインの時に基準のひとつとしたIEにあわせて「ブックマーク」を「お気に入り」に、「Sidebar」を「エクスプローラバー」にしないのでしょうか? 「ロケーションバー」はきちんと「アドレスバー」に修正されているのに、です。このことから、結局はこの理屈は建前、言い訳であることが分かります。(もしくは単純に知識が足りないだけかもしれませんが。)

とりあえず、どのくらいユーザにとって不便な言い分かを顕著に表すために、似たような例を考えてみました。次のようなものです。

「Windowsのアプリケーション」で可能なデータの保存には、大きく分けて2種類の表記がある。1つは、ゲームでよく使われる“セーブ”。そして、ゲーム以外で使われている“保存”がある。どちらも「Windowsのアプリケーション」の情報を保存するという点では同じで。一般的なソフト利用者が違いを意識する必要はない。また、PlayStationなど他の端末では保存機能全般のことを一般的に“セーブ”と呼んでいることもあり、当サイトでは、その違いを意識せずに「Windowsのアプリケーション」を利用してほしいという観点から、他の端末と同様に「Windowsのアプリケーション」の保存機能を“セーブ”と表記する。

まあ、こんな注意書きがあれば普通は正気を疑われますね。保存というわかりやすい日本語を、わざわざ日常生活で使わないセーブという横文字に置き換えているんですから、分かりにくくなっていることは誰の目にも明かです。でもこれと同義のことを社を挙げてやっているのが某サイトなので困ったものです。(もっともこの例の場合、保存とセーブとに今回のような意味の違いはありませんが、用語の無責任な統一がどのように問題があるのかを考えるには十分な例だと思います。)

ちなみに、Mozilla FoundationでもMozilla Japanでも「プラグイン」と「拡張機能」は明確に使い分けていることがわかります。

Firefox(1.6a1)のHelpよりpluginの用語解説。原文でDeer Parkとなっている部分はFirefoxに置換しています。

Plugins add new capabilities to Firefox, such as the ability to play audio or video clips. Unlike other kinds of helper applications, a Plugin installs itself into the Plugins directory within the main Firefox installation directory and typically can be opened within Firefox itself (internally). For example, an audio Plugin lets you listen to audio files on a web page or in an e-mail message. Macromedia Flash Player and Java are both examples of Plugin applications.

それからExtensionsの解説。

Extensions are small add-ons to Firefox that change existing browser functionality or add new functionality.

Mozilla Japan ナレッジベース - テーマ・拡張機能とはより。

拡張機能は、Firefox の機能を強化するアドオン (小さな追加プログラム) です。タブブラウズ機能を充実させたり、マウスジェスチャーを使えるようにしたり、ツールバーを追加したりするものなど、様々なものがコミュニティのメンバーによって作成され、公開されています。

また、当該文書のキーワードに「プラグイン」という語はありません。

Mozilla JapanのFirefox FAQ、拡張機能とはなんですかより。

拡張機能は Firefox のブラウジング経験を強化するツールです。Firefox に新機能を追加する小さなプログラム (アドオン) だと考えてください。

このように、全般的にこんな感じでオフィシャルな文書で混同は見られません。

私の感覚では、問題のサイトは自分たちの呼びたいように呼んでいる、というのが現状のように思えます。用語を統一することでユーザの便宜を、と建前が書かれていますが、デメリットが大きいのは誰の目にも明かですし、他の用語は統一できていません。 (最もひどいのは、IEでの追加プログラムはプラグインと呼んでいると主張していますが、当のサイト自身がアドオンをプラグインとは表記していないという事実があります。つまり、建前の前提すら自身で否定しています。) 何よりも、用語はアプリケーションのUIにも関わる重要な製品の一部ですが、それを尊重しないというのは人としてどうなのか、と思います。

時々「検索プラグイン」という語を見かけます。これは使い分けがうまくいっていないようです。今回の騒動でのプラグインと拡張機能の定義を見ていると、プラグイン、拡張のどちらの語もこの機能には適切ではないように思います。そのためか、この用語はオフィシャルな文書ではほとんど登場せず、Firefoxの製品内(UIやヘルプ)では発見できませんでした。どうも、ユーザコミュニティで通っている通称のようです。ただ、オフィシャルな文書ではセキュリティ情報でMozilla Foundationがsearch pluginという語を使っており、MJ側でも検索プラグインと訳しています。また、Mozilla Foundationではpluginという語を使ってなくても、MJの和訳文書でのみ検索プラグインと表記されている文書もあります。ただ、インストールされるフォルダ名がsearchpluginsなので昔はこう呼んでいたドキュメントがあったものの、徐々に使わなくなってきているという状況なのかもしれません。

Bug 4501 letter-spacingのリファクタリング 初回投稿日時: 2006年03月14日02時36分01秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2006031400
SNS: Tweet (list)

概ね仕様がfixしてきた。基本的には文字間にのみスペースを追加する、画像等のインラインのオブジェクトもletter-spacingによって余白を持つ等の仕様になる予定。ちなみに、今のところWinIEの実装ともOperaの実装ともずれているが、インライン要素への指定で最もそれっぽいのはWinIEかもしれない。とりあえず仕様のディスカッションの一部を以下に引用しておく。

------- Comment #11 From fantasai  2006-03-11 22:14 PST  [reply] -------
Applying the letter-spacing to spaces within the letter-spaced element is well
established implementation-wise, so that can't change. But the behavior at
element boundaries is inconsistent, so we can spec that to be consistent and
reasonable.

Here's what I've drafted so far:

  | At element boundaries, the letter spacing is given by and rendered within
  | the innermost element that contains the boundary.
  | 
  | For example, given the markup
  |
  |   <P>a<LS>b<Z>cd</Z><Y>ef</Y></LS>g</P>
  |
  | and the style sheet
  |
  |   LS { letter-spacing: 1em; }
  |   Z { letter-spacing: 0.3em; }
  |   Y { letter-spacing: 0.4em; }
  |
  | The spacing would be
  |
  |   a[0]b[1em]c[0.3em]d[1em]e[0.4em]f[0]g

------- Comment #18 From fantasai  2006-03-12 11:03 PST  [reply] -------
> Doesn't the letter-spacing of end of line appear, right?

No letter-spacing at the beginning or end of a line.

> Should we render as:
> a[0]b[1em]c[0.3em]d[1em]e[0.4em]f[0]g
>           ~~~~~~~~~

Yes.

I would set up frames like this:

+-+------+---------+-----+---------+-+
|a|b[1em]|c[0.3em]d|[1em]|e[0.4em]f|g|
+-+------+---------+-----+---------+-+

Imagine putting backgrounds or borders on the elements.
The hierarchy needs to come out like this:

         +---------+     +---------+
  +------|---------|-----|---------+
+-|------|---------|-----|---------|-+
|a|b[1em]|c[0.3em]d|[1em]|e[0.4em]f|g|


> <p style="letter-spacing: 1em;">ab<img/>cd</p>

That should render as a[1em]b[1em]<img/>[1em]c[1em]d

Bug 4575 [GTK2] IME APIの実装 #1 初回投稿日時: 2006年03月14日16時04分47秒
カテゴリ: Mozilla Core
固定リンク: id=2006031401
SNS: Tweet (list)

Linuxユーザの方、お待たせ。GTK2でもエディタ以外のウィジェットや、パスワードエディタでIMが無効になるようになった。

これで残るはMacのみ。

Bug 4724 Javascript ConsoleにComponents.classes['@mozilla.org/thpeadfind;1'] has no propertiesが出る 初回投稿日時: 2006年03月14日16時06分13秒
カテゴリ: Thunderbird
固定リンク: id=2006031402
SNS: Tweet (list)

ThunderbirdのTrunkですさまじい数のJavascriptのwarningが出ていたバグ。ようやく修正完了。

Bug 330268 RTL characters typed into a textarea after a long unbreakable string don't appear on screen until scrolled 初回投稿日時: 2006年03月14日16時21分43秒
カテゴリ: Mozilla Core
固定リンク: id=2006031403
SNS: Tweet (list)

textareaに長い英単語を入れて、空白を入力して、RTLのテキストを折り返された次の行で入力すると二文字目以降、表示が更新されないというバグ。元々のワードラップ処理にバグがあったのが、word-spacingのリファクタリングで露出しただけだった。既に修正は完了している。

オープンソースはありとあらゆる要望を取り入れるものではない 初回投稿日時: 2006年03月16日02時12分51秒
最終更新日時: 2006年03月16日03時55分04秒
カテゴリ: 雑談
固定リンク: id=2006031600
SNS: Tweet (list)

Bugzillaで作業をしていて、オープンソースプロダクトはユーザの要望を積極的に取り入れていくべきだという思いこみを抱いている人がいるように思える。程度の問題であるのは言うまでもないが、過度のアプローチが破綻を招くことは、旧Mozilla Application Suite(現SeaMonkey)が皮肉にも証明してしまっている。ユーザの要望を(たとえその声が大きかったとしても)無闇に取り込むことはアプリケーションの肥大化を招く。toolkitによるアプリケーション群(FirefoxやThunderbird)のそれに対する答えが拡張機能であり、これは一定の成功を収めていると思う。(もちろん、先日、Developer Meetingで言ったように予期せぬ(?)弊害が出てしまっていることも否めないが。)

それでも拡張機能では難しい機能や、抜本的な改造が必要なものになると要望が提案され続けている。で、その中で問題だと思うのは(おそらく大半がそうなのだが)、自分が作業をする訳でもないのに要望だけ出していく人間である。こういった個人的な要望は開発コミュニティのデータベース上ではただのノイズだと思う。本当に多数の人が集まるのは開発コミュニティよりユーザコミュニティなのだから、ユーザコミュニティでよく挙がる要望を開発者が参考にすべきだと思う。つまり、要望はユーザコミュニティで一定の賛同、反応を得るべきであり、開発者はユーザコミュニティでよく持ち上がる要望を実装のアイデア、またはパッチと共に開発コミュニティに持ち込むべきだと思う。

要望の報告の難しいポイントは要望を思いついた人にはとても便利な機能という点である。だから、開発コミュニティに要望を出してくる人は要望が却下されると文句を言うが、これは提案者と、開発者に温度差がありすぎるために発生する。開発者からすれば、提案者がいくら便利だと騒ぎ立てたところで、実際の世論を知る由もないから、すぐに乗り気になれる優れたアイデアで無い限りは却下、あるいは放置ということになる。これを覆すにはやはりどのくらいの人が欲しがる機能であるかを開発者に示さなくてはいけない。それにはユーザコミュニティが一番良い場所だと思う。その要望がユーザコミュニティで大多数の賛同を得られない、または、その話題で盛り上がらないなら(おそらくは大抵はそうである)、開発者がその要望を蹴るのは正解だと言えると思う。

Bug-org 192767 Horizontal scrollbar missing on right-to-left (RTL/Hebrew/Arabic) page that doesn't fit in the screen #2 初回投稿日時: 2006年03月16日02時50分55秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2006031601
SNS: Tweet (list)

例の負の方向へのoverflowの問題が決着した。

Geckoの機能として、マイナス方向へのスクロールは実装された。しかし、現在のWebページへの配慮から実際にスクロール可能範囲を算出する際に(nsGfxScrollFrameInner::GetScrolledRect) Y方向へは常に0まで、X方向はLTRな要素では0まで、RTLなら負の値も許容されるものの、要素の右端が限度という制限がかかっている。つまり、LTRなWebページでのoverflowの挙動は今までと変わらない。

CSSは意味に対する表現の定義ではない 初回投稿日時: 2006年03月16日03時43分37秒
カテゴリ: CSS HTML XHTML XML
固定リンク: id=2006031602
SNS: Tweet (list)

CSSのセレクタはDOMツリーにとって都合のよい設計が行われている。都合がよいというのは処理が単純で、実用的な速度が確保できることを意味している。そのため、祖先から子孫は参照可能だが、その逆はできない。ここで問題がある。

<code><var>foo</var></code>

<var><code>foo</code></var>

これら二つの例はテキストに意味づけを行うというHTMLの原理からすると、同じ意味である。共に、ソースコード(片)であり、変数であることを意味している訳だ。(普通はvarだけで済ますかもしれないが、まあ、例ということで勘弁して欲しい。)

しかし、varとcodeの両方にスタイル指定を行っていると、これらの二つは違うものに見えることがある。例えば、それぞれの要素のcolorを変更した場合、当然、子孫になっている側の要素の指定が生き残ることになる。

HTMLで文書構造を定義して、CSSで表現方法を定義する、という一般的な解説ではHTMLで定義した、共通の意味を持つテキストに対して表現方法を一括指定するかのようにとれてしまうが、実際は共通の構造の要素に対して表現方法を一括指定しているだけの実に理系的な話なのである。XMLの存在や、HTMLでも親子関係に意味のある組み合わせを考えると、当然のことではあるのだが、この説明を単純に聞いてしまうと陥りがちな勘違いかもしれない。(別にこの説明が誤解を生む、悪い表現と言いたい訳ではない。端的にHTMLとCSSの関係を分かりやすく説明できる、これ以上の言葉を知らない。)

Flash Player の更新に関する注意喚起 初回投稿日時: 2006年03月17日02時43分21秒
カテゴリ: Software
固定リンク: id=2006031700
SNS: Tweet (list)

Windowsユーザで、IEなんて使わない、という人は特に注意してください、この問題。

Bug 4425 オートコンプリートが画面下部で発生した場合、候補リストがエディタを隠してしまう 初回投稿日時: 2006年03月19日02時15分16秒
カテゴリ: Firefox
固定リンク: id=2006031900
SNS: Tweet (list)

人によってはかなり鬱陶しかったのではないかと思われるこのバグがようやく修正されている。

Bug 4805 オートコンプリートを表示させたままwheel scrollすると、オートコンプリートが残ったままスクロールする 初回投稿日時: 2006年03月19日02時19分20秒
カテゴリ: Firefox
固定リンク: id=2006031901
SNS: Tweet (list)

ようやく修正完了。

だが、提出からレビュー開始まで実に三ヶ月半もかかっている。あまりにも問題。

1.8 branch用のパッチはしょうもないミスに気づかずに作成に半日もかかってしまった。

Mountain viewにて 初回投稿日時: 2006年03月30日15時49分17秒
最終更新日時: 2006年03月30日16時05分58秒
カテゴリ: Firefox Thunderbird
固定リンク: id=2006033000
SNS: Tweet (list)

ふぉくす子さんと、さんだば子さんの話題が出ました(あとOSたん)。そんだけ。