Latest topics 近況報告

Firefox 3.5 on Mac OS Xのタイトルバーまわりの新機能 - Mar 24, 2009

以前、Mac OS X上でタイトルバーとツールバーがくっついた様な見た目を実現するためにFirefox 3から導入されたactivetitlebarcolor属性とinactivetitlebarcolor属性について調べたけど、このあたりの仕組みがFirefox 3.5ではまた変わった。Firefox本体に同梱されるテーマでは上記の仕組みは使われなくなって、代わりに-moz-appearanceプロパティの-moz-mac-unified-toolbarという値が指定されている。

• -moz-appearance: -moz-mac-unified-toolbarと指定されたtoolbar要素は、外観が自動的にUnified Toolbarになる。
• と同時に、そのtoolbar要素が含まれているウィンドウのタイトルバーも自動的にUnified Toolbarスタイルになる。
• Unified Toolbarスタイルになったタイトルバーの色は、ウィンドウがアクティブな時は-moz-mac-chrome-active、ウィンドウがアクティブでない時は-moz-mac-chrome-inactiveになる。
• 一旦Unified Toolbarスタイルが適用されたウィンドウは、後から当該toolbar要素に-moz-appearance: none等を指定してUnified Toolbarでなくした後も、タイトルバーはUnified Toolbarスタイルのままになる。

最後の項の挙動はひょっとしたら今後変わるかもしれない。スタイル指定の意味合い的には、Unified Toolbarが存在しなくなったらタイトルバーの表示も元に戻すべきだろうし。とりあえず2009年3月24日時点のビルドではこうだった、ということで。

ちなみに、activetitlebarcolor属性とinactivetitlebarcolor属性は、今の所はFirefox 3.5でもまだ使えるみたい。

本気でやるならprototype.jsやjQueryやYUIは避けてonclickを使うべき - May 18, 2008

タイトルは釣り。

• 本気でやるならonclick属性は避けてライブラリを活用すべき - id:HolyGrailとid:HoryGrailの区別がつかない日記
• 本気でやるならクロスプラットフォームは避けてMozillaアプリを作るべき - hogehoge
• onclick 属性問題について - IT戦記

僕自身はなんだかんだで仕様原理主義者な所が今も強いわけで、その考えに則れば、onclick等のイベントハンドラは一応W3Cの仕様に含まれてるから（HTML4、XHTML 1.0、XHTML 1.1）OKだけど、ライブラリは業界団体の作る標準仕様になってないからNG、と言える。というのはまあ半分冗談だし、そもそもHolyGrailさんの指摘とは次元が違う話なのですが。

しかしこの考えも、権威主義だけじゃなくて、実利的に考えて「そうあるべき」と僕は割と真面目に思っていたりもする。

1. いつでも詳細な取り決めを確認できて、不安無く使える。
2. 特定のベンダの意向や、世間の流行り廃りに振り回されずに、安心して使える。
3. 学んだことが無駄にならず、他の場面でも使える。

この三つの点について、満たしている物が多ければ多いほど、満たしているレベルが高ければ高いほど、それは良い物で学ぶ意義も大きいと僕は思う。

今でこそ僕はFirefox一辺倒だけど、これも「1」と「3」がそれなりに満たされているからという所が大きい。仕様は無いにしても実装がソースコードレベルで公開されているから、必要とあらば「こういう時にどうなるのか」をどこまでも追いかけられる。また、少なくともWindowsとMacとLinuxというマルチプラットフォームで使えて、どれか一つの環境で作り込んでおけば、他の環境でもそのまま使える（最悪でも、それほど大きな労力を掛けずにポーティングできる）。

そして上記三条件それぞれを最も突き詰めた物が、オープンスタンダードであり、デジュールスタンダードであり、デファクトスタンダードだ。

一昔前までは、ことWebについてはデファクトスタンダードとデジュールスタンダードが激しく乖離しているのが当たり前で、GeckoくらいしかまともにW3Cの仕様を実装している物が無い頃には「W3Cの仕様はWeb標準だからこれに則ってればいいことあるよ」と言っても「でもそれって夢物語じゃん」と返されるのが世の風潮だったと思う。でも今は時代が変わった。OperaもSafariも高いレベルでWeb標準に対応してきたし、IEも少しずつだけどWeb標準に合わせてきてる。今だったらはっきりとこう言える。「Web標準の技術を使っていれば、FirefoxでもOperaでもSafariでも動作するし、AirでもGoogleガジェットでもFirefoxの拡張機能でも使えるし、いいことだらけだよ」と。

不遇の時代を乗り越えて、「Web標準」は今、上記三つの条件を兼ね備えた物にようやくなりつつある。W3CやWHATWGやISOやECMAに仕様があって、仕様が公開されていて、しかもそれをほとんどのベンダがサポートしている。これって凄い事だと思わんかねぇ？（誰ともなく）

ウィンドウ全体を覆い隠してゴニョゴニョするのは実は簡単だった - Apr 28, 2008

Firefox 2まででは、position:fixedな要素はz-indexを適切に指定すれば内容領域の上にも普通に表示できた。なので、ウィンドウ全体を覆い尽くすというのも簡単だった。

でもFirefox 3では仕様が変わって、常にサブフレームの内容が上に表示されるようになったため、CSSのポジショニングだけでは任意の要素を任意の位置に表示することはできなくなってしまった。仮にposition:fixed; top:0; left:0なボックスを置いても、その上にブラウズ領域の中身が表示されてしまう。ウィンドウの内容の上に何かを重ねて表示したい時には汎用のポップアップであるpanel要素を使え、というのがFirefox 3流のやり方らしい。

しかし古い拡張機能をアップデートするにあたってそこらへんのつくりを全面的に書き換えるのは大変な労力を要するし、果てしないregressionの嵐が発生しかねない。できれば最小限の労力で、今までのやり方に一工夫加えるだけで正常に動作するようにしたい。

ということでウィンドウ全体を覆い隠してゴニョゴニョするアレの時に試行錯誤して、CSSのポジショニングをどーしても使いたければサブフレームを新たに生成するしかないっぽいという結論に辿り着いていただけれども、その方法をタブカタログで使おうとしたところDOMDocumentの違いとかで死にそうになったので、諦めて別の方法をいくつか探ってみた。

で、結論としては、visibility:hiddenになったサブフレームの上なら、普通にCSSのポジショニングで要素を重ねられるようです。display:noneとかvisibility:collapseとかをサブフレームに使うとDocument Shell（nsIDocShellのオブジェクト）がぶっ壊れてしまってまともに動かなくなるので、この辺のプロパティをいじるのはヤバイと思って今まで全く触ってなかったんだけど、少なくともFirefox 3ではFirefox 2でもFirefox 3でも、visibility:hidden/visibleの切り替えではDocument Shellは破壊されないようだということに、ああでもないこうでもないといじってるうちにたまたま気がついたのですよ。

でもこれだとタブカタログのように、一旦全面を覆い尽くしてその上に全然別のコンテンツを表示するといった機能は作れるけど、InterNoteのようにページ上に任意の要素を置くっていうことはできそうにない。そういう場合はページ内のDOMDocumentを編集するしかないようだ。

XHTMLルビサポートで文字の均等割り付けに対応したよ - Mar 13, 2008

XHTML Ruby Supportで、ルビベースよりルビテキストが短い時や、ルビテキストよりルビベースが短い時などに、均等割り付けを行うようにしました。 このスクリーンショットはW3Cのテストケースの物ですが、下のルビの「言語」が今までなら中央寄せになっていたところ、ちゃんとルビベースに合わせて字間が広がってます。すぐ上にある「こうあるべき」という表示結果の例と比べても遜色ないことが分かってもらえるかと思います。このテストケースは複雑ルビも使っているので、ルビ実装の本家本元のIEでも表示できないですよ（多分）。

てか、W3Cのテストケースのテスト結果のページ見たら、このアドオンを使った場合の結果が妙に優秀でワロタ（テスト自体は昨年9月の物のようで、注釈で文字の均等割り付けに非対応であると指摘されてる）。

「均等割り付けなんてtext-align:justifyでやりゃいいじゃん、何を今更……」と思う人もいるかもですが、text-justifyのような均等割り付けのアルゴリズム変更の手段がないGeckoでは、段落の最終行は常に左寄せになってしまうので、こういう場面では使えないんですよ。なので、今回は自前で地道に字間を計算して調整してます。計算の仕方は、ずっと昔に中野さんがブログで書いてた本物のtext-align:justifyの実装の解説を参考にしてるつもりです。詳しく知りたい人はjustifyTextメソッドのコードを見てください。

@JOJOとかも、これで心おきなく楽しめます。

あー、しかし北村さんがCSSでルビを擬似的に表示する方法を発表されてから、もう7年も経つのか……その頃生まれた子が今じゃ小学生ですよ？　僕は相変わらず独りでこんな事ばっかやってるというのにねぇ。

Thunderbirdでスレッド表示のインデント幅を小さくする - Feb 28, 2008

Thunderbirdで受信メールをスレッド表示してると、スレッドのネストが深くなりすぎて後の方のメールが見えない状況になってきてしまったので、インデント幅を小さくした。以下の内容をThunderbirdのプロファイルフォルダ内のchromeフォルダ（無ければ新規作成）の中のuserChrome.css（これも無ければ新規作成）に以下の内容を書く。

@-moz-document url(chrome://messenger/content/messenger.xul) {
  treechildren::-moz-tree-indentation {
    width: 9px !important;
  }
  treechildren::-moz-tree-twisty {
    padding-right: 0px !important;
  }
  treechildren::-moz-tree-cell-text(colNodeName) {
    margin-left: 1px !important;
  }
}

DOM Inspectorのインデント幅を減らすやつそのまんまですな。

ちなみに上記のままだとフォルダペインのインデント幅も小さくなってしまいます（僕はその方が都合がいい）が、スレッドペインだけに反映させたい場合はtreechildrenという箇所を#threadTree treechildrenとかなんとか書き換えてください。

XULのtoolbarbuttonとCSSのopacityとpositionで嵌った - Oct 12, 2007

昨日XULとCSSであれこれ頑張ってみていて浮き彫りになってきた、XULとCSSのバッドノウハウの話の続き。

前のエントリで書いたことを踏まえて、toolbarbuttonの中のlabelを、XBLとstackを使って影付きテキストに置換するということをやってみたんだけど、そうすると今度は、ボタンを押しても何も反応しなくなってしまったじゃあないですか。こりゃ大変だ。

よーく観察してみると、ボタンのラベル文字列の部分はクリックしても無反応（ボタンの外観はちゃんと「押した」風になるんだけど、commandイベントが発行されない。コードを色々書き換えてみたけど、clickイベントすら発行されなかった。）だけど、それ以外の部分――ボタンの枠線とラベル文字列の間の余白部分あたりをクリックすると、ちゃんとボタンを押したものと認識される、ということに気がついた。ということはやっぱり、stackを使って影付きテキストにしたlabel要素が癌だってことだ。

んで条件を変えつつ色々試してみたら、以下のことが分かった。

• 半透明にしたlabel要素をクリックしても、親のボタンをクリックしたとは見なされない。
• 半透明じゃなくても、positionがstatic以外になっているlabel要素は、クリックしても、親のボタンをクリックしたとは見なされない。

言い換えると、「完全に不透明で、且つ、positionがstaticであるlabel要素」をクリックした時にだけ、そのtoolbarbuttonがクリックされたものとして正しく認識されるようだ、ということ。

というわけで苦肉の策として、ボタン上にポインタが乗っている時（:hover状態）はpositionもopacityも初期値（staticで不透明）にする、という風にしてみたところ、やっとちゃんとボタンをクリックできるようになってくれた。positionがstaticということはz-indexでの重ね合わせ順の制御が効かなくなるんだけど、影の方のopacityが1になればstackの原則通り内容は文書中の登場順に描画されるようになるので、トータルでは問題なくなる。:hoverの時だけ影が濃くなる（不透明になる）のは、まぁ、:hover時の特別なハイライト表示にも見えるので、結果オーライと言えよう。

