|
2012年07月31日 (火) | 編集 |
フォーム入力をリアルタイムチェックすることでコンバージョン率が22%アップ
によるとリアルタイムの入力チェック（元記事では、「インライン・バリデーション」と呼んでいる）で、
「成功率が22%向上」とか、いい事が色々書かれている。
しかし、そんな都合のいいことばかり鵜呑みにしては行けない。
「私は昨年FXで、1,000万儲けました」という話を聞いても、それをすぐに自分に当てはめてはいけないのと同じだ。
これは、色々なタイプで調査した時のベストパフォーマンスだ。
中には「-10%」とかあったかも知れない。
そもそも入力ミスをするのは、注意事項が小さく書かれていたり、意表を付く入力を強制するからだ。
半角、全角とか、サーバ側で自動で変換すればいいじゃん、と思うことも多い。
それはさておき、インライン・バリデーションって、そんなにいいのだろうか？
確かに中にはいいのもあるが、個人的には迷惑としか思えないものも多い。
フォームのバリデーション用jQueryプラグインいろいろ+α
で、幾つか紹介されているサンプルを試してみたところ、、
例えば、入力する前から、「入力してください」と出てきたり、
まさに入力中なのに、「正しいメールアドレスの形式を入力してください」
とか、アピールされたりする。僕の場合、その瞬間フォームを閉じる。
他にも、必須項目を飛ばすと、「ここは必須です」とか表示されたりするので、
その項目に戻ると、今度は戻る前の項目で、「ここは必須です」とか表示されたりする。
エラーが、出まくりだ。
更に例えば、エラーメッセージが、表示領域を確保するために高さが変わったりすると、
まさにカクカクしまくりで、めまいがする。
リアルタイムチェックは、いつ、どこで、どのようにをしっかり考えて実装しないと、
逆にユーザーを不快にしてしまうかも知れない。
今一度、A List Apartの元記事をしっかり確認すべきだ。
この元記事では、後半で、入力チェックのタイミングについて触れている。
一番最後（3番目）の Youtube を見ると分かり易い。
・入力後
・入力中
・入力前と入力中
のタイミングのどれがいいかを検証している。
この記事の入力チェックは、Ajaxを使っているので、少し元々遅い部分はあるかも知れないが、
見ていると「入力後」のチェックが一番快適となっている。（記事でもそう結論付けています）
更にこのフォームでは、ユーザーIDとパスワードについては、
「入力中」においても、少しの時間差をおいてチェックするというこだわりを見せています。
（ユーザーIDは、既に使用されている場合、使用できないようにしているから）
ところで、キーイベント（keydown,keypress,keyup）系は、ブラウザによって挙動が異なるので、
ちょっと厄介ですね。
http://freefielder.jp/blog/2010/11/javascript.html
今一度我々もUIについて、がっちり勉強しておきたい所です。
によるとリアルタイムの入力チェック（元記事では、「インライン・バリデーション」と呼んでいる）で、
「成功率が22%向上」とか、いい事が色々書かれている。
しかし、そんな都合のいいことばかり鵜呑みにしては行けない。
「私は昨年FXで、1,000万儲けました」という話を聞いても、それをすぐに自分に当てはめてはいけないのと同じだ。
これは、色々なタイプで調査した時のベストパフォーマンスだ。
中には「-10%」とかあったかも知れない。
そもそも入力ミスをするのは、注意事項が小さく書かれていたり、意表を付く入力を強制するからだ。
半角、全角とか、サーバ側で自動で変換すればいいじゃん、と思うことも多い。
それはさておき、インライン・バリデーションって、そんなにいいのだろうか？
確かに中にはいいのもあるが、個人的には迷惑としか思えないものも多い。
フォームのバリデーション用jQueryプラグインいろいろ+α
で、幾つか紹介されているサンプルを試してみたところ、、
例えば、入力する前から、「入力してください」と出てきたり、
まさに入力中なのに、「正しいメールアドレスの形式を入力してください」
とか、アピールされたりする。僕の場合、その瞬間フォームを閉じる。
他にも、必須項目を飛ばすと、「ここは必須です」とか表示されたりするので、
その項目に戻ると、今度は戻る前の項目で、「ここは必須です」とか表示されたりする。
エラーが、出まくりだ。
更に例えば、エラーメッセージが、表示領域を確保するために高さが変わったりすると、
まさにカクカクしまくりで、めまいがする。
リアルタイムチェックは、いつ、どこで、どのようにをしっかり考えて実装しないと、
逆にユーザーを不快にしてしまうかも知れない。
今一度、A List Apartの元記事をしっかり確認すべきだ。
この元記事では、後半で、入力チェックのタイミングについて触れている。
一番最後（3番目）の Youtube を見ると分かり易い。
・入力後
・入力中
・入力前と入力中
のタイミングのどれがいいかを検証している。
この記事の入力チェックは、Ajaxを使っているので、少し元々遅い部分はあるかも知れないが、
見ていると「入力後」のチェックが一番快適となっている。（記事でもそう結論付けています）
更にこのフォームでは、ユーザーIDとパスワードについては、
「入力中」においても、少しの時間差をおいてチェックするというこだわりを見せています。
（ユーザーIDは、既に使用されている場合、使用できないようにしているから）
ところで、キーイベント（keydown,keypress,keyup）系は、ブラウザによって挙動が異なるので、
ちょっと厄介ですね。
http://freefielder.jp/blog/2010/11/javascript.html
今一度我々もUIについて、がっちり勉強しておきたい所です。
2012年07月30日 (月) | 編集 |
つい最近楽天から出た電子書籍端末のKobo Touchは、酷評されまくりだ。
ところで、Kobo Touchには、お試し機能として、ブラウザ機能があるようです。
そのブラウザ機能を評価している人は少ないが、例えば、こちら
http://zapanet.info/blog/item/2427を見ると、「iPhoneやiPadのSafariの性能を100点としたら、kobo Touchのkoboウェブブラウザは5点くらいです。比べるのはApple製品に失礼な話でした。」
と、やはり酷評だ。
ただ、海外サイトのBroken LinksでもKobo Touchブラウザの評価をしています。
前半はやはり酷評そのもの。
そして、後半部分、HTML5のhttp://html5test.com/のテスト診断結果は、246点とあります。
ほう。
Chrome20は414、FifeFox14は330、IE9は、138。
なかなか検討しているようです。
そして、CSS3のhttp://css3test.com/のテスト診断結果は、48%とあります。
Chrome20は56%、FifeFox14は51%、IE9は、33%。
こちらもなかなか検討しているようです。
そして、私なりに勝手にまとめさせていただくと、ブラウザとしての可能性（ポテンシャル）はあるけど、
端末自体ががダメダメなので、結果的にダメダメ、という感じでしょうか。
ところで、Kobo Touchには、お試し機能として、ブラウザ機能があるようです。
そのブラウザ機能を評価している人は少ないが、例えば、こちら
http://zapanet.info/blog/item/2427を見ると、「iPhoneやiPadのSafariの性能を100点としたら、kobo Touchのkoboウェブブラウザは5点くらいです。比べるのはApple製品に失礼な話でした。」
と、やはり酷評だ。
ただ、海外サイトのBroken LinksでもKobo Touchブラウザの評価をしています。
前半はやはり酷評そのもの。
そして、後半部分、HTML5のhttp://html5test.com/のテスト診断結果は、246点とあります。
ほう。
Chrome20は414、FifeFox14は330、IE9は、138。
なかなか検討しているようです。
そして、CSS3のhttp://css3test.com/のテスト診断結果は、48%とあります。
Chrome20は56%、FifeFox14は51%、IE9は、33%。
こちらもなかなか検討しているようです。
そして、私なりに勝手にまとめさせていただくと、ブラウザとしての可能性（ポテンシャル）はあるけど、
端末自体ががダメダメなので、結果的にダメダメ、という感じでしょうか。
2012年07月27日 (金) | 編集 |
W3CとWHATWGについてはご存知だと思うが、
W3Cは、昔からWEBに関する技術の標準化を図る団体である。
一方、WHATWGは、W3CのWorking Groupが学術的観点からの仕様策定、
現実から離れた仕様策定、そして、ダメダメな企画ばかりを作っているのに業を煮やし、
ブラウザベンダのApple、Mozilla、Operaによって2004年に設立されたコミュニティーである。
以前は、W3CのWorking Groupは、XHTML 2.0 の仕様の作成を進めていたが、
これは現実路線に合ってないため、今はお蔵入りしている。
さて、問題のWHATWGの名前だが、正式名称は、
「Web Hypertext Application Technology Working Group」だ。
最後の「Working Group」は分かるにしても、
「Web Hypertext Application Technology」って、何？と思う。
それぞれの単語の意味は分かるが、全体としては、やや強引な名前だ。
つまりこれは、こういうことだろう。
その昔、WHATWGを作る前、W3Cに対してブラウザベンダは、イライラしていた。
「全く！W3CのWorking Groupって、一体何だよ？」「Working Groupってどうよ？」
そんな会話が交わされたに違いない。
英語に訳せば、「What's Working Group ?」
そして、「What's Working Group ?」と言っていたブラウザベンダにより作られたのが、
WHAT WG、つまり「WHATWG」という訳だ。
正式名称は、後付けだろう。
以上、私の勝手な想像（解釈）です。
ここら辺の歴史については、「入門 HTML5」に詳しく書かれています。
参考URL
http://www.atmarkit.co.jp/news/200801/25/html.html
http://www.atmarkit.co.jp/news/analysis/201001/19/w3c.html
「入門 HTML5」
W3Cは、昔からWEBに関する技術の標準化を図る団体である。
一方、WHATWGは、W3CのWorking Groupが学術的観点からの仕様策定、
現実から離れた仕様策定、そして、ダメダメな企画ばかりを作っているのに業を煮やし、
ブラウザベンダのApple、Mozilla、Operaによって2004年に設立されたコミュニティーである。
以前は、W3CのWorking Groupは、XHTML 2.0 の仕様の作成を進めていたが、
これは現実路線に合ってないため、今はお蔵入りしている。
さて、問題のWHATWGの名前だが、正式名称は、
「Web Hypertext Application Technology Working Group」だ。
最後の「Working Group」は分かるにしても、
「Web Hypertext Application Technology」って、何？と思う。
それぞれの単語の意味は分かるが、全体としては、やや強引な名前だ。
つまりこれは、こういうことだろう。
その昔、WHATWGを作る前、W3Cに対してブラウザベンダは、イライラしていた。
「全く！W3CのWorking Groupって、一体何だよ？」「Working Groupってどうよ？」
そんな会話が交わされたに違いない。
英語に訳せば、「What's Working Group ?」
そして、「What's Working Group ?」と言っていたブラウザベンダにより作られたのが、
WHAT WG、つまり「WHATWG」という訳だ。
正式名称は、後付けだろう。
以上、私の勝手な想像（解釈）です。
ここら辺の歴史については、「入門 HTML5」に詳しく書かれています。
参考URL
http://www.atmarkit.co.jp/news/200801/25/html.html
http://www.atmarkit.co.jp/news/analysis/201001/19/w3c.html
「入門 HTML5」
| Amazon.co.jp （和書） | Amazon.com （洋書） |
  |   |
