jsを弄る前にhtmlとcssを勉強したほうが幸せになれるぞ

>>351
やってみる。
しかしどの程度までできるようになったらいいんだ？

>>352
HTML５とかDHTMLの質問スレッドがあればそこに行った方がいい

もはやここは隔離スレだな

質問者が初心者なのはいいんだが、回答する方に初心者がいると不毛な議論に発展するんだよな

初心者スレだからそれでいい

HTML5が流行ってWebProgから人が流れ込んできたせいだな
2012年はHTML5の時代やで

本スレがないのがよくない

あれ、名前が…。

jQueryでドロップダウンメニューをslideToggleで作ったのはいいんですが、
連続でマウスオーバーしたらその回数だけ開閉するのはどうにかならないんでしょうか？

調べてもそれらしい情報がでてこないもので・・・

>>367
eval()を使うのが間違い。parseInt(文字列, 10)を使う。
>>366
onmouseoverではフラグ立てるだけにして、setInterval()から呼ぶコードで
フラグ立ってたらメニュー開くようにすればいいんじゃないかな。

eval不要説唱えてる奴は宗教でしょ。
言われてた当初はそれなりに意味があったのかもしれないけど
多くは思考停止して闇雲に追従しているだけみたいな。
スレの性質に関係なく「sageろカス」とかいうのもその類。

「スクリプトのコードはコメントタグで囲わなきゃいけないんだよ＾＾」なんて
自称JSそれなりに知ってる人さんから昔優しく“指導”されたことがある。
そのくせ「Netscapeなんてもう誰も使ってないし切り捨てていいよ」みたいな。はぁ。

自称JSそれなりに知ってる人さんにとっては、Netscapeなんかよりも
JavaScript非対応でコードが文字列としてずらずらと表示されちゃうブラウザ
（NCSA Mosaicとかですかね？）の占めるシェアの方が無視出来ないらしいです。
そういうくだらないしがらみはもう捨てていきましょうよ。

eval()必要説も同じくらい宗教なんだよね。宗教論争、無意味でスレの浪費だからやめてほしい。
せっかく終わったのに上から目線でまた火をつけるとかもやめてほしい。

>>366
少し待ち時間入れればいいよ
マウスオーバですぐ発火させないで、setTimeoutで20msecくらい
待ってから表示させるだけでだいぶ違う
触った時のレスポンスと待ち時間はバーターだから丁度よいタイミングに
なるように待ち時間をすりあわせするといいよ


ここまで書いて>>368に気付いた…
せっかくだから投下しときますすんません

まあevalはCのgotoと同様に、宗教上?の理由で嫌われているのと同様だろうな。
要するにユーザーの入力を単なる文字列では無く、
JavaScript的(あるいはDOM的)に意味のあるものとして利用するのは危険なので、
evalでもinnerHTMLでも、本当にその文字列を使って大丈夫かどうかを必ず意識する必要があるという事。
初心者云々は単に慢心を生むだけなので、初心者経験者は全く関係無い。
evalが嫌われるのは、代替手法が無いような本当に必要となる場面が少ない(JSON文字列をJSONオブジェクト化するなどくらい)ので、
わざわざリスクのある手法を回避したいという人間が多いからでは。

>>370
うだうだ言ってないで早くコードかけよ

>>373 ん？数式の解析とかは >>328-329 にあるからね。
>>372 とっても賛成。テンプレに入れるかはともかく、Q&Aにしてみた。

Q. eval()は使ってはいけないと言われたのですがなぜでしょう。
A. ユーザ入力をそのままeval()に与えるということは、ユーザにあなた
のプログラムを全く任意に改変させるのと同等なリスクがあります。
また、プログラム保守上も、そこで「何が」起きるかコードを見たとき
に分かり難くなるというリスクがあります。なのでeval()を使う際は
(a)与える文字列は予め検査して想定されている事だけが起きることを確認。
(b)そこで何が起きることを想定しているかをコメント等で記述。
の2つを守るのがよいスタイルですが、これは一定の手間が掛かります。
過去スレにあるほとんどの(99%以上の)事例は「数値への変換」「変数
の設定」など自然かつ安全な代替手段があるものなので、そのような
ものを知らないレベルの人が安易に使うことを警告して「eval()禁止」
と言われることが多いようです。eval()を使わなければできないことは
確かに存在しますが、そのようなことで普通のWeb制作者がやりたいこ
とは大抵、上記の要件をカバーしたライブラリなどの形でパッケージさ
れたものがあるので、自分で直接eval()を書こうとする前に十分見直さ
れることを薦めます。

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　 　 　 　 　|　　は　　ん ・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;":: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

