主要ブラウザのツールで document.write した JavaScript をデバッグできるか確認してみた

おはようございます。なかじまんです。

主要ブラウザのツールで eval した JavaScript をデバッグできるか に続いて document.write した JavaScript をデバッグできるか確認してみました。もとネタとした JavaScript は、次のとおりです。

<script type="text/javascript">
document.write(
' <script> ',
' function d2() { \n',
' var foo = 1; \n',
' var bar = 2; \n',
' foo += bar; \n',
' console.log(foo, bar); \n',
' }; ',
' <\/script> '
);
</script>
<input type="button" value="d2" onclick="d2();" />

IE8

標準の開発ツールでデバッグできませんでした。何か方法をご存知でしたら教えてください。

IE7 以前

調べていません。ご存知でしたら教えてください。

Firefox 3

Firebug を使ってデバッグできますが、実用レベルではありませんでした。JavaScript 中から debugger; を使ってデバッガを起動し、ステップ実行できるのですが、ソースコードと実行中の行がチグハグで、どの箇所をデバッグしているか判断できません。何か方法をご存知でしたら教えてください。

Firefox 2 以前

Firefox 3 と同じです。

Chrome

次のとおり、標準の JavaScript Debugger を使って、デバッグできませんでした。関数単位でブレークポイントは指定できましたが、行単位はできませんでした。具体的なファイル名が分かれば、行単位でデバッグできるのですが、document.write で生成した無名リソースは、関数が最小単位のようです。何か方法をご存知でしたら教えてください。



Safari 4

標準の Web Inspector を使ってデバッグできませんでした。何か方法をご存知でしたら教えてください。

Safari 3 以前

Safari 4 と同じです。

Opera 9.5, 9.6

次のとおり、標準の Dragonfly を使ってデバッグできました。



Opera 9.2 以前

調べていません。ご存知でしたら教えてください。

以上です。document.write した JavaScript をデバッグするときは Opera 9.5, 9.6 を使うとよさそうです。本当に困り果てたときは Firebug でガンバルという選択もありそうです。

主要ブラウザのツールで eval した JavaScript をデバッグできるか確認してみた

こんにちは。なかじまんです。Twitter での言いだしっぺということもあり、少し泥臭いことしました。

主要ブラウザのツールで eval した JavaScript をデバッグできるか確認してみました。もとネタとした JavaScript は、次のとおりです。

<script type="text/javascript">
eval(
' function d1() { \n' +
' var foo = 1; \n' +
' var bar = 2; \n' +
' foo += bar; \n' +
' console.log(foo, bar); \n' +
' }; '
);
</script>
<input type="button" value="d1" onclick="d1();" />

IE8

次のとおり、標準の開発者ツールを使って、デバッグできました。



IE7 以前

デバッグできませんでした。アドインが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Firefox 3

次のとおり、Firebug を使って、デバッグできました。ただ、タイミングなどによって、うまく動作しないことがあります。何かコツがあるのかもしれません。



Firefox 2 以前

Firebug を使っても、デバッグできませんでした。JavaScript 中から debugger; を使って、デバッガを起動できるのですが、eval した JavaScript を行単位でデバッグできませんでした。また、他のアドオンが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Chrome

次のとおり、標準の JavaScript Debugger を使って、デバッグできませんでした。関数単位でブレークポイントは指定できましたが、行単位はできませんでした。具体的なファイル名が分かれば、行単位でデバッグできるのですが、無名リソースは、関数が最小単位のようです。無名リソースで、行単位にデバッグする方法をご存知でしたら教えてください。



Safari 4

次のとおり、標準の Web Inspector を使って、デバッグできました。



Safari 3 以前

デバッグできませんでした。アドオンが存在するかもしれませんが、調べていません。ご存知でしたら教えてください。

Opera 9.5, 9.6

次のとおり、標準の Dragonfly を使って、デバッグできました。



Opera 9.2 以前

調べていません。ご存知でしたら教えてください。

