こんにちは、martinです。掲示板の方で、MHT形式のファイルからログが復元できないだろうかと要望があり、これは出来るべきであろうと思いますので、とりあえず作ってみました。MHT形式からのログ復元は、原理的に100%というわけには行きませんが、なるべく元のログを再現するようにしたつもりです。

　MHTファイルを作成したブログで作動させるのが原則です。使い方は、

1. index.phpがあるディレクトリにこのファイルをアップします。
2. 次に、同じディレクトリにmhtディレクトリを作成(FTPソフトで)、パーミッションを707にします
3. index.phpかadmin.phpでログインした状態で、このmht2log.phpにアクセスします

　すると、ファイルアップロードの画面になるので、ここで手元にあるMHT形式のファイル(もちろんppBlogが作成したものです)を指定して「変換」ボタンを押せば、作成したmhtディレクトリにアップした月のログが作成されます。例えば、200805.mhtであれば、200805.logというログファイルが作成されます。これは、そのままppBlogのlogディレクトリに流し込むことが可能です。

　出力されるログの文字エンコードは、UTF-8かEUC-JPか選べます。入力元のMHTファイルのエンコードはUTF-8でもEUC-JPでもどちらでも構いません。

　そう使う機会はないかもしれませんが(出来れば皆無がベスト)、何かの拍子にログが壊れてしまったけどMHT形式のバックアップログがある場合などに有効かと思います。バージョン1.6.4が生成するMHTファイルを参考に作ったので、古いバージョンで作成されたMHTファイルではうまく動かないかもしれませんが、その時はお知らせ下さい。

添付ファイル： mht2log.php 

　こんにちは。３つです。

　ひとつは、jsディレクトリのphotoeffect.jsですが、たまにFirefoxでJSエラーが出るようなので、try..catchで逃げました。どのタイミングで発生するのか実はよく掴めていないんですが、少なくともローカルのテスト環境で再現性のあるエラーが出ていたのでそれを回避するようにしてます。

　2つめは、画像アップロードに際して、動的にメモリ割り当て量を増やす処理を入れているのですが、見積もった必要メモリサイズがサーバーの初期値よりも小さい時に、わざわざ小さい値に設定してしまうのを避ける処理を入れました。個人のブログ の方で写真をアップしていて、この現象に気付きました。この修正でutils_admin.php。

　後は、モブログの設定でちょっと弄った箇所があるのですが、中途半端でした。これはmodulesディレクトリのmoblog.inc.phpです。

　あ、あと、前回のアップデート記事で書き忘れたことがあったので追記です。テーマ関連の修正ですが、テンプレートのtemplate.phpにある記事ボックスのひな形の部分ですが、従来のバージョンでは、カテゴリー部分の指定がちょっと入り組んでいたので、この部分はシンプルに

<p class="article-category">%_ARTCL_CATEGORY_%</p>

のようにしています。

添付ファイル： photoeffect.js  utils_admin.php  moblog.inc.php 

　こんばんは。とりあえず自動インストール版を昨日リリースしました。が、今日ちょっと弄っていてutils.phpのurl_encode関数辺りを変更したので、その差分を添付しておきます。また、テーマ管理画面で「テンプレート」←→「スタイルシート」の切り替えリンクが適切に作動してしなかったので修正しました（theme.inc.php）。あと見栄えの修正でpages.inc.php。以上の３つを添付しておきます。

　先月の4月23日に差分ファイルを出しましたが、それから至る所を弄りました。昨日のリリース版では、JSスクリプトはoParts.js, lib.js, photoeffect.js, syntax.js, comment.jsは軒並み手が入ってます。modulesも色々変更を加えているので、1.7.3ベータ版をお使いの方は、現行リリース版(080511)をダウンロードされて、jsディレクトリとmodulesディレクトリの中身は一括して上書きするのが楽だと思います。utils.phpなどのトップディレクトリのファイル群については、これも一括して上書きして下さい。変わっていないＰＨＰファイルもありますが、アップデート漏れを避けるにも、とりあえず上書きというのが良いかと。ログやらownerディレクトリ、cssディレクトリ、statディレクトリの中身は特に何も変更することはないです。

