元スレ+ JavaScript の質問用スレッド vol.114 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

451 = :

子要素を全て削除する処理ってどう書くべきでしょうか
やはりループでchidlNodes.lengthが0になるまで繰り返しますか？
そうするとinnerHTMLで上書きしたほうが速度的に有利になることが多いのですが、もっと良い方法が別はないのでしょうか

452 = :

>>451
子を含まない親のコピーを作って、旧親を消して、新親に置き換える。
…とか？

454 = :

>>449
まーた前提条件捏造法か
詭弁が骨身に沁み込んだこの種のカスとの議論は本当に得るものがない

455 = :

>>454
ちなみに骨身に沁み込むなんて日本語無いですよ

456 = :

捏造の意味も分かってないんだろうなｗ
母国語さえまともに使えない奴にプログラムなんて無理だな

458 = :

>>455
まーたネトウヨお得意の「定義」かw
骨身という名詞に沁み込むという動詞を組み合わせた比喩的表現で何もおかしくねーわ
ネトウヨってこの種の低レベルな詭弁大好きだよな
馬鹿でも簡単に出来るだからだろうが、
そんなものには意味がないんだよ
議論というものは両者が何かをそこから得ることのできる創造的な営為だが、
詭弁の生産性はゼロ。
誰一人として得しないのが詭弁。
むろんお前自身もな。

459 = :

>>458
慣用表現というのは広く人口に膾炙そて初めて成立するものなんだよ
こっちは別に議論をしているつもりなんてなくて、ただ間違った言葉使いを指摘してあげただけ
せっかく勉強になっただろうに、なんでそんなにムキになっちゃうのかな

460 = :

>>459
膾炙そてww
言葉というものは拡張可能なんだよ
「沁みる」より「沁み込む」の方が一層深く浸透している感じがするだろ？
それがレトリックだ
おのれの愚かさを棚に上げるな

461 = :

タイポしちゃった
骨身に沁みるじゃ、意味が違うよね？
辞書調べてみなｗ

462 = :

レトリックに頓珍漢なツッコミしてくる奴たまにいるけどアスペルガーなのかな
辞書が先にあるのではなく言葉が先にあるのに逆だと思ってるんだよな

463 = :

言葉の誤用はレトリックとは言いません

464 = :

>>461
だから骨身に沁みるって書いてねーだろ
レトリックを勉強しろ

465 = :

>>464
>>460
ちょーアスペｗｗｗ
こわい

466 = :

無知であることは恥ずかしいことじゃない
無知を認められないことこそ恥ずべきことなんだよ

467 = :

アスペはお前だよ
「骨身に沁みる」という慣用表現を「沁み込む」に書き換えることで新しい言葉に拡張する
高度に文学的なレトリックだ
俺にしてみればこの程度の知的遊戯は日常だが読み手の知性を高く見積もりすぎたらしい
その点は俺のミスだったな

468 = :

まぁプログラマーに文学的リテラシーは必須ではないし
適当ではなかったことは認めよう
もっと無機質な言葉を心がけるよ

469 = :

言葉の誤用を指摘しているだけなのにな
なぜ間違いを認められないんだろう

470 = :

間違いを認められない奴はプログラミングに向いてない。

471 = :

web制作版をみていて思うのは「俺は質問者じゃないけど」みたいな雰囲気で
回答者にかみつくひとが多くてほんと萎える
有意義なことを言っているのならその発言は歓迎されるべきだけど
大したこと言ってないしな

472 = :

>>471
おれはお前みたいな表向きは控えめな自己主張をする奴が一番ウザいと思う

473 = :

>>472
俺のことが嫌いなのは理解できたが
表向きは控えめな自己主張とやらは理解できなかったわ
もっと分かりやすく説明してくれ

474 = :

>>453
該当親要素にイベント定義されているとcloneNodeした時点でイベントがなくなるので注意(わかってるとは思うけど、念の為)

476 = :

>>457
その何らかのオブジェクトを
その空間においてのみグローバルな変数にする
ために var で宣言することになる

477 = :

どうも回答にいちいち噛みつかないと落ち着かない人が常駐しているみたいね

478 = :

質問者が噛みつくならわかるけど、質問者のことをわかったつもりで赤の他人が噛みつくのは…質問者の意図とかけ離れていたらどうするんだろうね
質問者も出てきづらくなるだろうしね

479 = :

どうも出て来辛くなった質問者こと>>429です

そもそもの発端はどこかで聞いた「try/catchは遅い」というのを
ちょうど話題になっているcloneNode()を使った重めの処理を回している時に
ふと思い出し、それをtryブロックで囲ってみたら速度低下が見られなかったので
じゃあこれまでの認識が間違ってたのかな…と疑問に感じたことでした
軽い気持ちで質問してしまったのでなんだか申し訳ない次第です

速度に関してのレスはまだ理解できないことが多いので
少しずつ調べながら自分の知識にしていきたいと思います
たくさんのレスありがとうございました

480 = :

イライラ解消、ストレス発散の場所としてここが重要な人はいるからな
気にするな

481 = :

>>479
最初から答えは出てるんだよ。
速度に関しては、計測が全てって。

try-catchに関しては、どういう時に使うかを考えれば、
何度も実行されるものではないので、上級者はたとえ重かったとしても
使うべき所に使うものという印象でしかない。

try-catchに速度の観点で考えるべきことは殆ど無いんだよ。
実際に計測して遅くもなってないだろう？
ここまで上級者はわかっていた話。

荒れたのは、速度第一みたいなアホが現れたから。

482 = :

>>479
回答者の教育が至らず、誠に申し訳ございません
舐めたことをぬかす回答者を今後もビシバシ鍛え上げていく所存ですので
今後とも何卒よろしくお願いいたします

483 = :

>>481
>速度第一

そんな奴一人もいねえ
ひっとりもいねえ
いつまで藁人形を槍で突く愚行を続ける気なのか

484 = :

>>476
やはりそうですか
ありがとうございました

485 = :

>>482
お前キモいわ

486 = :

ライブラリが他のライブラリを使っている時、
依存しているライブラリを示すにはどうすればいいですか？

488 = :

JSDocっていう書き方をしたらいいんですね
ありがとうございました

489 = :

document.elementFromPoint
ですが、これは要素が実際に画面に表示されていない時には
取得できないようです。
画面外の要素を、座標で検出するには、
スクリプトで当たり判定するしかないでしょうか？

490 = :

>>489
「表示されていない」
が、レイアウトの対象でない（ display: none など）を意味するならば
レイアウトの対象に置いてやる必要があるだろう
例えば一時的に display: none を解除して visibility :hidden にするなど

「表示されていない」
がスクロールしたなら表示できる状態を意味するのなら取得できる筈
（「画面外」が正確に意味する所は？）

491 = :

>取得できる筈
間違えた。やっぱ取得できないと思う

492 = :

>>489
P = 入力座標（画面外）
Q = 適当な画面内の座標
Q-P だけスクロール
document.elementFromPoint(Q)
P-Q だけスクロールして元に戻す

でいけるかな？

493 = :

　　　　ノヽ
　　　／ヾツ＼
　　／　 )ﾉ　＼
　　/　　　　　　ﾍ
　｜　＿　　＿　｜
　 <ﾍ　,,,　 ,,, />
　　Y (●)　(●) Y　　　＜よんだ？
　　ヽ ⌒)ー(⌒ ノ
　　　＞―――＜
　 _／　　　　　＼_
　(ﾐ　/　　　　Ｙﾐ)
　￣｜　　　　｜￣
　　 (＼　＾　／)
　　ヽ＼＿／ /
　　　ヽ　｜　/
　　　 (mn人nm)