以上です。最新か次世代のブラウザであれば、おおむねデバッグできるようですね。

CSS Browser Selector を使って Google Chrome を個別対応する。textarea のフォントサイズの相対値がおかしな件。

Google Chrome だけ textarea の font-size がひとまわり小さくなってしまう

Google Chrome を使って Golazo MA4 の動作確認をして気が付いたのですが、Google Chrome だけ、次のように textarea の font-size がひとまわり小さく表示されてしまうのです。em 単位で指定してるのが良くないのかなぁ。ネットで調べてみたのですが、それらしき話題は見つかりませんでした。時間があるときに原因を調べてみます。

引き続き、調べてみました。Google Chrome の textarea は、気になるところが2点ほどあります。

1つ目は、textarea のフォントサイズが、他のブラウザに比べて、ひとまわり小さいことです。他のブラウザに比べて 80% くらいの大きさでしょうか。Styling even more form controls を使うと、様々なフォームのスタイルを手軽に確認できます。

2つ目は、次のように textarea のフォントサイズに相対値を指定すると、元々の textarea のフォントサイズに対して .8em 分、小さく表示されるということです。CSS の仕様は、あまり詳しく把握できていないのですが、.8em と指定したときは、1em に対する .8em のフォントサイズになると理解しているのですが、どうもそうじゃないようです。Safari 3.1 だと期待どおりなのですが...。

#content form input,
#content form textarea {
font-size: .8em;
}

次のとおり、フォントサイズに絶対値を指定すると、Google Chrome も含め、すべてのブラウザで、期待どおりのフォントサイズで表示できます。ただし、フォントサイズを固定すると、文字サイズの拡大と縮小で、ブラウザ間で差異が出てしまう(特にIE)ため、対処としては不完全といえます。

#content form input,
#content form textarea {
font-size: 13px;
}

Google Chrome だけ個別に対応する手法(いわゆる CSS Hack)がないか探してみましたが、Google Chrome は Safari 3 の CSS Hack を適用できるが、Google Chrome だけ適用できる CSS Hack はなさそうでした。Google Chrome を調整すると Safari 3 に影響が出ちゃうということですね。う～む。

ということで CSS だけでの対応はあきらめ、CSS Browser Selector という JavaScript を使って、User-Agent ごとに CSS を切り替える仕組みを使って対応することにしました。

CSS Browser Selector の導入はとても簡単です。次のように JavaScript をロードして、

<script type="text/javascript" src="css_browser_selector.js"></script>

次のように、ブラウザごとに CSS を記述するだけです。Google Chrome だけ textarea のフォントサイズを 1em にしています。これで、すべてのブラウザで、ちょうど 80% の大きさになります。

#content form input,
#content form textarea {
font-size: .8em;
}

.chrome #content form textarea {
font-size: 1em;
}

CSS Browser Selector が何をするかというと、navigator.userAgent を見分けて、HTML 要素にブラウザの種類を表すクラス名を動的に追加するというだけです。ブラウザのエンジン、オペレーティングシステムの区別もできます。なかなかシンプルなアイディアに感心します。

<html class="gecko ff2 win js">

JavaScript が無効だと使えないという欠点がありますが、JavaScript の有無による CSS の区別も備えるため、JavaScript が無効なときの妥協的な CSS を用意するといった対応もできます。

Safari2 で Golazo MA4 の CSS が適用されない不具合を解消しました

Golazo MA4 team のなかじまんです。

ごめんなさい。Golazo MA4 ですが、Safari2 だと CSS が適用されない状態となっていました。本日(9/20)、その不具合を改善したことをお知らせします。

その原因ですが、Golazo MA4 を iPhone (iPod touch を含む) 向けに最適化したものを公開しようと考えていました。その前準備として、メディアクエリを使って、CSS を切り替えるようにしていたのですが、Safari2 がメディアクエリに対応していないため、CSS が適用されないという状態になっていました。これらの経緯は、次のエントリにまとめてあります。

メディアクエリによる iPhone スタイルの切り替えは万能じゃないのか?