2012年07月26日 (木) | 編集 |
こちらに紹介されている「Adaptive Images」と呼ばれるものを使ってみた。
http://coliss.com/articles/build-websites/operation/work/js-and-php-adaptive-images.html
「導入も簡単で、5分くらい」とあったので、意気込んでやってみたが、早速つまづいた。（笑
以下、注意事項を3点ばかり。
【注意事項1 … ブラウザサイズの判定では無い】
Responsive Webでは、ブラウザのサイズで表示が変化するのが一般的だ。
なのでその調子でブラウザの横幅を変えてみたが、いっこうに画像が変化する様子が無い。
.htaccessに問題があるのか？と思い調べているうちに、5分が経過する。
しかし、よくよく見て分かったが、HTMLに書き込むJSが、
screen.width,screen.heightのようになっている。
つまり、ブラウザのサイズではなく、ディスプレイのサイズで変化するのだ。
Responsive Webに慣れていると、調子を狂わされるかも知れません。
（もっとも、JSは自分好みにカスタマイズできますが）
【注意事項2 … JSの記述は最上位箇所で】
ドキュメントに書いてあるのでそのままですが、
一番最初のアクセスでは、クッキーを書き込む前に画像を取りに行ってしまうことがあり得るとのこと。
たとえ、imgタグより前に記述していても。
このクッキーを元にPHPがデバイスサイズを判定して、適切な画像を返すのだ。
なので、headタグ内で、他のJSを読み込むより前にこのおまじないJSを書けとの事。
外部ファイル化もするな、との事。
それでもクッキーが設定されていない場合は、このPHPファイルは、User agentから判定して、
PCの時は、最大の画像、スマホの場合は、最小の画像を返すようになっています。
【注意事項3 … 更新日でキャッシュをクリア】
問題になるケースは稀だと思うが、設定の$watch_cacheが有効（TRUE）な場合（デフォルトTRUE）、
キャッシュされた画像が最新かどうかは、実際の画像ファイルと更新時刻を比較して判断される。
実際の画像ファイルの更新時刻がキャッシュよりも新しければ、キャッシュも入れ替わる訳だ。
しかし、ファイルの管理の仕方によっては、画像ファイルを入れ替えたとしても、100%更新時刻も新しくなるとは限らない。
そうすると、いつまで経っても画像が入れ替わらないことになる。
しかもキャッシュ画像は、www権限で作成されるので、FTP権限ではキャッシュを削除できなくて、
少しパニクることもある。（私がそうだった…）
以上。
ところで、これだと画像に、width="" height="" とか基本的に指定できないですね。
ブラウザ的には、レンダリングがカクカクして不自然にならないか心配です。
http://coliss.com/articles/build-websites/operation/work/js-and-php-adaptive-images.html
「導入も簡単で、5分くらい」とあったので、意気込んでやってみたが、早速つまづいた。（笑
以下、注意事項を3点ばかり。
【注意事項1 … ブラウザサイズの判定では無い】
Responsive Webでは、ブラウザのサイズで表示が変化するのが一般的だ。
なのでその調子でブラウザの横幅を変えてみたが、いっこうに画像が変化する様子が無い。
.htaccessに問題があるのか？と思い調べているうちに、5分が経過する。
しかし、よくよく見て分かったが、HTMLに書き込むJSが、
screen.width,screen.heightのようになっている。
つまり、ブラウザのサイズではなく、ディスプレイのサイズで変化するのだ。
Responsive Webに慣れていると、調子を狂わされるかも知れません。
（もっとも、JSは自分好みにカスタマイズできますが）
【注意事項2 … JSの記述は最上位箇所で】
ドキュメントに書いてあるのでそのままですが、
一番最初のアクセスでは、クッキーを書き込む前に画像を取りに行ってしまうことがあり得るとのこと。
たとえ、imgタグより前に記述していても。
このクッキーを元にPHPがデバイスサイズを判定して、適切な画像を返すのだ。
なので、headタグ内で、他のJSを読み込むより前にこのおまじないJSを書けとの事。
外部ファイル化もするな、との事。
それでもクッキーが設定されていない場合は、このPHPファイルは、User agentから判定して、
PCの時は、最大の画像、スマホの場合は、最小の画像を返すようになっています。
【注意事項3 … 更新日でキャッシュをクリア】
問題になるケースは稀だと思うが、設定の$watch_cacheが有効（TRUE）な場合（デフォルトTRUE）、
キャッシュされた画像が最新かどうかは、実際の画像ファイルと更新時刻を比較して判断される。
実際の画像ファイルの更新時刻がキャッシュよりも新しければ、キャッシュも入れ替わる訳だ。
しかし、ファイルの管理の仕方によっては、画像ファイルを入れ替えたとしても、100%更新時刻も新しくなるとは限らない。
そうすると、いつまで経っても画像が入れ替わらないことになる。
しかもキャッシュ画像は、www権限で作成されるので、FTP権限ではキャッシュを削除できなくて、
少しパニクることもある。（私がそうだった…）
以上。
ところで、これだと画像に、width="" height="" とか基本的に指定できないですね。
ブラウザ的には、レンダリングがカクカクして不自然にならないか心配です。
2012年07月26日 (木) | 編集 |
JavaScriptに、Event Delegation（イベント委譲）と呼ばれるパターン（テクニック）がある。
例えば、
<div id="click-wrap">
<button>ボタンA</button>
<button>ボタンB</button>
<button>ボタンC</button>
</div>
この場合において、1つ1つのボタンにイベントを割り当てるのではなく、
その親要素である<div>の方にイベントを割り当て、
イベントのbubblingを利用して、親のイベント上で子供をフィルタリングをしつつ、
必要な処理を施すという手法だ。
この手法であれば子供が仮に1000個あったとしても、設定するイベントは1つだけで済む。
イベントの設定というのは、onload（又はDOMContentReady）の時に設定されるが、
そのタイミングは、ブラウザにとっては忙しい時間帯であるし、
割り当てにはCPUも食うし、割り当てたイベントをトラッキングするため、メモリも食う。
おまけに、せっかくイベントを割り当てても、それらが使われるとは限らない。使われても数個とか。
1000個が1個で済むなら、遥かに軽くなる。
下記の2冊の良書にEvent Delegationは、詳しく書かれているが、
親に割り当てるイベントのポイント部分を紹介しておくと、こんな感じになる。
もっぱらjQueryの人には、何だか分からないかも知れない…。
さて、jQueryには、このEvent Delegationを簡単に設定できるAPIがある。
それは、.delegate()だ。（そのままだ）
そして、Ver1.7からは、今までのイベント関係が統合された.on()が導入された。
そのため、今後は、.delegate()ではなく、.on()を使うべきだ。
（が、まだあまり普及していないようにもみえる…）
上記で書いたサンプルの場合、こんな風に書いてやればいいことになる。
ついでに、本家APIドキュメントにも書かれているが、この親子（先祖子孫）の関係を必要以上に離している場合は、パフォーマンスが劣化するのでやらないように。
$(document).on() とかは、なるべく避けるようにということですね。
参考書籍
「ハイパフォーマンスJavaScript」
「JavaScriptパターン ―優れたアプリケーションのための作法」
例えば、
<div id="click-wrap">
<button>ボタンA</button>
<button>ボタンB</button>
<button>ボタンC</button>
</div>
この場合において、1つ1つのボタンにイベントを割り当てるのではなく、
その親要素である<div>の方にイベントを割り当て、
イベントのbubblingを利用して、親のイベント上で子供をフィルタリングをしつつ、
必要な処理を施すという手法だ。
この手法であれば子供が仮に1000個あったとしても、設定するイベントは1つだけで済む。
イベントの設定というのは、onload（又はDOMContentReady）の時に設定されるが、
そのタイミングは、ブラウザにとっては忙しい時間帯であるし、
割り当てにはCPUも食うし、割り当てたイベントをトラッキングするため、メモリも食う。
おまけに、せっかくイベントを割り当てても、それらが使われるとは限らない。使われても数個とか。
1000個が1個で済むなら、遥かに軽くなる。
下記の2冊の良書にEvent Delegationは、詳しく書かれているが、
親に割り当てるイベントのポイント部分を紹介しておくと、こんな感じになる。
もっぱらjQueryの人には、何だか分からないかも知れない…。
さて、jQueryには、このEvent Delegationを簡単に設定できるAPIがある。
それは、.delegate()だ。（そのままだ）
そして、Ver1.7からは、今までのイベント関係が統合された.on()が導入された。
そのため、今後は、.delegate()ではなく、.on()を使うべきだ。
（が、まだあまり普及していないようにもみえる…）
上記で書いたサンプルの場合、こんな風に書いてやればいいことになる。
ついでに、本家APIドキュメントにも書かれているが、この親子（先祖子孫）の関係を必要以上に離している場合は、パフォーマンスが劣化するのでやらないように。
$(document).on() とかは、なるべく避けるようにということですね。
参考書籍
「ハイパフォーマンスJavaScript」
| Amazon.co.jp （和書） | Amazon.com （洋書） |
  |   |