　テーマ関連で変更があります。Ajaxを利用してコメントなどを読み込んで表示させるボタンですが、これらのボタンにはcute-buttonというクラス名を与えました。utils.phpが出力する、このボタンのHTMLは以下のようになります。

<div class="cute-button" onclick="loadComments(1209722736);">
 <button title="ここでコメント・トラックバックを展開します">12件のレスポンス [+]</button>
</div>

　これに対するテーマBasicでのCSS指定は以下のような感じです。

.cute-button {
  background: url(Images/button-bg-left.png) no-repeat 0 0;
  height: 24px;
  margin: 3em auto 2.5em 1em; /* 好きな値を。本文とのマージン */
  padding: 0 0 0 12px;                 /* ボタンの左パディングに相当します */
  display: inline-block;
  display: -moz-inline-box; /* for Firefox2.x */
  zoom: 1; *display: inline; /* for IE */
}
.cute-reply { margin: 1em auto 4em 4em; } /* 「コメントする」ボタンへの対応 */
.cute-button button {
  background: url(Images/button-bg-right.png) no-repeat 100% 0;
  height: 24px; line-height: 24px;
  cursor: pointer;
  display: block;
  padding: 0 12px 0 0;           /* ボタンの右パディング。上記の左パディングと同じ値。 */
  margin: 0;
  border: none;
  overflow: visible;                 /* IEのために必要 */
  font: 500 13px Trebuchet MS, Tahoma, 'ヒラギノ丸ゴ Pro W4', 'メイリオ', Arial, sans-serif;
}
* html .cute-button { overflow-y: hidden; width: 1%;} /* for IE6... */
* html .cute-button button { width: 1%;}   /* for IE6... */
.cute-button:hover {
  background-position: 0 50%;
}
.cute-button button:hover {
  background-position: 100% 50%;
}
.cute-button:active {
  background-position: 0 100%;
}
.cute-button:active button {
  background-position: 100% 100%;
}
.cute-button button[disabled] { 
  color: #aaa;
}
.cute-button button:focus::-moz-focus-inner { 
  border-color: transparent !important;  /* Firefoxでのドットフォーカスを避けるため */
}

　上記以外に、配布しているベーシックテーマのCSSには、一応IE6向けに、モダンなブラウザに似せたボタンアクションにするための記述も書いてますので参考に。とりあえずコメントアウトしていますが。

　結果として、それまでのこのAjaxボタン関係で使用していた.button-ownerとか.comment-expandとか.commentFormHereは不要になります。

　あと、1.6以下のバージョンと現行バージョンでは、カテゴリー定義ファイルとページリストの定義ファイルの形式が異なっているので、これを現行のものに対応させるための変換ページを用意しました。トップページのメニューバーの「Tools」にあります。

　1.6系からのバージョンアップに関しては、新規に最新バージョンをアップロードして、そこに既存のログなどを流し込むやり方をオススメします。既存のカテゴリー定義ファイルとページリスト定義ファイルは上記ページで変換した後にアップして下さい。

添付ファイル： DIFF080511.zip 

　以前に、window.onloadの代替スクリプト^Gの記事を書いていたんですが、今はちょっと違ったスクリプトになっているので、この辺で、まとめもかねてメモを。

　今ではどのJavaScrptライブラリーも、画像も含めたページ読み込み完了まで待って、つまりwindow.onloadのタイミングで初期化関数を走らせるなんてことはせずに、もっと早い段階、つまりブラウザがDOMの構造を把握してパースしたタイミングを見計らって、初期化関数を実行するようにしています。Firefox、Operaでは、ブラウザ側がDOMContentLoadedというイベントハンドラを用意してくれているので、これを使います。Safariがこれを採用するのも時間の問題だろな、と前々から思っていたんですが、昨日、Safari最新版(3.1.1)も対応しているっぽいことに気が付きました。こういうスクリプト を書いて、イベントの発火順序を調べていたんですが、何気にSafariで動いているんでちょっとビックリしました。

