jQuery 質問スレッド vol.7 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
JavaScriptでDOM用ライブラリであるjQueryのスレです。
このスレはjQueryやjQuery UIの使い方やjQueryプラグインの作り方を質問するスレです。
jQueryを使って作る側のスレであって、こんなプラグインありませんか?と聞くスレではありません。
そういうのは自分で探してください。
ろくにサポートもされてなさそうな野良プラグインの使用はおすすめしません。
JavaScriptの質問は関連スレで質問して下さい。
■前スレ
+ JavaScript & jQuery 質問用スレッド vol.6 +
http://echo.2ch.net/test/read.cgi/hp/1465566635/
■関連スレ
+ JavaScript の質問用スレッド vol.122 +
http://echo.2ch.net/test/read.cgi/tech/1472426483/
+ JavaScript(ECMAScript)質問用スレッド vol.122 +
http://echo.2ch.net/test/read.cgi/tech/1472401404/
+ JavaScript の質問用スレッド vol.131 +
http://echo.2ch.net/test/read.cgi/hp/1478053599/
JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/hp/1465399470/
+ JavaScript & jQuery 質問用スレッド vol.6 +
http://echo.2ch.net/test/read.cgi/hp/1465566635/ >>829
> 座標っても領域やサイズなど色々あるのに何その根拠?ってのは俺も思った
座標って言ってない。「取得座標」だ。
領域やサイズの「取得座標」ってなんのことだ?
サイズの「取得座標」ってなんのことだ? >>831
いちいち細かい、それを揚げ足とりと言うんだよ
それくらい脳内変換しろよ 明らかに説明が足りないことを言う
誤解するのを狙って、実際に誤解したらそこを執拗に攻撃する。
罠だったんだな。 あ、分かってないと思うけど、フォームっていうのはHTMLの
フォームのことでこれはHTMLであってJavaScriptではないからなw >>837
だな
もうこれ以上は不毛なやりとりが続くだけだろう つまり俺だけがまともなことを言って、
そのまともなことを言われるのが気にいらないやつは
煽っておしまいということかね?w
お前はまともなやり取りをしたかって話だよ。 >>805
俺は答えを知らない
知っているのに答えないのと、知らないので答えられないのはまるで違う
あなたはどちらなのかね?
あなたが答えを知っているのなら、他人を冷やかすだけでスレに貢献しない人だ
あなたが答えを知らないのなら、知ったかで確証のないこと(>>802)を書くいい加減な人だ
どちらにしても、信用できる人だとは思えない >>841
俺は>>805じゃないが
質問者に答えてるのは俺だけだったと思うよ >>814
8つの条件の組み合わせを考えると、2^8 = 256 通りの組み合わせ爆発で、
CSS, JavaScript のどちらでも、プログラミングの設計段階で破綻している
こういう仕様を作ったら、ダメ >>844
表示、色、サイズ等を変更するなどよくあるケース
jQueryならチェーンメソッド1行で済む
問題は設計仕様ではなくSSだけで済まそうとするそのやり方 全部SS(スタイルシート?誰も使ってない略語を使うな。恥ずかしい)
でやろうなんて言ってない。
JavaScriptでやるのは状態の管理までで
見た目はスタイルシートでやるという話だ >>846
>JavaScriptでやるのは状態の管理までで
>見た目はスタイルシートでやるという話だ
それは皆わかってるからもういいよ
くどいったらありゃしない
それを踏まえた上で話してんだろ >>848
元はその線引きをどうするということなんだよな
例えば実際、1つの要素にこれらを指定するときみんなはどうしてるのだろう?
表示
<label><input type="radio" name="hoge" value="block" checked>表示</label>
<label><input type="radio" name="hoge" value="none">非表示</label>
色<input type="color">
文字サイズ
<select>
<option>8</option>
<option>10</option>
〜
<option>72</option>
</select>
文字サイズは少なければ属性でできなくもないが<option>変更の度にCSSも変えなくてはならないので保守性悪い >>849
そんなものはユーザCSSの範疇なので、作ろうとも思わない >>842
>>776?
唯一答えてるのは776だけだが >>853
頼むからそいつを刺激しないでくれ
餌を与えれば、誰にでも食いついてくる輩だぞ >>852
不必要とはどういうこと?案件によるし君がこの件の何を知ってると?
そんなに特異な条件ではないぞ たぶんお問い合わせフォームかその延長くらいしか手がけたことなくて想定できないのでは >>853
フォームを使わない派の人?
であればリロードしたときや進む・戻るを
押した時にフォームの値と画面がずれる件を
どう対処してるか聞きたいんだけど >>857
俺が言いたいのはそこなんだよね。
みなさん、そこまで考えたことありますか?ってこと
確かに少しぐらいフォームと見た目がずれていても
ブラウザのせいですとか言って逃げるのもありだし、
キャッシュを強制的に破棄してリセットするのもありだろう。
仕事は時間が有限に有るわけじゃないから手抜きするのも
ありなんだけど、それはそれとしてブラウザの挙動をちゃんと
理解して最善の方法も提案できないとダメだと思う。
それができないと小規模なコードしか書いたことがないように見えてしまうよ フォームを使わない「派」?
<form>は使ってるよ
ずれは案件による。大雑把に言うと
・単純なものはブラウザまかせ
・図形など複雑なのは初期化(クッキーが関係してくる場合もあるので)
いずれにしろ必要なときに正確に取得することには注意してる
当たり前だが >>859
図形とフォームが結びつかないんだけどどういうこと?
ドローツールみたいな物の話をしてる? 加えて書くと、<form>を使うか、使わず部品だけ使って即座に反映させるかは時と場合による
ユーザ目線での使いやすさ、他の部分及び全体との統一性、仕様、引継ぎなら元の状態などなど
書いててばかばかしくなる >>861
ユーザー目線での使いやすさやそこに書いてある理由は
フォームを使わない理由にはならないよ。
例えば、日付入力のinput要素があったとして
最近のブラウザはHTML5のリッチなインターフェースを
出すようになったけど古いブラウザでテキスト入力になるから
ユーザー目線で使いやすように独自で作ろうとなったとする。
だけどこれはフォームを使わない理由にはならないのはわかるよね?
Bootstrap Datepickerとかを使ったことが有る人ならわかると思うけど
textタイプのinput要素がリッチな日付選択フォームに化けるんだよ
この発想の応用で「ユーザーが何かしらの値を入力するもの」は
全てフォームのinput要素で実現できる。
(もちろんinput要素を使いやすいインターフェースに化けさせるわけだけど)
たしかに使いやすさのためにフォームが適切じゃないのはあるだろうけど
ドローツールみたいな具体的な利用例を書いてくれてないので、説得力がないんだよ。 たしかに案件による。殆どの案件はフォームで良い
フォームが適切じゃない案件はほとんどない。
探せば有るだろうけどぱっと思いつかないぐらい。
という意味で案件による。 「案件による」っていうのは反論ではない。
何が食べたい?なんでもいい。これと同じぐらい意味がない答
だからそんなにムキにならなくていい。 いやそれはそうなんだけど、せっかくレスするなら
自分の意見を言ってくれと >>862
>説得力がないんだよ。
別にいいよ、そんなつもりないから
>>857にレスしただけだ
クライアントでもないお前さんにあれこれ言われる筋合いはないし、
うちのやり方なんてどうでもいいだろ? 割り込み失礼。
>>849の1つの要素(オブジェクト)に、>>852の不必要なものって何でしょう?
タグ何か余分? > うちのやり方なんてどうでもいいだろ?
あなたのやり方はどうですか?
という質問に対して、
うちのやり方なんてどうでもいいだろ
は、なんのために答えたんですか?レベルなんだけどw
正解が有る問題だと思ってるのかな?
正解がない問題は、あなた(だれか)のやり方を
聞くしか無いでしょうに。 >>871
客にどちらが良いと思う?という質問された時に
場合によるなんて言っていたら仕事無くすよ?
場合によるならば、○○の場合はこうで
××の場合はこうです。という答え方をしなきゃ
質問している方だって「場合による」っていうのは
分かって専門化の判断基準っていうのを聞いてるんだよ。 >>870
↑うざーーーーーーー
絡まないほうがいいよ つか、なんで新人に対しての顧客対応の
やり方みたいなのを説明しなきゃならんのだよw >>872
↑もっとうざーーーーーーー
自分が客だとでも いや「場合による」で答えたつもりになってるのは
恥ずかしいなぁって話だよ。 >>873
871が読めないらしい
もうスレ違いになってきてるしな >>877
そういう話なら、>>871にレスしている
>>872を読むべきでは? jqueryスレッドがあったのでこちらに書かせてください。
fancybox3のサイトの記述通りにパーツを落とさないでリンクを貼るだけのやりかたで
fancyboxを動かしています。
この場合はオプションが追加可能な下記スクリプトで
<script type="text/javascript">
$("[data-fancybox]").fancybox({
オプション
});
全画面中の透明なし、背景色の指定、枠線追加等はできないでしょうか?
やはりcssとjsファイルを落として自分で書き換えないと無理でしょうか?
どなた教えてください。 分析解析などの分野でOK/キャンセルボタンがない場合がある。
resetもあるわけがない。(事前確認によるその類はあるが。)
よってformが不要なことはある。 OK/キャンセル/resetボタンがないから
formがいらないっていうのは短絡的だな
input要素を一塊にして扱うならば、
formにしておくことで、JavaScriptから
一括でデータを読み込んだりキャンセルできる 短絡的な発想ついでに言っておくと、
submitボタンがないからといって、
Ajaxを使わなければいけないってことにはならない。
formにしておけばsubmitメソッドが使えるからだ だろ、その分野を知らない>>881
そこはclickだろ submitがいらないっつーのに「submitが使えるからだ」て >>884
よく読め
OK/キャンセル「ボタンがない」場合だ
ボタンがないだけでsubmitしないとは書いていない それをいうならば
「書いていないからしない」
も思い込みなわけで JavaScript飛ばしてjquery勉強するやつなんなの?
業界未経験者採用してる会社って、新人にどういう順番で教えてる? とりあえずの戦力と言うことで…
使い捨てじゃないの?
大事に育てたいならJavaScriptは必要だね。
あと、とっかかりとしてjQなのかもよ。
いずれは内部の事も知らないといけないけど、
まずは何でもいいからねーって。 >>865
例えば人員の表で、男のみや女のみの絞込み、ID順に並び替えなど、
よほど処理時間かからない限りOKボタンなど配置しない
よくあるケースで今までもたぶん目にしてると思うよ
気にして見てる人は少ないだろうけど
あと君に言うわけではないが「フォームが適切じゃない」と>>862さんが書いてるが誰もそんなこと書いてないかと
なくてもよくね?の類は見られるが >>895
それはぱっと思いついた話だけど、、一歩ずつ考えていこうか?
まず、表全体のデータがクライアントにあるとしよう
(サーバー側にあっても同じことなんだがとりあえず)
絞込などの条件は、場合によっては1つしか無いって場合も有るだろうけど、
どちらかと言えば1つしか無いのは例外で、絞込項目は複数あって
並び替え機能もあるとしよう。
そうすると変更した項目だけからでは、表データを作ることはできない。
なぜなら、性別での絞込 + 年齢での絞込 + ID順 といった情報が
すべて揃ってないと表示する一覧は組み立てられない
そうすると必然的に複数の条件は「人員の表を出すために必要な条件」と
してグループ化考えることができるわけよ。
ボタンがなくて即時反映したとしても概念的なグループが存在する。
そのグループをフォームとして考えればいいわけ。
---- ここまではフォームとして作るのが自然でしょ?っていう話。以下はJavaScript側のメリット ----
グループをフォームとして作っておけばこれはJavaScript的にも便利なことがあって、
フォームデータをシリアライズするライブラリを使ったり作ったりすると、
条件オブジェクトとして{gender: 'man', age: 20, order_by: 'id'} みたいな
ハッシュを生成するのが簡単になる。
こういうライブラリは汎用的なライブラリとして作れるのでテストもしやすい。
そして全体のデータを、これらの条件オブジェクトを使って、フィルタするようなものを作る。
DOM操作が不要でこれも汎用的なライブラリにできるだろうからテストしやすくなる
最後に表示すべき表データからDOMを生成して完成。 >>897
divはデザインのために使うものだから
input要素をまとめるのには適していない
例えばこんなのとかnameが一緒でも
別々のものとして扱ってくれるし
<form id="form1">
<input type="radio" name="a">
<input type="radio" name="a">
<input type="radio" name="a">
</form>
<form id="form2">
<input type="radio" name="a">
<input type="radio" name="a">
<input type="radio" name="a">
</form>
名前空間みたいなもんだよ。グローバルに置くよりも
form配下においておけばメンテナンス性もよくなる 名前空間は変数のバッティングを防ぐためで当てはまらない
メンテナンス性向上はあるがHTMLに関しては必要なければ余計な囲いはないほうがいい
<p>や<ul>にクラス付ければ済むのにわざわざ<div>つけることはない
便利なのはわかるが今回それでなくてはならない理由がないんだな
使うか否かは記事の内容や本人次第だろう
押し付けがましいにもほどがある 上とは全く別件です
フォーム(#fm)の中にリセットボタン(#rst)を設置
Windowを閉じる前に確認
$('#rst').click(function(){$('#fm').reset();});
$(window).on('beforeunload',function(){return '終わるよ';});
#rstでも終わるよダイアログがでてしまうのですがどこがいけないのでしょうか? >>900
押し付けてないよ?
事実としてグループととして扱えるように
form要素で囲んでおくとのが良いってだけ
form要素で囲んでおくとメリットは有るが
デメリットはない >$(window).on('beforeunload',function(){return '終わるよ';});
$(window)
ここには普通、セレクターが入る
$('#fm')
とか 「js event bubbling」で検索!
DOM イベントのバブリング。
子要素から、親要素の方向へ、イベントが伝播されていく
event.stopPropagation
イベント伝播を止める >>900
> 必要なければ余計な囲いはないほうがいい
それ大事
引継ぎで何か意味あるのかと無駄な手間が減る jqplotで凡例の項目の一部をデフォルトfalseにしたいのですが
どのようにすればできるでしょうか?
例えば以下のサンプルサイト様の凡例「花子」を
初期起動時にはデフォルトでfalseにするイメージです
http://alphasis.info/2012/04/jquery-plugin-jqplot-line_charts-legend-numberrows/
よろしくお願いします Windowを閉じる前に確認、とは親Window=ブラウザです
>>904
具体的にお願いできないでしょうか
$('#rst').click(function(e){e.stopPropagation()});
でも同じでした >>905
それは別に大した問題じゃないかな。
一連のフォーム要素があることに対するパラメータ群であれば
formで囲えるだけじゃなくて名前もつけられる。
例えばsearch_paramsとかcustomer_infoとかね
そうするとこれは検索条件の名前なんだ、顧客の名前なんだと
意図が明確になる >>908
もっと簡単な例で、質問してくれ
何を言っているのか、さっぱり分からない >>908
こうかな?
$('#rst').click(function(e){e.preventDefault(); e.stopPropagation(); $('#fm')[0].reset();}); >>911
完璧です!邪魔だったクエリまで消えてくれて
ありがとうございます 珍しくスレ伸びてると見たらdiv厨ならぬform厨が張り付いてたのか
こんだけ拘っておいて押し付けてないってどんな神経なんだ 押し付けてないよ?
どうするのが良いかの話をしているだけであって
悪い方を選ぶのは自由だから >>916
満足とかそういう問題じゃなくて
単にあるべき姿を言ってるだけ 今回はreset()は使わないですしformは不要なので使わずにやります。
みなさんどうもでした。 白々しいw
わざわざ>>751のふりして、悪いやり方をしますって
宣言するとか、やるだけ無駄だってわからんの?w >>917
あるべきという言葉はそれ以外を否定しているわけで結局のところ押し付けの婉曲表現です
なぜならそのあるべきから外れることは「間違いである」と言っているのと等価ですので
better to beではなくshould beまたはmust be(場合によってはshall be)ならね >>920
http://ejje.weblio.jp/content/%E3%81%82%E3%82%8B%E3%81%B9%E3%81%8D%E5%A7%BF
あるべき姿の英語
主な英訳
ideal form; ideal state
私のあるべき姿
what I should be
英語の「must」「have to」「should」の基本的な使い分け方
https://eikaiwa.weblio.jp/column/phrases/natural_english/difference_must_should_have_to
「should」は助言や提案を表す
「should」は「〜したほうがよい」というニュアンスの助動詞です。助言や提案をするときに使われるため、
「must」や「have to」に比べて強いニュアンスはありません。 >>921
should=〜した方がいい は日本の英語教育の害悪の一つ しなければならない ・・・ must
するべきである・・・ should
ある(する)べきなんだから、それ以外を否定しているわけじゃない >>925
日本語の勉強した方がいいんじゃないか?
「〜するべき」と言われていることに反した行動をとった人がいたら普通眉をひそめるだろ?
それってどういうことか考えてみなよ >>919
いえ、本人です。
もちろん普通のお問い合わせフォームでは使ってますよ。 レス数が900を超えています。1000を超えると表示できなくなるよ。