jQueryサイト:v1.9によるリファレンス更新

v1.9にともなうリファレンスの更新

今週は以下のリファレンスを更新しました。今回で全ての更新作業が完了しました。

trigger(ラジオボタン/チェックボックス)

これはバグ修正に近いと思います。これまでラジオボタンやチェックボックスをtriggerでクリック
した場合は、直接クリックしたのと異なる動作をしていました。これが修正されています。
リファレンスの「メモ」に一番下にサンプルを追加しました。
→リファレンス:triggerイベント

focusとblurの実行順

v1.9以前はフォームの要素でフォーカスが移動する際、本来であれば「以前フォーカスされていた
要素のblur処理」が実行されてから「新しくフォーカスされた要素のfocus処理」を実行すべきが
逆になっていました。v1.9ではこの問題が解決されています。
focusのリファレンスの「メモ」にサンプルを追加しました。
→リファレンス:focusイベント
 
 
 

リファレンスを変更しなかった項目

バグ修正や、もともとドキュメントにない機能の変更/削除などはリファレンスに反映しません。

htmlタグとセレクタの判断方法

v1.9以前は、$()内にhtmlタグがある場合はhtml文字列と判断し、それ以外はセレクタと認識して
いました。しかしv1.9からは「<」で始まる文字列をhtmlと判定するようになりました。 →本家サイト:jQuery(htmlString) versus jQuery(selectorString)

ピリオドを含んだdata属性に対応

ピリオドはクラスを示す記号でもあるので、データ属性の名前として利用すると紛らわしいのでは?
と思うのですが、この仕様変更によって何かメリットがあるのでしょうか?。
→本家サイト:Events not fired by the .data() method; names with periods

ドキュメント上にない要素のソート

前回説明したafter、before、replaceWith、addの仕様変更はこれが原因なのでしょう。
→本家サイト:Ordering of disconnected nodes within a jQuery set

htmlコンテンツ内のスクリプトの実行

wrapメソッドやappendメソッドによってスクリプトの実行を含むhtmlコンテンツが追加されても
スクリプトを実行しなくなりました(というか実行する方が問題のような…)。
もしスクリプトを実行したい場合はgetScriptメソッドを利用してください。
→本家サイト:Loading and running scripts inside HTML content

propメソッドとattrメソッド

2つのメソッドの違いはリファレンスのpropメソッドで説明しているのですが、更新しません
でした。リファレンスで説明している使い分けを徹底するようにすれば良さそうです。
→本家サイト:.attr() versus .prop()

input要素のtype属性設定時のエラー

IE6〜9ではattrメソッドでinput要素のtype属性を設定するとエラーになっていましたが
v1.9ではエラーを無視(throw)するようになったそうです(無視しているだけなので内部的
にはエラーのままです)。というかinput要素のtype属性を変更するシチュエーションなんて
想像つきません。→本家サイト:$(“input”).attr(“type”, newValue) in oldIE

疑似イベントとしてのhover

これまではonやbind等のイベントとして”hover”を指定すると”mouseenter mouseleave”と
置き換えていたそうですが、それを廃止したそうです(そんな仕様だったとは知りませんでした)。
マウスイベントのhoverは変更無しで問題なく利用できます。
→本家サイト:“hover” pseudo-event

.selectorプロパティの非推奨化

私がリファレンスを作成したのはv1.7〜v1.8の期間だったのですが、その際に.selectorなんて
プロパティは本家サイトにありませんでした(たぶん)。なので当然リファレンスにも無いため
リファレンスの変更はありません。→本家サイト:.selector property on jQuery objects

attrメソッドの裏引数の廃止

attrメソッドにはドキュメントにない裏引数のpassがあったそうなのですが、それが廃止
になりました。そんなの知らなかったのでリファレンスには載せていません。というわけで
これによりリファレンス修正もありません。→本家サイト:jQuery.attr()

jsonでのカラの文字列の問題

これもバグ修正だと思います。これまでjsonデータを読み込む時にカラの文字列が返される
様な時も通信成功とされていましたが、カラのjsonなんて利用できないので、
失敗と判断されるようになりました。
→本家サイト:jQuery.ajax returning a JSON result of an empty string

proxyメソッドのコンテキストにfalse

これはproxyメソッドの第2引数にfalseを設定した場合の動作を変更したということだと思うの
ですが、そもそもfalseを設定する意味が分かりません。条件式を設定して、条件によって
thisを変更するような手法があるのでしょうか?だとしたらtrueの時は何が設定されるの?
理解不足のため、良いサンプルが作成できないのでリファレンスは修正していません。
→本家サイト:jQuery.proxy() context

dataメソッドによるイベントの取得

ドキュメントにない裏技でdataメソッドでイベントを取得することができていたそうですが
それが廃止されたそうです。もともとドキュメントにない技なので、これによるリファレンスの
修正はありません。→本家サイト:data(“events”)

マイナーなイベントオブジェクトの廃止