メディアクエリを使って iPhone (iPod touch を含む) とその他のブラウザで、スタイルシートを切り替えようと試みているのですが、Apple の開発者サイトやネット上で紹介している方法だと、なぜか Safari 2.0.4 (Multi-Safari) が期待どおり振る舞ってくれません。

まだ準備の段階にも関わらず、iPhone (iPod touch を含む) を意識したコードを HTML ページに忍ばせたのが失敗でした。Safari2 はきっと大丈夫という勝手な判断もよくなかったですね。ちょー反省です。

MacOS X Tiger と Safari3、Safari2 (Multi-Safari)、Firefox3、Firefox2 を使ってみて、どのブラウザでも不都合なくレンダリングしていることを確認できました。もしも、まだ不都合があるようでしたら教えてください。改善していきます。

メディアクエリによる iPhone スタイルの切り替えは万能じゃないのか?

メディアクエリを使って iPhone (iPod touch を含む) とその他のブラウザで、スタイルシートを切り替えようと試みているのですが、Apple の開発者サイトやネット上で紹介している方法だと、なぜか Safari 2.0.4 (Multi-Safari) が期待どおり振る舞ってくれません。

次のとおり link 要素を記述しました。ですが、

<link media="only screen and (min-device-width:480px)" rel="stylesheet" type="text/css" href="/css/golazo-iphone.css" />
<link media="screen and (min-device-width:481px)" rel="stylesheet" type="text/css" href="/css/golazo.css" />

IE6 と IE7 がスタイルシートを読み込まなかったため、次のとおり [if IE] .. [endif] を追加して個別に対応しました。

<link media="only screen and (min-device-width:480px)" rel="stylesheet" type="text/css" href="/css/golazo-iphone.css" />
<link media="screen and (min-device-width:481px)" rel="stylesheet" type="text/css" href="/css/golazo.css" />
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="/css/golazo.css" />
<![endif]-->

これで OK という気になっていたのですが、MacOS X Tiger の Safari 2.0.4 (Multi-Safari) を使ってみると、どのスタイルシートも読み込まれないのです。[if IE] .. [endif] はコメントでスキップしているので、つまり、メディアクエリを指定した link 要素をスキップしているということです。

何か方法が悪いのか、勘違いしているのか、自分自身の中で謎が深まっていくばかりです。Safari 2.0.4 (Multi-Safari) 固有の振る舞いなんでしょうか。今となっては Safari 2.0.4 を試す環境がないので、確認もできないのです。困りました。ヘルプみー。

追記です。-- 2008-09-19

明確な記述のある文献は見つかっていないのですが、ネット上などの情報を総合すると、Safari 2.0.4 の時点では、メディアクエリに対応していなかったようです。

ですので、1～1.5世代くらい前のブラウザも範疇に含める必要があるなら、UserAgent を見分けた切り替えが妥当という結論です。う～む。やっぱり、何らかのプログラム的な要素が必要になりますね。

Aptana Jaxer でファイルをアップロードすると、特定の条件で mod_jaxer がエラーになる

次のようなフォームを使って、Aptana Jaxer に対してファイルをアップロードを試みました。

ファイルのアップロードは期待どおり動作するのですが、ファイルを指定せずにアップロードしようとすると、mod_jaxer がエラーになり、Apache が 500 Internal Server Error になってしまいます。

<form method="post" action="/picture.html" enctype="multipart/form-data">
<input id="form_picture" type="file" name="picture" value="" />
<input type="submit" value="写真をアップロードする ≫" />
</form>

Apache のエラーログには、次のように出力されます。

[Wed Aug 06 06:46:20 2008] [warn] (OS 10054)既存の接続はリモート ホストに強制的に切断されました。 : mod_jaxer: receive data over socket error: total len=3 read=0
[Wed Aug 06 06:46:20 2008] [warn] (-1)Unknown error: mod_jaxer: read data from socket error

