>>700
天才は現在のDOMを意識なんかしてねーよ
その時点でずれてるんだな。

天才っていうほどでもないが普通は
DOMが変化しても柔軟に対応できるように作る

idやclassや属性を使うことで、実際のDOMが
変わったとしてもコードはそのままで動くようにする

それは作業分担にもつながる。DOM（HTML）を書くのは
ほかの人に任せることができる。同様にCSSもだな
仮想DOMを使うとプログラマがHTML相当のものを書かなければいけなくなる。

自分の担当の部分に集中できる仕組みにするのが常識だと思ってる俺に
なに？天才はありとあらゆることを把握してる？ アホかｗ
前提が間違ってるんだわ。

あらゆることを把握するのが無理だから仮想DOMが必要だって思ってるようだが
こっちはあらゆることを把握しなくていいから仮想DOMは不要だって言ってるんだよ

> idやclassや属性を使うことで、実際のDOMが変わったとしてもコードはそのままで動くようにする

そうなってないコード山ほどあるよね？
理由は出来ないやつ気にもしないやつがたくさんいるから。

できないやつは何を使ってもできないだろ
人間の問題は技術の話の対象外だ

程度と言うものがあるだろ。
DOM直接操作に比べて仮想dom使ってるライブラリは簡単だよ。
だって宣言的に書くだけで操作しなくていいんだもの。
diffしてパッチ作って実domに反映はライブラリがやってくれる。
だからバカにウケてる。
カップ麺が低所得者層にウケるのと同じ。

それを言うならHTMLを書くだけで
画面にレンダリングされるが？
プログラム一切不要

Reactの良さはDOMからセマンティクスやなんやかんや
とにかくレンダリングに必須でない部分を削ぎ落としたスマートな仮想DOMを提供してくれることで
もっと言えばDOMから離れたReact Nativeとかその逆輸入版のReact Native for Webが良さを体現してる

で、>>693

> もっと言えばDOMから離れたReact Nativeとかその逆輸入版のReact Native for Webが良さを体現してる

俺に言わせれば、それらが、世界に多数存在するウェブサイトに
どう適用できるの？って感じだけどな

Reactは完全にオーバースペックなんだわ

>>708
そもそも既存のWebサイトに適応するようなものではないということ
出発点が違うからオーバースペックとかいう話にはならない

嫁さんがちゃんとご飯作ってくれてるのにわざわざカップ麺買ってきていつ食べるか悩んでるようなもの。
でも独身には人気。そういうこと。

よく分からんけど、画面側とか作ってくれる人が別にいるのに
自分一人で画面も何もかも作っていた人にとっては
Reactは便利ってことかな？

スレ違い

俺の嫁さんは２日に１回は平気でインスタントを晩飯として食わせるぞ

じゃあこっちに書けクズ

クズじゃないのでこっちにもかかない

jQueryがHTMLエスケープ用のメソッドを用意していない理由は何ですか？
あほなのでしょうか？

あほはお前。
http://semooh.jp/jquery/api/attributes/text/val/

>>717
textってHTMLエスケープされるんですね
というか当然ですね・・
半角スペースが に置き換わらないのでしないのかと勘違いしましたが
スペースはHTMLエスケープに含まれなかったです

半角スペースとnbspは別物だからな
nbspは何の略かしってるか？ non-breaking space、自動改行しないスペースだ
半角スペース（英単語の区切り）では一行に収まらなければ改行するが
nbspだと自動改行しない。別物だ。エスケープじゃねぇ

>>719
まさに望まない場所で改行されることに困って置換したのですが
「自動改行しないスペース」の意味だとは気づきませんでした
ありがとうございました

blurイベントはデレゲートできませんでした
おそらくバブリングしないからだと思います
バブリングしないイベントは全てデレゲートできないと考えていいのでしょうか？

特定のページにアクセすしたときに
<div class="contents">
...
</div>
の中だけ表示ってできますか？

