以前、テキストエリアのサイズを文章の長さに合わせて変えるスクリプトを考えて、それをppBlogのエディタにも採り入れているのですが、それは意図した様に動くには動くのですが、えらく力業なスクリプトでした。その恥ずかしいスクリプトは、ここ に置いてます

　記述も長くてスマートでないし、もっと簡単に出来ないかなぁと考えてみましたが、要は、自動調節というのは、テキストエリアのスクロールバーが表示されなくなるまでエリアを伸ばすということなので、その考えで行けば簡単でした。以下のような記述でいけますね。

function autofit(el){
 if(el.scrollHeight > el.offsetHeight){
  el.style.height = el.scrollHeight + 'px';
 } 
}

element.scrollHeightで、目的のテキストエリアの、スクロール分も含めた高さ(+ボーダー幅)を取得できます。で、element.offsetHeightで、見た目の高さを取得できます。なので、スクロールバーが表示されている状態というのは、文章が長くて表示しきれない状態なので、じぁ、テキストエリアの高さをscrollHeightに合わせれば良い、ということになりますね。なんで、こんな簡単なことに気が付かなかったかなぁ。まず、このデモを見てみましょう。

　とりあえずは、これでよさげですが、もうちょっといじってみましょう。例えば、この文章をコピペして、元の文章の下に貼り付けると、表示領域からはみ出るので、自動的にスクロールバーが表示されると思います。なので、ここでもう一度「AutoFit」ボタンを押すと、テキストエリアが広がります。次に、この貼り付けた文章を削除してみて下さい。テキストエリアが広がった分、下に大きな余白が出来ますね。今度は縮めようと再度ボタンを押してもテキストエリアのサイズは変わりません。これは、このautofit関数の定義からして当然なのですが、気持ちとしては、今度は逆に縮んで欲しいなと。では、どうするか？

　強制的にスクロールバーを表示させる状態に持っていって、そこでこのautofit関数をかませば良いです。スクロールバーを表示させるには、意図的にテキストエリアの縦サイズを小さく取ればよいわけです。なので、極端な話、

element.style.height = '1em';

とでもして、つぎにautofit()を呼び出せばOKですが、これだと見た目にテキストエリアがスプラッシュみたくなるので、なるべく最小量のサイズ変更でいくには、次のような感じで良いかなと思います。

/* AutoFit関数その２ */
function autofit2(el){
 if(el.scrollHeight > el.offsetHeight){
  el.style.height = el.scrollHeight + 'px';
 } else {
  while (el.scrollHeight - 50 < parseInt(el.style.height)){
   el.style.height = parseInt(el.style.height) - 50 + 'px'; // 適当に50pxずつ
  }
  arguments.callee(el); // 高さを縮めてスクロールバーが出てくるタイミングで呼び出す
 }
 el.focus();
}

　以下に、これを適用したものを付けておきます。上の関数との動作の違いが分かると思います。

　この関数をonkeyupなどのキーイベントと結びつけておけば、入力に合わせて自動的にサイズが変わるテキストエリアの出来上がりです。これのデモを以下に挙げておきます。

　→http://p2b.jp/demo/autofit-textarea.html

---

　ppBlogでは、コメントやトラックバックが付いている記事には、それを記事の下の方に表示するレスポンス展開ボタンが付いてます（複数記事モードのとき。単独表示では、最初からコメント類は表示されている）。ここで、ボタンをクリックすると、Ajax経由で動的にコメントを読み込むので、わざわざページをリロードさせる必要もなくスムーズにコメントなどを読むことができます。

　現行では、このボタンをクリックしてデータを読み込むと、コメントエリアにフォーカスが移っていたと思いますが(ウィンドウがスクロールする)、これが、瞬時でピクッと移るために、何となく読み手の視点が混乱するというか、一瞬、何が起こったのか分からなくなるかもしれないと思い、このフォーカス移動を止めてみました。

　すると、特にウィンドウのスクロールを伴うことなく、展開されたコメント・トラックバックがボタンの下に表示されて良い感じです。でも、ひとつ問題があって、もし、このレスポンス展開ボタンをブラウザ画面の結構下の方でクリックすると、展開されたコメント類がブラウザ画面の領域下に表示され、これはこれで、何も展開されてないように見えるので、読み手を困惑させる可能性があります。

　なので、Ajaxで読み込んだデータを展開した際に、それらがウィンドウの枠外であるときに限って、そのエリアまでスクロールさせるようにしました。かといって、単なるフォーカスの瞬間移動では、最初に述べたように、これも読み手を惑わせるかもしれないので、瞬時に移動ではなくて、スクロール制御するようにしてみました。以下のようなスクリプトでいけます。

