iPhone5 と iOS6 での HTML5開発についてあれこれ
本日、iOS6がリリースされましたね。明日は iPhone5 の発売日。Mobile Safari も大幅にアップデートされて、Web開発者にとって非常に気になります。
iPhone 5 and iOS 6 for HTML5 developers, a big step forward: web inspector, new APIs and more で素晴らしいまとめがありましたので、簡単に紹介したいと思います。
iPhone5
新しい画面サイズ
新しい 4インチ画面になり、解像度は WDVGA (Wide Double VGA) 640×1136px になりました。横幅はこれまでと変わりませんが、高さが 176px 増えました。
新しいシミュレーター
Xcode4が新しくなり、iOS6のシミュレータが出ました。Mac AppStore からダウンロードできます。
何をすべきか
画面サイズに依存したWebサイト（アプリ）は注意が必要です。縦幅が足りなくなります。Google Mapsの例のように、下が切れます。
レスポンシブWebデザインを使っていても不十分です。通常RWDは横幅に対して使われますが縦には使われていません。
デバイスの検出
サーバーサイドでiPhone5を検出する方法はありません。userAgent は iOS6 としか判定できません。iOS6 の載った iPhone4/4s と区別不能です。
しかし、JavaScript か メディアクエリーを使えば判定できます。スクリーンの高さが 568px の時は 4インチディスプレイになります。
isPhone4inches = (window.screen.height==568);
また、CSSメディアクエリーとレスポンシブWebデザインのテクニックでiPhone5を判定できます。
@media (device-height: 568px) and (-webkit-min-device-pixel-ratio: 2) { /* iPhone 5 or iPod Touch 5th generation */ }
ホームスクリーンWebアプリ
ホームにWebアプリを追加すると、上下にレターボックスが表示され、今までの画面サイズと同じように表示されます。しかし、4インチに対応したWebサイト（アプリ）でもこうなってしまう問題があります。
iOS6 での HTML5
ファイル管理
ついに iOS6 の Safari でファイルアップロードをサポートしました！
input タグの fileタイプで、カメラとギャラリーから画像を選択できます。強制的にカメラにする方法はありません。しかし、accept 属性で 動画と画像の選択は出来ます。
他のファイル、オーディオ、Pagesドキュメント、PDFなどはサポートされません。getUserMedia を使ったライブストリーミングなどもサポートされません。
画像やビデオを選択した後に出来ること:
Web Audoi API
Web Audio API が モバイルブラウザに初めて乗りました。これでゲーム開発などに役立つかもしれません。
Smart App Banner
Webサイトを訪れたとき、サイトに紐付いたアプリがインストールされていなければインストールボタン、インストールされていれば View ボタンを自動で表示できるようになりました。
CSS3 Filter
CSS3 Cross-Fade
フルスクリーン Safari
iPhone、iPod（iPadは無し）で Safari をフルスクリーン表示することができます。アドレスバーやツールバーが隠れます。しかし、ランドスケープ（横）表示の時だけで、強制的にフルスクリーンにすることは出来ません。
Animation Timing API
requestAnimationFrame として知られている Animation Timing API がサポートされました。これによって setInterval をつかったダサイ描画ループは卒業ですね！
CSS Image Set
低解像度と高解像度用の画像セットをまとめて定義できます。これを使えば、メディアクエリによる切り替えをせずとも、複数の解像度向けの画像を１つで定義できます。retinaディスプレイ対応のための使用ですね。これに対する標準化グループはまだない、とのことで Apple 独自仕様のようです。
Passbook クーポンとパスの配布
Passbook は iOS の新しいアプリです。入場券、チケット、ディスカウントクーポン、ポイントカード、ギフトカードなどを全てまとめて管理します。ネイティブアプリだけでなく、Webサイトからもこのパスの発行ができます。詳しくはこちら developer.apple.com/passbook
（日本でも iPhone5 発売日から電通がなにやら仕掛けてくるそうです。これから流行るかもしれませんねー）
Storage API と WebAppの更新
相変わらず IndexedDB は使えず、特に利用可能な新しいAPIはないようです。しかし、幾つか変更点が。
- Application Cache の制限が 25Mb に増えました。（これまでは約5M）
- ホームスクリーンWebAppは独自のストレージサンドボックスを持つようになりました。
（追加する度に新しいストレージを持つようになったため、複数アプリの切り替えにはよいニュースです。Webサイトとホームの間でデータのやりとりをするには問題があります。） - ホームスクリーンWebAppのタイトルが定義できるようになりました。これまではサイトのページタイトルが使われていたのが、別名を定義できるようになりました。
また、apple-mobile-web-app-orientations という、WebAppの向きを指定できるメタタグもあるそうです。しかし、これはまだ動かないそうな。
WebView の更新
WebView の JavaScript は Safari の 3.3倍 遅い。しかし、これは SunSpider（ベンチマークツール）の結果に過ぎない。全ての機能をカバーしているわけではないし、トータル描画時間でもない。だから、WebView のアプリが 3.3倍 遅いという意味では無い。
他に幾つかよいニュースを発見しました。
リモート デバッギング
初めて、 iOS 上の Safari に公式リモート Web Inspector が追加されました。これで iWebInspector や Weinre は過去の物となりました。このリモートデバッガーはシミュレータか、USBで繋がれた実機で動きます。（実機はUSBに繋がないといけない）
リモートインスペクションを始めるためには Safari 6 for Desktop が必要です。残念なことにサポートしているのは Mac だけです。Safari for Windows は 5.x で開発が止まり、もう利用出来ません。ですので、iOS デバイスのwebデバッグができるのは Mac OS だけです。
セキュリティの理由から、最初に Web Inspector を有効にする必要があります。「Safari」→「環境設定」→「詳細」から、「メニューバーに”開発”メニューを表示」をチェックします。
次の環境でデバッグが可能です。
ネイティブアプリは、Xcodeでインストールしたアプリだけインスペクできます。（つまり自分で開発したアプリ）そのため、Google Chrome のようなものはできません。
Safari 5 や Chrome の Webkit Inspector を使っているなら、Xcode のネイティブ開発UIをベースにした Safari 6 の 完全に再デザインされたインスペクターを目にするでしょう。新しいUIを理解するまで迷うでしょう。 このインスペクターでできることは
- HTML、CSS の確認とライブ変更
- ストレージへのアクセス: クッキー、Local Storage、Session Storage、SQL Database。
- webapp のプロファイル: ネットワークリクエスト、レイアウト＆レンダリング、JavaScript、イベントのパフォーマンスレポート。パフォーマンスツールの大きな進歩です。
- DOMの検索
- 全ての警告とエラーを一カ所で確認
- worker thread の管理
- JavaScript ブレークポイントの管理、キャッチしない例外のブレーク
- コンソールへのアクセスとJavaScriptの実行
- JavaScriptコードのデバッグ
- 対象の要素をタッチしてインスペクトする
素晴らしいよApple！ 私達はこれを長い間待っていた！！
その他の小さなアップデート
- JavaScriptのパフォーマンスが 20%向上
- Google Maps が iOS6 から使えなくなる。http://maps.google.com へのアクセスは ネイティブアプリではなく、GoogleMapsのWebサイトへリダイレクトされる。そこで、ネイティブマップアプリを開く新しいURLスキーマができた。maps:?=<query> queryはまさに検索文字列か、緯度経度をいれる。ルートナビゲーションを開始するパラメータは次のようになる。maps:?saddr=<source>&daddr=<destination>
- XHR2: XMLHttpRequestProgressEvent をサポート
- input の autocomplete を公式サポート
- DOM4 の Mutation Observers を実装。WebKitMutationObserver で DOMの変更をキャッチできる。
- -webkit-transform: preserve-3d でのハードウェアアクセラレーションの廃止。パフォーマンステクニックとしてこれを使うことは止めるべきだ。
- window.selection による Selection API
- <keygen> 要素
- Canvas アップデート: createImageData の引数は1つになり、二つの関数が増えた。高解像度対応の、webkitGetImageDataHD と webkitPutImageDataHD。
- SVGプロセッサとイベントの更新
- 新しい CSS viewport が結びつけられた。 vh (viewport height), vw (viewport width) と、vmin(vw と vh の最小値)
- CSS3 Exclusions と CSS Regions が β1で利用可能だったが、最終バージョンで削除された。
- iCloud タブ。Mac、iPhone、iPadでタブを同期することが出来る。そのため同じURLが全てのデバイスへ配布される。モバイルWebのアーキテクチャに気をつける必要がある。
以上、 iPhone 5 and iOS 6 for HTML5 developers, a big step forward: web inspector, new APIs and more の紹介でした！あとちょっと、「まだ待っているもの」、「最後に」と続きますが、そこは割愛。気になる方は是非原文を読んで下さい。かなり意訳＆はしょったところもありますので、ご指摘＆コメント歓迎です。
個人的に今回の目玉はやはり リモートWebインスペクターに限りますね！特にプロファイラとブレークポイントが泣けるほど嬉しい！これを切望したWeb開発者も大勢いると思います。
これで開発環境も充実してきたし、ますますWebアプリが盛り上がっていくとおもしろいなー、と思う次第でありました。
HTML5 x Touch UI の UXを考える（補足）
昨日、ありえるえりあミニ勉強会#3 ～Sencha Touch で、「HTML5 x Touch UI の UXを考える」 を発表しました。 発表資料は こちら HTML5 × Touch UI の UX を考える
川野さんの「Sencha Touch - カスタムコンポーネントを作るためにおさえておきたい 10 のステップ」、森本さんの「About Sencha Architect」も非常に面白く、勉強になりました！Sencha 使ってない方でも勉強になるかと思いますので、ぜひ次回でも覗いてみて下さい！
そして、懇親会も楽しかった！まさかみんな Sublime Text 2 ユーザーになっているとはｗ 他にも Inkpod（Desktop版） を使ったことあるという方もいてびっくり！色々と刺激を受けることが出来ました。
帰って Ust で自分の発表見直してみたら、やたらと咳払いが多いですね。。。あと、ちょこちょこ移動したせいで音声が聞こえないところもチラホラ。せっかくマイク用意してもらったのに。。等々 お聞き苦しいところも多々有り申し訳ないです（−−； 今後改善したいと思います。
さて、このEntryでは、資料では書ききれなかった点、こぼれ話なんかを補足したいと思います。
Touch Position (p.5)
Nikkei BP さんの記事 iPhone/iPadに込められた「見えないデザイン」を参考にさせて頂きました。この話は、あくまで特許から実装されている機能を予測する、というもので、実際にはどうなのか検証された方もいました。日経BP『iPhone/iPadには”見えないデザイン”が込められてる』記事がホントかどうか検証してみた（エミュレータ編）
少なくともエミュレータでは6角形ではないようです。ただ、当たり判定についてはやはり動的に変わっているように見えます。iPhoneでソフトウェアキーボードを英語で表示して、「S」キー（少し左寄り）を連打すると、「Sa」と入力されます。Xperiaなどではキーピッチが見た目自体可変でしたけど、iPhoneは内部的に可変の可能性が十分にあると思います。
また、iOSでは押した場所（実際にタッチされた箇所）よりも確実に、少し上が認識されます。指で普通に使う分にはむしろ自然に狙った位置がポイントされます。タッチペンをつかってもあまり違和感を感じません。しかし、タッチペンを垂直に立てるなどすると、上向きにずれているのがよく分かります。逆さにしても同様。ボタンがタッチにしにくくなるのがわかります。
これは斜めに画面にタッチすることを想定し、指（またはペン）の軸の延長線上をタッチポイントとしたほうが自然と感じるのだと思われます。HW的なタッチエリアの楕円形状や扁平率から、傾きを検知し、ずらす量を調整、までしていればすごいんだけど、そこまではやっていないようです。
なお、Android（2.3，3.0，4.0で検証）ではこの上方向への補正は感じられません。恐らくAppleの特許が影響しているのではないかと思います。
Touch Feedback (p.6)
視覚フィードバックの他に、バイブレーションを使う方法もあります。Androidなんかでは結構使われています。iOS で使われていないのは特許のせいかポリシーかは分かりません。
Webで使うには、Vibration API というのが現在仕様策定中です。以下のように使えるようです。
navigator.vibrate(1000);
ただ、2012/07/27現在、これが使えるのは Firefox Aurora Preview（Android 4.0以上）のみだとのことです。
Touch Event Specification (p.8)
jQuery の中の人のBlog jQuery Blog: GETTING TOUCHY ABOUT PATENTS で、タッチイベントの歴史、現在の状況、将来、について非常に良くまとめられています。MSPointerが技術的には将来有望だとみている点など、興味深い話です。
Touch Event Interface (p.10)
W3Cの仕様で最後の Editor's Draft で大変興味深い仕様がありました。
Touch Events version 2 W3C Editor's Draft 14 November 2011
TouchEvent に radiusX, radiusY, rotationAngle というプロパティがあります。これは、タッチした範囲の楕円半径と、その傾き角度。つまり、タッチエリアのrawデータがとれるということです。
これが使えれば、上述の指の傾きを検知してずらす量を調整などもアプリ側でできるかもしれない。是非とも仕様に入れて欲しい！
TouchEvent のはまり所
touchEvent ではまりそうな所を2点。
touchEvent は現在タッチされているポイントを、touches、changedTouches, targetTouches というプロパティとして持っています。touches はすべてのタッチ、changedTouches は変更があった点、targetTouches はその要素上のタッチの配列として取得できます。
注意するのは、toucheend イベントの時、touches は空になっている、という事です。既に指が離れたため、現在タッチしている点は無いよ、ということなのだと思います。そのため、離れたタッチを取得するには changedTouches を使用します。
二つ目は、 2本以上で同時にタッチした時、touchstart イベントが1回の場合と2回発生する場合がある。ということ。
完全に同時にタッチしたときはtouchstart イベントは1回だけ発生し、changedTouchesに二つのタッチが入ります。わずかでもタイミングがずれると、touchstart イベントは2回発生し、それぞれ changedTouches に 1つずつ入ります。
なので、マルチタッチ操作を実装する場合、どちらでも動くように対応する必要があります。
GestureEvent (p.11)
ジェスチャーイベントの発生順序は少し癖があるため、注意が必要です。
GestureEvent Class Reference に詳しくありますが、タッチイベントとジェスチャーイベントの発生順序は以下のようになっています。
- touchstart: 1本目の指がタッチ。
- gesturestart: 2本目の指が触れると gesturestart が発生。
- touchstart: 2本目の指のタッチイベント
- gesturechange: 指を離さず、動かしたときに発生
- touchmove: 動いた指のタッチイベント
- gestureend: 2本目の指が離れたら（指が残り1本になったら）発生
- touchend: 2本目の指が離れたタッチイベント
- touchend: 最後の指が離れたタッチイベント
GestureEvent は touches プロパティをもっていません。そのため、タッチポイントを取りたいときは、TouchEvent で取得したものを保持しておく必要があります。
しかし、上記の順序 2. で、まだ2本目の指の touchstart イベントが来る前に、先にジェスチャーイベントが発生します。このとき、まだ touches は 1 つしかないのため、2つのTouchを取得できません。
User action event restrictions (p.21)
私が勝手に命名しました(^^;
キーボードが出ない理由にはついては不明ですが、動画の再生については Apple から説明があります。
- Safari HTML5 Audio and Video Guide: Audio and Video HTML
- 参考: iPhone Safariだとaudio/videoタグのautoplay, autobuffer属性が効かない
携帯が従量課金とかの可能性があるから、autoplayとautobufferは無効にしてるよ。ユーザが意図して再生を開始するまで、データはロードされないよ。
ということだそうです。
ちなみに、Sencha Touch (1.1の場合) でこれらを操作するために、ちょっとした裏技があります。Sencha Touch では通常ブラウザが出すクリックイベントは抑止して出ないようになっていますが、以下のコードをアプリ起動前に設定することで、デフォルトのクリックイベントを抑止しません。
Ext.gesture.Manager.defaultPreventedMouseEvents = [];
これを設定すると、ブラウザが出すクリックイベントと、Sencah Touch がエミュレートしたものと2個発生します。Sencha Touch がエミュレートしたクリックイベントは isSimulated フラグが true になるので、それでどちらか判断できます。
ブラウザが出す clickイベントの方で、これらの制限機能を使うことができるようになります。
Scroller (p.22)
iScroll は素晴らしいのですが、全画面でのスクロールのみになってしまいます。App Storeのサムネイルみたいに、部分的にスクロール対応したい時もあります。そういう時は以下のjQueryプラグインが便利です。
flickGal・・・iPhoneでフリックギャラリーを簡単に実装できるjQueryプラグインです
ただ、惜しいかな縦/横スクロールのロックがありません。そこで、githubで公開されているものをフォークして、スクロール方向ロックオプションを付けたものをアップしました。
https://github.com/dsuket/flickGal
lockDirection を true にすると、 scrollMargin 分動くまでスクロールを待機し、動き出した後はその方向でロックします。
HTML5 × Touch UI の UX を考える
今日、 ありえるえりあミニ勉強会#3 ～Sencha Touch で 「HTML5 x Touch UI の UXを考える」というタイトルで発表してきます。
その資料がとりあえず出来たので、一足お先に こちらで公開します。
Webアプリの Touch UI で UX を実現するために、ということで Touch UI の概要や課題、Touch API の仕様と現状、そしてUX実現のポイントなどについて書いてみました。ちなみに、Touch API は HTML5ではないのでタイトルに偽りありです(^^; すみません。。
ちょっと詰め込みすぎた感はありますが、まだまだ書ききれないことも沢山。
後日、当日の様子と補足記事なんかもアップできればと思います。
2012/10/18 追記
@ITで記事になりました！
最近のMVCとJavaScriptのMVCについて まとめ
ここ最近のWebアプリの進化に伴い、ネイティブアプリ並のUIを持ったWebアプリへの期待が高まっています。jQueryなんかで簡単にDOMを操作できるようになりましたが、ある程度の規模のアプリを作ろうとすると jQuery だけでは厳しいものがあります。
そこで、JavaScript でも MVCパターンを適用し、モデルとビューの分離して、開発・保守しやすい設計にする、という流れになってきています。MVCは、元々は Smalltalk で GUI アプリを作るときの設計指針として考えられました。デザインパターンの一つでもありますが、Singleton や Observer といった GoFのデザインパターンよりも抽象度の高い、ソフトウェアアーキテクチャです。
そして時は流れ、Webの時代になると Strutsなどで代表されるWeb3層モデルとして、Webアプリの設計パターンとして一世を風靡しました。そして今、クライアントサイドのWebアプリへの適用として、再度GUI向けのMVCが脚光を浴びています。
Webの時代でもMVCパターンはWebだけに使われていたわけではありません。GUIアプリを作るためのMVCについて色々と議論が進んでいました。
モデルとビューを分離しコントローラーで制御するという古典的MVC、ドメインモデルにビューに関するロジックを埋め込んだプレゼンテーションモデルを使うPM（Presentation Model）、PMの派生でビューモデルをビューとデータバインドするMVVM（Model, View, ViewModel）、ビューでユーザの入力を受け、プレゼンタに渡し、プレゼンタがモデルを更新するMVP（Model, View, Presenter）など、様々な派生パターンがあります。（参考: 開発者が知っておくべき、6つのUIアーキテクチャ・パターン）
他にも大規模MVCを分割するパターンとして、階層的MVCとしてのRecursiveMVC、エージェントをいう塊にして他のエージェントと連携して階層をつくるPAC（Presentation, Control, Abstraction）などがあります。（参考: PACについてのまとめ http://hamamuratakuo.blog61.fc2.com/blog-entry-432.html）
こういったパターンを、JavaScriptで簡単に使えるようにしたフレームワークが沢山できています。Backbone.js、Spine.js、Ember.js、javascriptMVC、AngularJS、...etc。（参考: JavaScriptのMVCフレームワークと仲間たち）
これらは同じMVCパターンを実現しているのだけれど、それぞれの解釈で、それぞれ異なる使い方になっていることが非常に面白い。例えばコントローラーの責務についても、Backbone.js ではurlハッシュのルーティングを行うのが主目的で、Spine.js では モデルのイベントをビューにバインドするもの、Ember.js は モデルをラップして操作する、といったようになっている。
なお、これらの色々なMVCフレームワークでTodoアプリを実装したサンプルが TodoMVC にあります。同じアプリを別のフレームワークで作るとどうなるか大変参考になります。
今後、クライアントサイドWebアプリがますます注目され、このような設計、フレームワークの重要性が増していくでしょう。MVC is dead なんて話が最近盛り上がりましたね。まだまだ良い設計パターンが出てくるでしょう。特に個人的に気になるのが、規模が大きくなったときに、どう設計するのが良いのか。ベストプラクティスが溜まることを期待しています。
JavaScript の Array.forEach vs jQuery.each vs Ext.each
前回の JS ArrayのforEach, filter, map の速度を調べてみた。 に引き続き、Sencha Touch の Ext.each や、iPhone, iPad でどうなのかを比較してみました。
結果はこちらに → forEach 速度比較: jQuery、Senchaのブラウザ毎の差異
Macでは遅かった ネイティブ forEach がモバイルでは早い結果となりました。また、Mac Chrome では一番早かった Sencha は、モバイルではちょっと遅いですね。そんな中 jQuery は安定した速度です。
100万回ループでの結果ですので、通常ならそんな問題にならないレベルだと思いますが、パフォーマンスが厳しいときに参考になるかも。
Sublime Text 2 の チートシートを開くショートカット
ここのところ Sublime Text ２ というエディタにはまっている。
なかなか使い勝手が良くて重宝しているのだけれども、新しいエディタはキーボードショートカットがなかなか覚えられない。
調べてみるとPDFのチートシートは見つかった。 Sublime-Text-Cheat-Sheet
が、ショートカットキー一発で表示してくれると嬉しいのだけどなぁ。
そこで Open-Browser-SublimeText2-Plugin というブラウザで任意のページ開くプラグインを見つけた。けど、これは基本的に検索エンジンへ投げることを想定していて、文字列を選択していないといけないとか、パラメータが必要とか制限があったので、forkして修正してみた。
Readme の Other Examples に書いたのが チートシートを開く設定です。
本家へ Pull Request は出しておいたけど、取り込まれるかわからないので、それまでは自分でコードを書き換えるといいかも。
追記: 本家へ取り込まれたようです。package managerでインストールするとそのまま入ります〜
JS ArrayのforEach, filter, map の速度を調べてみた。
最近のモダンブラウザのJS実装には、Array#forEach や filter, map などがビルトインされている。
jQuery とかの each使うより、ネイティブ実装のほうが早そう。しかし forEach、filter、map の速度に違いがあるのかちょと気になったので実験してみた。
環境は Mac OS X 10.7.4, MacBook Air（Late 2010）
2012/06/22 追記: −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Sencha Touch, iPad等を追加しました → JavaScript の Array.forEach vs jQuery.each vs Ext.each
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
100万個の配列にたいして、forEach と filter、map を実行して速度を比較した。コールバックの中身は同じ。それを10回やって、平均取ったのが以下の表。
Google Chrome 19.0.1084.56
| # | forEach | filter | map | jQuery |
|---|---|---|---|---|
| 1 | 365 | 350 | 258 | 59 |
| 2 | 123 | 106 | 335 | 62 |
| 3 | 192 | 105 | 351 | 62 |
| 4 | 187 | 107 | 561 | 66 |
| 5 | 181 | 101 | 325 | 94 |
| 6 | 175 | 101 | 323 | 68 |
| 7 | 186 | 100 | 324 | 62 |
| 8 | 178 | 99 | 322 | 66 |
| 9 | 178 | 108 | 354 | 57 |
| 10 | 234 | 115 | 362 | 58 |
Safari 5.1.7 (7534.57.2)
| # | forEach | filter | map | jQuery |
| 1 | 53 | 52 | 60 | 42 |
| 2 | 52 | 47 | 63 | 62 |
| 3 | 56 | 48 | 204 | 47 |
| 4 | 53 | 48 | 79 | 71 |
| 5 | 64 | 48 | 63 | 115 |
| 6 | 52 | 46 | 59 | 49 |
| 7 | 64 | 46 | 62 | 43 |
| 8 | 52 | 45 | 59 | 42 |
| 9 | 51 | 44 | 59 | 46 |
| 10 | 62 | 47 | 187 | 55 |
Safari はえーーー！！
jQuery.each はえーーーー！！！
jQuery はどちらのブラウザも早いですね。ネイティブのほうが早いと思い込んでいたけど、Chrome のネイティブ forEach はだめですね。。初回 forEach はなぜか必ず遅くなります。Safari ではそんなことない。
forEach と filter の比較をしようと思っていたんだけど、jQuery.each が早すぎて、もうこれでいいじゃんという予想外の結果に。
ネイティブをも凌駕するとは jQuery 恐ろしい子･･･