特定の要素だけ非表示ってのはできるみたいなんですけど

a:not(:target) じゃねぇの？ jQueryというよりセレクタの話

>>725
効かないようですが、記述間違ってますか？

<style>
a:not(:target){
border: solid 1px #000;
}
</style>

<a href="https://www.google.co.jp/">targetなし</a>
<a href="https://www.google.co.jp/" target="_blank">targetあり</a>

すいません解決しました
a:not([target])
でした

:targetなんていう疑似クラスあったのかと思ってしまった

一応有るけど違う意味だったな

:target
http://developer.mozilla.org/ja/docs/Web/CSS/:target
CSS の :target 疑似クラスは、 URL のフラグメントに一致する id を持つ固有の要素（対象要素）を表します。


:target Selector
http://api.jquery.com/target-selector/

>>729
へぇ～
知らなかった

>>722
visibility …… ボックスの表示・非表示を指定する
http://www.htmq.com/style/visibility.shtml

722ですけどスタイルを変更できるのはしってるんですけど
visibleをnoneにするのは簡単でもきりとるのはそれ以外の全部けさないとだし
ターゲットの親は残さないといけないしで簡単にやる方法ってないのかなと…

すっかりアロー関数式を使うようになっていたのですが
jQueryはメソッドの中でthisを使うことが多いので
アロー関数式だと問題が出ます
普通の関数を書くしかないのでしょうか？

コールバックにthisで渡される変数は引数でも渡されているので
こっちを使うのがES6風なのでしょうか？

なんでもかんでもアロー関数を使うのが間違いだと思うけどね
addEventListenerでも同じ問題が有るけど
そういう風にthisが変わるようなときには使わないほうが良いと思う

誰か知らないけど（ｗ）この人も同じようなことを言ってる
http://dmitripavlutin.com/when-not-to-use-arrow-functions-in-javascript/
> 2. Callback functions with dynamic context

個人的にはアロー関数は、関数を値のように使いたいときだけにしてほしい
それは大抵一行で済むものになるので () => { return n } みたいな
{} とreturnを使う構文は無くしてほしいね

thisじゃなくて引数を使えばいいじゃん

オブジェクト指向的にthisを使うためにアロー関数を使うわけで、
イベントハンドラではtargetを使うのが普通だと思う

少なくともmdnだとメソッドでない関数に最適と書いてある。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/arrow_functions

そうするとオブジェクト指向的にthisを使うため、って出自ではなさそうだが。
むしろ関数型的に使うためでは。

イベントハンドラではtargetを使うのが普通というのはそう思う。

>>738
その文書の"thisを束縛しない"の項目に、
＞これは、オブジェクト指向プログラミングをする上で煩わしいということが分かりました。
って書いてあるよ

まじか

そういや関数型に使うんならそもそもthis使わないし短く書けるくらいしか使用上の違いなかったな

別にアロー関数がオブジェクト指向に向いてるというわけでもそうでないわけでもない
アロー関数はメソッド自体として使うには確かに不適切
だがメソッド中で関数を定義したりすると必要になるthat=thisなんかは不要になる
適材適所

jsbinで追加出来るjQueryのバージョンに
jQuery WIP
という版があるのですが、このWIPとは何の略でしょうか？

Work
In
Progress

>>744
作成中というような意味ですね
とすると、新しいほどいいだろうと思って選んでいましたが
あまり使わない方がいいのでしょうね
ありがとうございました

どんどん使うべきだよ
万が一問題があってもそれを報告すればいいだけだし
自分のスキル向上にもなる
良いことしか無い

まあオレは使わない

removeの範囲にdataを持った要素があった場合、
そのdataも解放されるのでしょうか？

そこまで気になるようになったのなら自分でソース見て調べたほうが良い

もし、そのdata が、削除されないオブジェクトから、参照されていれば、
必要だから、dataはガベージ(GC)されない

生きているオブジェクトからの、参照カウントが1以上あるから

メモリリークするかどうか、チェックすべし