「JavaScriptパターン ―優れたアプリケーションのための作法」
| Amazon.co.jp （和書） | Amazon.com （洋書） |
  |   |
2012年07月20日 (金) | 編集 |
意外と知られていないかも知れないFacebookの「いいね！」ボタンについてです。
予め整理しておきますが、Facebookページ（旧ファンページ）の「いいね！」ボタンの話ではなく、自分のホームページに設置する「いいね！」ボタンの話です。
「いいね！」ボタンを設置する際は、こちらからコードを取得できますが、
http://developers.facebook.com/docs/reference/plugins/like/
このページを見ていると、次のように書いてあります。
「If you include Open Graph tags on your Web page, your page becomes equivalent to a Facebook page.」
は？Facebookページと等価？になる？
「Your page will appear in the "Likes and Interests" section of the user's profile, and you have the ability to publish updates to the user.」
ほう。分かってきました。
「Open Graph Protocol」をページに仕込んでおけば、「いいね！」ボタンを押した人に対して、Facebook上で後々、色んな情報を発信（投稿）することができるのですね。
「Open Graph Protocol」は、
http://developers.facebook.com/docs/opengraphprotocol/
ここに詳しく書かれていますが、先のURLのSTEP2で取得できるようなメタタグですね。
これで、Facebookページを作らずして、自分のホームページがFacebookページのような感じになる、とのことです。
ううん、意外。でも、そこまで認識して「いいね！」ボタンを押している人は少なそうですね。
予め整理しておきますが、Facebookページ（旧ファンページ）の「いいね！」ボタンの話ではなく、自分のホームページに設置する「いいね！」ボタンの話です。
「いいね！」ボタンを設置する際は、こちらからコードを取得できますが、
http://developers.facebook.com/docs/reference/plugins/like/
このページを見ていると、次のように書いてあります。
「If you include Open Graph tags on your Web page, your page becomes equivalent to a Facebook page.」
は？Facebookページと等価？になる？
「Your page will appear in the "Likes and Interests" section of the user's profile, and you have the ability to publish updates to the user.」
ほう。分かってきました。
「Open Graph Protocol」をページに仕込んでおけば、「いいね！」ボタンを押した人に対して、Facebook上で後々、色んな情報を発信（投稿）することができるのですね。
「Open Graph Protocol」は、
http://developers.facebook.com/docs/opengraphprotocol/
ここに詳しく書かれていますが、先のURLのSTEP2で取得できるようなメタタグですね。
これで、Facebookページを作らずして、自分のホームページがFacebookページのような感じになる、とのことです。
ううん、意外。でも、そこまで認識して「いいね！」ボタンを押している人は少なそうですね。
2012年07月19日 (木) | 編集 |
「Beginning iPhone and iPad Web Apps」という本にJavaScriptイベントのcaptureとbubblingの実感しやすいサンプルが載っていたので、少し改変して載せてみた。
そもそもcaptureとbubblingが、何かというのは、JavaScript本やこちらの分かり易いサイトを参照いただくとして、下記サンプルは、addEventListenerやcaptureが無いIE8以下では対応していません（追記：IE9も動作せず…）。
最新ブラウザのデバッグ用コンソール画面（Firebugなど）でご覧ください。
● まず、captureから。HTMLは、以下。
<div class="event_capture">
<div>0<div>1<div>2<div>3<div>4<div>5</div></div></div></div></div></div>
</div>
0
1
2
3
4
5
JSは、こちら。
例えば、数字3の箇所をクリックすると、コンソールログに、
(1) 0
(1) 1
(1) 2
(2) 3
と表示されます。最初の括弧の中は、そのイベント発生時のフェーズ番号をしてしています。
1 → captureフェーズ
2 → targetフェーズ
3 → bubblingフェーズ
最後だけ、2番になりますが、後は1のcaptureフェーズですね。
括弧の後の数字は、その番号のDIVがイベントを発生していることを表しています。
● 次は、bubbling。HTMLは、以下。
<div class="event_bubbling">
<div>0<div>1<div>2<div>3<div>4<div>5</div></div></div></div></div></div>
</div>
0
1
2
3
4
5
JSは、こちら。
例えば、数字3の箇所をクリックすると、コンソールログに、
(2) 3
(3) 2
(3) 1
(3) 0
と表示されます。最初だけ、2番になりますが、後は3のbubblingフェーズですね。
● 最後におまけで、1つだけcaptureで、他はbubblingにしました。HTMLは、以下。
<div class="event_combine">
<div>0<div>1<div>2<div>3<div>4<div>5</div></div></div></div></div></div>
</div>
0
1
2
3
4
5
JSは、こちら。
div[0]だけcaptureで、後は全部bubblingにしています。
例えば、数字3の箇所をクリックすると、コンソールログに、
(1) 0
(2) 3
(3) 2
(3) 1
と表示されます。
最初に0番が表示され、そのあとは、3→2→1となりました。captureが最初に来るのが分かります。
括弧の中の数字もそのままかと思います。
以上、実感し易いサンプルでした。
ところで、bubblingは、分かり易かったのですが、当初なぜcapture（or capturing）が、そのような名前なのか良く分かりませんでした。
が、よくよく考えてみれば、targetに到達するよりも前にcapture（捕らえる）するから、そのような名前なのかなと思います。
参考サイト
addEventListener()の第３引数の意味とかをちゃんと理解する為のメモ
http://d.hatena.ne.jp/snaka72/20100925/1285404467
「addEventListenerの第三引数がtrueの場合は…
http://javascript.g.hatena.ne.jp/edvakf/20100219/1266572196
参考書籍
「JavaScript 第5版（or 第6版）」
| Amazon.co.jp （翻訳本） | Amazon.com （洋書） |
  |   |
