>>848
代替案をくれ

>>849
分けるというのは>>4の一部を>>5に移すということか？

>>850
確かに俺もhttp://fiddle.jshell.net/vSqKr/33/show/ があれば、>>3は不要だと思うが…
今のところは、>>4の一部を>>3か>>5に移すのが妥当か

>>1-5のテンプレを更新した
http://fiddle.jshell.net/fH4cC/163/show/

- ECMAScript 3 和訳を Internet Archive 版へ差し替え(現在、閉鎖中の為)
- ECMAScript 3 原文サイトを追加
- ECMAScript 5 和訳を追加 (http://tsofthome.appspot.com/ecmascript.html )
- >>4の一部を>>5へ移行した (>>849の提案通り)
- リンク集を更新した (http://fiddle.jshell.net/vSqKr/35/ )

>>850は他の人の意見待ちで保留
テンプレサイトのrev数が尋常じゃないな...

> Q4. フォーム部品名を変数にした「...myform.変数名.value」が動きません…
> A4. 「document.forms.myform.elements[変数名].value」でどぞ。

これとかさぁ、今は普通フォームにID付けて
getElementByIdとかするだろ・・・ってな。
一体いつの知識なんだか。

実際のところ、>>3は定期的に消す要望が出るが、賛成意見が出てこなくて保留することが多い
とはいえ、サイレンとマジョリティの可能性もあるので、>>3を消した版も作って意見を待つべきか...

http://fiddle.jshell.net/vSqKr/35/show/ も古い情報を基にして作っているところがあるな

Q2. JavaScriptでローカルファイルを読み/書きたいのですが…
Webではセキュリティ制約により絶対無理です。できたら恐ろしいことに…
⇒window.postMessage or XHR2 で可能

Q2. JavaScriptでローカルファイルを読み/書きたいのですが…
Webではセキュリティ制約により絶対無理です。できたら恐ろしいことに…
⇒File API でファイルの読み込みは可能

Q9. <a href="http://example.com/" onclick=""> で動作指定してるのですが時々動きません…
return false; でデフォルトアクションを抑制しないとページ移動してしまいます。
⇒そもそも、リンク処理を抑制させるなら a 要素で表現しようとするな

Q14. setTimeout() やイベントハンドラ関数に設定するコードに this を含めたいのですが…
this を別の変数(下例では that) に束縛し、その変数を使って対応してください。
⇒Function#bind でもOK

Q17. document.getElementById('hoge') や $('#hoge') で要素ノードが取れないのですが…
コード実行時点でHTMLがそこまで読まれてない。window.onload 中でやるとか。
⇒addEventListener (attachEvent) を使うべき

いつもテンプレ編集お疲れさんです
そもそも論だけど、>>3については適当な質問者は読み飛ばす文量だし
またこれを見て理解できる人はそれ以前に検索で答えを見つけられると思う
該当する質問がきたらアンカー投げる先って程度の役割なら不要かな
もちろんやる気のある質問者のためにFAQへの誘導文は残すべきだけど

>>856で Q2. を2回書いたが、一方は Q1. を書いたつもりだった

Q1. 開いた別窓/フレームの内容にアクセスできないのですが…
ページ内容が別サーバの場合セキュリティ制約により絶対無理です。
⇒window.postMessage or XHR2 で可能

>>3を消すなら、開発者ツールやDeveloper Toolsの基本的な使い方でも書くといいと思うな
実際、これが使えればすぐ解決するような質問は多いし

あと、>>4のDHTMLはさすがに古すぎだしいらなくね

循環参照もテンプレに入れろよ

>>859
「Developer Toolsの基本的な使い方」はあったら便利だと思うが、どこまで説明したものか
- ページ上で右クリックして [要素を検証] -> [Styles], [Computed], [Properties] でステータス確認
- [Ctrl] + [Alt] + [J] でコンソールを呼び出し、コンソールデバッグ
- Breakpoints
正直、Breakpoints は上手く説明できる自信がない

>>860
定期的に要望が出るので入れようとは思うが、「言うは易し」という言葉があってだな

循環参照は初心者が引っ掛かる内容でもないしテンプレ入りは不要でしょ
頻出する話題としてテンプレ案に設けるのが理想的だと思うけど中の人の負担が強いかな

じゃあなんか循環参照のレスで大量消費するつもりなんだよ

>>864
循環参照なんかしてんじゃねーぞ。

>>862
指摘されて気がついたが、テンプレではなく、FAQ入りとして脳内変換していた
そもそも、文章量が1レスに収まらない事が予想されるのでテンプレ入りは無理だ
現在は下記の構成で考えている

- >>3を削除してFAQへのリンクのみにする(>>854,854,856)
- >>3に「Developer Toolsの基本的な使い方」を代わりに入れる(>>859)
- FAQ(jsfiddle)に循環参照の説明を入れる(>>860)

> 頻出する話題としてテンプレ案に設けるのが理想的だと思うけど中の人の負担が強いかな
循環参照については説明量が多すぎるので時間がかかるのは事実
早くても今夜帰宅して、「Developer Toolsの基本的な使い方」まで書ければいいところだろう
気長に待って欲しい

FAQを更新した
http://fiddle.jshell.net/vSqKr/37/show/#Browser-Developer-Tools

- 後でFAQ項目を整理するときにタイトルがナンバリングされていると不便なのでタイトルのナンバリングを削除してフラグメント識別子をユニークにした
- FAQ に「開発者ツール(Developer Tools)の基本的な使い方」を追加した

テンプレへの書き起こしは後でやる(要素の検証、コンソールで埋まる予定、他候補があれば要望は受け付ける)
FAQからナンバリングを廃止したので、FAQのリンクリスト生成JavaScriptで ol 要素も生成できる機能を追加したい⇒後でやる

>>1-5のテンプレを更新した
http://fiddle.jshell.net/fH4cC/165/show/

- >>3の主要FAQを削除し、FAQリンクと「Developer Toolsの基本的な使い方」を代わりに入れた(>>854,854,856)
- リンクリスト生成JavaScriptを更新してFAQリストを ol 要素でマークアップするようにした
-http://fiddle.jshell.net/vSqKr/40/show/#Browser-Developer-Tools を加筆

おつおつ

書き起こしとか一人で一々やってたらキリがないわな
適当な解説にリンク貼ってよさ気なレス書かれたらそれと入れ替えればいいんじゃない

要望出すだけ出して文章を一人に丸投げしている現状が異常だと思う
自分が要望を出したときには文案ぐらいは出していたし、簡単な更新ならやったことがある
「テンプレ更新者が専任でいて頼めば何でもやってくれる」という風潮が良くないと思うな
全部やれとまではいわないけど、簡単な文案を出すとか、テンプレの要望リストに載せるとか、可能な範囲で要望者も作業を負担すべきだと思う

JavaScript界でフォローすべきTwitter アカウント一覧を入れるべきだ

・mizchi
・kyoago

この二人をウォッチしとけばJavaScript素人も自然と能力を伸ばすことが出来る

ジャップ技術者にそんなレベル高い奴いるわけねーだろ

日本語大変お上手ですね
ジャップの掲示板にわざわざ出張しての書き込み、ご苦労様です

そういうのはネトヲチ板でやってね

・jagarikin

ユーザ名を掲載するのは本人の迷惑になるので今すぐに止めるべきだ

前も書いてたな
書いてるの同一人物だろ

それってprogrammerprofile.netに勝手に登録されることにも言えるね
俺は初心者だから有名な人を挙げてくれるのは助かってる

そもそも何の迷惑になるのか疑問

自分の名前が上がらないから嫉妬でしょ、たぶん

名前書いてる奴は性格が気持ち悪いから
わざと叩かせようとしてるみたいな印象を受ける

thisのことをコンテキストと言いますが、いまいちしっくり来ません
「オブジェクト自身」とでも呼んだ方がいいと思います
どの辺がコンテキストなんですか？

２ちゃんだから叩くっていう発想自体が気持ち悪い

>>883
コンテキスト＝状態とすると
JavaScriptのthisは状況に応じて参照しているオブジェクトが変わるから
thisをコンテキストと呼んだりするんだろう
他の言語ではコンテキストなんて言わない

>>883
仕様書的に言うと、this（ThisBinding）は "Execution Contexts" の中のひとつ。
だから「コンテキスト」と呼ばれているのではないかと思う。
http://www.ecma-international.org/ecma-262/5.1/#sec-10.3

>>885
C言語にも「実行コンテキスト」が存在する

カスタムイベント名は分かりやすくプリフィックス付けたりした方がいいですよね？

多分その方がいい
分かりやすいのはもちろんだし、将来新たに定義されるイベント名とたまたま被ってしまうこともなくなるし

>>887
thisをコンテキストって言わないって事だけど
C言語の実行コンテキストってthisじゃないよね

>>889
ありがとうございました

>>883
単純に「コンテキスト」の直訳「文脈」でいいだろ？

同じ関数呼び出しであっても、文脈によって
意味が変わってくる。それがJavaScriptの場合呼び出し方、
つまりxxx.foo()のxxx（文脈）が何になるかでthisが変わる。
ということを言ってるだけだよ。


>>890
文脈っていうのは一般的な英語なので、それを
どういう用途で使ってるかは言語次第だよ。

>>883
Function#call, Function#bind, コンストラクタ呼び出し..etc
this 値は文脈によって変化するので「オブジェクト自身」ではない

>>894
JScriptだのDHTMLだの、時代の１要素を担っては来たものだが、
所詮は現在に於いてはもはや、歴史の１ページ。

比べるべくもない。よって、A5で「全部要らない」

>>896
「Internet Explorer API」も含めて不要だろうか？
「Internet Explorer API」が古いとは思えなかったので、念のため

とほほのリンクを入れろや