　イベントの発火順序を調べる→http://p2b.jp/demo/events-order.php

　IEに関しては、DOMContentLoadedというイベントハンドラはないので、以前から色々なアプローチが取られてましたが、今ではbase2 のDean Edwardsも、jquery のJohn ResigもDiego Periniが見つけたdoScroll を採用しています。確かに、これでも良いのですが、自分は天の邪鬼なので、HTCファイルでondocumentreadyを監視するというアプローチにしています。上に挙げたイベントの発火順序を調べるページの結果を見ると、IEに関しては、次のようなイベント順位で実行されてます。

1. oncontentready　　　　　/* この時点でDOMのパースが終了 */
2. deferred script　　　　　　/* defer指定された外部スクリプトが実行される */
3. ondocumentready　　　　/* 次にHTCでのこのイベント。oParts.jsではこの時点で初期化。*/
4. doScroll　　　　　　　　　/* 次にdoScroll */
5. window.onload　　　　　/* 最後にこれ */

　このサイトのように、ソースをハイライト表示するスクリプトなどを使ってる場合は、数ミリ秒でも早くハイライト関数を起動させたいので、ondocumentreadyのタイミングで実行させてます。doScrollのタイミングでも良いんですが、十数ミリ秒程度遅れるんですよねぇ。oncontentreadyが一番早いですが、極々まれにこれが評価されないことがあるので、確実なondocumentreadyにしてます。ondocumentreadyとかoncontentreadyってBehavior絡みでしか使えないのが玉に瑕です。普通のイベントハンドラとして使えるようにしてくれれば良いのに、マイクロソフトさん。

　というわけで、ppBlogで使っているJSライブラリ oParts.js での初期化関数は以下のような感じになってます。

oParts.start = function(F){
  if(client.Gecko || client.Opera || client.Safari){
   document.addEventListener('DOMContentLoaded', F, false);
  } else if(client.MSIE){
   $IEHTC = document.documentElement.addBehavior('js/ie.htc');
  } else o(window).on('load', F);
};

　SafariでもDOMContentLoadedが使えるようになったので記述が少なくて良いですね。IE向けのie.htcファイルの中身は以下のような感じ。

<public:attach
  event="ondocumentready"
  onevent="oParts.callee[oParts.callee.length-1]();
           document.documentElement.removeBehavior($IEHTC);
           $IEHTC=null;" />

　ちなみにイベント発火順位を調べるスクリプトですが、以下のように指定すると、このサイト以外のページも読み込めます。Yahoo!の例を挙げておきます。

http://p2b.jp/demo/events-order.php?site=yahoo.co.jp

　余談ですが、jquery-1.2.3のテストをしていて、気になった点がありました。以下のようなスクリプトを書くと、$()関数がwindow.onloadの後にしか実行されません(IE7の場合)。jqueryに関しては素人なので使い方が間違っているのかもしれませんが、非常に簡単な例なので気になります。

<script type="text/javascript">
  window.onload = function(){
   document.getElementById("test").innerHTML = '<p>window onloaded!</p>';
  }
  $(function(){
   alert($("#test").html());
  });
</script>

　実際の実行サンプル 。FirefoxとIE7で挙動が違います。Firefoxでは意図したように、window.onloadよりも先に$()が評価され、<p>original</p>とアラート表示されますが、IE7ではなぜか、window.onloadに割り当てた関数が先に実行されて、<p>window onloaded!</p>って表示されるんですよねぇ。何でかなぁ。doScroll絡み？

JavaScript  

　こんにちは。日本にいるのと同じ感覚で、職場の自分の机上にアップル社のiPhone^Gを置いていたらいつの間にか盗まれていたmartinです。まだ購入して2ヶ月も経ってなかったと思うけどなぁ。こちらでは、たとえ自分のデスクに置いていても、それが貴重品であれば「どうぞご自由に持っていって下さいませ」ということになるらしい。おかげ様で、今ではトイレに行く際にも、いちいちノートパソコンを隠すようにしています。人を見たら泥棒と思えなんて実践したくはないけど、この国ではしょうがないです。愚痴ったところで、正式版で実装予定のボタンのデザインについてメモしておきます。最終的に目指すのは以下のようなボタンです。

　ppBlogのベータ版1.7.3では、Ajax向けのコメント展開ボタンやコメントフォーム表示ボタンをAタグとSPANタグとを組み合わせて、いわゆるSliding doors と呼ばれるよく知られたテクニックを用いて実現していました。

　参考サイト

• CSS Oval buttons
• How to make sexy buttons with CSS
• Simple Round CSS Links ( Wii Buttons )

バージョン1.6までは、素直にBUTTONタグを使っていたんですが、これだとデザイン上の制約があるなぁ、と思ってました。各種ブラウザでBUTTONタグに対するpaddingの解釈も違うしなぁというのもあって。でも、デザインに関してこれらの点はクリアできることが分かりました。個人的に、BUTTONタグを使う際にデザイン上のネックであった点を挙げてみると、

1. IEで、ボタン内のテキスト左右に指定を無視したパディングが取られること。
2. Firefoxで、BUTTON要素内に入れたSPAN要素周りのパディング(マージン？)をなくすことが出来ない。

で、これの回避方法が分からなかったというのもあり、A要素とSPANとを用いていたんですが、解決しました。まず、1番目の実例から。以下のような記述の実際例を下に挙げます。スクリーンショットのように、IEではボタンが横長（縦方向もですが）になり、パディングの指定を無視してるのが分かります。（注：以下に挙げるサンプルは、インライン指定になってますが、これはあくまで説明のためで、最終的にはクラス指定などを用いたスタイルシート指定になります）

<button style="padding: 0;">山のフドウ</button> /* パディングをゼロに */　

左がFirefox、右がIE7。

　では、このIEでのパディングをなくすにはどうすれば良いか？ ググればいくらか出てきますが(この辺 を参考に)、結論から言えば、以下のようにoverflow: visible;を追加すれば良いです。IE8では廃止が予定されている悪名高きhasLayout 絡みだとは思いますが･･･。この方式では、この指定によって他のブラウザが影響を受けないのがグーです。

<button style="padding: 0; overflow: visible;">山のフドウ</button> /* 左右のパディングをゼロに */　

　２番目のネック、FirefoxでBUTTON要素の入れ子要素に余分な余白が付く件ですが、これも実例で。次のようにスタイルを指定します。期待するのは、BUTTON要素の背景色である赤が見えずに、入れ子のSPAN要素に適用した背景色の黄のみが見えることです。SPAN要素に display:block 指定をすることでSPANの高さを親要素のBUTTONの高さと一致させていることに注目。

<button style="background: red; height: 24px; border: none; margin: 0; padding: 0; overflow: visible;  white-space: nowrap;">
  <span style="background: yellow; height: 24px;  line-height: 24px; display: block;">雲のジュウザ</span>
</button>

　さて、実例を見てみましょう。

少なくともFirefox2.0.0.14では(Firefox3 beta 5でも同様)、意図しない余白が左右と上に現れ、BUTTONタグの背景色の赤色が見えると思います。他のブラウザでのスクリーンショットを以下に。IE6だと下の部分にパディングが現れるかもしれません（下に赤いラインが入る）。

左から順にFirefox2.0x、IE7、Opera9.27、Safari3.1.1

　珍しくIE7が他のモダンなブラウザと肩を並べています　で、このFirefox特有の振る舞いを回避する方法ですが、この構造（BUTTON要素にSPAN要素を入れ子にする）を維持したいのであれば、スタイルシートに以下の指定を追加します。これは色々試してようやく辿りついた方法ですが、左右の余白までは消すことは出来ません。。

button::-moz-focus-inner { border-width: 0 !important; }

　どうせなら他のブラウザみたく左右の余白も消し去りたいです。ではどうするか？ Sliding doorsのテクニックは使いたいので、入れ子構造は必須です。実は、簡単で、BUTTONタグの中に別の要素を入れ子するのではなく、BUTTONタグを入れ子の対象にしてやれば良いです。具体的には、以下のような感じになります。

<div style="background: red; height: 24px; margin: 0; padding: 0;">
 <button style="background: yellow; height: 24px; line-height: 24px; border: none; overflow: visible;">海のリハク</button>
</div>

　実際のサンプルは下。DIV要素は別にP要素でも構いませんが、BUTTON要素にはブロック要素も含めることが出来るので、そんな場合はインライン要素のみを包括できるP要素では役不足になります。

　おや？ 余白が消えたのはいいですが、今度はBUTTONタグを囲ったDIV要素の背景色の赤が、ズラッと端まで伸びてます。これはDIVがブロックレベルの要素なので当然の振る舞いです。これを回避するには、具体的な横幅を指定するというのがありますが、長さが予め分かっていて決め打ちなら良いのですが、このブログでの使用例のように(コメント数に応じて)長さが変わることもあります。こんなときはどうするか？　よくあるのはフロートを使うやり方。具体的には、DIV要素に

<div style="background: red; height: 24px; margin: 0; padding: 0; float: left;">

とfloat: left;を追加します。この修正をしたのが以下。

正しくレンダリングされていればBUTTONタグの黄色の背景色と黒い文字しか見えないはずです。これでオッケーですね。

うん？　ちょっと待ったぁー（ねるとん紅鯨団 風に）。フロートをかませば確かにいいけど、ボタンをセンタリングとかしたいときってどうするの？ うーん、確かにフロートを使用すると、この辺りの扱いが難しくなります。フロートを使わないで出来るやり方はないのか？ ちゃんとあります。CSSには、ブロックレベルの要素をあたかもインライン要素のように扱える指定があって以下のやつです。そのまんまの名前が付いてます。

display: inline-block;  /* 正当な指定。インラインブロックとして振る舞う */
display: -moz-inline-box;     /* Firefox2.xは上に未対応なので独自のやつで。 */
zoom: 1; *display: inline;    /* hasLayoutをかまし、さらにIEだけにinline指定。 */

　何だかちょいと入り組んでます。これは説明が必要ですね。1段目は、まっとうな指定でこれに対応しているのは、Opera9.2xとSafari3x、Firefox3.x、そして条件付きでIEです。Firefox2.xは未対応ですが、独自の-moz-inline-boxで対応できます。さて「条件付きで」IEにも効くと書きましたが、これはどういうことかというと、もともとインライン要素のもの（SPANとかSTRONGとか）に対しては、これを指定するとインラインブロックとして振る舞いますが、もともとブロックレベルの要素(DIVとかPとかH3とか)に対してはこの指定は無効です(それどころか振る舞いが更におかしくなる)。ではどうするか？　うまいやり方があって、IEでは、hasLayoutを有効にして、かつdisplay: inline;という指定をするとほぼdisplay: inline-block; と同じ振る舞いをします。DIV要素はもともとはhasLayoutが無効なので、zoom:1;(常にhasLayoutが有効になる)を指定します。その上でdisplay: inline;という指定をしますが、これだと他のブラウザ向けの指定を上書きしてしまうので、IEしか解釈しないように、頭にスター（＊）を付けます（スターハック。IE７では効かなくなった* htmlのスターハックとは別物です）。この修正を施したものを見てみましょう。扱いづらいフロート属性はもはや不要です。

　ちゃんとセンタリングも出来ますね。

　以上の指定でようやく各ブラウザでの差異を吸収できて、ボタンタグを使う準備ができました。IE6は、これらでも完璧にはならないけど、まぁいいか。前置きが長くなりましたが、こうやってパディングやマージンの指定がきちんと効くやり方（最初はゼロを指定してそれがきちんと適用されるか）を抑えておけば、後は、それを弄るのは簡単です。次のページで、背景画像を利用したボタン効果を見ることにします。と、思いましたが、疲れたのはとりあえず今日はここまで。デモページへのリンクを貼っておきます。

　http://p2b.jp/demo/cute-buttons.html

CSS