やっぱり宗教だなあ
evalに限った危険なんて１つもないのにｗ

ユーザーが入力したコードが実行されて何が問題なのかわからない
あるとしても重箱の隅を突くような特殊なケースじゃないか？
そんなんだったらevalに限った話じゃない

>>366

var obj = $(selectors).not(':animated');

animate()実行中要素を選択しない


var obj = $(selectors).stop();

実行中animate()を停止

別にユーザが任意の改変をしてもかまわないという人は別にそれでいいんじゃないの。
ふつう、ユーザ入力に対してチェックとかするよね。それはサーバ側に送られる
ユーザ入力をある程度制御しないとまずいと思うからやるんだと思うけど。
JS上でのチェックとサーバのチェックと２重にするところを、サーバだけの
チェックになっても構わないとか、よそのAPIをJSから直接叩いてるところで
何を叩かれても構わないとか、そういう意味になるわけどいいんだろうか。
漏れはそれは嫌だからユーザに任意の改変は許したくないと思うわけで。

ユーザー入力じゃなくて開発者の意図しない入力って言えよ

>>380 なるほど御意。

>ユーザ入力をある程度制御しないとまずい
これは間違いだろ
JS側での入力チェックはユーザビリティの観点以外の何物でも無いと思うのだが

全くもって意味わからんな
ユーザーが改変したいと思ったときは
わざわざソース調べてここにeval使われてるから狙おうとかしないだろ
普通にアドレスバーに打つだけ
それにそもそもformチェックでevalの出番はないでしょ

屁理屈こねないで使うなって注意されたら使うなよ。
躾がなってないなこいつら。

>>382
フォームとかからサーバに投げる前段階としてのチェックならそうだけどね

入力から、それによって引き起こされる何らかのアクションまで
ブラウザ側で完結してる部分なら、当然ブラウザ側でちゃんとチェックしないといけない

問題とされている領域を間違えてるっていうかなんと言うか…
jsでアプリケーション作ったこと無いから、もしかしてこういう発想しか出来ないのかな

入力をチェックすることとeval禁止が直接結び付かないんすけど…
こいつさっきから何言ってんだ？
例えば
NAME=prompt("主人公の名前を決めてください","")
～NAMEのチェック～

とやるのはわかるが
こいつが言いたいのは

NAME=eval(prompt("主人公の名前を決めてください",""))
～NAMEのチェック～

ってことか？？

>>385
うだうだ言ってないで具体的で示せよ。
特殊じゃない凡例をな。

evalは悪魔
悪魔は不要
不要不要
不要
悪魔
悪魔
不要
悪魔
不要
悪魔
不
要悪
魔
不
要
悪
魔不要悪魔不要悪魔

>>385
クライアント側のみで完結する方が珍しいだろ。
通信が発生する時点で完結はしないからな？
それに
>サーバ側に送られる
これがついてる時点で"ブラウザ側で完結してる部分"なんて意図するわけ無いだろ
ブラウザ側で完結する部分ならチェックするのは当たり前

文字の色を上下でわける方法はありますか？
http://jsfiddle.net/gxuJw/
このような感じに書いてできると思ったのですができませんでした。
アドバイスおねがいします。

そういう特殊なことはブラウザ間で差が出るからやめとけ
素直にシンプルにCSS3使っとけ

>>107お願いします

>>393
えー、別にその要素のXY座標を求めて差し引くだけじゃないの。
offsetTop、offsetLeftで調べてみては。

>>394
今から調べてやってみます
どうもありがとうございます

>>395
マウスイベントのoffsetX,offsetY

>>393
var xo = $('selector').offset().left;
var yo = $('selector').offset().top;
var x = Math.floor( event.clientX - xo - 180);
var y = Math.floor(-event.clientY + yo + 180);

こんなかんじでやれる。

±180消し忘れた

jqueryは甘え