元スレ+ JavaScript の質問用スレッド vol.139 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

652 = :

>>633
JSの処理でずっと止まってたら、そもそも画面が更新できないから、
無限に出力どころか一文字も表示できないだろ
計算及び表示はsetTimeoutあたりで再帰的に非同期で実行されるだろうから
いつまでもHTMLのパースが終わらないわけではない
ちなみにこのページの場合、DOMContentLoadedは、読み込み直後におこってたよ

http://3.141592653589793238462643383279502884197169399375105820974944592.jp/

653 = :

ブラウザの画面のレンダリングって

ダウンロード
↓パース　　　　　　←DOM構築はここ
↓スクリプティング
↓スタイル計算
↓レイアウト
↓ペイント
↓ラスタライズ

の順よね？
円周率サイトみたいにhtmlの内容が限りなくドバドバ流れ続ける場合
パースより先に進めるのはなぜ？

654 = :

>>652
> JSの処理でずっと止まってたら、そもそも画面が更新できないから、
> 無限に出力どころか一文字も表示できないだろ

お前さんは基礎を勉強したほうが良いぞｗ

JavaScriptの処理で止めることができるのは、alertやconfirmといった
一部のダイアログ表示関数と無限ループだけだ

HTMLが無限に出力されるという話にJavaScriptなんか関わってこない。
正直お前が、なんで画面が更新できないと思ってるのかわからん。

655 = :

>>653
JavaScriptは一旦忘れろ。

ブラウザはHTMLを受け取ると同時に並行してレンダリングしていく
パースが完了してからレンダリングではなく
パースしながらレンダリングだ。

途中でCSSファイルを読み込むなど、
最初から再レンダリングが必要な場合は、再度レンダリングされる。
スタイル計算も同じ。後からやり直しが必要になったらやり直すだけで
パースと同時にレンダリングしている。

DOM全体の構築が完了してからレンダリングではなく
DOM一部分の構築が完了するとすぐにレンダリングするんだよ

658 = :

>>655
なるほどー
勉強になりましたありがとう

659 = :

>>650
そんな勘違いをするわけないだろ

660 = :

おマヌケな解答者が多すぎて笑える
DOMContentLoadedが発生しない状態なんて現実的なコンテンツだとありえないから
一度もイベントループを回さないって、それ操作も効かないしフリーズしてるのと同じだから

661 = :

> DOMContentLoadedが発生しない状態なんて現実的なコンテンツだとありえないから

HTMLが大きいまたは回線が遅くて
DOMContentLoadedが発生してないが
ページは表示されてるって状態なら普通にある
時間が短いだけで、ほとんどのサイトはそういう状態が発生してる

誰もイベントループの話なんかしてない。

662 = :

>>657
だからなにかって、このサイトはHTMLがすごく短いんだから
今話をしてる、ずーっと円周率が表示され続ける
「ページの読み込みが完了しない」サイトではない。

665 = :

> 詳しくは知らんが、多分ブラクラ扱いで受け取り拒否で終わるんじゃないか？

アホかｗ

どうやって、無限に表示され続けるかどうかを
クライアントで判断するんだよｗ

1TB読み込んで終わらなくても、もしかしたら1TB+1バイトで終了するかもしれんだろ

666 = :

>>657
> HTMLのパース中にscriptタグが出てきたら、それにasync/deferが付いてない限り、JSの読み込みと実行が終わるまでパーザは止まるよ
> だからscriptタグはなるべく（DOMツリーの構築がほぼ終了している）bodyのケツに書けってセオリーが生まれたんだろ

お前はこの言葉の意味がわかってないな。

今話しをしてるのは、パーサーが止まるかどうかじゃなくて、
画面は表示されるのかどうかだ。

画面はいつ表示される？
body終了タグ直前になるJavaScriptの実行が
終わらないと表示されないと思うか？

667 = :

「JavaScriptが実行されなくても画面は表示される」から、
bodyの終了タグの直前に書けってセオリーができたんだろ（呆）

で、bodyの終了タグの直前だと
「JavaScriptが実行されなくても画面は表示される」
ページが重くなればなるほど、コンテンツ表示からjs実行時までのタイムラグが発生する。

だから

> コンテンツ表示からjs実行までのタイムラグを減らすなら、
headに入れたほうが良いって話をしてる。

bodyの終了タグの直前にいれるのは、デメリットが一切ない完璧な解決策ではなく
コンテンツ表示からjs実行時までのタイムラグは短ければ十分許容できるだろうという
判断があって使う方法。どうせ何も考えてないんだろうけどなｗ

大抵の場合はタイムラグは許容できるんだろうが、タイムラグを許容したくないという理由で
headでJavaScriptを読み込むってのもありなんだよ。
その場合は重くならないように必要最小限のことだけをする。

