var img = new Image();
img.src = 'path/to/image';

としたときに同期的に読み込む方法はありますか？

>>334
> domとjsで循環参照してはいけないということは分かる

わかってないじゃないかｗ
もしDOMがJavaScriptで実装されていれば循環参照してもいいんだよ。

DOMが参照カウンタ方式で管理されている別言語（多くはC言語やC++）の
ライブラリを単純な方法で使ってる場合に問題になる。

JavaScriptで完結した世界であれば循環参照には何の問題もない。
逆に言えばDOM以外でもJavaScript外の言語で作られたライブラリを
使用している場合は同様の問題が起きる。

JavaScriptの範囲内で考えても、問題が起きるかどうかはわからないんだよ。

>>328
> ここはJavaScriptスレだからjQueryを使って解決って言うよりも
> どういうふうにすると解決するのかが知りたい

オープンソースなんだからさ、jQueryなどのライブラリが
どのように解決しているかを見てみればいいのさ。

オレオレコード書いたって、それが本当に問題を解決できれいるかどうかわからない。

jQueryだけじゃない。いろんなライブラリの
ソースコードを読むのが上達の近道だぞ。

そういうのはいらないから結果をテンプレにまとめてね

通常起こり得ないことが起きるんだから、
domとjsが別の系で動いていることは分かるが
内部的な動作を知らん言葉で説明されても
jsプログラマーは興味がないってこと。
jsがcで作られていようがc++で作られていようが、
それはjsの本質にはなり得ないんだから。
どういう時に問題が起きるかと、それを避ける方法さえ分かれば十分。

>>355
C++云々は俺もわからないが、わからない部分は読み飛ばすなり勉強すればいいじゃん
自分が分からないことを相手にあたるのは八つ当たりだと思うぞ

>>355
>domとjsが別の系で動いていること
これが本質であって、
c言語がうーたら言ってるやつの説明は論点ずれてるよな

>>356
八つ当たりではないと思う。

>>357
C++云々はわからないが、ECMAScript及びDOMの仕様はある程度わかる俺からいわせてもらえば、DOMとスクリプトの循環参照はECMAScript, DOM仕様で規定されていない
実装寄りの話になるからC++を持ち出すのはおかしくないと思うぞ
本格的に理解したいなら「Firefox や Chromium のソースコードを読め」と言われると思う

それでも反論するなら、「domとjsが別の系で動いていることが本質」の根拠となる仕様を知りたい
根拠となる仕様を明示できるなら納得するよ
そうでないなら、実装依存になるからC++云々の話は全うだと思う

>>359
どの言語で実装しようが
別の系のGC（複数のGC）で管理されてるオブジェクト同士が参照しあうことが問題だってことなんだよ。

FirefoxとChromiumのｊｓエンジンもc++で記述されてるんだから、
言語レベルで云々言うなら問題起こらん話になるんだから、c++って単語が出てくるはずないだろ。

>>358
Lightbox的なポップアップ機構を実装してはどうでしょう。
(ばっさりいえば、window.openは既に時代遅れです)
http://lokeshdhakar.com/projects/lightbox2/

>>360
C++言語独自の問題とはいわないが、C++ならこうなるというケースを教えてくれているとは思えないのかね
正直、主義主張の違いだけでそんなに怒る内容とは思えんのだが
怒りの沸点が低すぎじゃないか？

.>>362
別に怒っているわけではないので不快に感じたらすまんよ。
ただ、問題の本質についての説明がずれていることに対して問題提起してるんだよ。
C++はこういうケースを教えてくれているわけではないので。

最近のgoogle mapはメモリリークが激しい気がする
現在位置動かすたびに重くなっていってそのうちフリーズする

気がするじゃなくて数字出せよ

>>361
ありがとうございます。それも考えています。
しかし、キャプション類が数種類あり（説明、撮影地、データ等）、Lightboxだとそこまで対応できないように感じました（一言添えるくらいはできるようですが）。
ストレートに写真だけを見せるだけならLightboxがスマートだとはわかってはいるのですが・・

また、写真の量（見せたいhtmlファイル）が膨大で、（時代遅れと知りつつも）window.openでなんとか対応できないかと思った次第です。

>>355
> 内部的な動作を知らん言葉で説明されても
> jsプログラマーは興味がないってこと。

それはお前だけだろ。勝手に決め付けるなや。

>>359
> ECMAScript, DOM仕様で規定されていない

なでEMCAScriptでDOMの仕様が規定されてないのだろうか？

>>360
> FirefoxとChromiumのｊｓエンジンもc++で記述されてるんだから、

JavaScriptエンジンが「C++で作られた実行環境」で動いているのと
JavaScriptエンジンで動いているスクリプトが「C++で作られたライブラリを呼び出している」
のとでは全然意味が違うだろ。

「C++で作られた実行環境」はJavaScriptコードを実行していると
わかってるんだから、JavaScriptの仕様どおりに実装できるが、
「C++で作られたライブラリ」はどの言語から呼び出されているかわからないので
JavaScriptの仕様を考慮できるわけじゃない。

そこでJavaScriptの仕様を考慮していないライブラリを
JavaScrptの仕様に適合させるラッパーオブジェクトというものがでてくるんだよ。

>>360
ほんまそれ
言語がc++じゃなくても同じように組まれてれば同じ問題が出るんだから
c++は本質じゃない
cだろうがアセンブラだろうがアルゴリズムが同じなら同じ現象が出る

MSの「Internet Explorer リーク パターンを理解して解決する」の中にも
当たり前だがC++なんて言葉は出てこない
本質じゃないから。
はっきり言ってこの感覚が分からない奴はセンスない
知識とセンスは違うということを理解しろ

>>371
本質を知っている人は同じことだってわかってるはずだが。

なぜInternet Explorerの古いバージョンでメモリリークするのかというと
DOMがC++で作られているから。古いIEはDOMをほぼ直接使っていたために
メモリリークしていた。現在はラッパーオブジェクトでメモリリークしないようになってる。

IEのDOMがCOMオブジェクトであるってこと知らないのかな？
それがメモリリークの原因なんだけど。

COMオブジェクトは参照カウンタで管理する方式なんだよ。
COMオブジェクトは別にC、C++以外でも作られるが
実質C/C++で作られているだろう。

>>372
だから
>DOMがC++で作られているから
ってのが本質じゃなくて参照カウンタを用いている、そしてjs側のGCとは通信してないから
完全に参照されていないか検出できないってのが問題なんだよ。
DOMがVBだとかほかの言語で書かれていてもこの問題は起こるっていってるんだよ。

>>374
仮にDOMが.NET言語で作られていたら起きないよ。
なぜなら.NET言語自体が参照カウンタ方式ではない方法で
メモリ管理しているから。

本質的にはバインディングの問題。古くはライブラリを使う時に
静的にリンクしなければ使えなかった。それが共有外部ライブラリ
（LinuxのsoやWindowsのDLL等）で静的にリンクしなくても使えるようになった。

だけどそのリンクするときの仕様として、GCという概念はなかった。
GC自体がもっと後に出てきたものだからね。

初期の共有外部ライブラリの仕様はC言語が基本となっていた。
だからオブジェクト指向という概念が抜けている。
Windowsではオブジェクト指向（正確に言えばコンポーネント指向）を
取り入れた仕様ができた。それがCOM。Firefoxではクロスプラットフォームが
要件にあるためCOMに似たXPCOMという仕様があるらしいね。

COMではオブジェクト指向には対応できてもメモリ管理は参照カウンタ方式だった。
AddRef()でカウンタを増やし、Release()でカウンタを減らす。という仕組みがある。
.NETではCOMを拡張して参照カウンタではない方法でメモリ管理する、共有ライブラリの仕組みがある。

あと、そもそもなんでDOMがC/C++で実装されているかについては速いし再利用しやすいから。
最近はJavaScriptによるDOMの再実装なんてプロジェクトもあるらしいけど。

DOMは別にJavaScript専用のものではなく、他の言語からも使えるからね。
IEコンポーネントブラウザをVBで作るとかやったことあればわかると思う。
そもそもJavaScript（ECMAScript）の仕様の範囲じゃないしね。

>>375
お、おう。

>>377
その質問の答は詳しい人に任せるとして
代替スタイルシートって機能があるよ。

HTMLの仕様でスタイルシートを複数書いておいて
ブラウザが持っているであろう代替スタイルシート切り替え機能で
適用するスタイルシートを切り替えたり、JavaScriptで切り替えたり出来る機能

CSSを使ったメリットとして同じマークアップで
見た目を変えられるってことで、CSSが出だした頃からある機能なんだけど
あまり使われてないね。

これを使えばJavaScriptなしでも切り替えられるよ。

関係ないけど、時々見かける

<link ～ /> ← この / に何の意味があるの？

なくてもちゃんと動くんだけど？
これがないといけないブラウザでもあるのかな？

>>379
一言で言うならば、/> は古い書き方

正式勧告された仕様の中では最新だけど。

http://www.html5.jp/trans/whatwg_html5faq.html#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F
ここに書いてあるのを見ると、/>と書いても/は無視されるだけで閉じないって書いてあるね。

だから<script></script>を<script />と書くのは間違い。

>>382
だからHTML5はまだ正式じゃない。

ECMAScript 6は正式になるのは2016年。
このスレもES5が最新であり、ES6を使っては駄目ということである。

HTMLの<input type=“file”>のテストを書きたいのですが（テスト用ファイルの選択を自動化）
何か良い方法はありますか？

>>385
質問がよくわからんが
load時に自動で選択windowが出るってことか？

>>385
Selenium使ってみたら。
まあどっちみちハマると思うけどね。

確実に言えることは、fileに好きなファイルをJavaScriptで勝手に
設定できたら、ユーザーディレクトリにあるファイルを勝手に
送信できてしまうということ。

そんなことはできたらまずいので、JavaScriptでは
fileのテストは書けない。

この時間に起きてる奴結構いるんだな

>>386
Fileオブジェクトを指定したかったです

>>387
Selenium IDEで動作を記録して、テストエクスポートでできました
ひとまずこれでやってみます。
ありがとうございました

id表示ってどうやってやるの？

>>383
HTML5 が正式じゃないっていっても、多くのページが HTML5 に移行しているからなあ
実装ありきの HTML だから、勧告で全てが決まる訳ではないのが HTML の難しいところ
JavaScript も然り

つまり、 / は書いた所で意味がなく、
無視されるだけのものってこと。

>>379
XHTMLでは空要素も閉じなければならない
HTML5では既に普及しているXHTMLからの移行を考慮して空要素を閉じても良い(XHTML5では当然、閉じなければならない)
空要素を閉じておけば、同一HTML文書でHTML, XHTMLの切り替えが生じた時に処理が楽になる
ようするに何の意味もないわけではない

>>368
> なでEMCAScriptでDOMの仕様が規定されてないのだろうか？
そもそも、ECMAScriptとDOMは別々に仕様が定義されているのだが…。
仕様の話をするなら仕様書を読んできた方が良いぞ。
DOMはJavaScriptだけの仕様ではないから別定義なのは当然。
仕様と実装の関係を学ぶと良い。

メモリ管理は実装寄りの設計だからDOMで規定されてないのだろう。
各実装の仕様はあってもおかしくないが、下手に仕様定義してしまうと実装を変更しにくい事情はあるかもしれない。

ECMAscriptってW3cが作ったん

ECMAScript6 で symbol っていう新しい型があるみたいだけど、有用性が全然わからん…

特殊なプロパティのキーに"__proto__"とかだっせーよなー
文字列以外にもプロパティのキーになれる値作ろうぜ
つう感じ？
function Foo(){}
Foo.prototype[Symbol.toStringTag]="Foo";
({}).toString.call(new Foo); //"[object Foo]"

>>382
script要素は空要素じゃないんだから<script />と書くわけないからその例はおかしい

>>394
そんなのツールで一発で変換できるから不要