「Beginning iPhone and iPad Web Apps: Scripting with HTML5, CSS3, and JavaScript」（洋書）
| Amazon.co.jp | Amazon.com |
  |   |
2012年07月17日 (火) | 編集 |
いつも混乱するので、軽くまとめてみた。
スマホ（iPhone）で文字や画像のコピペを禁止する方法、と言ってしまうと何だが、
そのような理由からでなくても、ユーザービリティが不便にならない範囲において、
不用意に出てしまうダイアログを抑制したいという場合もある。
また、スマホでアプリを作る場合などでもそうだ。
まず、テキスト部分などを長押ししている時に出てくる「COPY」ダイアログの抑制方法。（画像1）
これは、以下のCSSで解決。
*:not(input):not(textarea):not(select),
input[type=image],
input[type=file],
input[type=submit],
input[type=button],
input[type=reset] {
-webkit-user-select: none;
}
画像1
注意されたいのは、テキストフィールドなどは、除外している点。
これも対象にしてしまうと、フォームで文字入力ができなくなってしまう。
次に、リンクや画像又はリンク付き画像の長押しで
下からヒョイと出てくるメニューの抑制方法。（画像A～C）
画像A … リンクの長押し
画像B … 画像の長押し
画像C … リンク付き画像の長押し
これで解決。
body {
-webkit-touch-callout: none;
}
参考書籍（洋書）
「Beginning iPhone and iPad Web Apps: Scripting with HTML5, CSS3, and JavaScript」
スマホ（iPhone）で文字や画像のコピペを禁止する方法、と言ってしまうと何だが、
そのような理由からでなくても、ユーザービリティが不便にならない範囲において、
不用意に出てしまうダイアログを抑制したいという場合もある。
また、スマホでアプリを作る場合などでもそうだ。
まず、テキスト部分などを長押ししている時に出てくる「COPY」ダイアログの抑制方法。（画像1）
これは、以下のCSSで解決。
*:not(input):not(textarea):not(select),
input[type=image],
input[type=file],
input[type=submit],
input[type=button],
input[type=reset] {
-webkit-user-select: none;
}
画像1
注意されたいのは、テキストフィールドなどは、除外している点。
これも対象にしてしまうと、フォームで文字入力ができなくなってしまう。
次に、リンクや画像又はリンク付き画像の長押しで
下からヒョイと出てくるメニューの抑制方法。（画像A～C）
画像A … リンクの長押し
画像B … 画像の長押し
画像C … リンク付き画像の長押し
これで解決。
body {
-webkit-touch-callout: none;
}
 画像A |  画像B |
 画像C |
