+ 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にして見えないようにしてください。文句をつける=荒らしです >>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 そのくらい年単位で開発する案件に使うもの そこからわかると思うがフレームワークは前もって勉強する必要はない 実際使うべきときには役に立たないから 大手も使うと決めたときに改めて勉強会を開くなりして対応してる 離脱したくても離脱しづらくなるから使うなら見合った理由が必要 大規模だから使うというより 少数の比較的小規模な会社が 使い続けてく方が多い印象がある jQueryってもう役目が終わってるんだよ いい加減目を覚ましたほうが良い 作者も見放してReactやってるじゃん jQuery 73.2%(前年比 +1.4%)、React 0.6%(前年比 +0.5%) jQueryの役目が終わってからjQueryの役目が終わったというように https://w3techs.com/technologies/overview/javascript_library/all w3techsによると2017年1月の時点で71.9%のサイトが JavaScriptのライブラリとしてjQueryを使用していることが判明したが それから1年たった2018年1月現在、73.2%に1.4%も増えていることが判明した。 またAngularは0.5%、だがReactが伸びてきており0.5% とAngularを逆転したことがわかる だがjQueryには大幅なさをつけられており取って代わるのは いつになるのか動向が注目される >>701 これからの自分たちがどうしていくかの話をしてるのに 他の人が今何をやってるのかを気にするって意味がわからんな 良く使われてるのは所謂「枯れた技術」とは言えるけど 熟れた物ってこれから先腐っていくこととほぼイコールじゃん HTTPがまだ周りでよく使われているからHTTPSにしないって言ってるのとかと同じだぞ? >>702 せやな、一年前に、これからはjQueryは減っていくとか これからは腐っていくとか予想を立てた人恥ずかしいよな これから?来年にはまたjQueryのシェア増えるんじゃね? AngularもReactも熟れる前にくされなきゃ良いけど Angularは一回腐れたよな HTTPSは費用と処理と通信のコストがあるからなあ >>703 > HTTPがまだ周りでよく使われているからHTTPSにしないって言ってるのとかと同じだぞ? わかったわかった。HTTPSは最初からある程度使われいたからな 何かのフレームワークの使用率が10%を超えたら考えよう。 それでいいだろ? >>696 中小規模の会社が請ける規模の案件なら 素のJSだけでも十分やってけるよ 昔と比べて格段に安定して書けるようになってきたから 万が一必要になったらその時必要な分だけ調べれば済む 大規模な会社がReact使っているかと言ったらそうじゃないからな なにせ0.5%しか使われていない Ruby のHTMLのテンプレートエンジン、erb では、 HTMLとRubyの構文が交互に来るから、わかりにくい。 PHP なんかもそう <% @items.each do |item| %> <li><%= item %></li> <% end %> もしRuby に、JSX があれば最強だろう JSXもクソじゃん。条件分岐とループごときに 言語の機能を使うようじゃダメ mustacheが最強 ここまで見てきて分かったのは 仕様というのは作って環境というのは動かしていくもんだと考えてる開発者と 仕様というのは与えられて環境というのは落ち着いたものに浸かるもんだと考えてる開発者じゃ 話合うわけ無いってことだな 問題 「作って環境というのは動かしていくもん」と 「与えられて環境というのは落ち着いたものに浸かるもんだ」の 違いを完結に述べよ >>712 簡潔に言えば仕様標準化と実装に関わっているかどうかってことで言えるんじゃない? 企業で言うとミーティングやカンファレンスに社員を出張させているかどうか 別にそれは社会貢献のためではなくて自分たちのやりたいように環境を動かすためにそうしてる 環境というが実際は人 その場にいる仕様や実装書いてる人に直接会って、 こここういうバグが有るんですよとか、こういうところで困ってるんですよとか話ができるってことが重要 やっぱりそれはオンラインでプルリクエスト送るのとはぜんぜん違う 仕様や実装を作ってるのは人間で、意外と少数だから、向こうも幅広い意見を汲み取ろうとはしてるけれど どうしても自分たちの近い範囲が得をする恣意的なものになってしまう そのために皆わざわざ録画で見れるものを会場まで行く >>693 です ひとまず自分のやりうる業務のことを考えたらjqueryやes6の習熟でひとまずは大丈夫だと感じました まずはjqueryを使い倒してみて、jqueryでは不十分だと感じられるようになった段階で改めて考えてみることにします ありがとうございました オブジェクト型の分割代入やasyncジェネレータなど 既にモダンブラウザで使える重要なES2018の機能もあるよ 初めてのJavaScript 第3版、オライリー、2017 ES2015 の本。 これを読めば、クラスとか、素人はあまりの難しさに愕然とするだろう 素人が騒然とするのは当たり前だろ? いや、お前がプロで、難しくて騒然としたっていうなら それはそれで面白いことだがw 人間のメンタルモデルとコードを一致させられるから 理解しやすくなる。可読性の向上 ひねくれた方法で「実現できる」じゃだめなんだ 普通に書いて普通に読めなければいけない 設計で方法論に従うことができる。 しかしテストでパターン数爆発で大抵死ぬ。 JSにテストなんて必要ない、トライアンドエラーがベスト テストしたいんならよりし易い言語で書いてコンパイルすべき > テストしたいんならよりし易い言語で書いてコンパイルすべき ではその、よりし易い言語がなにで どういう理由で、よりし易いのか言えるんでしょうな? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる