+ JavaScript の質問用スレッド vol.131 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【条件】期待する回答の条件を書いてください。(ex: jQuery不可, フレームワーク不可)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです > 使われ方が全く違うだろ
ちゃんとした考え方できる人はそうわかるんだけどね。
今のところjQueryがなくなることはない。
jQueryの代替技術はない
だけど一部のjserどもが、jQueryはオワコン
これからはAngular、Reactやで！
jQuery使わなくて頑張ればコストがかかるだけでできる！
などと言い始めたからね。 jQueryがまだ下り坂になってないのは
この一年でシェアが更に増えたことからも明らかだよな >>592
addEventListenerとattachEventの違いの吸収のように
UA間で異なる仕様が少なくなっていくにつれて
jquery自体が不要になっていくんじゃないの
例えばアニメーションだって5年前とは比較にならんほどcss対応進んだし どっちかっていうとこれからはピュアなjavascript >>594
addEventListenerとonの違いを考えれば
jQuery優位になるんだよ。
今はaddEventListenerが優位な点も残っているが解決できる
でも逆にaddEventListenerはonの優位な点を解決することができない
onが優位な点
・onの方が文字数が少ない
・複数のイベントに対して一度にイベントを設定できる
・後から追加される要素に対しても働くイベントハンドラが簡単に書ける
addEventListenerが優位な点
・イベントハンドラの設定が速い（だが体感できるものではない）
・キャプチャフェーズにも対応できる（そもそもIE8非対応の機能。jQuery 4.0で対応予定）
https://github.com/jquery/jquery/wiki/jQuery-4.0-Event-Design
結局jQueryオブジェクト＝DOM要素のコレクションという仕組みが最強なんだわ
jQueryオブジェクトはjQuery独自のものだから標準にとらわれず自由にメソッドを追加できる >>595
> どっちかっていうとこれからはピュアなjavascript
ピュアなjavascriptがループとか条件分岐なしに
書けるようになればね・・・
結局、言語の設計方針レベルの問題だから
ループなしにセレクタに一致する要素群に対して
一括でイベントハンドラを設定できるようにはならんと思うよ >後から追加される要素に対しても
よくわからないんだが
適切にHTML構造作ってバブリング考えてリスナ組み立てればいいだけでないの >>598
jQueryだと
$('.class').on('click', function() { this はクリックされた要素 } );
これを
$(document).on('click', '.class', function() { this はクリックされた要素 } );
こう書き換えるだけでいい。
イベントハンドラの中身も書き換えなくて済む
これとまったく同じことをjQueryを使わずに書こうとしたら
ほんとうに大変だよ class名でイベントリスナ貼り付けるの好きだよねjquery使い >>600
IDでイベントハンドラを付ける意味が無いからね。 jQueryは動的ページと相性が良くて動的ページっていうのはある要素が条件によって
存在したりしなかったりするわけだけど、jQueryを使うといちいち要素が
存在しているかしていないかをチェックする必要がない
その動きはCSSと一緒。
CSSでも特定の要素が存在しなくてもエラーにならない
そして要素が1つであっても複数であっても、それを気にする必要がない。
まったく同じコードで処理できる。
同じことをDOM APIだけでやろうとするとループが必要になってしまう。
そのループを避けるため、ID指定で一つの要素だけ取得しようとするが
そもそもループが存在しないjQueryではID指定に拘る必要がない。 >これとまったく同じことをjQueryを使わずに書こうとしたら
>ほんとうに大変だよ
後から追加した要素のイベントを検出するのは、
JavaScriptで同じ事をやろうと思えば出来るんですか？
jQueryではどんな手法でやっているんですか？ そもそもそんなハッキーな状況に軽やかに対応しないといけないって言うのが理想的ではないんじゃないか
やっぱり中に何があるかわからんけど、取り敢えず外から操る、それを楽にしたいでは無くて
コンポーネント化に努める方向で気にしなくていい事を増やした方が良いだろう
グローバル変数は楽し小さなケースでは良いけど、やっぱり色々考えると推奨されないのと同じ >>603
まずイベントバブルを利用してdocumentにイベントハンドラを設定する
その後、発生したイベントの発生元が、指定したセレクタに一致するか比較する
そうすればできる。
最近のブラウザなら、指定したセレクタに一致するか比較するのは簡単に
できるようになっているらしいが、jQueryはそれができない時代から
独自で実装していた >>604
> そもそもそんなハッキーな状況に軽やかに対応しないといけないって言うのが理想的ではないんじゃないか
JavaScriptを使ったページで、要素が動的に増えたり減ったりするのは
よくあると思うけど？ >>604
> コンポーネント化に努める方向で気にしなくていい事を増やした方が良いだろう
そうそれ！ jQueryが得意な所
IDを使ってしまうとコンポーネント化とは逆の方向になってしまう。
コンポーネントというのは使いまわしできるもので、
同じコンポーネントが一つのページに複数存在したりするものだからね。
それがjQueryと相性がいい。
同じコンポーネントというのは同じクラスであるということ
クラスに対してイベントハンドラを設定することで
コンポーネントに対しての処理が書きやすくなる。
> グローバル変数は楽し小さなケースでは良いけど、やっぱり色々考えると推奨されないのと同じ
即時関数を使ってグローバル変数を無くすってのはよくあるけど、
jQueryを使うと即時関数を使わなくてもグローバル変数はなくなってしまう。
実際に書いてみればわかるがこんな感じになるから
$(".class").on('click', function() {
// ここはローカル変数
}); 結局、ここ数年のWeb界隈を見るに、既存のDOM構造の地位を脅かすようなモデルが現れてないからね
それらと相性がいいjQueryは、好みはともかく、現実的にはまだしばらくは覇権でしょう jQueryは設計センスが良すぎてとても真似できない
これとlodashであと10年戦う 懐かしいな。もう一年前になるのか。
jQueryはオワコン、下降傾向にあるって言ってたやつ
一年経って減るどころか1.4%も増えたで？
その増えた量はReactよりも多い
どんな気分？ｗ angularやreactとかは大規模複数人開発案件でないとメリットがデメリットを上回らないからjQueryはなくならないと思う。
jQueryにマウント取ってるreactファンボーイが頭おかしいだけ。
しかも攻撃理由がreact等のvirtualDOMとjQueryの生DOM操作は相性悪い→jQueryはオワコン だからな。最高に頭悪い。
飛行機ができたから電車オワコンと言ってるようなもの。
原爆できたから軍隊にナイフ要らないと言ってるようなもの。 >>607
直近の親要素にaddEventListenerすれば済むことでは
classをjsの判断に使ったらcssで他の箇所に容易に再利用できなくなる >イベントバブルを利用してdocumentに
とりあえずグローバル変数、とりあえずsingletonみたいな感じで気持ち悪い
最低限にまとめろよ jQueryの是非は置いておいても
angularもreactもJSXもダメすぎる、あんなものが覇権取れるわけない >>612
直近の親要素にaddEventListenerするだけだと、クリックされた要素をうまく取得できない
下記のHTMLで動的に増えるものがliだとして、そのliの中に更にspanなどが入っている場合
[click here]の部分をクリックすると期待するliが取得できない
<ul id="ul">
<li>list1 <span>[click here]</span></li>
<li>list2 <span>[click here]</span></li>
<li>list3 <span>[click here]</span></li>
</ul>
document.getElementById('ul').addEventListener('click', function(event) {
console.log(this); // ul
console.log(event.srcElement); // span
console.log(event.target); // span
console.log(event.currentTarget); // ul
})
jQueryだと大丈夫。実際にイベントハンドラを付けたulも
イベントハンドラで取得したいliも
実際にクリックされたspanも簡単に取得できる
$('#ul').on('click', 'li', function(event) {
console.log(this); // li
console.log(event.target); // span
console.log(event.currentTarget); // li
console.log(event.delegateTarget); // ul
}) >>612
> classをjsの判断に使ったらcssで他の箇所に容易に再利用できなくなる
なんで？ 再利用させたいならばjQueryプラグインになるだろうけど
jQueryプラグインは特定のクラスに結びつくものじゃない >>615
>spanなどが入っている場合
HTML構造がそうなってるならspanだったらparentNode拾ってくればいいだけでは
classを使う必要性がない spanじゃなくて、divの中にspanだったら
こんどはparentNodeのparentNodeを取ってくればいいだけ。
またその他の要素が入っていたら、頑張ってJavaScriptを
メンテナンスすればやれないことはない
気合と金と時間さえあれば歩いて九州から北海道だって行ける！ >>618
今はどれだけ簡単にできるかって話をしてるんだから
そこでparentNodeを取ってくればーと言った時点で、
簡単にはできないってことになるんだよ やっぱりjQueryのdelegate相当のことをやろうとしたら
素のDOM APIでは大変そうですね やっぱりjQuery良く出来てるわー
一年経って減るどころか増えてるからぐうの音もでないだろうね html構造 javascriptも使うしCSSも使う
class名 一般的にはCSSが使う
html構造変わったらjavascriptコードも変わるのが当たり前
class変わってもjavascriptコードが変わることはあまりない
javascriptでclassをトグル切り替えするとかその程度 >>620
1個ifが追加で入れば「簡単じゃない」「難しい」になるのかい？
逆に、デザイナがCSSいじるとき
javascriptが利用しているclass名に拘束される面倒さは「簡単じゃない」に繋がらないのかい
そういう話をしているんだけど再利用ならjQueryプラグインが云々で何を言いたいのかさっぱり > html構造変わったらjavascriptコードも変わるのが当たり前
そう、それがDOM APIの常識だった。
だけど、jQueryはそれを打ち破った。
なにせCSSと同じくセレクタを使って要素を絞り込むわけだから、
CSSと同じ効果が得られた
そして同じセレクタに同じデザインを適用するCSSと
同じセレクタに同じ振る舞いを持たせるjQueryという関係が出来上がった
考えてみれば、セレクタ＝コンポーネント、
同じコンポーネントが同じデザインとう振る舞いを持つのは当然ではないか
そして混沌としてHTMLとJavaScriptの世界に
汎用性がもたらされた 生DOMはいい加減自分を操作するために親を経由するとかそういうのやめてほしい
やるとしても適当に関数作って内部でやっとけばいいのに >>624
> 1個ifが追加で入れば「簡単じゃない」「難しい」になるのかい？
そうだよ。知らなかった？
複雑度っていうのは条件分岐一つで大きく膨れ上がる。
ifが1つ増えれば2倍、2つ組み合わさればなれば、2倍の2倍で4倍。
3つだと8倍。一つ増えるだけででテストしなければいけない場合は
指数関数的に増加する
if一つだから簡単だと思っているやつは
考えが浅いというわけさ >>624
> javascriptが利用しているclass名に拘束される面倒さは「簡単じゃない」に繋がらないのかい
デザイナがいじるのはデザインであってclass名じゃないからね >>628
同じスタイルを適用したくても
javascriptがclass名で決め打ち処理入れてるから
CSSをコピペしたり別のclass名を作ったりしなきゃいけない、と嘆かないデザイナ？ >>629
違うものに同じデザインを適用したいってことないでしょｗ Webデザイナと連携したことないけど何かいろいろ闇があるんですか？ 切り分けたい時もあるし切り分けたくない時もある
切り分けられないを強要するライブラリということだ あるわい！
違うものであってもデザインが同じなら
クラス名も同じにするんだい！
デザインが赤なら、クラス名もredにするだろ！ デザインが同じでも、本質的に別物なら
それは違うクラス名を与えるべきだよ CSSに他classのスタイルを継承する文法があれば筋が通るんだけどね デザインが同じなら同じクラス名にしたいっていうのは
このボタンの色は青でフォントサイズ2emですね。
こちらの見出しも青でフォントサイズも2emですね。
ならボタンと見出しでデザイン一緒ですから
同じクラス名にしましょうって考える人？ JavaScriptを使う人はHTMLとCSSのことも理解していなければ
だめだってわかる典型的な例だな
なぜかJavaScript使う人でHTMLやCSSが苦手な人が多い 違うものに同じスタイルを適用したいからって
クラス名を同じにするとか愚の骨頂
素人同然だわ HTML仕様的にはclassはスタイルの為のものであってJavascriptの為のものではないはずだが
idはscriptから参照するためという目的が明示されてるが
併記されているclassにはそれがない
同じclassが同じ振る舞いであるべきかどうかは定かではないと言っておきたい > HTML仕様的にはclassはスタイルの為のものであってJavascriptの為のものではないはずだが
思い込みな。何処かに書いているというのなら言ってみてくれ
ちなみに、idはスタイルのためのものかい？ｗ どうせ適当な事を言うだけ言って逃げるだろうから
書いておくわ
https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes
> 要素のクラスを空白区切りで並べたリストです。クラスは CSS の
> クラスセレクター や JavaScript の Document.getElementsByClassName() メソッドと
> いった関数により、特定の要素を選択したり特定の要素にアクセスしたりすることを可能にします。
https://dev.w3.org/html5/spec-preview/global-attributes.html#classes
> Assigning classes to an element affects class matching in selectors in CSS,
> the getElementsByClassName() method in the DOM, and other such features. CSSがなんたるかどう書くべきかを理解しているデザイナとしか仕事しないのならいいけどね >>642
なんで今さらHTML4.01なんか持ち出してきたの？
わざと？ >>643
後者引用の文章は、classの割り当てはgetElementsByClassName()に影響すると言っているのみであって
classとは何であるかを説明しているものではないようだが ほう、やっぱり意図的にHTML4.01を持ってきたようだ
https://www.w3.org/TR/2014/REC-html5-20141028/dom.html#classes
Note: Assigning classes to an element affects class matching in selectors in CSS,
the getElementsByClassName() method in the DOM, and other such features. >>642
w3 vs mozilla、ファイッ！ >>646
クラスは色んな使い方として用いられると書いてあるが
スタイル専用なんてどこに書いてあるか？ https://www.w3.org/TR/2014/REC-html5-20141028/dom.html#classes を翻訳してみた
> 3.2.5.7class属性を
> すべてのHTML要素にはclass属性が指定されている場合があります。
>
> 属性が指定されている場合は、要素が属するさまざまなクラスを表すスペース区切りのトークンのセットである値を指定する必要があります。
>
> クラスHTML要素がの値とき、それはすべてのクラスで構成さに割り当てたが返さclass属性がされた空間に分割します。重複は無視されます。
>
> 要素にクラスを割り当てると、CSSのセレクタでのクラスマッチングgetElementsByClassName()、DOMでのメソッドなどの機能に影響し ます。
>
> 作成者がclass属性で使用できるトークンには追加の制限はありませんが、作成者はコンテンツの所望の表現を記述する値ではなく、コンテンツの性質を表す値を使用することが奨励されています。
>
> IDLは、DOMの仕様で定義され、属性を反映したコンテンツ属性を。 [DOM]classNameclassListclass
スタイル専用のものと書いてない 同様にIDがJavaScript専用とかも書いてない
実際CSSで使えるわけだしね >>645
MDNでclassのことを確認したときに参照として書いてあったのでブックマークしておいたからだ
シンプルで分かりやすかったから記憶に残っていたんだが
>>643の後者のURLを見ると目的が明示されなくなっているんだな
詳しく読んでくるがその前に>>640は取り消す、横から済まなかった >>652
お前の知識は古いから話にならないってだけだよ 仕様文書の読み方よく知らないんだけど
こういうのって打ち消されない限り以前
のが有効だったりしないの？ どちらを採用するかって話
HTML5を採用するなら、HTML5の仕様が全て
他の仕様書に書いて有ることは何の参考にもできない 過去を継承的に考えるのか過去を取り消
し的に考えるのかってことね ？
HTL4.01という仕様を元に
必要なことを付け足し、必要ないものを削除し
そして以前のものを継承させて完成させたのがHTML5だろ
HTML4.01で引き継ぐ所は全部引き継いてるんだから
HTML5だけを見ればいい。なくなった部分は廃止されたって意味だ。 HTMLの意味論にどこまで意義があるかはわからないけど
目的が抹消された例は結構あるな
理由はわからんが<dl>, <dt>, <dd>は定義リストじゃなくなった >>636
議論に関係ないが、こういう人いるわ……
わりと疲れる jQuery のソースコードを読むと、
Android 4.0, IE 9, IE 8 などの分岐処理がある
こんなの自分で対応できないだろ。
アホらしい つうかここでjQueryはあれに向いてる、これもできると言ってる奴らのレベルが低すぎる
一昔前JSとWebAPIだけであらゆることができると豪語してた奴ら未満
俺達はきちんとその時点でできることできないこと、得意なこと苦手なことを研究して
この先何が必要か考えES Discasにも参加したし、ブラウザにissueも投げた
JS大好きマンだが渋々C++でパッチも書いたこともある
結局自らの敵は自らで、jQueryがそういう用途に最適化された設計がされていない、
するつもりもあまりない、そういう用途で使おうと思ってる人が少ないって言うことが最大の敵なんだよ
いつまでもDOM APIと張り合って、使うべきか使わないべきかみたいなレベルの低い争いを続けてるようじゃ、
今あるjQueryマンセーじゃ未来はないよ HTMLの最後でjs読み込むのとwindow.onLoadで処理させるのと基本どっちを選ぶべきなの？ >>663
そうあってほしいと考えているわけですね
でもね、最初からjQueryはDOMライブラリだって言ってましたー
その他の用途には、それ用のライブラリを使いますー >>667
jQueryがそういう用途に最適化された設計がされていないことについてはどう考える？ 「いつまでもDOM APIと張り合って」って
書いているところから読み取れないかな？
jQueryはなんでもできるんだろ？
あれもこれもできるんだろ？
だがjQueryはあれもこれもの用途に
最適化された設計になっていない
所詮DOM API代わりのDOM用ライブラリにすぎない 当たり前ですよね？
jQueryはDOM用ライブラリですよ？
なんでDOM用ライブラリをなんでもできるライブラリに
しないといけないんですか？
どんな機能にも対応している神ライブラリとでも
思っていたんですか？
アホですねｗ ムキー！ お前らがjQueryはなんでもできるライブラリだって言っていただろ
その公約を守ってないからjQueryはクソライブラリだ！
お前らが言っていたことができないからクソだ >>666
window.onload
https://developer.mozilla.org/ja/docs/Web/API/GlobalEventHandlers/onload
load イベントは文書のローディング工程の終了時に発生します。
このイベントが発生した時点で、文書中の全てのオブジェクトは DOM 内にあり、
全ての画像とサブフレームのロードは完了しています
画像のロード完了を待つ必要があるかな？
漏れなら、画像など無視するから、<body>のラストで、JS を読み込む お前らが言っていた = 妄想
自分の妄想が実現されてないからクソだって言ってたのか
アホだな window.onloadは発動が遅いから、
それよりも早く発動するDOMContentLoadedってのができた。
そしてjQueryはDOMContentLoaded相当のタイミングで発動する
readyメソッドっていうのをDOMContentLoadedができるより前から実装していた
でもbodyの最後で実行していれば、readyはいらんのよね。
なぜか昔はJavaScriptは、<head>の中に書くもんだってお作法があった
今はbodyの最後で書いてもよいとなったから、実はjQueryでもreadyは使う必要がない。
更に言うならば、<head>で書いたとしても、
$(document).on(イベント, セレクタ) の形式を使っていればreadyはいらないんだよね。
なぜならdocumentはその時点で存在しているから
bodyの最後で書くのは最速に思えるかもしれないけど、
1ページの長さが極端に長かった場合、bodyの最後に到達するまでは
JavaScriptの処理が発動しないことになる。
でも、<head>で $(document).on(イベント, セレクタ) の形式で書いていれば
bodyの最後に到達しなくてもイベントを捉えることができる。
イベントを捉えてももちろんまだ該当の要素が読み込まれていなければ反応はしないが
jQueryの正しいやり方で書いていれば、要素が0個でもエラーにはならない。
というわけで要素が画面に表示された直後からJavaScriptの処理が働くように
するには、<head>で $(document).on(イベント, セレクタ) の形式で書くやり方なんだが
思考に慣れが必要ではあるだろうな >>673
上でコンポーネント化の話などが挙がってるし、
逆に色々話題が出たときこれはjQueryでは向いてないという話になったことがない
なんやかんや無理やりjQueryが使えると思い込んでる 思い込みが酷すぎて怖い
一緒に仕事したくないタイプ >>679
向いていないという話が出なかったら
向いていると言っているんだ！って思い込んでんのか？
例えば日付処理にjQueryは向いてない
ほら言ってやったぞ？どうするんだ？ >>682
jQueryはDOMライブラリである。
誰もjQueryが何にもでも使えるとは言ってない
ここまではいいな？ > なんやかんや無理やりjQueryが使えると思い込んでる
誰もjQueryが何にでも使えるとは言ってないので
（エスパーでもない限り他人が思ってることなんてわからないので）
思い込んでる事とわかるのは自分自身（>>679）だけである
ここまではよい ああ、スレ建てたやつがライブラリ禁止のテンプレ消したのか example.com?q=文字列
をサーバーサイドで受け取る時に文字列中に￥ｒや￥ｎも渡す事は出来ますか？ >>685
一番の問題はそう思われてるってことだと思うぞ
jQuerer含むライブラリスタが過剰にライブラリを推してるのは事実
度々スレ分離したり議論になってるのにまだ自分たちがどう思われてるのかが分かってないのか > 一番の問題はそう思われてるってことだと思うぞ
jQueryのアンチが変なふうに思い込んでるのは
アンチが悪いってことで終わりじゃね？ ライブラリの書き方はライブラリ使わないと通じない
ライブラリを使わない書き方はライブラリ使ってても使ってなくても通じる
ってところか？ クチャラーに自覚したらと諭したら
俺は普通に食べてるだけ
耳障りに聞こえるのはお前が悪いと言われたって感じか ■ このスレッドは過去ログ倉庫に格納されています
