さくっと作ってみた（DENY の例）。詳細は IEBlog の記事を参照[1]。要するに HTTP レスポンスヘッダか meta 要素を使って X-FRAME-OPTIONS を送出し、その値として DENY ないし SAMEORIGIN を指定する。
重要なのは、X-FRAME-OPTIONS を指定するのが frame/iframe 要素によって呼び出される側のコンテンツである、ということだ。つまり、この X-FRAME-OPTIONS が指定するのは、「自身が frame/iframe 要素によって他のコンテンツから参照されている場合、frame/iframe 要素へのロードを許可するか否か」なのだ。
次に IEBlog に書かれた仕様をまとめてみた（私が英語の解釈をミスっている可能性があるので注意）。
DENYframe/iframe 要素に含まれている場合、「無条件で」ページのレンダリングを防止する。
例えば http://example.com/sub.html に X-FRAME-OPTIONS が設定されている場合：
http://example.com/index.html が呼出 → 不許可http://evil.com/index.html が呼出 → 不許可SAMEORIGINframe/iframe 要素に含まれている場合、「呼び出し元が同一のトップレベル ブラウジング コンテキストでなければ」ページのレンダリングを防止する。
例えば http://example.com/sub.html に X-FRAME-OPTIONS が設定されている場合：
http://example.com/index.html が呼出 → 許可http://evil.com/index.html が呼出 → 不許可何千ページもあるような企業サイトなどで、Apache などの WWW サーバの設定を変更できる環境ならば、HTTP レスポンスヘッダとして X-FRAME-OPTIONS を送出する方法が効果的だろう。次のコード断片は、X-FRAME-OPTIONS を HTTP レスポンスヘッダに含めさせるようにする Apache の設定例である。mod_headers を有効にし、httpd.conf か、.htaccess に記述を行えばよいだろう（未テストにつき注意）。
DENY を設定する場合Header set X-FRAME-OPTIONS "DENY"
SAMEORIGIN を設定する場合Header set X-FRAME-OPTIONS "SAMEORIGIN"
meta 要素を使った方法も利用することができる。こちらは WWW サーバの設定を変更できなかったり、適用したい (X)HTML 文書が少なかったりする場合に効果的だろう。次の XHTML 断片は、X-FRAME-OPTIONS を meta 要素を用いて設定した例である。
DENY を設定する場合<meta http-equiv="X-FRAME-OPTIONS" content="DENY" />
SAMEORIGIN を設定する場合<meta http-equiv="X-FRAME-OPTIONS" content="SAMEORIGIN" />
但し、この X-FRAME-OPTIONS を用いる方法に対して「本当に効果があるのか」を疑問視する声もある。まずは肯定・否定両方の意見を参照し、十分な吟味と評価を行うべきだろう。
表題の通り、IE8 の RC1 がリリースされた。概要は IEBlog のリリース告知と RC1 の変更点に関する記事を参照のこと。リリース候補なので、一般ユーザのインストールは非推奨。
Beta 2 で発生した、IE8 Standard Mode で resize イベントが全く発生しない問題は Fix された。だが、どうにも IE7 とは挙動が違っているようだ。まだ調査中だが、どうやら全ノードの resize イベントが bubbling しているような気配。IE の resize には「resize イベント時にサイズ変更を伴う DOM 操作を行うと、処理が無限ループする」という潜在的な問題があるのだが、それが更に酷くなったような感じ。簡単なテストケースで IE6 や IE7 と違う挙動になることを再現できていないので、目下原因特定中（あるプログラムを作成中に、「複雑な」ケースで発生することは確認できた）。
あと、本サイトのメインナビゲーションを押下すると Opera 9.6 や Opera 10 と似た挙動をとる。:active 疑似クラスがうまく伝搬していないようで、アイテム全体が押下されず、一部の要素しか押し込み効果を得られていない。これは CSS 2.1 の仕様なのか、それともバグなのかハッキリしていないのだ。ただ、position:fixed の位置基準が包含要素になっていたバグは修正されている。
RC1 がリリースされた後、続々とバグ報告も上がっているようだ。まだ追いきれていないが、気になるものがあったらチェックしていきたい。
既に持っていたけれども、一応買っておいた。デザイナが同じなこともあり、テイストは『アンドロ羊』と同じ。因みにハーケンクロイツが描かれているのも日本ならでは。
どうせならカバーだけじゃなくて解説をもうひとつ追加するとか、そういう付加価値もつけてくれないかなぁ > 早川書房
面白いツールとして。FrameworkScanner は各種 JavaScript ライブラリが定義するグローバル変数と、ネイティブオブジェクトへのプロパティ追加をスキャンして一覧にしてくれるツール。更に嬉しいのは、スキャン後に左上で押下可能となる "Show collision matrix" ボタン。各ライブラリ同士の「衝突」を一覧表にしてくれる。ありがちな $ の衝突もそうだが、以外と知られていないような変数名の衝突までチェックできる。
改めて数字にされると「これはひどい」といえるライブラリを散見することができる。そのひとつが MooTools。65変数151プロパティ追加って！ JavaScript の名前空間をことごとく汚染する気かよと。最近では「影響がデカすぎる」として敬遠される傾向にある、ネイティブオブジェクトの prototype プロパティを通じた機能拡張も平気でやっていたりする。アレ、結構バグや不審挙動の原因になるから「やらない方がいい」のに。そんなに機能拡張したいなら、ネイティブオブジェクトを継承するオブジェクトを定義すればいいのに。勿論、仕様的な限界はあるが、ネイティブオブジェクトを直接いじることに比べれば何てことはない。
ちなみに FrameworkScanner 自体は Ext JS を利用している。ボタンまわりのマークアップが「ふざけんな！」っていう感じなのが残念だが、色々と事情があるのだろうか。
rem が mozilla-central ブランチでサポートされたらしいもずはっく日記経由。該当 Bugzilla は Bug 472195、パッチの詳細は changeset 23982、仕様は 3.4.2. Relative length units。
パッチが入ったのは mozilla-central ブランチ[1]なので、一般的な trunk とほぼ同義。Firefox 3.1 用のコードは mozilla-1.9.1 ブランチ[2]で管理されているので、Firefox 3.1 に入るかは不明（チェックインはされていない模様）。
新単位 rem は the font size of the root element
とあるように、ルート要素の font-size を意味する。仕様から引用してみよう。
The 'rem' unit ('root em') is relative to the computed value of the 'font-size' value of the root element. The exception is when 'rem' occurs in the value of the 'font-size' property of the root element itself, in which case it is relative to the 'medium' font-size. It may be used for vertical or horizontal measurement.
要するに em が継承された font-size プロパティ値の計算値を 1em とするのに対し、rem はルート要素（例えば XHTML なら html 要素）の font-size プロパティ値の計算値を 1rem とするようだ。次の XHTML 断片を例に考えてみる（尚、各計算値はデフォルトのフォントサイズが 16px だった場合を想定している）。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<title>タイトル</title>
</head>
<body>
<p>以降の数値は、デフォルトのフォントサイズが 16px だった場合の計算値。</p>
<div class="section1">
<p>12px</p>
<div class="section1">
<p>9px</p>
</div>
</div>
<div class="section2">
<p>12px</p>
<div class="section2">
<p>12px</p>
</div>
</div>
</body>
</html>
前述の XHTML 断片に、次の CSS 断片が適用されているとしよう。
.section1 { font-size : 0.75em; }
.section2 { font-size : 0.75rem; }
.section1 を入れ子にした場合、入れ子になった .section1 側が持つ子孫ノードでは 1em = 12px になる。よって再計算の結果は 0.75em = 9px になる。
対して .section2 を入れ子にした場合、入れ子になった .section2 が持つ子孫ノードでは 1rem = 16px になる。よって再計算の結果は 0.75rem = 12px になる。
これが使えるようになれば、入れ子になった場合の em を考えた指定を行う手間を省くことができるようになる。前述の XHTML 断片のような例では、よりスッキリとした CSS コードを書けるようになるわけだ。
また、ルート要素自身で rem を使用した場合は UA のデフォルト font-size プロパティ値を基準に計算を行うという。次の CSS 断片が与えられた場合を考えてみる。
html { font-size : 0.75rem; }
このとき計算値は 0.75rem = 12px になる。
ただ、1つ疑問がある。そもそもルート要素の font-size プロパティ値を変更した場合は、その影響を継承してしまうのだろうか？ 実際のところ、仕様には何も書かれていないので、どうやら継承するようだ。つまり、次の CSS 断片を前述した XHTML 断片に適用した場合を考えてみる。
html { font-size : 0.75rem; }
.section1 { font-size : 0.75em; }
.section2 { font-size : 0.75rem; }
このときルート要素の子孫ノードでは、1em = 12px という計算値が継承される。そして、もし前述した疑問が真ならば 1rem = 12px にもなっている。
よって、.section1 の場合は 9px と約 6px になる。
そして .section2 の場合は 9px と 9px になる。
要するにrem でも UA デフォルト値が利用されないことがありうる、ということだ。以後、これを暫定的に「rem 継承値問題」と命名して話を進める。
まあ、一般的に XHTML 文書全体の font-size プロパティ値を変更する際は body 要素の font-size プロパティ値を変更することが多いだろう。html 要素さえいじらなければ、前述した rem 継承値問題は発生しない。
つまり、次の CSS 断片のようにしておけば rem 継承値問題は発生しない、という具合。
body { font-size : 0.75rem; }
.section1 { font-size : 0.75em; }
.section2 { font-size : 0.75rem; }
この rem 継承値問題は想定されている……のだろうか。多分「されている」とは思う。だがきちんと理解していないと思わぬところでしっぺ返しを喰らうことになる。頭の片隅に入れておいた方が、後々のためには良いのかもしれない。
先日の記事に対する追記。jQuery 1.3 で追加された新機能のうち、あまり話題になっていない（と思ってる）もののひとつに "Live Events" がある。これは、通常のイベント設定に加えて「将来的に生成される要素」に対してもイベントを設定してしまえる機能だ。
基本的に、イベントは「既に生成されている要素」に対してのみ設定が可能になっている。W3C DOM Events の設計や、jQuery における bind メソッドの動作はまさにこれだ。
"Live Events" では、live メソッドを利用する。live メソッドは bind メソッドと同様に、指定要素に対してイベントをセットする。だがそれ以上の操作を1つ実行する。呼び出し元の jQuery オブジェクトが持つセレクタが示す要素全てに対し、もし将来的に該当する要素が増えた場合、その増えた要素に対してもイベントをセットするのである。つまり、要素が追加された時系列に関係なく、イベントがセットされるようになるのだ。
例えば、セレクタ #date-2009-01-18-test > button について考えよう。(X)HTML 上では次のようなマークアップになっているとする。
<p id="date-2009-01-18-test"> <button type="button">新要素生成（元要素）</button> </p>
次に、この button 要素に対し、JavaScript で click イベントをセットする。
click イベントには、「button 要素を挿入」する動作を割り当てよう。最終的なマークアップは次の状態になる[2]。
<p id="date-2009-01-18-test"> <button type="button">新要素生成（元要素）</button> <button type="button">追加された要素</button> </p>
つまり、次の順序で新規に生成された button 要素が挿入される。
button 要素に click イベントをセットclick イベントにより新規 button 要素を挿入bind の場合次のコード断片で強調した要素にしか、イベントはセットされない。
<p id="date-2009-01-18-test-1"> <button type="button">新要素生成（元要素）</button> <button type="button">追加された要素</button> </p>
次のコード断片は、bind メソッドを利用してイベントを設定している例である[1]。
$(window).load(function() {
var nodeNum = 0;
// 既に (X)HTML 文書上にある button 要素を取得
// button 要素にイベントを設定
$("#date-2009-01-18-test-1 > button").bind("click", function() {
// 新しい button 要素を生成 & (X)HTML 文書に追加
$(this).parent().append(
'<button type="button">何もしない ('+nodeNum+')</button>'
);
nodeNum++;
// 新しく生成された button 要素には何もイベントをセットしていない
// 新規生成した button 要素を click しても何も起こらない
});
});
次の段落にある button 要素で実際にテストしてみることができる。
実行例：
live の場合次のコード断片で強調した全ての要素にイベントがセットされる。
<p id="date-2009-01-18-test-2"> <button type="button">新要素生成（元要素）</button> <button type="button">追加された要素</button> </p>
$(window).load(function() {
var nodeNum = 0;
// 既に (X)HTML 文書上にある button 要素を取得
// button 要素にイベントを設定
$("#date-2009-01-18-test-2 > button").live("click", function() {
// 新しい button 要素を生成 & (X)HTML 文書に追加
$(this).parent().append(
'<button type="button">何もしない ('+nodeNum+')</button>'
);
nodeNum++;
// 新しく生成された button 要素には自動的にこの無名関数で設定
// されたイベントがセットされる
// 新規生成した button 要素を click すると
});
});
次の段落にある button 要素で実際にテストしてみることができる……が、どうやらバグがあるらしく、application/xhtml+xml で送出される XHTML 文書（XML モード）だと動作しない[3]。text/html で送出されている場合（HTML モード）だとうまくいく。
実行例：
いちいち生成された要素に対し、イベントをセットしなおす手間が省けるのはいいことだ。1回セットすれば何もしなくていいのだから。
だが心配の種がいくつかある。ひとつはパフォーマンスだ。公式発表では「はやいよー」と謳っているが……。Sizzle が実際のところかなりアレゲらしいという話もあるし、鵜呑みにはできんなぁ。
ふたつめは、前述したバグらしき動作だ。前述した通り、application/xhtml+xml で送出される XHTML 文書（XML モード）だと動作しなかった。text/html で送出されている場合（HTML モード）では動作したので、UA の XML モード/HTML モードまわりでトラブっている可能性がある[4]。1.3.1 での Fix を期待したい。
まあ便利なことに違いはないので、イロイロ試してみるつもり。
次のコード断片は、前述した bind メソッドの例を W3C DOM のみで書きなおした例である。
window.addEventListener("load", function() {
var parent = document.getElementById("date-2009-01-18-test-1");
// 既に (X)HTML 文書上にある button 要素を取得
var button = parent.getElementsByTagName("button");
var nbutton = button.length;
var nodeNum = 0;
for (var b = 0; b < nbutton; b++) {
// button 要素にイベントを設定
button[b].addEventListener("click", function() {
// 新しい button 要素を生成
var newButton = document.createElement("button");
newButton.setAttribute("type", "button");
newButton.appendChild(document.createTextNode("何もしない ("+nodeNum+")"));
nodeNum++;
// (X)HTML 文書に追加
parent.appendChild(newButton);
// 新しく生成された button 要素には何もイベントをセットしていない
// 新規生成した button 要素を click しても何も起こらない
}, false);
}
}, false);
$(window).load を使用したのは、後述する W3C DOM のみを利用した場合と完全に対応させるため。application/xhtml+xml をサポートしている UA には application/xhtml+xml を返している。サポートしていない UA には text/html を返している。nodeName プロパティの返す値が HTML モードでは常に大文字になる（例：BODY）のに対し、XML モードでは文書の記述に従う（例：body）。HTML 文書と XML 文書の仕様が異なることに起因する（HTML 4.01 文書は要素名の大小文字を区別しないが、XML 文書は区別する）。あのアイザック・アジモフ大先生のファウンデーションシリーズが映画化されるらしいという噂。これが本当なら大事件である。……ただ、情報ソースがないのでどうにも眉唾だなぁ。
もし映画化するならどこまでやるのだろう。『ファウンデーションの序曲』『ファウンデーションの誕生』は含めないかもしれない。初期3作品『ファウンデーション』『ファウンデーション対帝国』『第二ファウンデーション』までかもしれない。「うまくいった場合の3部作」に対応できる点も、ハリウッドの要望に即している。ただ1作が長い（連作短編形式）ので『ファウンデーション』だけで3部作、というのも考えられる。『ファウンデーションの彼方へ』『ファウンデーションと地球』もあるが、どうなるか。さすがにそれ以降の「ファウンデーションもの」[1]は入らないだろう。
個人的には日本でアニメ化……というのもいいなぁと思っていたりするのだが、果たして実写映画ではどういうものに仕上がるのだろう。
ついに JavaScript ライブラリ jQuery の 1.3.0 がリリースされた。jQuery の Blog に記事があがっている。一部では「思ったよりパフォーマンスと正確さがアレげ」といわれている Sizzle セレクタエンジンを搭載。
とりあえず速報。詳細はあとで追記予定。
ついにやったか Microsoft、と思ったが、どうもドキュメントを読むと ECMAScript 3.1 の最新ドラフトとは仕様が違うような……。まだ MS のドキュメントはちゃんと読んでないので明言はできないが、おおむね次のような差異があるっぽい。
getter, setterget, setMSDN に記載された具体例を引用してみる（強調筆者）。
Object.defineProperty(window, "prop",
{ getter: function() { return "Can get"; } } );
// ...
Object.defineProperty(window, "prop",
{ setter: function(x) { console.log("Can set " + x); } } );
// Now both getter and setter are defined for the property
ECMAScript 3.1 の最新ドラフト仕様だと、次のようになるはずだが……（強調筆者）。
Object.defineProperty(window, "prop",
{ get: function() { return "Can get"; } } );
// ...
Object.defineProperty(window, "prop",
{ set: function(x) { console.log("Can set " + x); } } );
// Now both getter and setter are defined for the property
「もしかして、ここも独自仕様にする気なのか？」と、個人的には気が気でない。ただ、プロパティアクセスは get/set だよ、という表もあるし、ただの誤記？ ……もう少し MSDN のドキュメントを読んでみる。
以下、参考文献。
特に仕様書の「15.2.3.6 Object.defineProperty ( O, P, Attributes )」と、Attributes を処理する「8.10.5 ToPropertyDescriptor ( Obj )」を参照。
ToPropertyDescripter のステップ7と8には If the result of calling the [[HasProperty]] method of Obj with argument "get" is true
、If the result of calling the [[HasProperty]] method of Obj with argument "set" is true
という文面がある（強調筆者）。getter, setter の記述はどこにもない。
Object.defineProperty のコードがある）有名なタイトルだ。そして、つい最近装丁が変更されたタイトルでもある。今日は書店に寄ったついでに新装版（53刷）を買ってしまった。前の装丁（42刷）のも持ってるのに。
ぶっちゃけた話、そんなものはどうでもいいから早く新訳出してくれと。絶版・版元品切れ目白押しのディック作品群なのだから……。とりあえず、未訳の長篇だけでも次の列挙分だけ存在するのだ。
早川でも創元でも他の出版社でもいいから、早く出してくれ……。最近ディック成分が足りないのだ！ それが大問題なのだ！
確かに、私のはじめてのディック作品は表題にもなった『アンドロ羊』であった。それからはカタログと睨めっこしながら、予算が許す限り書店に注文しまくったものだ。そのうちのいくつかは、既に版元品切れだった。「版元品切れ」という言葉を知ったのもこの頃だ。頻繁に大量の注文をするというので、書店員に「図書館の方ですか？」と尋ねられたのもいい思い出である。
創元も『最後から二番目の真実』を復刊させたきり音沙汰なし。我慢できなくて神保町まで出向いてサンリオ SF 版を買った後のことだったのをよく覚えている。両方読んだけど。
いかん……段々禁断症状が出てきた。仕方ないので『フロリクス8から来た友人』（創元 SF 文庫）でも読んで気を紛らわすとしよう。
アイザック・アジモフ大先生の『鋼鉄都市』『はだかの太陽』『夜明けのロボット 上・下』『ロボットと帝国 上・下』を一気読み。イライジャ・ベイリとR・ダニール・オリヴォーの絡みがアレげというのも、確かに描写が描写なので……。アジモフ先生、何も考えてなかったとは思うが。
そしてやはり『ロボットと帝国』のラストシーンは涙腺を刺激させられる。あんな結末になるなんて、ね。
因みに『夜明けのロボット』と『ロボットと帝国』に出てくるヴァジリア博士って、ぶっちゃけ最後までデレのないツンデレだと思うんだがどうよ。まあ、その相手が父親ってのがアレだが。しかもそのマインドは完全に少女のソレ。ウン百歳にもなって「リトル・ミス」[1]だもの。ジスカルドが哀れだ。
ロボット三原則は千葉大学のロボット憲章にも組み込まれていたりする。現実にも影響力を持ちはじめている。だが、未だスーザン・カルヴィンやドノバン、パウエル、アンドリュー、そしてジスカルドとダニールといった存在を用いてアジモフ先生が思考実験をされたような状況が発生するレベルに、まだ人工知能が至っていない。……いつになるんだろう。
resize で clientWidth と clientHeight が0になる表題の通り[1]。とりあえず簡単にテスト。本段落（p 要素）の clientWidth, clientHeight, offsetWidth, offsetHeight を window オブジェクトの resize イベント発生時に取得して、次のリストで表示させている。UA のウインドウサイズを変更すると値が変化する。
clientWidth: noneclientHeight: noneoffsetWidth: noneoffsetHeight: noneoffsetWidth と offsetHeight も駄目だった。……これでは全く使いものにならない。因みに、IE7 でも同様の挙動を示すが、offsetWidth と offsetHeight はとれていた。
IE8 では相変わらず getComputedStyle が利用できないので（いい加減にしろ！）、純粋に CSS の width と height プロパティの計算値を取得するには clientWidth と clientHeight からそれぞれ padding プロパティの上下左右値を減算してやることで計算するしかない。だが値がまともにとれないとなると、その手法も使えなくなり、要するにお手上げになってしまう。
また、offsetWidth と offsetHeight も使えないとなると、border まで含めた減算を行う手法すら使えなくなる。
完全にバグだ。なのでどうにかしてもらわねばならない。ただ、以前に dt 要素と dd 要素でテストした時は IE8 でも offsetWidth と offsetHeight はとれていたような……。要素によって違いがあるのかしらん？ もう少し調べてみよう。
という噂。まだ噂レベルなので信憑性は何もないのがポイント。ネタ元はとあるはてなダイアリー。ここも2次情報を参照しているので微妙すぎ。確固たる証拠が何もない。
再始動がもし本当ならば実に嬉しい限りなのだが……また頓挫してしまったらどうするのかしらん？ 以前にアニメ化企画がスタートして、最終的にあぼーんした時は、『S-F マガジン』にお詫び文まで掲載された。紙面の隅だったけれども。2年くらい前だったろうか？ よく覚えていない。
期待しないで待ってみよう。
絶賛試聴中。『愛おぼ』は TV シリーズ全36話を観終えてからと決めている今日この頃。今8話まで。これから続き。
そういえば、今日はようやっと『S-F マガジン 2009年2月号』を買った。久しぶりに登場のパオロ・バチガルピによる短編が入っている上に、雪風の最新回と森奈津子の新作、伊藤計劃のインタビュー。個人的には万々歳。表紙は全面『ハーモニー』の対比になってるし。実にイイ。バチガルピの短編集、出ないかしらん。
次の雪風は4月号か……。執筆ペースが向上しているようで実に嬉しい限り。ますますワケがワカラン存在であることが明かされていくジャムとの闘いはどうなっていくのか。
カウンタをとっぱらったり、Copyright を書き換えたり。一年の始まりはまずコレから。
もうめんどくさいから、デザインをめちゃくちゃ単純なのにしちゃおうかなぁ……。CSS 書くのも楽だし。うん。そうしよう。
特に言うこともなく……。喪中なので挨拶はできないし。
ただ、ようやくゼロ年代最後の年なんだな、と思うと感慨もわいたりわかなかったり。
それより、相変わらず最悪な腹の調子をどうにかしてほしい。