いろいろ確認してみたところ、Safari 3 と Opera 9 (ともに Windows XP) でのみ再現することがわかりました。どうやら、ファイルを指定しないときの multipart/form-data の扱いが、ブラウザによって違いがあり、その違いが mod_jaxer の期待と異なることがあると推測できます。

次のように、送信ボタンに name="submit" と名前を指定したところ、この不都合は発生しなくなりました。つまり、multipart/form-data でファイルをアップロードするときは、type="file" 以外のフィールドも合わせて送信するのが無難そうです。

<form method="post" action="/picture.html" enctype="multipart/form-data">
<input id="form_picture" type="file" name="picture" value="" />
<input type="submit" name="submit" value="写真をアップロードする ≫" />
</form>

ということで、実用上は不都合はないという結論です。

Aptana Jaxer のバグ報告を検索してみましたが、それらしきバグは報告されていないようです。ここで扱った Aptana Jaxer のバージョンは 0.9.7.2472 (Windows XP) です。ですので、先日公開された 1.0.0 RC B では改善されているかもしれません。もしも、改善されていないようでしたら、Aptana に報告したいと思います。

Safari と Opera でキーボードを使ってアンカーを移動する方法

ページ上のアンカーテキストにフォーカスが移ったとき、その a 要素の onfocus イベントをハンドリングして、その中からさらにページの要素を操作するといった JavaScript コードを書いています。

この JavaScript コードを Safari 3.1 と Opera 9.2 でテストしようとしたところ、TAB キーだとアンカーを移動できないことを知りました。これだと、a 要素の onfocus イベントのテストがしにくいです。

そもそも Opera の TAB キーは、フォームの要素を移動するためのものだそうです。その変わりに Opera は、別のショートカットキーを用意しています。

a キーでアンカーを進み、q キーでアンカーを戻ります。Ctrl + ↑↓ キーも同じ動きをします。また、Shift + ↑↓←→ キーで、アンカーとフォームの要素を上下左右に移動できます。

Safari の TAB キーも、フォームの要素を移動するためのものだそうです。が、次のように、"タブキーを押したときに WEB ページ上の各項目を強調表示" オプションを ON に変更すれば、その動きを変えることができます。



オプションを ON にすると、TAB キーを使ってアンカーとフォームの要素を移動できるようになります。もちろん Shift + TAB キーで、その逆に移動できます。

Safariの変更を追跡する

以前にSafariの特徴的な振る舞いについて記事を書いたのですが、状況が変わったようです。最近、Win版Safariの3.1.1が配布されたのをきっかけに次の二点について再確認を行ったところ、他の主要ブラウザに合せる形で修正されていました。

　１．組み込みオブジェクトの文字列表現が"[function]"となる
　２．未定義値が設定された配列インデックスはfor inやhasOwnProperty()関数で無いものとして扱われる

っで、どのバージョンで修正されたのか知りたかったので１について調べてみました。
まずSafariのJavaScript実装である、KJSを管理しているTracを眺めて、Changeset 29817のfunction_object.cpp(r29817)で修正されていることを見つけました（多分これだと思います…）。

http://trac.webkit.org/projects/webkit/changeset/29817

次にWikipediaにSafariのバージョンとビルド番号の対応表を参考に、Tracのタグを眺めたところWin版Safariはr29817を3.1から3.1.1へのバージョンアップで取り込んでいるようで、最新の3.1.1から振る舞いが変わるようです（Tracには五千番台のビルド番号もあるのですがこれはMac版かな…）。

http://ja.wikipedia.org/wiki/Safari

こういった追跡は他のプロジェクトのChangeLogやコミットコメントを眺める事になるので、書き方など色々と勉強になります。

Multi-Safari で Safari3 と Safari2 が共存できました

開発した WEB サイトや WEB アプリの動作確認のために Mac mini を所有してますが、MacOS X Tiger を最新にアップデートすると Safari3 に入れ替えバージョンアップとなって Safari2 が使えなくなる。その逆で、アップデートしないと Safari2 のままで Safari3 が使えないというジレンマがありました。

旧バージョンの Safari をスタンドアロンのパッケージとして配布するサイトがあると聞いたので、さっそく試してみました。

Multi-Safari

These special versions of Safari use the original Web Kit framework that came with them, bundled inside the application. They will mimic original Safari rendering and javascript behaviours. HTTP requests and cookies however are still handled by the system and may not work exactly the same.

使うのは簡単でした。Multi-Safari から希望するバージョンのパッケージをダウンロードして実行するだけです。試しに Safari 2.0.4 を使ってみましたが、確かに Safari 2.0.4 の振る舞いをしています。

旧バージョンの各 Safari に対応した WebKit を組み込んでいるようなので、HTML/CSS のレンダリングと JavaScript の動きは、旧バージョンそのものになるようです。ですので、WEB サイトや WEB アプリの動作確認にはもってこいです。

ただ、MacOS X のシステムとして扱っている部分は、旧バージョンそのものの動きとはならないかも？という制限があるようです。

あと、MacOS X のバージョンにも依存するようです。例えば、MacOS X Tiger で Panther 時代の Safari は不都合(動作しない？)があるなど、すべての旧バージョンが試せるというわけではありません。

動作条件や制限は Multi-Safari に記載がありますので、ダウンロードする前に確認してみてください。

MacOS X Tiger で Safari1.3 が動かせないのが残念ですが、Safari3 と Safari2 が共存できるだけでも、とても助かりますね。

JavaScript「クロスブラウザ」テクニック―どのブラウザでも、どのOSでも同じに動くスクリプトの“技” (Programmer’s lounge) 半場 方人 by G-Tools

(訂正) マッシュアップレシピ BLOGRANGER TG touch の Google ニュース和え

昨日の マッシュアップレシピ BLOGRANGER TG touch の Google ニュース和え エントリに誤りがありました。

BLOGRANGER TG touch のリンク先が、イントラネットのアドレスを指していました。すみません。

本来のリンク先は、次のとおりです。訂正します。

BLOGRANGER TG touch
http://developmentor.lrlab.to/blogranger/touch.html

iPod touchパーフェクトガイド (アスキームック) (アスキームック) マックピープル編集部 by G-Tools

マッシュアップレシピ BLOGRANGER TG touch の Google ニュース和え

Google Maps と同じく BLOGRANGER TG も iPod touch で地図をスクロールできない不都合がありました。詳しくは キーボードを前提としない Wii でも使えるという BLOGRANGER TG は iPod touch でも使えるか？ のエントリを見てください。

そのエントリの中で Google Maps API を使って iPod touch のタップ操作で Google Maps を使えるようにした Google maps touch を紹介しました。そこで BLOGRANGER TG も API を公開しているので、BLOGRANGER TG も同じように iPod touch のタップ操作で使えるようにしてみました。

その名も BLOGRANGER TG touch です。ベタベタな名前ですみません。

BLOGRANGER TG の地図をタップすると、そのタップした位置が画面中央になるように移動します。画面端をタップしながら地図の上を歩いていくような感じです。



