私的なメモなので、あまり信用しないでください。 実際の動きは自分で確認してください。 基本的に、IEは6が対象となっています。 それ以外のバージョンの話題も含まれるかもしれませんが、まあ気にしないでください。 メモというより独り言になっている部分もありますが、今更編集しなおすのも辛いので軽くスルーしてください。 また、同じような内容が繰り返し記述されている可能性もありますが、まとめる気力がないのでスルーしてください。
工事中・・・
現在ナッシングです。
bodyタグのscroll属性が不正な場合（yes又はno以外の値）、clientWidthプロパティで取得できる値が不正っぽい。
window_onloadイベントはドキュメントが全てロードされた後に発生するが、 htmlタグの外に書かれているスクリプトなどに関してはこの場合関係ないかも。 この場合、全コードをダウンロードする前にonloadイベントが発生する可能性あり（と言うかhtmlタグの外にコードを書くべきではない）。
IMGタグに設定されたイメージの正確なwidthとheightは、イメージがロードし終わった後でないと判断できないっぽい。 例えば、イメージを設定した後すぐにwidthを変更すると、元の画像のwidthと変更後のwidthの比率に応じてheightの値も自動で変更されるが、 この時のheightの値が正確な値でないことがある。この場合、イメージのロードが終了した後（imgのonloadイベント時）、 自動で正しいheight値が設定されるっぽい。 よって、正確な値が必要な場合はimgのonloadイベントで値を処理しないと駄目っぽい。
window_onunloadの中で他のページへのリダイレクト等を行っても、再びwindow_onunloadイベントが起こる事はない （考えてみれば当たり前かもしれないけど・・・再帰が止まらないから）。
クライアントサイドスクリプトの場合、自ドキュメントのlocationをreplaceした時点でそのルーチン内の処理が終了するわけではない。 明示的にExitしていなければそれ以降の処理も行われるので、特に理由がなければreplaceした後にExitするべき。
絶対にそうだとは言えないが、調べたところでは以下のような関係だった。
1. 子ウィンドウを持つウィンドウは全ての子ウィンドウのreadyStateが"complete"にならないと、
自ウィンドウのreadyStateは"complete"にならない。
また、正確にはreadyStateが"complete"でdocument.onReadyStateChangeイベントを抜けた時に、
完全に"complete"したとみなす。
2. window.onloadイベントは自ウィンドウのreadyStateが"complete"になった後、発生する（正確な判断は1と同様）。
3. 兄弟ウィンドウ同士は非同期で動作する。
4. （重要）1及び2からウィンドウが"complete"する順番は子ウィンドウから正しく"complete"する事になるが、
各ウィンドウのonloadイベントに関しては必ずしも同期しているとは限らない。
親ウィンドウのonloadが子ウィンドウのonloadよりも先に走る可能性もタイミングによっては有り得る。
5. 他のファイルをインクルードしているものに関しては分からないが、
readyStateが"complete"になるのはhtmlタグ内のドキュメントが読み込み終わった時ではなくて、
そのファイル全体のソースが読み込み終わった時に発生しているっぽい（どっちにしろhtmlタグ内に全て書いていれば関係ないが）。
補足：もし、子ウィンドウのロードを非同期で（同時に）行い、
各ウィンドウの初期処理を正確に順番通りに行いたいためにトップウィンドウのonReadyStateChangeイベント、
もしくはonloadイベントで子ウィンドウの初期処理を順番に行うのであれば、
子ウィンドウのonReadyStateChangeイベントもしくはonloadイベントに初期処理を入れるべきではない。
トップウィンドウからの初期処理関数呼び出しと、各子ウィンドウのonloadイベントに初期処理が記述されている場合、
どちらの初期処理が先に走るかは不定。
よって、もう片方の初期処理が完了している事を前提でコーディングすると、処理が走るタイミングによっては未初期化でエラーが発生するかも。
1. タグの属性として記述する。
<frame id="fraTest" onReadyStateChange="fTest">
2. スクリプト内で動的にバインドする
<html>
<head>
<script language="vbscript">
Function fTest()
If (fraTest.document.readyState = "complete") Then
fraTest.document.onReadyStateChange = Null
' 行いたい処理を記述・・・
End If
End Function
</script>
</head>
<frameset>
<frame id="fraTest" src="〜">
</frameset>
</html>
<script>
If (fraTest.document.readyState = "complete") Then
' 行いたい処理を記述・・・
Else
fraTest.document.onReadyStateChange = GetRef("fTest")
End If
</script>
1の方法ではイベントプロパティにバインドされるわけではない。
よって、onReadyStateChangeイベントプロパティの値はNull。
そもそもonReadyStateChangeはframeタグには属性としてバインドできないかもしれない。
MSDNライブラリの説明では適用できるタグとしては載っていなかった。
documentやscriptタグはリストされていた。
でも、取りあえずIE5.5では正常に動く。
2の方法ではイベントプロパティに直接バインドするので、用が済んだらNullを代入しておいた方がいいかも。
ちなみにバインドする時に使用している「GetRef」関数はVBScriptバージョン5.0から使用可能。
JavaScriptの場合は直接関数名を代入するだけでバインドできる。
フォーカスをセットする前に、必ず対象コントロールのdisabledをfalseにする。 disabledがtrueのコントロールにフォーカスをセットしようとすると、スクリプトエラーが発生する。
disabled属性が設定されているコントロールの値はFormのSubmit時に送信されないので注意。
onReadyStateChangeイベントでコントロールのロック解除（disabledプロパティ）を行うと、
window_onload時にはロックが外れている可能性があるのでwindow_onloadイベント中に記述した初期化処理前にユーザが操作できてしまう可能性がある。
特に理由がない限り、画面表示時のロック解除はwindow_onloadの最後で行うようにする。
同じような理由で、
window_onload時にコントロールのロックを行うとHTMLがダウンロードされてからwindow_onloadイベントの該当コードが実行されるまでは
ロックが外れている可能性があるので、画面表示時のロックはhtmlタグのdisabled属性で行うようにする。
特に、HTMLソースの先頭に対象コントロールのHTMLコードが記述されている場合はまずい。
ただ、htmlタグのdisabled属性を指定すると、textareaタグで値の表示がおかしくなる場合があったので注意。原因は不明。
htmlタグより前にスクリプトをインクルードしたり直書きしてもスクリプト自体は動作するが、ブラウザの設定によっては文字化けする可能性がある。
なので、
（htmlタグの外に書く事自体どうかとも思うが）スクリプトの記述はheadタグの中でmetaタグによる文字コードの指定が終わった後に記述する。
まあこれはスクリプトに限らないのだが、metaタグによる文字コードの指定は可能な限りHTMLソースの先頭（HEADセクションの先頭）に記述する。
innerTextはHTMLタグを含まない文字列を表し、innerHTMLはHTMLタグを含む文字列を表す。
また、文字列の中に実体参照（&など）の文字列が含まれている場合、innerHTMLではそのまま（「&」の形）の文字列を取得するが、
innerTextでは解決された文字（「&」）が取得される。
フォント名の頭に「@」が付いているフォントは縦書き用のフォントなので注意。
aspxファイルはデフォルトではUTF-8でResponseが返る（web.configのglobalization要素を設定することで変更可能）。
外部CSSファイルは通常、Shift-JISで作成されているため、何の対策もしていないと外部CSSの内容を正しく読み込めない
（特にフォント名に2バイト文字を使用している時）。
この場合は外部CSSの先頭行に@charset "Shift_JIS";を記述すればうまくいく
（呼び出し元のlinkタグのcharset属性も試したけど駄目だった）。
※この問題はCSSと言うよりも外部ファイルを指定した時の問題。
よって、外部JavaScriptファイルをscriptタグで指定した時も同様。
この場合はscriptタグのcharset属性で指定する。
最終列以外の列幅を全て指定し、最終列の列幅は指定しないでTABLEタグの列幅で調整するようにする。 また、列幅の指定はヘッダ行も含めた全行でwidthを指定しないとうまく表示できない。
selectタグの高さはsize属性の指定による行数の指定のみで行う。 style属性でもheightを設定してしまうと、フォーカスの当たり方とかがおかしくなる。
JavaScriptのイベントは、戻り値にfalseを設定しないとイベントが発生したときの動作が継続してしまう（タブ移動とか）ので注意。
Visual Studioで（scriptタグでインクルードしている）外部のスクリプトをデバッグする場合、 そのscriptのエンコードを正しく判別できていないとまともにデバッグできない （たぶんエンコードできてない行数分、デバッグ位置がずれる）。 まあその場合でもデバッグ実行じゃなくてIEにアタッチしてデバッグする分にはうまくいくこともあるみたいだけど・・・あまり意味ないので、 エンコードをちゃんと指定すること（charset属性で）。
モーダルダイアログの呼び出し引数に親ウィンドウのwindowを渡してモーダルダイアログ側から親ウィンドウの制御を行った場合、 その処理が反映されるのはモーダルダイアログが閉じた後？ 少なくとも親のlocationをモーダルダイアログ側から変更した時は、モーダルダイアログが開いている間は何も起こらず、 モーダルダイアログが閉じた後、親ウィンドウの画面遷移が発生した。
IEのモーダルダイアログからwindow.showで子ウィンドウを呼び出すと、子ウィンドウでセッションが切れる。 状況による。IEを2個立ち上げてから上記操作を行うと、子ウィンドウでセッションが切れるらしい。 親ウィンドウ（モーダルダイアログ）のセッションを子ウィンドウでも使用する場合は、 モーダルダイアログ呼び出し時の引数に（モーダルダイアログの）親ウィンドウを渡して、 window.showで子ウィンドウを起動する時にモーダルダイアログのwindowを使うのではなく、 引数で渡された親ウィンドウのwindowオブジェクトを使用するようにする。
上記以外でもセッションが切れるバグは色々とあるみたいなので、 注意。
IE＋ASP.NET（と言うかサーバーサイドプログラム）でファイルダウンロード処理を行った場合、 IEからのリクエストに対するレスポンスはファイルダウンロード用に使われて、HTMLの描画が行われない。 見た目は（HTMLは）リクエスト前の状態がそのまま残っているのだが、 内部的なwindow.documentは消滅してたりする（まあ、消滅と言うか単純に空の状態）。 なので、ダウンロード処理をした後、window.documentを参照しようとするとエラーになる。 呼び元のwindowにレスポンスが返ってこないのはもうどうにもならないので、別の方法で回避する。 つまり、隠しiframeを用意し、ダウンロード処理はそちらのwindowで行う。 こうすれば、HTMLのレスポンスも通常どおり返せるし、ファイルのダウンロードも正常に行える。
こっちの問題も似たようなものか？ 違うか
iframeを使用することによりファイルのダウンロード自体は正常に行われるようになるが、 場合によっては注意が必要となる時がある。 ファイル内容のダウンロード自体は親HTMLソースとは非同期で行われるっぽいが、 ファイルダウンロードのダイアログが表示された時の動きが微妙。 ファイルダウンロードダイアログ（モーダルダイアログ（？））に関しては親のwindowと微妙に同期が取られているっぽい。 ソースのダウンロードに関しては非同期でいけてるっぽいが、windowのイベントがうまく処理されない感じ。 よって、ソースダウンロード後にwindowのイベントによって初期化処理が走るような処理やコントロールを使用していると、 その辺りの関係で微妙にうまくいかない。 要はwindowイベントが発生して初期化処理が終わった後にファイルダウンロード（ダウンロードダイアログ（？））が走れば問題ないので、 iframeのsrc設定をサーバーサイドでは行わず、空でIEに送った後、IEのwindow.onloadイベント内でsrcを設定するようにする。 こうすればwindowイベントも正常に発生し、その後で改めてファイルのダウンロードが行われるようになる。 但し、この辺りの動きは調査不足。もっと正確な動きを確かめるにはもうちょっと調査する必要がある。
自分でwindowイベントの処理を書いていないとしても、 知らないうちにwindowイベントを使用するコントロールを使用している可能性があるので注意。 特に、サードパーティー製のリッチなコントロールとかは内部で利用しているかもしれない（SPREADとか）。
httpsのURLからファイルダウンロードを行う際、キャッシュ制限を行っているとダウンロードできない場合がある。 httpの場合は正常にダウンロードできるので、本番機でSSLを使用している場合は注意。
IEはローカルにキャッシュが作成できないとファイルのダウンロードは行えないらしい。 特にhttpsサイトの場合はセキュリティの関係で、 キャッシュを保存させない設定が行われているとクライアントに一切キャッシュを作成しない仕様らしいので、 結果、ファイルのダウンロードに失敗するらしい
ファイルのダウンロードダイアログで「保存」ボタンを押下すると、 次回ポストバック発生までキーボードのキー入力が効かなくなるみたい・・・。 「保存」ボタンを押して「名前を付けて保存」ダイアログまで進まなければ問題ないみたい・・・。 上記現象はiframe使用によるダウンロード時の話。 詳しく調べていないので、もしかしたらプログラムの問題かも。 コレ本当だったら、iframe使ってもまともにできないっぽいので、ウィンドウを使い捨てるつもりでやらないと駄目か？ アンカーだったらうまくいったりするのかなぁ（全くもって未確認）。
IEはページ表示時にsrc属性が設定されていないframe/iframeを「セキュリティで保護されていない項目」と判断する為の挙動。 SSL領域に用意したダミーファイル（空HTMLファイル等）を指定することにより、この警告メッセージの表示を防ぐことができる。
IE関連のバグや予期せぬ仕様は凄いたくさんあるので、 IE絡みで予期しない動きが発生したらとりあえずマイクロソフトのナレッジベースを検索した方が良いかもしれない。
"Internet Explorer" (kbbug OR kbprb)