Taken SPC

もじら組Wiki が少し見づらいなと思ったので、とりあえず、見出しに応じて内容をインデントさせてみることに。以下はそのユーザスタイルシート。

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain(wiki.mozilla.gr.jp),
               domain(wiki2.mozilla.gr.jp) {
    div.wiki_body > h4 ~ *:not(h4):not(h3):not(h2):not(form) {
        margin-left : 1.5em !important;
    }

    div.wiki_body > h3 ~ *:not(h3):not(h2):not(form) {
        margin-left : 1em !important;
    }

    div.wiki_body > h2 ~ *:not(h2):not(form) {
        margin-left : 0.5em !important;
    }
}

Firefox 3 ではロケーションバーの Favicon 部分をクリックするとポップアップが表示されて、サイトの身元や接続の暗号化されているかを確認できます。

ポップアップに表示される警官の名前は Larry というらしいです。

で、このポップアップは背景色は白に決め打ちなんですが、前景色は一部だけ黒に決め打ちになっているため、システムの前景色が白に近いと一部の文字が読みにくくなってしまいます 。以下は Windows のハイコントラスト (黒)　でのスクリーンショットです。

さて、このポップアップは IE7 の「セキュリティ報告」のポップアップを基にしていると思うのですが、こちらは大部分の背景を画像にしていますが、前景色はシステムの前景色を使っています。なのでシステムの前景色が白に近いと、ほとんどの文字が読めなくなってしまいます 。以下は Windows のハイコントラスト (黒)　でのスクリーンショットです。

背景を決め打ちするときは前景色も決め打ちしましょう、という話。

Piro さんのエントリを見て思ったこと。

Firefox の非人間的なところは何であろうかと。私はアドオンだと思います。Piro さんのエントリ風に書けば、以下のような感じです。

「アドオン」が存在するツールでは、何かするためには必ず、「何をするか」をあらかじめ決めておき、その上で、然るべき「アドオン」を追加しなくてはならない。よって、追加するアドオンを間違えたら使えない。あるアドオンを使い始めてから「あ、これは別の(しかも、今入れているアドオンと衝突する)アドオンにしかない機能だ」と気がついても、手遅れだ。そのアドオンをアンインストール/無効にしてから目的のアドオンを追加して、Firefox を再起動し、もう一度、操作を最初からやり直さないといけない。

そういう Firefox を人間的にするのであれば、開発者に喧嘩を売って、泣きついて、ゴリ押しして、レビューをもらってツリーにパッチを投入する、つまり Firefox そのものを改善するしかないのではないだろうか、と思うことが時々あります。

とはいえ、アドオンというのは非人間的であったとしても、一部の人間には手放せない機構です。万人を幸せにすることは、もしかしたら、できないのかもしれませんが、幸せになれる人たちも確実にいるわけで、嘆き悲しむようなものでもないと思います。

Mozilla 24 サイト を幅の狭いウィンドウでも見やすくする拡張機能 CrossZoom を開発しました。

これは何?

テキストサイズを一定に保ったまま、ページ全体を拡大/縮小します。

ダウンロード

以下のリンクよりダウンロードしてください。この拡張は Gran Paradiso (Firefox 3) Alpha 7 以降で動作します。

crosszoom-0.1-fx.xpi ( application/x-xpinstall : 3 KB)

使いかた

インストールすると、ステータスバーに CrossZoom のパネルが表示されます。

スライダを動かすか、テキストボックスに数値を入れてページ全体の拡大/縮小率を設定してください。

活用例

Mozilla 24 サイト での例

before

after

CrossZoom で 70% 縮小した場合のスクリーンショットは以下の通り

解説

Gran Paradiso (Firefox 3) Alpha 7 から、これまであったテキストズームに加えて、ページ全体を拡大/縮小するフルズームが実装されました。この拡張機能ではテキストズームにフルズームの逆数を設定することで、テキストサイズを保ったままページ全体を拡大/縮小します。肝となるコードは以下のようになります。