attrChange,attrName,relatedNode,srcElementのようなクロスブラウザでない
マイナーなイベントオブジェクトが削除されました。しかしevent.originalEventを利用すれば
これまで通り利用できます。これはスマートフォン特有のイベントオブジェクトにアクセスする時
にも利用します。→参考:iOS+jQuery:部分横スクロール(3)
→本家サイト:Removed properties of the Event object

ドキュメントにない引数やプロパティ,メソッドの廃止

ドキュメントにない引数やプロパティ、メソッドが廃止になりました。もともとリファレンスに
内ので更新はありません。
 
これで本家サイトの1.9アップグレードガイドに即したリファレンスの更新作業は完了です。
 
 
 

11 Responses to jQueryサイト:v1.9によるリファレンス更新

  1. こんにちは。
    下記ページに関して、少し気になったものですから、投稿いたします。
    http://www.jquerystudy.info/reference/traversing/add.html
    最下部の「v1.9での仕様変更」にある、addメソッドの動作の差を比較するための2つのサンプルが、まったく同じ結果になります(説明では「div要素の前にp要素が追加されます」と書かれていますが、どちらもdiv要素の【後】にp要素が追加されます)。

    原因は、おそらく仕様の解釈を勘違いされていると思われ、「新規に作成された要素はjQueryオブジェクトの最後に並べられます」と書かれておられる点、正確には、(新規かどうかにかかわらず)「ドキュメント順の接続ノード、その後にaddした順の非接続ノード(disconnected nodes)」という順番になります。新規でなくてもremoveなどで非接続ノードになります。
    サンプルはいずれも非接続ノードしかないので、どちらもaddした順になります。
    おそらく意図されたサンプルとしては、p要素のほうを接続ノードにする(あらかじめドキュメントに存在させる)と、仕様変更を示す結果になると思います。

    • ご連絡ありがとうございます。サンプルが同じ結果になってしまうことを確認致しました。該当箇所はすでに修正致しました。また何かありましたらご連絡ください。
      よろしくお願いいたします。
      変更箇所→v1.9での仕様変更

  2. 連続で失礼いたします。
    先ほどの件、さらに正確性を重視するなら、下記の文

    > ドキュメント内に存在しない要素に対しaddメソッドで要素を追加した場合、返されるjQueryオブジェクトの要素順がソートされるようになりました。

    は、下記のように

    > addをはじめほとんどのメソッドは常に、jQueryオブジェクトの要素順をソートして返すようになりました。

    という旨にしたほうが良いように思います(非接続ノードがあってもなくても「常に」ソートします)。

  3. 何度もしつこくてすみません…
    申し上げたように、「新規かどうかにかかわらず」常にソートされるので、この点を反映させたほうが良いように思います(むしろサンプルよりも重要かと)。

    上にも書きましたが、おそらく「新規に作成した要素」と表現されているものと、非接続ノードというものについて、勘違いして理解してしまっているように見受けられます。
    これは、たとえば以下の2つの面からも重要な点です。

    1.
    あのページには「新規要素に対し既存要素をaddした場合」と書かれているのですが、そうではなく「既存要素に対し新規要素をaddした場合」も同じように新旧で異なりますし、ようはそれらに関係ありません。
    さらに、$(”)などによって新規に作成された要素は、そのままであれば非接続ノードに含まれますが、appendToなどで接続、removeなどで切断できますから、これもまた新規かどうかは関係ないわけです(接続前のみを「新規」と表現されているのかもしれませんが、切断後も対象です)。

    見たほうが早いと思うので、下記サンプルを試してください。
    まずは単純に、すべて既存の接続ノードのみの場合です。もちろん旧バージョンでもソートされ、この場合は同じ結果になります。
    https://jsfiddle.net/tkphsq6u/
    次に、あのページの説明とは逆のケース、既存要素に対しaddした場合です。
    https://jsfiddle.net/uye4p9kp/

    繰り返しになってしまいますが、新規かどうかにかかわらず、常にソートされます。これはSizzleが変更されたためで、旧バージョンのSizzleのsort関数が「compareDocumentPositionメソッドがPOSITION_FOLLOWINGフラグ(後に位置する)を返した」場合に-1を、そうでない場合はすべて1を返していたのが、新バージョンではDISCONNECTEDフラグやDocumentFragment配下なども考慮し状況に応じて0をも返すようになりました。
    逆に言えば、これらフラグの影響を受けないなら、旧バージョンのソートでも同じ結果になります。
    既存要素を切断してみると、こうなります。
    https://jsfiddle.net/s6y2fo39/

    「○○をした場合」とか、あまり難しく考えずに、単に「jQuery.uniqueメソッドが返すもの(Sizzle.uniqueSortの戻り値)」の話ですから、言い換えれば、ほとんどのメソッドの戻り値ですね。「jQueryが保持するリスト」と言っても過言ではないでしょう。

    2.
    ご承知のとおり、昨今は特にWebアプリなどのパフォーマンスが重視され、大量の要素を追加したり移動したりなどする場合にはDocumentFragmentの使用が推奨されており、多くの有名無名フレームワークやライブラリでも(もちろんjQueryでも)使われています。
    DocumentFragment配下の要素はすべて非接続ノードですから、これもまた、新規かどうかにかかわらず、常に新仕様でソートされます。
    これを使って画面を操作するケースは非常に多いと思われ、むしろ1よりも(?)、掲載されているご説明では誤解を招いてしまうかもしれません。
    DocumentFragmentの既存要素をaddしてみると、こうなります。
    https://jsfiddle.net/f2Lhqod0/

    本当に余計なおせっかいで申し訳ありません…
    私の最初の指摘によって、さらなる誤解を招いてしまったのかも、と思い長々と説明してしまいました。

  4. ちなみに、v1.9未満でもDocument Orderにソートされるという点は、大丈夫でしょうか。
    つまり、そういえばaddの結果の並び順について本文で言及されていないので、そもそもaddした結果の並びはaddした順番ではない(v1.9未満でも)、という点を踏まえていれば、v1.9の仕様変更は非常に自然なもので、むしろ今までチェックされていなかった接続状態をチェックするようになっただけ、とも言えます。今も昔もDocument Orderが基本なのは変わりません。

    p.s.
    前の投稿、「$(‘~’)」のHTML部分が、コメントシステムによって削除されてしまったようです。

    • いいえ、こちらは大丈夫ではなかったです。なので以下の項目の追加に至りました。
      この件はaddメソッドに限らないのでチュートリアルにまとめるべき内容ですね…。
      変更箇所→HTML上の並びに従う

      >p.s.
      >前の投稿、「$(‘~’)」のHTML部分が、コメントシステムによって削除されてしまったようです。
      wordpressの管理画面では確認できましたので大丈夫でした。

  5. 図らずもダメ出しを重ねるような形になってしまい、失礼いたしました。
    偉そうに添削などする立場ではありませんが(^^;)、特に問題ないように思います。

    しいて言うなら、また別の点ですが、サンプルのremoveに関する文章で、「削除して~保存」や「削除した要素を~追加」などの表現が少し不自然な気がするのですが、どうでしょう。「削除」というと「消し去る」ようなニュアンスで、「erase」とか「delete」に近い気がします。削除されて、消えて無くなったのに保存や追加?あるいは人によっては、そもそも消えたものの並び順とか、もっと言えば消えたものがなぜリストに存在?とかが、ピンと来ないかもしれません。

    英語の「remove」は「取り除く」とか「はずす」とか「移動させる」というニュアンスだと思うのですが、実際にもremoveメソッドは「(ドキュメントから)取り除く」動作をします。「消す」ことはしません。
    ついでにサンプルを書きましたので、見てください。
    https://jsfiddle.net/54df82vb/

    あくまでも「ドキュメント上から、見えないどこかに移動した」だけで、操作もできます。その点でDocumentFragmentと同様と思えば良いかと思います。
    なので、蛇足ながら、「削除しているため~テキストを追加できないので」と書かれていますが、普通にテキスト操作できます(この場合、「テキストを追加しても見えないので」が正しいと思います)。

    まぁこのあたりは感覚的なニュアンスの話かもしれませんが…

    一応、本家のドキュメント
    http://api.jquery.com/remove/
    を見てみると、「Remove ~ from the DOM.」と書かれていました。この「from the DOM」が効いて「DOMから取り除く」と理解しやすいのではないかと思います。
    内部ではremoveChildを実行しているので、ではremoveChildのMozillaのドキュメント
    https://developer.mozilla.org/en-US/docs/Web/API/Node/removeChild
    はどうだろうとみてみると、同様に「removes ~ from the DOM.」とあり、そしてその日本語版
    https://developer.mozilla.org/ja/docs/Web/API/Node/removeChild
    では「DOM から~取り除きます。」と訳されていました。

    やはり「削除」より「取り除く」のほうが、より正確に理解されるように思いますが、いかがでしょう(removeのページも、ということになってしまいますが…)。
    例の「disconnected」との関係も、「取り除く」≒「切断する」と理解しやすいかもしれません。

    ちなみに、関連情報ですが、このremoveメソッドはじめ「disconnected」による例の影響の件ですが、ソート処理が実行される際にのみ影響があり、それ以外で状態が変化してもリストの並び順は変化せず、次にソートが行われるメソッドを呼び出した時に、初めて反映されます。
    これが、もしかしたらハマる人がいるかもしれません。
    これもサンプルを書きました。
    https://jsfiddle.net/yy37gkve/

    • ご連絡ありがとうございます。ご指摘を受けて「セレクタエンジンの仕様」の文言を微妙に変更しました。removeメソッドの「削除」と言う表現を「HTML上から外す」という表現に変更しています。
       
      この変更に合わせて、removeメソッドにも以下の文言を追加しました。
      *****
      ただし「削除」とはいっても「HTML上から外される」だけでデータとしては存在しています。メモ「削除しても存在している」にサンプルを載せています。
      *****
      削除しても存在している
       
      今後ともよろしくお願いいたします。
       
       

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


× 六 = 18


*

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>