var wscY = oParts.metrics(3); // ウインドウのスクロール量を取得
var firstComment = o("div.comment-entry", commentsDiv).item(0); // 表示エリアの最初のコメント要素を取得
var diff = firstComment.offset(1) - Number(wscY + oParts.metrics(1)); // 上記コメントを表示させるためのスクロール量を算出

if(diff > 0){
   (function(){
     var a = 30, s = arguments[0] / a; // スクロール量を適当に分割。ここでは30分割してる 
     var yy = []; // 縦移動させるスクロールポイントを入れる配列を用意
     for (var i = 0; i < a; i++) yy[i] = wscY + s * i; // 適当に移動ポイントを作成
     var i = 0, t = setInterval(function(){ window.scrollTo(0, yy[i++]); if(i >= a) clearInterval(t);}, 1);
   }).await(300)(diff + firstComment.rect(1) + 140); // データ読み込み後、300ミリ秒後に発動
  }
});

　データを読み込んでからいきなりスクロールしだすと、それで面食らうかもしれないので、.await(300) と微妙に間を持たせています。

　ここのサイトで、実際にコメントの付いた記事で試せますので、興味のある方は、あえてコメント展開ボタンをブラウザ画面ぎりぎりにセットして試して下さい。

　こんばんは。ppBlogでの記事作成は、テキストエリアに、タグ入力支援ツールバーの助けをかりて、(ベタに)ぐいぐい書いていくやつです。以前、IEとFirefoxがサポートしていたWYSIWYG^G(contentEditable/designMode)モードを採り入れようと思いましたが、IEの生成するHTMLソースがひどくて諦めたことを、どこかに書いたと思います。今は、Safariもそれをサポートしているようですが、まぁ現状の、テキストエリア方式でいいんじゃないかなと思っています。その場でプレビュー機能も付いてますし。

　で、このタグ入力支援の機能が、グーグルのChromeでうまく動かないなと前々から認識はしていたんですが、今回調べてみました。IEとの切り分けに、

if(document.getSelection){ // Firefox などIE以外のブラウザ

としていたのが駄目だったようです。Chromeはこれを無視していたようで。なので、この部分はwindow.getSelection()を使えばOKでした。でも、今や、IE以外のブラウザはみんな同じ仕様に沿ってるようですし(2-3年前はOperaが遅れていた)、IEとそれ以外という大まかな切り分けで行けば良さそうです。なので、よくある、テキストエリアのマウスカーソルのある位置に文字列を挿入するというスクリプトは以下のような感じで行けるかなと思います。ここでは汎用性のあるサンプルを載せます。ppBlog用のlib.jsには、これを若干modifyして載せます。

/* テキストエリアでカーソルで指定したポイントあるいは文字列に新たな文字列を挿入するスクリプト　*/

var Caret = {
 getArea : function(){ return document.getElementById("ta");}, // ID名ta(適当)というテキストエリアを用意
 selection : '', // ここに選択したテキストを収納する
 get : function(){ // テキスト選択メソッド
  var area = Caret.getArea();
  /*@cc_on@*/
  /*@if(1)
  if(!document.selection.createRange()) area.focus();
  Caret.range =  document.selection.createRange().duplicate();
  return Caret.selection = Caret.range.text;
  @else@*/
  return Caret.selection = area.value.substring(area.selectionStart, area.selectionEnd);
  /*@end@*/
 },
 set : function(string){ // 選択テキストを指定文字列に置換する
  var area = Caret.getArea();
  /*@if(1)
   if(Caret.selection.length > 0){
    Caret.range.text = string;
    Caret.range.select();
   } else {
    area.focus();
    Caret.range = document.selection.createRange().duplicate();
    Caret.range.text = string;
   }
  @else@*/
  if(Caret.selection.length >= 0 && area.selectionStart >= 0){
    var s = area.selectionStart, scrollTop = area.scrollTop;
    area.value = area.value.slice(0, s) + area.value.slice(s).replace(Caret.selection, string);
    area.setSelectionRange(eval(s + string.length), eval(s + string.length));
    area.scrollTop = scrollTop; // Firefoxでカーソルがトップに戻らないための処理
    area.focus();
  } else area.value += string;
  /*@end@*/
 }
}

　IEだけが違うと分かっているので、条件コンパイルを使って、動作の切り分けをしています。Firefox系で、指定位置に文字列を挿入した後、フォーカスが、テキストエリアのトップに戻ってしまうのを防ぐ処理を入れています。これはFirefox1.5で見られて、今はどうかなぁと思ったら相変わらずでした

　→参考リンク「 Firefoxでテキストエリア内のマウスカーソルが最初に戻ってしまう件 」

　一応、簡単なデモページを挙げておきます。

　　→上のスクリプトを使った、簡易JavaScriptエディタ。http://p2b.jp/demo/jseditor.html

　このデモにあるHTMLビューは悪くないなぁ。

　ヘッドラインモードでの表示周りを整備していて、記事ごとのスタイルシート指定が効いていなかったので、効くようにスクリプトを書き換えましたが、正規表現周りの挙動がブラウザ間で異なっていて、ちょっとはまったのでメモ。簡単な例を示します。

<script type="text/javascript">
function doRex(){
 var example = "J'adore Firefox!"; // I like Firefox!
 var RE = /Fire/g;
 var result = RE.exec(example); 
 if(result) alert("マッチ: " + result + "¥nlastIndex: " + RE.lastIndex);
       else alert("マッチしません！:" + "¥nlastIndex: " + RE.lastIndex);
}
</script>
<button onclick="doRex();"> 実 行 1 </button>

実 行 1

　上のdoRex()関数を実行すると、最初ボタンを押したときはちゃんとマッチしますが、2回目にボタンを押したときの結果がブラウザで異なります。Firefox3.0.7, Chrome1.0, Opera9.64では、「マッチしない」、IE6-8とSafari4 public betaでは、マッチして1回目と同じ結果です。なぜ、こういうことになるかというと、lastIndex絡みです。1回目の実行に対して、lastIndexの値が保持されているからです。2回目の実行で、マッチしないとなると、RE.lastIndexはまた0に戻るので、3回目の結果は初回と同じく「マッチ」です。

　でも、疑問なのが、doRex()という関数の中で定義したローカルな変数だから、doRex()を実行する度に、lastIndexの値はリセットされるのが正しい気もするんだけどなぁ。doRex()の中ではなく、グローバルな空間で同様のことをやれば、SafariもIEも2回目は「マッチしない」となり、これは納得できる挙動なんですが。

　では、このブラウザ間の差異をなくすにはどうするか？ひとつは、RE.exec(example) した後に、

RE.lastIndex = 0; // 値をリセット

という記述を加えて、明示的にlastIndexを元に戻す方法。もうひとつは、new演算子を使う方法です。これなら、どのブラウザでも同じ挙動、何度ボタンを押しても、「マッチ」となります。new RegExp("foo", "g") と /foo/g って同じと思っていたんだけど。

<script type="text/javascript">
function doRex2(){
 var example = "J'adore Firefox!"; // I like Firefox!
 var RE2 = new RegExp("Fire", "g"); // new演算子を使用する
 var result2 = RE2.exec(example);
 if(result2) alert("マッチ: " + result2 + "¥nlastIndex: " + RE2.lastIndex);
       else alert("マッチしません！:" + "¥nlastIndex: " + RE2.lastIndex);
}
</script>
<button onclick="doRex2();"> 実 行 2 </button>

　上のコードであれば、ブラウザ間の差異がない。

実 行 2

　でも、Safari/IE と Firefox/Chrome/Opera、どっちが正しい挙動なんだろうな。今イチ、すっきりしないです。

---

　こんにちは。まだまだ寒い日が続きますね。さて、ppBlogには、以下のような感じで、普通のアップした写真をちょいとお洒落に演出するスクリプトが付いてますが、IE8でエラーが出ていたりしたんで、更新しました。

　IE8のdocument.querySelectorAllの実装に始まり、Safariもサポート、Firefoxは3.1でサポートするでしょうし、この手の用途には、staticなnodeListでこと足りるので、photo-effectをいうクラス名を付けたIMG要素の検索には、document.querySelectorAllを第一に試すようにしてます。

　始めは、よくやるように、

var nodes = Array.prototype.slice.call(element.querySelectorAll("img.photo-effect"));

　としたのですが、何故かIE8では、JSオブジェクトがないと怒られて折角のquerySelectorAllが使えません。なので仕方なしに次のようにしました。

var nodes, items = element.querySelectorAll("img.photo-effect"), index = items.length;
while(index) nodes[--index] = items[index]; /* 地道に */

　IE8でも、Array.prototype.slice.call(arguments) は問題なく作動するのに。。きっと、正式版前のバグなんだろうけど。

　てな訳で、最新版を添付しておきます。ついでに言っておくと、このスクリプトは単体で動作します。ただし、2種類の写真フレームの画像も用意して適切にパスを書かないといけませんが。デフォルトでは、Imagesディレクトリにあるphotoframe.png とstampframe.png の2つです。