var factor = 0.8; // 1 で等倍
var mackupViewer = gBrowser.selectedBrowser.markupDocumentViewer;
mackupViewer.fullZoom = factor; // ページ全体のズーム
mackupViewer.textZoom = 1/factor; // テキストのズーム

ToDo

• キーボードショートカット
• アイコン
• 見た目の向上
• サイト毎に設定を覚える
• AMO に投稿

その他

• コードネームは「キモズーム」でした
• 実際の名前はヒッチコックの「めまい」にあやかった Vertigo も考えていました
• メインとなるボックスがやたら狭いページでも役にたつかもしれません

木達さんのブラウザだらけの討論大会の告知を読んでいたところ以下の文が目にとまりました。

以下、開催概要です（microformatsのhCalendarを使って記述しているので、Operatorのような処理系を利用している方には情報を取り出すのに便利かもしれません）。

そこで早速 Firefox 2 に Operator 0.8 をインストールして試してみました。が、残念ながら Operator は hCalendar を見つけてくれませんでした 。

そこで、Operator のソース (Microformats.js)を見たところ、title 属性を拾っているのは abbr 要素だけという悲しい事実がわかりました。木達さんの記事では abbr 要素ではなく sapn 要素を使っているので hCalendar を検出できていませんでした。

ということで、プロファイルディレクトリの /extensions/{95C9A302-8557-4052-91B7-2BB6BA33C885}/chrome/operator.jar の中の content/Microformats/Microformats.js の該当部分を書き換えます。書き換え前のコードは以下の通り

    defaultGetter: function(propnode, parentnode, datatype) {
      if (((((propnode.localName.toLowerCase() == "abbr") || (propnode.localName.toLowerCase() == "html:abbr")) && !propnode.namespaceURI) || 
         ((propnode.localName.toLowerCase() == "abbr") && (propnode.namespaceURI == "http://www.w3.org/1999/xhtml"))) && (propnode.getAttribute("title"))) {
        return propnode.getAttribute("title");
      } else if ...

書き換え後のコードは以下のとおり。

    defaultGetter: function(propnode, parentnode, datatype) {
      if (((((propnode.localName.toLowerCase() == "abbr" ||
              propnode.localName.toLowerCase() == "span") ||
             (propnode.localName.toLowerCase() == "html:abbr" ||
              propnode.localName.toLowerCase() == "html:span")) &&
            !propnode.namespaceURI) || 
           ((propnode.localName.toLowerCase() == "abbr" ||
             propnode.localName.toLowerCase() == "span") &&
            (propnode.namespaceURI == "http://www.w3.org/1999/xhtml"))) &&
          (propnode.getAttribute("title"))) {
        return propnode.getAttribute("title");
      } else if ...

これで木達さんの記事でも hCalendar を検出できるようになりました 。

とはいえ、弊害もあるかもしれませんのでご注意ください。

あるいは、処理する要素の要素型名に関係なく title 属性を持っていたら title 属性の内容を優先する方がより良いのかもしれません。

久し振りに Mozilla SVG ネタを。Mozilla SVG が Thebes を使う予定なので、近い将来 non-cairo ビルド で SVG が無効になります。現時点の設定で影響を受けるのは Mac OS X の Trunk Nightly です。

• Bug 354866 - Replace nsSVGCairoCanvas with gfxContext
• Bug 359101 Need SVG disabled on non-cairo trunk builds

以前はパッチを当てないとクラッシュしていた OpenGL 支援ですが、今日パッチなしで試したみたところクラッシュせずに動きました。ビルド設定に --enable-glitz を付けてビルドし、 MOZ_GLITZ=1 firefox だけで試すことができます。

ただし常用するには程遠く、ウェブページが真っ黒になったりなんて当り前ですし、色々なページでクラッシュします。テキストが滲んで表示される場合もあります。

気になる速度の方ですが BenchJS と CSS Rendering Benchmark (~2500 positioned DIVs)(ローカルに保存して実行)でテストしてみました。結果からいうとどちらも OpenGL 支援を受けた方が遅かったです。

同一のビルドで MOZ_GLITZ=1 の指定無し(OpenGL 支援無し)と指定有り(OpenGL 支援有り)で試しました。新規プロファイルを作成し、プライバシー情報の消去でキャッシュ等は毎回削除するようにしました。テストは各回毎に Firefox を再起動しました。

BenchJS の Test3 画像の切替えと Test 6 の DHTML で OpenGL 支援有りの方が 2 倍以上時間がかかっているのは気になります。

CSS Rendering Benchmark は OpenGL 支援有りでは 4 回目と 5 回目の結果が突出しています。OpenGL 支援有りの方だけ 6 回以降もやるにはやったのですが、数値は安定しませんでした。しかし 700 ミリ秒を切ることはありませんでした。

今回は X.org 7.0.0 を使いましたが、Aiglx ではどうなのか、気になるところです。

寄付をしろといいつつリンク先が別ドメイン、別組織の怪しいサイトを知りました。ところが Firefox 2 でも IE7 でもフィッシングの危険性について何も言ってこない。フィッシング検出はザルということなのでしょうか。

Mozilla Japan からお誘いが来たので 10 月 27 日の Firefox 2 貢献者交流会へ参加しました。 Mozilla Developer Center の開発者のための Firefox 2 関連のドキュメントを一部訳しましたが、貢献者という実感はあまり湧かなかったり。他の参加者は Mozilla Japan のスタッフ、l10n、テスタ、Mozilla の開発者、拡張開発者というそうそうたる方々でした。まさに今熱い方々が集まったのでは無いかと思います。

さて、Mozilla Japan のオフィスに 18 時頃に着き、19 時から渋谷のレストランでディナを頂きつつ歓談しておりました。終止和やかな雰囲気でした。

多くの話がでましたし、参加された人数が多かったので私が話に参加できた部分は一部だけです。その中からいくつかの話題を簡単に書いておきます。私の考えと他の人の考えが混じっております。こんな感じの話題が出たということで認識して頂ければ幸いです。

どうやって情報仕入れているのか

という質問が私にあったので、簡単に書いておきます

Bugzilla

Bugzilla から情報を拾うことはかなりあります。現在の bugzilla.mozilla.org ではバグ一覧のページからフィードを取得できるので、気になるフィードをフィードアグリゲータに突っ込んでいます。フィードで分かるのは最終更新日で、コメントなどはわかりません。また、公開されていないバグ(セキュリティフラグの立っているバグ)も取得できません。フィードアグリゲータで気になるバグを見付けたら節操なく CC に自分のアカウントを追加しています。以降そのバグの更新情報がメールで自分のところへ届きます。

• 一週間以内に更新された Mozilla SVG の開いているバグのフィード

Bonsai

Firefox 関係だけではなくて、レポジトリの中の全てのファイルの 1 日以内に更新記録を見ています。チェックインの概要に関連するバグが載っている事がほとんどなので気になるバグを見に行きます。最近は Reflow Branch の一週間以内の更新記録も見ています。

MozillaZine Forum

MozillaZine の Firefox Builds も見ています。見ているだけです。The Official Win32 ..... builds are out , RSS feed. はブックマークツールバーに入れています。

planet.mozilla.org

普通にフィードを購読

wiki.mozilla.org

普通にフィードを購読

もじらかけらアンテナ

アンテナに登録されているところのフィードは購読していますが、時々見に行きます。

MDC

後で書く

ウィジット/ガジェット

Microsoft の WPF や Adobe の Apollo などもあるなと。怖いのは IE7 ではなくて .NET Frameworks 3.0 だろうと。

参考

• Vistaの新機能「Windows Presentation Foundation」対応を国内10社が表明
• Windows Vistaで実現する次世代Webを披露、MSがWeb開発者向けイベント
• アドビ、次期プラットフォーム「Apollo」のプレビューバージョン公開(ただしダウンロード可能にはなっていない)
• Adobe、アプリケーション開発プラットフォーム『Apollo』推進を計画
• ApolloはFlash Playerとともに降りてくる?

Apollo では HTML + JavaScript のみでアプリケーションが書けるとのことです。さらに、この記事を書いている際に気が付いたのですが、HTML 等の処理は WebKit が行うとのこと(参考:Apollo が WebKit を採用)。

HTML と JavaScript と CSS でアプリケーションが作成できるようになった時の XUL のメリットってなんだろうかと思ってしまったり。

Opera

なんでか Opera の話もでて

• Opera の良いところは、首を傾げたくなるような謎な機能が最初からあるところ
• デスクトップ、携帯、ゲーム機等といったさまざまなデバイスで HTML をレンダリングするなど XHTML の原理主義に忠実といえば忠実

という話もでました。

私は SVG を確認したり弄ったりするときには Opera を使っています。Gecko は対応状況が悪いので動くかなというテスト程度にしか使っていません。 Inkscape で最初に作成して、テキストエディタで編集して、Opera で調整という流れです。UI の優位性とかほとんど知りません。普通のブラウザ程度の機能しか使っていませんので。

Windows 向けの Safari

という噂があるらしいです。Dashboard を Windows 向けに出すなら Windows への移植もあるかなと思いました。さっき知ったのですが Apollo が WebKit を使うということで WebKit 自体はそれなりの支援を受けて Windows に移植されることになるでしょう。

Thunderbird

日本では評価の高い、らしい Thunderbird について。

• (シェア獲得についてみれば) OE 以外の MUA は全部失敗。
• Thunderbird のアドレス帳はビジネスに向いている。
• 2 のリリース時期ははっきりしていない。
• U.S. では ウェブメールへの移行が進んでいる。
• Product から Project に降格?
  • 注力すべきところ(ブラウザ)に注力できなくて失敗するのは避けたい
  • Project に降格した方が逆に活発になるのではないか?
  • オープンソースなんだし誰か拾ってくるのでは?
• mozStorage に移行しないの? (参考 : Unified Storage)

拡張関連

tabbrowser の設計ダメダメじゃん。

二次会以降は参加しませんでした。

Bug-jp 5413 はFirefox の OpenSearch のエンコーディングの決定方法に難がある、という話。

OpenSearch 1.1 Draft 3 では InputEncoding 要素/テンプレートのデフォルトは "UTF-8" になっています。Firefox は InputEncoding 要素が出現しなかった場合デフォルトのエンコーディング(intl.charset.default の値) を使います。実は OpenSearch 1.1 Draft 3 では InputEncoding 要素が出現しなかった場合、どのエンコーディングを使うのかは書いていません。しかし、UTF-8 を使うのが妥当であると思います。

えむけいさんのコメントをそのままパッチにしてみたり。

diff -u -8 -p -r1.87 nsSearchService.js
--- browser/components/search/nsSearchService.js    18 Oct 2006 16:52:35 -0000  1.87
+++ browser/components/search/nsSearchService.js    28 Oct 2006 11:57:30 -0000
@@ -1489,16 +1489,17 @@ Engine.prototype = {
   },
 
   /**
    * Extract search engine information from the collected data to initialize
    * the engine object.
    */
   _parseAsOpenSearch: function SRCH_ENG_parseAsOS() {
     var doc = this._data;
+    this._queryCharset = "UTF-8"; 
     for (var i = 0; i < doc.childNodes.length; ++i) {
       var child = doc.childNodes[i];
       switch (child.localName) {
         case "ShortName":
           this._name = child.textContent;
           break;
         case "Description":

(Firefox のインストールフォルダ)/components/nsSearchService.js を直接書き換えても同様の効果を得られるようになりますが、変更は自己責任で。あるいは

get queryCharset() {
  if (this._queryCharset)
   return this._queryCharset;
  if (this._type == SEARCH_TYPE_OPENSEARCH)
   return "UTF-8";
  return this._queryCharset = queryCharsetFromCode(/* get the default */);
},

とかでしょうか。

「OpenSearch の仕様が将来変更されたら」等と考えると "UTF-8" ハードコーディングは不味いなあ等と、パッチを出した今さら考えていたりします。今日はもう寝ますが、明日定数に追い出すことにします。

関連

• あの不定記 IE7 の検索プロバイダ