参考書籍（洋書）
「Beginning iPhone and iPad Web Apps: Scripting with HTML5, CSS3, and JavaScript」
| Amazon.co.jp | Amazon.com |
| |
2012年07月14日 (土) | 編集 |
色んなブログで色々紹介されているが、
自分なりにシンプルにまとめてみた。個人的には、こうなる。
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="自サーバでのパス/jquery-1.7.2.min.js"><\/script>')</script>
【ポイント】
(1) GoogleのCDNを使ってjQueryを読み込む時は、マイナーバージョンまで指定する。
(2) protocol-relative URL を使うといい。
(3) CDNからjQueryが読み込めなかった場合のフォールバックを使うと更に安心。
(1) マイナーバージョン指定
マイナーバージョンまで指定しないで、1などと書いてその時の最新版を
読み込む方法だと、24時間しかキャッシュされない。
かつマイナーバージョン違いによる互換性にも問題が発生しうる。
(2) protocol-relative URL対応
各サイトのブログでは、
<script src="http://ajax.googleapis
や
<script src="https://ajax.googleapis
と、http と https が混在していてややこしい。
https://にしておけばいいのかも知れないが、ここは今時のprotocol-relativeを使って、
<script src="//ajax.googleapis
としておけば、どちらにも自動で対応し、SSL環境でのhttpとhttpsが
混在していることによるエラー表示を回避できる。
FacebookのJavaScript SDKもprotocol-relativeを使っている。
ついでに、元々デフォルトのtype="text/javascript"も省略して、スッキリさせる。
(3) フォールバック
Googleのサーバがダウンすることは、まず無いかも知れないが、万が一の対応として、
設定しておくと安心できる。
以上。
参考サイト
CDNでウェブサイトを高速化するためのまとめ
http://www.koikikukan.com/archives/2012/06/13-005555.php
Linking to jQuery: Always Reference a Specific Version
http://www.impressivewebs.com/linking-to-jquery/
自分なりにシンプルにまとめてみた。個人的には、こうなる。
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="自サーバでのパス/jquery-1.7.2.min.js"><\/script>')</script>
【ポイント】
(1) GoogleのCDNを使ってjQueryを読み込む時は、マイナーバージョンまで指定する。
(2) protocol-relative URL を使うといい。
(3) CDNからjQueryが読み込めなかった場合のフォールバックを使うと更に安心。
(1) マイナーバージョン指定
マイナーバージョンまで指定しないで、1などと書いてその時の最新版を
読み込む方法だと、24時間しかキャッシュされない。
かつマイナーバージョン違いによる互換性にも問題が発生しうる。
(2) protocol-relative URL対応
各サイトのブログでは、
<script src="http://ajax.googleapis
や
<script src="https://ajax.googleapis
と、http と https が混在していてややこしい。
https://にしておけばいいのかも知れないが、ここは今時のprotocol-relativeを使って、
<script src="//ajax.googleapis
としておけば、どちらにも自動で対応し、SSL環境でのhttpとhttpsが
混在していることによるエラー表示を回避できる。
FacebookのJavaScript SDKもprotocol-relativeを使っている。
ついでに、元々デフォルトのtype="text/javascript"も省略して、スッキリさせる。
(3) フォールバック
Googleのサーバがダウンすることは、まず無いかも知れないが、万が一の対応として、
設定しておくと安心できる。
以上。
参考サイト
CDNでウェブサイトを高速化するためのまとめ
http://www.koikikukan.com/archives/2012/06/13-005555.php
Linking to jQuery: Always Reference a Specific Version
http://www.impressivewebs.com/linking-to-jquery/
2012年07月13日 (金) | 編集 |
和書でもそれなりにjQuery Mobile本は、存在するので、あえて洋書でなくてもいいような気はしますが、上記の2冊を読み比べてみました。
「jQuery Mobile First Look」（以下、First Look）は、2011年6月に発行、一方、「jQuery Mobile Web Development Essentials」（以下、Essentials）は、2012年5月に発行されている。
ITの世界、この1年の差が大きな違いとなることがある。
では、サクッと雑感。
First Lookの方は、jQuery Mobileもまだ出たての頃というのもあるし、
やはりFirst Lookというだけあり、初心者向けです。
あえてこの本を買って読まなくても、@ITの「連載：jQuery Mobile入門」を見るという手もあります。
http://www.atmarkit.co.jp/fdotnet/chushin/jqmobile_index/index.html
一方、Essentialsの方は、基礎的な内容はもちろんカバーしつつも、ThemeRollerの解説を
しっかり行なっていたり、練習用にホテルのモバイルサイトの作成例や
簡易ノートアプリの作成、RSSリーダーの作成、更にPhoneGap Buildの解説も行なっています。
その他、なるほど！と思える内容が盛り込まれています。
なかなかお勧めできる一冊です。
「jQuery Mobile Web Development Essentials」
「jQuery Mobile First Look」（以下、First Look）は、2011年6月に発行、一方、「jQuery Mobile Web Development Essentials」（以下、Essentials）は、2012年5月に発行されている。
ITの世界、この1年の差が大きな違いとなることがある。
では、サクッと雑感。
First Lookの方は、jQuery Mobileもまだ出たての頃というのもあるし、
やはりFirst Lookというだけあり、初心者向けです。
あえてこの本を買って読まなくても、@ITの「連載：jQuery Mobile入門」を見るという手もあります。
http://www.atmarkit.co.jp/fdotnet/chushin/jqmobile_index/index.html
一方、Essentialsの方は、基礎的な内容はもちろんカバーしつつも、ThemeRollerの解説を
しっかり行なっていたり、練習用にホテルのモバイルサイトの作成例や
簡易ノートアプリの作成、RSSリーダーの作成、更にPhoneGap Buildの解説も行なっています。
その他、なるほど！と思える内容が盛り込まれています。
なかなかお勧めできる一冊です。
| Amazon.co.jp | Amazon.com |
  |   |
「jQuery Mobile Web Development Essentials」
| Amazon.co.jp | Amazon.com |
  |   |
2012年07月12日 (木) | 編集 |
初めての投稿です。
まだあまり慣れてないので、サクッとだけメモ。
元ネタは、Impressive Webs の以下の記事より。
http://www.impressivewebs.com/loading-different-jquery-version-ie6-8/
また、jQueryのブログも参照。
http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
2013年の早い段階で登場予定のjQuery2.0は、
IE 6/7/8 へのサポートは無くなります。
そこで jQueryのブログでは、IEの条件付きコメントを使って、
IEのバージョンに応じて、読み込むJSファイルを切り替える方法を紹介しています。
しかし、今日現在（2012年7月10日）、微妙に記述をミスっています。
<!--[if lt IE 9]>
<script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.0.0.js"><</script>
<!--<![endif]-->
最後の、</script>が、<</script>となってしまっています…。
さて、これを見て私も一瞬、ハッ？としてしまいましたが、
IE以外のブラウザではどうなってしまうのでしょうか？
分かる人には常識だったのかも知れませんが、
2つ目の条件は、微妙に1つ目の条件と比べ、余分なコメントみたいのが多いですね。
これは、2つ目のスクリプトは、IE9以上とIE以外のブラウザで読み込まれるのを表しています。
wikiにも書かれています。
http://ja.wikipedia.org/wiki/%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E3%82%B3%E3%83%A1%E3%83%B3%E3%83%88
しかし、一瞬見た人は戸惑いますね。
そこで、Impressive Websでは、見た目的にも分かりやすい方法を紹介しています。
<!--[if lt IE 9]>
<script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if (gte IE 9) | (!IE)]><!-->
<script src="jquery-2.0.0.js"></script>
<!--<![endif]-->
なるほど、これなら少し分かりやすいですね。
| ホーム |