ちなみに、この問題はtoolbarbutton要素だけでなく、menubar要素直下のmenu要素内にあるlabelについても起こる。こちらについても同じような対策で行けるかと思って、事実ほとんどの所はそれで良かったんだけど、:hoverの時だけということにしておくと、展開されたメニューを選択した後に再びmenuの部分にポインタを載せた時に、positionとopacityのリセット用指定が反映されないという現象が起こってしまったので、代わりに[_moz-menuactive="true"]という具合に内部処理用の属性を使ってみることにした。

そんな感じで、現行Geckoにはこういういやーなバグがまだまだ潜んでいて、案外苦労してしまうことが少なくない。そこら辺が改善された新しいバージョンっていつ出るのかなあ……

XULのstackとCSSのopacityで嵌った - Oct 12, 2007

昨日XULとCSSであれこれ頑張ってみていて浮き彫りになってきた、XULとCSSのバッドノウハウいくつか。

1. XULのstackとCSSのopacityの微妙な関係について
2. XULのtoolbarbuttonとCSSのopacityとpositionの微妙な関係について

まず一つ目。一般的なWebページ制作では、要素同士を重ね合わせるにはCSSのポジショニングを使うのが一般的で、XULでも同じ方法を使えるんだけど、もう一つの方法として、XULにはstackという要素がある。

通常、XULではhbox（内容が横に並ぶボックス）またはvbox（内容が縦に並ぶボックス）の2つのボックスをコンテナとして使い、縦横二方向のボックスの並びだけでGUIを作る、というのが原則となっている。この原則を覆すのがstackというコンテナ要素だ。多くのXULのコンテナ要素においては、内容に含めた要素のボックスが縦または横に並ぶのに対し、stackは、内容に含めた要素のボックスが同じ座標に重ねて表示される、という特徴がある。

チュートリアルではこれを使って影付き文字を作る例を示しているけれども、これを見て当然思いつくのが、影を半透明にして背景に自然に馴染ませたいという要求だろう。

<stack>
  <description value="Shadowed"
               style="color: black; opacity: 0.5;"
               top="1" left="1"/>
  <description value="Shadowed"
               style="color: white;"/>
</stack>

ところが、この例は実際には意図通りに表示されてくれない。Geckoのバグだと思うけど、stackの中に一つでも半透明の要素があると、stack全体が半透明になってしまうのである。つまり、ここでは影だけを半透明にしたいのに、実際には前景の文字まで半透明になってしまって却って字が読みにくくなる。

で、色々試してみた結果、stackを二重にするとこの問題を回避できるっぽい、という事が分かった。

<stack>
  <stack>
    <description value="Shadowed"
                 style="color: black; opacity: 0.5;"
                 top="1" left="1"/>
  </stack>
  <description value="Shadowed"
               style="color: white;"/>
</stack>

こうすると、内側のstackは全体が半透明になってしまうけど、外側のstackにはその影響は及ばないので、影だけを半透明にできる。（ここでは影のテキストが一つだけしかないけど、実際にはText Shadowと同様の方法で複数の薄い影をずらしながら重ねたかったということなので、stackを二重にしている。）

ただ、今度は入れ替わりに、要素の重ね合わせの順番がおかしくなるという問題が起こってしまった。XULのstackは先に入っている要素ほど下に、後に入っている要素ほど上に描画されるはずなんだけど、どういうわけか、半透明にした要素は不透明の要素よりも上に強制的に描画されてしまうようだ。

（……と思ってたんだけどもしかしたらこれは勘違いかもしれない。stack内の要素はtop属性とleft属性で場所を動かせるんだけど、もしかしたら、これらの属性がある場合は強制的にその要素がposition: relativeにされてしまって、通常のposition: staticな要素の上に表示されるようになってしまった、ということだけなのかも……これはまだ検証してない。）

そこでさらに、z-indexを使って重ね合わせの順番を指定してみたところ、やっと「半透明の影の上に不透明の文字を重ねる」という結果を得ることができた。

<stack>
  <stack style="position: relative; z-index: 1;">
    <description value="Shadowed"
                 style="color: black; opacity: 0.5;"
                 top="1" left="1"/>
  </stack>
  <description value="Shadowed"
               style="color: white; position: relative; z-index: 2;"/>
</stack>