要素がまだ表示されてないから、$('#id').on('click'・・・とかじゃなくて
$(document).on('click', '#id'・・・みたいな書き方をしてな。
要素ごとにイベントハンドラを設定しないから、この方法は軽い方法になる。

669 = :

頭の固い俺にはチンプンカンプンなので状況を整理させて

A. <head>でDOMContentLoaded
B. <head>でload
C. </body>手前で<script>
D. コンテンツ直後に<script>
E. MutationObserver

>>635はどれとどれを比較して、優位性を主張してるの？
どういう理屈でそれがいいの？
何にそんなに怒ってるの？(枝葉かもしれないけど、主張に関係してそうだから)

特に「永遠に円周率を表示するサイトっていうのは、</body>が永遠に来ない」のところが意味わかんない

671 = :

>>669
俺が言ってる円周率を表示するサイトっていうのは、
HTMLではなくテキストとして返してくるサイトだよ
content-type: text/plain で返してくるんだよ

672 = :

俺が昔見たのとは違うが、こことか永遠と円周率を表示するサイトだな
http://314.uw.hu/index.html

さてDOMContentLoadedは一体いつ発生するんだい？ｗ

673 = :

content-type: text/plainなら</body>は永遠に来ないでしょうね
<head>もありませんけど

674 = :

>>669

> コンテンツ表示からjs実行までのタイムラグを減らす

という話をしてる。

コンテンツ表示までの時間を減らすという話じゃない
コンテンツ表示からjs実行までのタイムラグを減らす話だ

表示されてるけどJavaScriptは動かないから
この間に画面に触ったらJavaScriptは反応しないという状態だ

675 = :

>>673
そこで重要なのは、同じことをHTMLでもできるってことだよ
</body>が永遠に来ないサイトを作ることはできる

676 = :

勘で書くけど、

setTimeout(g,0) に、0 を渡しても、最小単位の数ミリ秒、空くからだろ。
その間に、レンダリングするのだろう

setTimeout は非同期だから、キューに、callback 関数を入れるだけで、即リターンする。
その後に、キューから関数を取り出して実行するので、
その間、最小単位の時間が空くのだろう

677 = :

>>674
ありがとうだけど、答えてくれてない…

> >>635はどれとどれを比較して、優位性を主張してるの？
> どういう理屈でそれがいいの？
> 何にそんなに怒ってるの？(枝葉かもしれないけど、主張に関係してそうだから)

678 = :

>>676
お前はずれてるから答えなくていい。

誰もお前がレスしてるサイトの話なんかしてないんだから

679 = :

jQuery なら、同じ要素で、メソッドチェーンで、2つのイベントも設定できる。
例えば、mouseover, mouseout で画像を切り替える

$( '#foo' ).mouseover( function( ) {
$(this).attr('src', 'a.gif');

}).mouseout( function( ) {
$(this).attr('src', 'b.gif');
});

681 = :

>>680
なるほどね
理解できたけど、「やっぱりheadに入れるのがいいんじゃないの？」で$(document).on('click', selectorをエスパー出来る人はいないと思った
文脈的にはあなたの主張はBだと思ってたし、あなたに反論していた人もおそらくBの体で反論してたと思うよ
余計な争いを防ぐ為にも、投稿前に重要な情報が抜け落ちていないかを注意した方が良いように思う

682 = :

AとBのはどちらもDOMContentLoadedはコンテンツ表示から64秒後に発生する
正確にはJavaScriptファイル + HTML の両方のダウンロードが終わってから発生するが

AはJavaScriptファイルのダウンロードが終わってから、HTMLをダウンロードするのでコンテンツ表示が遅いが
BはHTMLからダウンロードしてから、あとでJavaScriptファイルをダウンロードのでコンテンツ表示が速い

ただし、どちらもJavaScriptファイルのダウンロードが終わるまでは
JavaScriptファイルが機能しないので、コンテンツ表示からJavaScript実行のタイムラグがある

> コンテンツ表示からjs実行までのタイムラグを減らす
には

JavaScriptを先にダウンロードし（この間読み込んでないコンテンツは当然表示されない）
DOMContentLoadedを待たずにJavaScriptを実行（ここがAとの違い）する。
こうすることでコンテンツが表示される時点ではすでにJavaScriptが実行されている。

685 = :

わざと欠けてる情報で相手を釣る。
おちょくり回して遊ぶ。
最後にマウントする

これが目的なのに何を言ってるんだ？ｗ

686 = :

お前ら盛り上がってるところすまんが
jQueryは使わない場合結局どうすればいいんだよ？教えてくれよ

687 = :

jQuery相当のことを自力でやればいいだけ
まあ頑張れｗ

688 = :

>>635はDOMContentLoadedの回答を得て「やっぱりheadに入れるのがいい」といってたから、Bと勘違いするのも無理ないな

689 = :

>>685
それ最後にマウント取られて終わるやつ

690 = :

無限に円周率を表示するページで
DOMContentLoadedっていつ発動するの？
→永久に発動しないんだ
→じゃあDOMContentLoadedを使うのは良くないね
→</body>もこないしね
→（DOMContentLoadedは使わず）<head>に入れよう。

691 = :

>>686
http://developer.mozilla.org/ja/docs/Web/API/EventTarget/addEventListener
jQueryなんかと違ってバブリングしなくても親ノードで待てるので、お勧め

692 = :

>>691
バグリングと親ノードの関係は？
親ノードで受け取ってから処理を振り分けすんの？

693 = :

このスレは>>685みたいなのが常駐していて実に糞だな

694 = :

>>622に話が戻ってきたな

window.addEventListener("click", function(evt){
　if (evt.target.id == "foo")...
　if (evt.target.id == "bar")...
},false);

jQueryを使わないってことは、こんな感じのコードを書かないといけない

695 = :

>>692
イベントバブリングでぐぐれ

696 = :

>>695
いやだから、親ノードで持てるのは
ずっと前からじゃんって話なんだが？

697 = :

>>696
いつからかは関係ない

698 = :

>>697
だから親ノードで持てるのは、バブリングと何の関係もないよね。
バブリングじゃないと親ノードで持てないとでも？

699 = :

>>698
> バブリングじゃないと親ノードで持てないとでも？
バブリングフェーズなら当然そうだ
いい加減、ぐぐれ

700 = :

>>699
バブリングの反対ってなにか知ってる？
バグリングでもキャプチャリングでも親ノードで持てるんだが？