どしたの急に

ネタをキレてると勘違いしてるんでしょ。
この回答じゃ「*」の意味を理解してないままなんだろうが
これくらい>>1調べたらすぐにわかることだわな。

ω(|)*

×ゼロデイ脆弱性
○マイナス312デイ脆弱性

理由は脆弱性が悪用されてからベンダーがその脆弱性に気がつくまで、平均して312日もかかっているから。
312日ってのはSymantecの調査報告な。

(*)が閉まんてっく

ベンダが気が付いたって、パッチがリリースされるまではゼロデイなんだが。

世間に認知されてない状態のことだな

本来ハッカーってのは
脆弱性見つけてベンダーに売るか闇の組織に売るか駆け引きする職業
んで闇の組織に売られた場合深刻な被害が起こるというわけです

オレオレ定義なんか訊いてねーし
ハッカーの解釈なんか、漫画の読みすぎだろ

>>856
それはゼロデイ攻撃な

は？なぜ「ゼロデイ」と呼ばれるか調べれば？

>>859

var w = window.open(...);
w.onload = function() { CheckFrame(w, m); };

とりあえずDOM構築完了を待とうぜ。あと

var form = w.document.forms['box_mylist_add'];

質問の際はDOM要素と分かるように、省略なしで書こうぜ。

>>859
ついでに、もういっこ指摘しとくと

undefined !== null // true
undefined != null // false

>>862,863 様
ありがとうございます！他の言語と混乱していたので、とても参考になりました。
勉強不足すぎてお恥ずかしい限りです。
重ね重ね感謝です。

お前らほんとくだらんことで争うよな
>>854はマイナス312デイ脆弱性と呼んだ方が名称として相応ではないかという皮肉交じりのジョークみたいなもんだろう
元ネタはこれだろうから読んでおけ
http://www.forbes.com/sites/andygreenberg/2012/10/16/hackers-exploit-software-bugs-for-10-months-on-average-before-theyre-fixed/

こんな事もわからずに突っかかる>>856>>861は頭おかしいわ

てやんでい、こんちくしょう！
こちとら脳味噌の容量がゼロでい！
おとといきやがれってんだ！

>>865
文脈も理解できないアホは黙ってればいいのに…

img要素の上でスクロールすると透明度が変わったりするの作りたいのですが
onscrollで上手くいきません
window.onload = function() {
　　　document.getElementById("gazou").onscroll = function() {
　　　　　　style変更;
　　　}
}
onscrollってスクロールバーがないと機能しないのでしょうか？
だとしたら良い解決方法とかあるんでしょうか？

>>868
ホイール系のイベントは、標準化されるのに時間がかかったのでちょっと複雑
WheelEvent, MouseWheelEvent, MouseScrollEventを使い分ける

http://developer.mozilla.org/en-US/docs/DOM/WheelEvent
http://developer.mozilla.org/en-US/docs/DOM/MouseWheelEvent
http://developer.mozilla.org/en-US/docs/DOM/MouseScrollEvent

ありがとうございます
firefoxだけちょっと違うみたいですね

ほんとJavaScriptクソだな

JavaScriptの問題じゃねーだろ・・

何の話だ

やーん、いやなのー
すくりぷとがじゃばじゃばしちゃってるのー

ほら、僕の黒夢もじゃばじゃばしちゃってるよ

Chromeのコンソールは実行したJavaScriptの再編集はできないのか
ログと実行部分を分けてフレーム表示とか

javascriptのアニメーションでwidthを変更する時
$('#hoge').animate({'width':300},500);
ってやるとスクロールバー消えるのは仕様？
max-widthとかだと消えないんだけどwidthだけ消えるのがどうも
消さないでアニメーションさせる方法とかあるの？

JavaScript関係なくてJQueryがどうなってるかだけでしょ。
jQuery使わずに素のJavaScriptで書けばできるんじゃないのかな。

今気付いた
どうやらheight/widthでは意図的にoverflowを消してるみたいだな

これだからお子様javascripterは。javscriptはjavascriptで考えるのが悪いクセだぜ
webデザイナーの俺はそんな問題3年前にとっくに気付いてクリアしてる
CSSのインポタントで解決

$('#hoget').animate().css('overflow', 'scroll');

おお、ありがとう
!importantの方が良いのかなこれは
animateで消した後.cssを直してるってわけだから

インポテンツ？

important規則はできる限り使いたくないなあ
場合にもよるけど

なんで？

おいちょっと理由説明しろ
important使うたびにお前のレスが頭の中で引っかかるじゃねーか

こんなことで優先順位いじる必要無いもの

importantが死んでも変わりはいるのも

代わりはいるなも

<div style="width:100px;height:100px;border:solid 10px black;border-radius:100px;" id="mouseOverTest"></div>
border,radiusが指定されている要素の、mouseover mouseoutイベントが発生する境界線ってどこですか？
document.getElementById("mouseOverTest").addEventListener("mouseover",function(){
document.getElementById("mouseOverTest").style.setProperty("background-color","red");
});
document.getElementById("mouseOverTest").addEventListener("mouseout",function(){
document.getElementById("mouseOverTest").style.setProperty("background-color","white");
});
で試したけどなんか仕様が固まってないような…
chrome 24です。

>>886
スレチだからあれだけど

基本的にCSSは
「同等以上のセレクタで最後に書いたもの書いたもの」が有効
っていう認識のもとで使われるじゃん
important規則はそれに対する例外になるから

ドキュメントが徹底されてて、そのような例外が完全に周知されていれば
問題は発生しづらいかも知れないけど、それ自体にコストがかかるし

try - catch - finally のfinallyはcatchが実行されたら実行されないって認識でいいですか?

これを読めるようになった方がいいよ。
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/12_Statements.html#Finally

finally文

filally文は、通常try～catch文の後に続いて書く。 catch節と違い、エラーが発生しなくても呼び出されて処理を行い、try節で行った処理の終了処理を記述するのが主な用途である。
ただし、次項で説明する様に、throw文が実行された場合だけはその例から外れ、finally節中の処理は実行されない。 ここにfinally節の存在意義がある。

>>893
難しすぎです。。
>>894
実行されないんですね

ありがとうこざいました

>>894
ここからのコピペか
http://ja.wikibooks.org/wiki/JavaScript_try-catch%E6%96%87
5年以上前からこの記述のままなんだ

wikiはダメだな

wikiの内容も間違ってるし、>>895は >>894を見て、
なぜ実行されないという解釈になったんだ？

throw文が実行された場合だけはその例から外れ、finally節中の処理は実行されない。
だろ

ただの皮肉。
その一文も間違いだし。