タグをタップすると、そのタグで最近のニュースを検索するようにしました。ニュースの検索は Google ニュースを使っています。BLOGRANGER TG の地図とタグは、ブログ界の様相を表している？ので、ブログ界とニュースの関係とそこから何かの発見があるかもしれない・・・。ない。ない。きっとない。(^^;



なお、PC のブラウザでも使えますが、ドラッグして地図をスクロールすると変な動きをしてしまいます。それはなぜ？かというと、次のような経緯があったためです。

Apple iPod touch 8GB MA623J/A by G-Tools

Google Maps API なら地図のクリックイベントを捕捉して、GMap2 クラスの setCenter メソッドや panTo メソッドを使って、そのクリック位置が画面中央になるように移動すればよいのですが、BLOGRANGER TG API リファレンス/TagMap を見ていると、そんなに簡単じゃないことに気が付きました。

BLOGRANGER TG の地図は TagMap クラスで操作するのですが、このクラスは緯度経度のような絶対的な座標ではなく、タグという論理的な座標を使うようになっています。

なので、クリックしたタグの位置には移動できますが、地図のクリックした位置に移動するという方法がありません。タグをクリックしたというイベントはありますが、地図をクリックしたというイベントは用意されていません。

う～ん。困りました。あきらめようと思いましたが、BLOGRANGER TG API の よくある質問 がヒントになり、ちょっと姑息？な方法かもしれませんがうまく？解消できました。

BLOGRANGER TG は、オープンソースのライブラリである script.aculo.us の dragdrop を使っているとあります。地図のスクロールに dragdrop を使っているのであれば、その dragdrop のイベントを横取りして、外側から操作してしまえばよいのでは？思い立ちました。

次のコードがその結果です。dragdrop の横取りは後半部分です。WEB ページ内のドラッグオブジェクトを取り出して繰り返し、その要素にクリックイベントを仕掛けています。これが地図のタップに該当します。

  var width = 320;
  var height = 356;
  var map = new TagMap($('map'), width, height);
  map.attachEventListener('tag_click', function(tag) {
    window.open('http://news.google.co.jp/news?' +
      $H({ q: tag, ie: 'UTF-8', scoring: 'n' })
        .toQueryString()
      );
  });

  Draggables.drags.each(function(drag) {
    Event.observe(drag.handle, 'click', function(e) {
      this.initDrag(e);
      this.updateDrag(e, [width / 2, height / 2]);
      this.endDrag(e);
    }.bindAsEventListener(drag));
  });

dragdrop のソースコードを見ると、onmousedown イベントで initDrag メソッド、onmousemove イベントで updateDrag メソッド、onmouseup イベントで endDrag メソッドを呼び出す仕組みになっています。

ですので、ドラッグ(ドロップ)する座標が常に画面中央となるように、クリックイベントの中で、その呼び出しの流れをシミュレートするようにしました。これが地図のスクロールに相当します。

これで地図のスクロールの不都合が解消できました。最後にもう1つ。

iPod touch の Safari は WEB ページのサイズに合わせて、自動的に拡大(縮小)する仕組みになっていて、初期の拡大率が 1.0 とはなっていません。このままだと BLOGRANGER TG の地図が iPod touch の画面一杯に表示されません。かなり小さく表示されます。

なので、次のように meta 要素を指定して、ページの横サイズと拡大(縮小)率を固定し、画面一杯に表示するようにしました。さらに、拡大(縮小)の操作も無効にしました。

<meta name="viewport" content="
  width=320;
  minimum-scale=1.0;
  maximum-scale=1.0;
  user-scalable=0;
" />

詳しくは Travellers Tales : iPhone 用 Web ページおよびアプリケーションの作り方 - iPhone Development Guidelines を読む を見てください。

ひととおり試してみましたが、今のところ期待どおり動作しているように見えます。もしも不都合がありましたらごめんなさいです。

Wiiフィット(「バランスWiiボード」同梱) by G-Tools

Safariで入力ボックスの貼り付け(ペースト)が無効にならない!?

Web Kit DOM Programming Topics の JavaScriptからのペーストボードの使用 によると、Safari は onpaste イベントを実装しているという解説があります。

しかし、実際に次のようなコードを Safari 2.0.4 (MacOS X) で試してみたところ、入力ボックスの貼り付け (Command+V) が期待しているように無効になりません。何か私に勘違いがあるのでしょうか。

// ignore_paste
function ignore_paste(name) {
  var element = document.form[name];
  if (element) {
    element.onpaste = function() {
      return false;
    }
  }
}

このコードは Safari 3 (Windows XP) では期待どおり動作しています。もちろん IE 6 と IE 7 (Windows XP) も同様に動作します。

それ以外のシェアの高いブラウザは、今のところ onpaste イベントをサポートしていないので、このコードは動作しないはずです。エラーにもならないはずです。試していませんが、聞くところによると Firefox 3 は onpaste イベントをサポートするとのことです。

[すぐにできる!] iLife'08 村上 弘子 白瀧 由裕 井村 克也 by G-Tools

キーボードを前提としない Wii でも使えるという BLOGRANGER TG は iPod touch でも使えるか？

NTT研究所とgoo、ブログ記事を地図のように眺める「BLOGRANGER TG」

タグクラウドをスクロール地図として表現して、その地図をスクロールしながらタグを探し、そのタグをクリックしながらブログを探すという、今までとはちょっと違ったスタイルのブログ検索サービスがはじまりました。

前述のとおり、地図のスクロールとタグのクリックが中心となるため、Wii のようにキーボードを前提としない端末でも有効であるとのこと。私は Wii を所有していないので体験できませんが、次のように Wii の ブラウザ (Opera?) でも使えるようです。画像はニュースの記事中のものです。



そうかい。そうかい。iPod touch オーナーの私としては、妙な対抗意識を覚えてみたわけです。であるならと、さっそく iPod touch の Safari で BLOGRANGER TG を開いてみました。

お見事です。PC と同じように JavaScript も動作するようですし、レンダリングも申し分なしです。サイトのデザインが横長なので、iPod touch も横向きで使うと見通しがよいです。



ブログを詳しく見るときは、縦置きにして拡大(ズーム)して見れたりするのが iPod touch のよいところです。最近の PC ブラウザでもページの拡大や縮小ができますが、iPod touch の操作性には及びませんね。

ダブルタップすると拡大(縮小)しますし、横になぞると、そのなぞった分だけ拡大(縮小)できます。何度も繰り返しても惚れ惚れしてしまう素敵なインタフェースです。



と iPod touch を褒めちぎっていますが、重大な欠点もあります。

Google Maps を使うときも同様の問題があるのですが、BLOGRANGER TG も同じように iPod touch ではドラッグして地図のスクロールができませんでした。iPod touch の操作はドラッグが基本のため、JavaScript のイベント (onmouse 系?) が Web アプリまで伝わらないのでしょうね。

Google Maps は Google maps touch のように Google Maps API を使ってタップで操作できる iPod touch (米国では iPhone も?) に最適化した Google Maps を提供している人がいます。

BLOGRANGER TG も API を提供しているので、同じように iPod touch 向きにカスタマイズしたものが作れたりするのかもしれませんね。

Apple iPod touch 8GB MA623J/A by G-Tools

Safari onfocus イベントで select してテキストを選択する方法 (改善案)

テキストボックスにフォーカスが移ったとき、そのテキストを選択するという、次のような JavaScript コードはよく見かけますが、onfocus イベントの中で select メソッドを使うという方法だと、Safari 3 では期待どおり動作してくれません。

テキストを編集しようとしてクリックすると、一瞬そのテキストが選択されますが、すぐに選択が解除されてしまいます。ただ例外もあって、タブキーでフォーカスが移ったときは、期待どおり選択され、解除されることはありません。う～む。

<form id="f">
<input id="c" type="text" name="c" value="160-0021" />
<input type="submit" />
</form>

<script type="text/javascript">
//<![CDATA[
jQuery(function($) {

$('#c')
  .focus(function() {
    $(this).select();
  });

}); //jQuery
//]]>
</script>

select メソッドは onfocus イベントが完了してから適用しないとダメのようです。ですので、次のように setTimeout 関数を使って、select メソッドの適用を遅らせてみたところ、期待どおり動作するようになりました。

<script type="text/javascript">
//<![CDATA[
jQuery(function($) {

$('#c')
  .focus(function() {
    var self = this;
    setTimeout(function() {
     $(self).select();
    }, 10); // Safari
  });

}); //jQuery
//]]>
</script>

理論上は onfocus イベントの中で select メソッドを適用していないので、そのタイミングによる副作用があること(ありそう)ですが、他のブラウザも含めて試行していますが、今のところ不都合は見つかっていません。

[すぐにできる!] iLife'08 村上 弘子 白瀧 由裕 井村 克也 by G-Tools