position: relative を指定しておかないとz-indexの指定が効かない(z-indexはpositionがstatic以外の要素にしか効果がない）ので、それもセットで指定してある。

これでやっと問題を解決できたか、と思ってたんだけど、あろう事か今度はまたさらに別の問題にぶち当たってしまった。というところで、話は次のエントリへ続きます。

CSS3セレクタとXPathでの表現の対応表 - Sep 13, 2007

拡張機能勉強会の時に焚き付けられた、Text Shadowのコード（textshadow.js）を教材にして拡張機能開発のノウハウを解説していくシリーズ。

XPathをノードの検索に活用する方法を紹介したけど、肝心のXPathが書けなきゃ意味がないわけで。でもXPathって、ノードセットがどうとかノードテストがどうとか軸がどうとか修飾がどうとか、いざ勉強しようとしてもこれ専用の用語がやたらたくさん登場してきてものすごく萎える。CSSのセレクタの方が、機能は限られてるけどまだ分かりやすい。CSSのセレクタとXPath式の対応表があればいいのになあ、ということを、だいぶ前から僕は思ってた。

実は何年か前、哀さんのサイト（Black Box）でそういうコンテンツがあったんだけど、移転のゴタゴタか何かで消滅したままになってる。しかも、今「CSS XPath」みたいなキーワードでGoogleで検索してみて上位にくるエントリは、情報が不十分だったり間違いが含まれてたりする。

というわけで、CSS3セレクタ（このエントリを書いた時点ではワーキングドラフト）とXPath式の対応表で、詳細な物を作ってみた。

続きを表示する ...

第6回拡張機能勉強会 - Sep 03, 2007

目が覚めたら14時でした。

勉強会本体の感想。

Firemacs作者の山本さんの話を聞いてると、以前の自分を思い出した。XPCOMにどんな機能があるのか知らなかった頃に、知ってる範囲の知識でどうにかして解決しようとあれこれ工夫を試みていた。そういう「工夫」を思い付くかどうか、というのが、もしかしたらある種の「分れ道」なのかもしれないなと思った。

marさんによるXUL preLoaderの話。

• XULオーバーレイでボタンを追加したいのに、その要素にidが指定されていない、という場合、JavaScriptとDOMを使ってXUL要素を生成して埋め込むという方法をとらざるを得ない。
• オーバーレイで読み込むXUL文書を間に一つ増やして、その「間に挟まれた」XUL文書においてid属性をスクリプトで設定してオーバーレイを適用できるようにしてから、改めて、本来オーバーレイで読み込ませたかったXUL文書をdocument.loadOverlay()で動的に読み込む。……というのが、preLoaderの発想。

preLoaderのような発想が僕に無かったのは、loadOverlayというメソッドを知らなかった・存在を忘れてたからというのも大きいんだけど、それ以前に、他の拡張機能で同じ方法を使われて異なるIDを指定されてしまったらこのテクニックは破綻してしまう、ということに気づいていたからだ。僕は以前から、拡張機能を作るときは他の拡張機能となるべく衝突しないようにということに気を付けるようにしている（TBEの時はそれで散々叩かれたし）ので、preLoaderのテクニックはあまり推奨しづらい。

ところで、今ふと思ったんだけど。E4X使ったらJavaScriptの中に普通にXUL文書片を書けるから、preLoaderあんまりいらなくね？（ぉ

誕生日を祝ってもらえて、フォクすけは幸せ者ですね。僕もこれくらい愛されてみたいです。どうでもいいですが、ケーキの周りのフィルムについたクリームを舐め取っている様子をばっちり撮られてしまっていました。

Mozilla 24のための各プログラムの番宣ビデオ？の撮影があって、Shibuya.jsのビデオに僕まで出ることになってしまった、というかほとんど僕が喋ってた。幽霊部員なのに。あとで映像見てみても、ほんとキモイなーと思った。また叩かれるんだろうなあ。いやだなあ。

続きを表示する ...

ダイナミック疑似クラスに対応したよ（暫定） - Aug 07, 2007

テキストシャドウを:hover, :focus, :activeのダイナミック疑似クラスに対応させた……つもり。でも試してみたら:focusは意図通り動いてくれない。何でだろう。