私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.88 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>850
イベントフローの話から、なんでArrayが出てきた?
まあそれならそれで、『崩壊』するコードの例と実行環境を出してくれ
あんた、ひょっとしてプロトタイプチェーンもよく理解してないんじゃないのか?
さっきundefined変数を普通に使ってるようなことを書いてたし、心配してはいたんだが
イベントフローの話から、なんでArrayが出てきた?
まあそれならそれで、『崩壊』するコードの例と実行環境を出してくれ
あんた、ひょっとしてプロトタイプチェーンもよく理解してないんじゃないのか?
さっきundefined変数を普通に使ってるようなことを書いてたし、心配してはいたんだが
>>850
で、俺はイベントデリゲーションのメリットを挙げたが、あんたはデメリットを挙げない
あんたが「自分には必要ないと思っている」のは分かったが、それは俺の主張に対する反論にはならず
俺が『ゴリ押し』している根拠にもならないことは、理解しているよな?
イベントデリゲーションのデメリットは大きく2個あると俺は考えるが
あんたからそれが出てこないということは、大した問題ではないのだろう
さるさんも出てきたし、俺はここまでにするよ
で、俺はイベントデリゲーションのメリットを挙げたが、あんたはデメリットを挙げない
あんたが「自分には必要ないと思っている」のは分かったが、それは俺の主張に対する反論にはならず
俺が『ゴリ押し』している根拠にもならないことは、理解しているよな?
イベントデリゲーションのデメリットは大きく2個あると俺は考えるが
あんたからそれが出てこないということは、大した問題ではないのだろう
さるさんも出てきたし、俺はここまでにするよ
>>852
横からだけどイベントバリデーションは話の発端となっただけで>>850はイベントバリデーションの話はしてないと思う。
「初心者にJavaScriptの基礎(イベントバリデーション等)を覚えさせるより、初心者がいい加減なコードを書いても動くように上級者が書いた方が手間が少ない」
彼はこれしかいってない。
prototype汚染を回避するために Array.prototype を定義しないのと理由は同じ。
「addEventListener を封印してHTMLのイベント属性を使えば初心者でもわかるだろ」ってこと。
理屈はわかる。裾野を広げればどこまでもルール無用のコードになって保守性が著しく低下するから賛成しないけど。
そもそも、コーディング規約を作って初心者に教える努力を怠らなければ解決できる話。
横からだけどイベントバリデーションは話の発端となっただけで>>850はイベントバリデーションの話はしてないと思う。
「初心者にJavaScriptの基礎(イベントバリデーション等)を覚えさせるより、初心者がいい加減なコードを書いても動くように上級者が書いた方が手間が少ない」
彼はこれしかいってない。
prototype汚染を回避するために Array.prototype を定義しないのと理由は同じ。
「addEventListener を封印してHTMLのイベント属性を使えば初心者でもわかるだろ」ってこと。
理屈はわかる。裾野を広げればどこまでもルール無用のコードになって保守性が著しく低下するから賛成しないけど。
そもそも、コーディング規約を作って初心者に教える努力を怠らなければ解決できる話。
>>853
IDは確かに強制しない方がいいかもね
ただ、レス番を名前は複数人が質問したときにホント困るから守って欲しいんだよなあ
「IDなし、名無しの状況で誰が誰かわかれ」って方が無理があると思う
(案1) ID推奨、レス番を名前推奨
(案2) ID推奨、レス番を名前強制
(案3) ID強制、レス番を名前推奨
(案4) ID強制、レス番を名前強制
(案5) ID推奨、レス番を名前強く推奨
(案6) ID強制、レス番を名前推奨 or ID推奨、レス番を名前強制
(案5) > (案6) > (案2) かなあ
(案6) は複雑すぎるかもしれないけど、強制対象を選択できる自由度はある
IDは確かに強制しない方がいいかもね
ただ、レス番を名前は複数人が質問したときにホント困るから守って欲しいんだよなあ
「IDなし、名無しの状況で誰が誰かわかれ」って方が無理があると思う
(案1) ID推奨、レス番を名前推奨
(案2) ID推奨、レス番を名前強制
(案3) ID強制、レス番を名前推奨
(案4) ID強制、レス番を名前強制
(案5) ID推奨、レス番を名前強く推奨
(案6) ID強制、レス番を名前推奨 or ID推奨、レス番を名前強制
(案5) > (案6) > (案2) かなあ
(案6) は複雑すぎるかもしれないけど、強制対象を選択できる自由度はある
わざわざ名前欄に番号を入れるのを忘れることはあっても
メ欄を空のままにすればID出るから
と、ここまで書いて、専ブラでsageをデフォにしてるヤツのことを思い出した
メ欄を空のままにすればID出るから
と、ここまで書いて、専ブラでsageをデフォにしてるヤツのことを思い出した
(案1)
(3) メール欄は空欄、2回目の投稿時は「前回のレス番」を名前にすることを推奨します。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案2)
(3) メール欄は空欄を推奨。2回目の投稿時は前回のレス番を名前にして下さい。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案5)
(3) メール欄は空欄を推奨。2回目の投稿時は前回のレス番を名前にすることを強く推奨します。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案6)
(3) 「メール欄は空欄」「2回目の投稿時は前回のレス番」のいずれかを守ってください。長い間連続して質問する場合にレス番かIDを明示すれば、質問の流れが回答者に伝わりやすくなります。
(3) メール欄は空欄、2回目の投稿時は「前回のレス番」を名前にすることを推奨します。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案2)
(3) メール欄は空欄を推奨。2回目の投稿時は前回のレス番を名前にして下さい。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案5)
(3) メール欄は空欄を推奨。2回目の投稿時は前回のレス番を名前にすることを強く推奨します。長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(案6)
(3) 「メール欄は空欄」「2回目の投稿時は前回のレス番」のいずれかを守ってください。長い間連続して質問する場合にレス番かIDを明示すれば、質問の流れが回答者に伝わりやすくなります。
レス番を入れて貰った方がいいな
IDは日付を跨いだときに質問の流れを追うのが面倒
IDは日付を跨いだときに質問の流れを追うのが面倒
>>857
質問者が自演して何か得することある?
質問者が自演して何か得することある?
attachEventのdragとかはdocumentにそれぞれ1個だけつけておいてその中でどの領域がドラッグされただのを検知してやればいいって話?
登録時にgetElementByIdとかで指定するんではなく
登録時にgetElementByIdとかで指定するんではなく
>>851
まず第一に、JavaScriptが操作対象にしてるのは、別にDOMに限ったことじゃない。
document.body.innerHTMLを誰もが操作できるのと同じように、
Array.prototypeも誰もが操作できるし、
そうしようと思えば、誰もが document.addEventListener = null; なんてことができる。
JavaScriptの環境ってのは、そもそもが、カギのかかってない倉庫みたいなもんなわけ。
誰かがdocument.body.innerHTMLに丸ごと干渉するコード、
たとえば丸ごと書き換えるようなコードを書く可能性がある。それ自体は正しい。
だが、それに対する対処として正しいのは、そんなバカげた処理をしないように
干渉するコードを書き直すことであって、そのコードと共存する側のコードが
そんなバカげたコードの存在を前提にして、面倒な処理をするのは無駄すぎる。
標準化されたDOMが提供しているものがあるとすれば、
それは、他者のコードに極力干渉することなくコードを書く手段を提供している。
全員が全員これに従って、お互いに極力干渉しないコードを書けば、
問題が発生する可能性は非常に小さくなる。
だから標準に従うことは重要だし、干渉しないことに注力することも必要。
だが、DOMの実装が、JavaScript内でJavaScriptに普通に従って実装されている以上、
DOM標準に従ってコーディングしたからといって、他からの干渉に完璧に対処して
正常な動作を保証することができるというわけじゃない。そんな優れたサンドボックスは提供されてない。
まず第一に、JavaScriptが操作対象にしてるのは、別にDOMに限ったことじゃない。
document.body.innerHTMLを誰もが操作できるのと同じように、
Array.prototypeも誰もが操作できるし、
そうしようと思えば、誰もが document.addEventListener = null; なんてことができる。
JavaScriptの環境ってのは、そもそもが、カギのかかってない倉庫みたいなもんなわけ。
誰かがdocument.body.innerHTMLに丸ごと干渉するコード、
たとえば丸ごと書き換えるようなコードを書く可能性がある。それ自体は正しい。
だが、それに対する対処として正しいのは、そんなバカげた処理をしないように
干渉するコードを書き直すことであって、そのコードと共存する側のコードが
そんなバカげたコードの存在を前提にして、面倒な処理をするのは無駄すぎる。
標準化されたDOMが提供しているものがあるとすれば、
それは、他者のコードに極力干渉することなくコードを書く手段を提供している。
全員が全員これに従って、お互いに極力干渉しないコードを書けば、
問題が発生する可能性は非常に小さくなる。
だから標準に従うことは重要だし、干渉しないことに注力することも必要。
だが、DOMの実装が、JavaScript内でJavaScriptに普通に従って実装されている以上、
DOM標準に従ってコーディングしたからといって、他からの干渉に完璧に対処して
正常な動作を保証することができるというわけじゃない。そんな優れたサンドボックスは提供されてない。
>>860
質問者になりすました第三者が荒らしたりする
質問者になりすました第三者が荒らしたりする
>>863
自演じゃないやん
自演じゃないやん
下手にテンプレを大きく変えようとするからおかしくなる
今まで上手くいっていたのをわざわざ変える必要はない
プログラムとおんなじだよ
今まで上手くいっていたのをわざわざ変える必要はない
プログラムとおんなじだよ
ここまで当然のように語られてるから聞くのが怖いのですが
エセ外人さんが言っていたレスはどこまで辿れば見れますか?
エセ外人さんが言っていたレスはどこまで辿れば見れますか?
問題視されてるんだから上手くいってない面もあるんだろう
実際流れがわかりにくい
実際流れがわかりにくい
JavaScript 第5版
http://books.google.co.jp/books?id=RDqQXFA42-kC&printsec=frontcover
初めてのJavaScript
http://books.google.co.jp/books?id=om2V2n9zw0oC&printsec=frontcover
Head First JavaScript: 頭とからだで覚えるJavaScriptの基本
http://books.google.co.jp/books?id=JxnSxoUdlXEC&printsec=frontcover
ここらへん関連リンクに入れない?
>>858安だったら5だな
強制はどれかをしていない場合テンプレ読めで終わる事が多い
そういう風潮はちょっと残念だし
http://books.google.co.jp/books?id=RDqQXFA42-kC&printsec=frontcover
初めてのJavaScript
http://books.google.co.jp/books?id=om2V2n9zw0oC&printsec=frontcover
Head First JavaScript: 頭とからだで覚えるJavaScriptの基本
http://books.google.co.jp/books?id=JxnSxoUdlXEC&printsec=frontcover
ここらへん関連リンクに入れない?
>>858安だったら5だな
強制はどれかをしていない場合テンプレ読めで終わる事が多い
そういう風潮はちょっと残念だし
>>840
> 二重登録が生じやすいのは、複製したノードにイベントリスナを付けるとき
> IE7ではノードの複製でイベントハンドラも複製されるため
IE9 で修正されたバグのようです。IE8 で未修正であることを確認しました。
http://jsfiddle.net/8nxpa/3/
> 二重登録が生じやすいのは、複製したノードにイベントリスナを付けるとき
> IE7ではノードの複製でイベントハンドラも複製されるため
IE9 で修正されたバグのようです。IE8 で未修正であることを確認しました。
http://jsfiddle.net/8nxpa/3/
>>873
試せばわかることを何で聞くの?
試せばわかることを何で聞くの?
>>877
ありがとう
ありがとう
>>878もありがとう
ここまでのテンプレまとめ
http://codepad.org/CdUhJKNu
http://codepad.org/CdUhJKNu
(2) ユーザの迷惑になるスクリプトの質問はご遠慮ください。
↓
(2) 迷惑になるスクリプトの質問はご遠慮ください。
迷惑するのはユーザーだけではなくなってるから変えたほうが良いのかもしれない
↓
(2) 迷惑になるスクリプトの質問はご遠慮ください。
迷惑するのはユーザーだけではなくなってるから変えたほうが良いのかもしれない
エセ外人ってか、
やたら「アホ外人が俗に言うイベントデリゲーション」とか書いてた人だろう。
やたら「アホ外人が俗に言うイベントデリゲーション」とか書いてた人だろう。
>>862
「俺がグローバルにiを使うからお前らは使うなよ」
「いやvarがあるんだから使ってよ、こっちも使いたいんだから」
「そんな馬鹿げたコードの存在を俺は認めない」
「…わかったよ、こっちがvarすればとりあえず回避できるから、君らもそうしな」
「まったく馬鹿げたコードを書く奴は困る」
お前の言ってるのはこういうことだぞ?
「俺がグローバルにiを使うからお前らは使うなよ」
「いやvarがあるんだから使ってよ、こっちも使いたいんだから」
「そんな馬鹿げたコードの存在を俺は認めない」
「…わかったよ、こっちがvarすればとりあえず回避できるから、君らもそうしな」
「まったく馬鹿げたコードを書く奴は困る」
お前の言ってるのはこういうことだぞ?
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
…とか。
…とか。
>>887
グローバル変数を避ける
組み込みオブジェクトのプロトタイプを拡張しない
ホストオブジェクトを上書きしない
これらと同じく、イベントデリゲーションも『道交法を守』って事故を起こさないためなのに
なぜこれだけをやたらと嘲笑しているのか、ちょと意味が分からない
グローバル変数を避ける
組み込みオブジェクトのプロトタイプを拡張しない
ホストオブジェクトを上書きしない
これらと同じく、イベントデリゲーションも『道交法を守』って事故を起こさないためなのに
なぜこれだけをやたらと嘲笑しているのか、ちょと意味が分からない
ところでaddEventListenerやattachEventはdocument全体にやるのと
getElementByIdなどで個別に追加するのとではどちらがクールなの?
getElementByIdなどで個別に追加するのとではどちらがクールなの?
>>889
酔っ払いを排除するという方針を言ってるに過ぎない俺を排除したとして、
結果はいずれ撥ねられる初心者と撥ねるボケコードが残るだけだが?
>>891
違ってるぞ。
「グローバル変数を避ける」「組み込みオブジェクトのプロトタイプを拡張しない」
「ホストオブジェクトを上書きしない」は、自分・他人のコードを両方とも共存することを保証するためのもの。
で、今回この話の発端は>>808や>>839だが、俺からすれば808の
「ハンドラが生き残る可能性が高い」なんつアホなコメントは前述の3つと全く別次元の話。
共存できることを『保証』できなければ意味がない。
まとめて書き換えられてハンドラが対象にしていたオブジェクトがデタラメな変更されてたら
生き残ったところでデタラメな動作するかせいぜいエラーがオチだ。
>>892
JavaScriptの動作環境は、いかようにもブチ壊せるというたとえ。
いかようにもぶち壊せるのだから、他人のコードに求めるのは、壊さないよう祈るだけにしとくに留めて
それ以上のことをしようとすることの意味はほぼ0だと悟るべきだってこと。
>>893
他人のコードと共存せず、自分のコードだけで動かすならどんな実装だろうが問題なかろう?
酔っ払いを排除するという方針を言ってるに過ぎない俺を排除したとして、
結果はいずれ撥ねられる初心者と撥ねるボケコードが残るだけだが?
>>891
違ってるぞ。
「グローバル変数を避ける」「組み込みオブジェクトのプロトタイプを拡張しない」
「ホストオブジェクトを上書きしない」は、自分・他人のコードを両方とも共存することを保証するためのもの。
で、今回この話の発端は>>808や>>839だが、俺からすれば808の
「ハンドラが生き残る可能性が高い」なんつアホなコメントは前述の3つと全く別次元の話。
共存できることを『保証』できなければ意味がない。
まとめて書き換えられてハンドラが対象にしていたオブジェクトがデタラメな変更されてたら
生き残ったところでデタラメな動作するかせいぜいエラーがオチだ。
>>892
JavaScriptの動作環境は、いかようにもブチ壊せるというたとえ。
いかようにもぶち壊せるのだから、他人のコードに求めるのは、壊さないよう祈るだけにしとくに留めて
それ以上のことをしようとすることの意味はほぼ0だと悟るべきだってこと。
>>893
他人のコードと共存せず、自分のコードだけで動かすならどんな実装だろうが問題なかろう?
>>895
対象が1つならそれそのものにつけても不便はないし、実装は簡単にできるな。
同じような内容がたくさん必要な場合、たとえば1年間のカレンダーをtableで表示して
1日ごとのセルをクリックで個別処理するなら、tableにでもくっつけて
クリックされたセルで分離した方がメモリなんかも効率がよくなる。
ケースバイケース。確定の回答なんてない。
対象が1つならそれそのものにつけても不便はないし、実装は簡単にできるな。
同じような内容がたくさん必要な場合、たとえば1年間のカレンダーをtableで表示して
1日ごとのセルをクリックで個別処理するなら、tableにでもくっつけて
クリックされたセルで分離した方がメモリなんかも効率がよくなる。
ケースバイケース。確定の回答なんてない。
>>895
バブリングを使っとけば、例えば表データの行を増やしたときに
ハンドラを付けるか悩まずに済む
クライアント側スクリプトは、1つの文書木を皆が争って使ってる状態なわけだ
自分のハンドラをそういう争いに巻き込ませたくなければ
震源地からできるだけ遠くで監視させた方が良い
であれば、震源地の情報を問い合わせるeventオブジェクトの存在意義が分かるだろ
イベントフローやeventオブジェクトは、そういう必要性から考案されている
まあ、IE4とNN4を単純合成しただけってのもあるけどな
バブリングを使っとけば、例えば表データの行を増やしたときに
ハンドラを付けるか悩まずに済む
クライアント側スクリプトは、1つの文書木を皆が争って使ってる状態なわけだ
自分のハンドラをそういう争いに巻き込ませたくなければ
震源地からできるだけ遠くで監視させた方が良い
であれば、震源地の情報を問い合わせるeventオブジェクトの存在意義が分かるだろ
イベントフローやeventオブジェクトは、そういう必要性から考案されている
まあ、IE4とNN4を単純合成しただけってのもあるけどな
>>896
俺が『ハンドラが生き残る可能性が高い』と言ったのは、バブリングしないイベント属性の方な
とりあえず、イベントデリゲーションにデメリットがあるなら、まずそれを書け
それとも「イベント属性」が気に入らないなら、俺の主張する「メリット」に反論してみせろ
自衛(別には自衛だけを語ったつもりもないが)が「愚かしい」という
お前の価値観は分かったが、「手法」に対して「価値観」で反論してくんな
俺が『ハンドラが生き残る可能性が高い』と言ったのは、バブリングしないイベント属性の方な
とりあえず、イベントデリゲーションにデメリットがあるなら、まずそれを書け
それとも「イベント属性」が気に入らないなら、俺の主張する「メリット」に反論してみせろ
自衛(別には自衛だけを語ったつもりもないが)が「愚かしい」という
お前の価値観は分かったが、「手法」に対して「価値観」で反論してくんな
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.81 + (1001) - [97%] - 2010/12/10 20:01
- + JavaScript の質問用スレッド vol.86 + (1001) - [97%] - 2011/5/27 21:50
- + JavaScript の質問用スレッド vol.98 + (1001) - [97%] - 2012/4/9 14:46
- + JavaScript の質問用スレッド vol.89 + (1001) - [97%] - 2011/9/4 4:17
- + JavaScript の質問用スレッド vol.78 + (1001) - [97%] - 2010/6/25 3:53
- + JavaScript の質問用スレッド vol.80 + (1001) - [97%] - 2010/11/9 2:17
- + JavaScript の質問用スレッド vol.87 + (1001) - [97%] - 2011/6/21 6:33
- + JavaScript の質問用スレッド vol.82 + (1001) - [97%] - 2011/1/19 7:54
- + JavaScript の質問用スレッド vol.83 + (1001) - [97%] - 2011/2/24 8:02
- + JavaScript の質問用スレッド vol.84 + (1001) - [97%] - 2011/3/30 7:32
- + JavaScript の質問用スレッド vol.85 + (1001) - [97%] - 2011/4/25 21:32
- + JavaScript の質問用スレッド vol.128 + (1001) - [95%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.108 + (1001) - [95%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [95%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.96 + (1001) - [95%] - 2012/1/28 23:01
- + JavaScript の質問用スレッド vol.94 + (1001) - [95%] - 2012/1/8 15:46
トップメニューへ / →のくす牧場書庫について