+ 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にして見えないようにしてください。文句をつける=荒らしです 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よりも多い どんな気分?w 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 違うものに同じデザインを適用したいってことないでしょw Webデザイナと連携したことないけど何かいろいろ闇があるんですか? 切り分けたい時もあるし切り分けたくない時もある 切り分けられないを強要するライブラリということだ あるわい! 違うものであってもデザインが同じなら クラス名も同じにするんだい! デザインが赤なら、クラス名もredにするだろ! デザインが同じでも、本質的に別物なら それは違うクラス名を与えるべきだよ CSSに他classのスタイルを継承する文法があれば筋が通るんだけどね デザインが同じなら同じクラス名にしたいっていうのは このボタンの色は青でフォントサイズ2emですね。 こちらの見出しも青でフォントサイズも2emですね。 ならボタンと見出しでデザイン一緒ですから 同じクラス名にしましょうって考える人? JavaScriptを使う人はHTMLとCSSのことも理解していなければ だめだってわかる典型的な例だな なぜかJavaScript使う人でHTMLやCSSが苦手な人が多い 違うものに同じスタイルを適用したいからって クラス名を同じにするとか愚の骨頂 素人同然だわ HTML仕様的にはclassはスタイルの為のものであってJavascriptの為のものではないはずだが idはscriptから参照するためという目的が明示されてるが 併記されているclassにはそれがない 同じclassが同じ振る舞いであるべきかどうかは定かではないと言っておきたい > HTML仕様的にはclassはスタイルの為のものであってJavascriptの為のものではないはずだが 思い込みな。何処かに書いているというのなら言ってみてくれ ちなみに、idはスタイルのためのものかい?w どうせ適当な事を言うだけ言って逃げるだろうから 書いておくわ 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用ライブラリをなんでもできるライブラリに しないといけないんですか? どんな機能にも対応している神ライブラリとでも 思っていたんですか? アホですねw ムキー! お前らが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=文字列 をサーバーサイドで受け取る時に文字列中に¥rや¥nも渡す事は出来ますか? >>685 一番の問題はそう思われてるってことだと思うぞ jQuerer含むライブラリスタが過剰にライブラリを推してるのは事実 度々スレ分離したり議論になってるのにまだ自分たちがどう思われてるのかが分かってないのか > 一番の問題はそう思われてるってことだと思うぞ jQueryのアンチが変なふうに思い込んでるのは アンチが悪いってことで終わりじゃね? ライブラリの書き方はライブラリ使わないと通じない ライブラリを使わない書き方はライブラリ使ってても使ってなくても通じる ってところか? クチャラーに自覚したらと諭したら 俺は普通に食べてるだけ 耳障りに聞こえるのはお前が悪いと言われたって感じか react.jsやangular.jsが役立つ大規模案件、とは具体的にどの程度の規模のサイトですか? 今まで小さな企業でしか勤めたことがなく、大規模案件と言われてもイメージが湧きません >>693 てことは一生知る必要がないんじゃないか すいませんageてしまいましたね 今のままの小さい仕事しかせずにjavascriptと言えばjqueryでチョロチョロ、みたいなキャリアで本当に将来生き残れるのかという不安があるのです あとは、自分がjqueryしかできないから会社も大きな仕事が取れないんじゃないかとか考えてしまったりですね どの位大規模かというと、最近YouTubeがPolymerを導入した だが、そのバージョンはv0.いくつのもの、今の最新はv3 そのくらい年単位で開発する案件に使うもの そこからわかると思うがフレームワークは前もって勉強する必要はない 実際使うべきときには役に立たないから 大手も使うと決めたときに改めて勉強会を開くなりして対応してる 離脱したくても離脱しづらくなるから使うなら見合った理由が必要 大規模だから使うというより 少数の比較的小規模な会社が 使い続けてく方が多い印象がある ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる