私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.139 +

みんなの評価 :
レスフィルター : (試験中)
>>633
JSの処理でずっと止まってたら、そもそも画面が更新できないから、
無限に出力どころか一文字も表示できないだろ
計算及び表示はsetTimeoutあたりで再帰的に非同期で実行されるだろうから
いつまでもHTMLのパースが終わらないわけではない
ちなみにこのページの場合、DOMContentLoadedは、読み込み直後におこってたよ
http://3.141592653589793238462643383279502884197169399375105820974944592.jp/
JSの処理でずっと止まってたら、そもそも画面が更新できないから、
無限に出力どころか一文字も表示できないだろ
計算及び表示はsetTimeoutあたりで再帰的に非同期で実行されるだろうから
いつまでもHTMLのパースが終わらないわけではない
ちなみにこのページの場合、DOMContentLoadedは、読み込み直後におこってたよ
http://3.141592653589793238462643383279502884197169399375105820974944592.jp/
ブラウザの画面のレンダリングって
ダウンロード
↓パース ←DOM構築はここ
↓スクリプティング
↓スタイル計算
↓レイアウト
↓ペイント
↓ラスタライズ
の順よね?
円周率サイトみたいにhtmlの内容が限りなくドバドバ流れ続ける場合
パースより先に進めるのはなぜ?
ダウンロード
↓パース ←DOM構築はここ
↓スクリプティング
↓スタイル計算
↓レイアウト
↓ペイント
↓ラスタライズ
の順よね?
円周率サイトみたいにhtmlの内容が限りなくドバドバ流れ続ける場合
パースより先に進めるのはなぜ?
>>652
> JSの処理でずっと止まってたら、そもそも画面が更新できないから、
> 無限に出力どころか一文字も表示できないだろ
お前さんは基礎を勉強したほうが良いぞw
JavaScriptの処理で止めることができるのは、alertやconfirmといった
一部のダイアログ表示関数と無限ループだけだ
HTMLが無限に出力されるという話にJavaScriptなんか関わってこない。
正直お前が、なんで画面が更新できないと思ってるのかわからん。
> JSの処理でずっと止まってたら、そもそも画面が更新できないから、
> 無限に出力どころか一文字も表示できないだろ
お前さんは基礎を勉強したほうが良いぞw
JavaScriptの処理で止めることができるのは、alertやconfirmといった
一部のダイアログ表示関数と無限ループだけだ
HTMLが無限に出力されるという話にJavaScriptなんか関わってこない。
正直お前が、なんで画面が更新できないと思ってるのかわからん。
>>653
JavaScriptは一旦忘れろ。
ブラウザはHTMLを受け取ると同時に並行してレンダリングしていく
パースが完了してからレンダリングではなく
パースしながらレンダリングだ。
途中でCSSファイルを読み込むなど、
最初から再レンダリングが必要な場合は、再度レンダリングされる。
スタイル計算も同じ。後からやり直しが必要になったらやり直すだけで
パースと同時にレンダリングしている。
DOM全体の構築が完了してからレンダリングではなく
DOM一部分の構築が完了するとすぐにレンダリングするんだよ
JavaScriptは一旦忘れろ。
ブラウザはHTMLを受け取ると同時に並行してレンダリングしていく
パースが完了してからレンダリングではなく
パースしながらレンダリングだ。
途中でCSSファイルを読み込むなど、
最初から再レンダリングが必要な場合は、再度レンダリングされる。
スタイル計算も同じ。後からやり直しが必要になったらやり直すだけで
パースと同時にレンダリングしている。
DOM全体の構築が完了してからレンダリングではなく
DOM一部分の構築が完了するとすぐにレンダリングするんだよ
>>654
http://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript?hl=ja
・JavaScript では、DOM と CSSOM のクエリと変更が可能です。
・JavaScript の実行は CSSOM をブロックします。
・JavaScript は非同期であると明示的に宣言されていない場合、DOM の構築をブロックします。
HTMLのパース中にscriptタグが出てきたら、それにasync/deferが付いてない限り、JSの読み込みと実行が終わるまでパーザは止まるよ
だからscriptタグはなるべく(DOMツリーの構築がほぼ終了している)bodyのケツに書けってセオリーが生まれたんだろ
あと無限のHTMLってなんだ?
ファイルサイズが無限のHTMLファイルがサーバーからひたすら送られてつづけてくるのか?
httpヘッダのcontent-lengthにはなんて書いてあるんだ?
HTMLパーザはとりあえずメモリ上にテキストを展開しないといけないが、どのくらいメモリを確保すればいいんだ?
JSを使ってDOMツリーに無限に要素を追加していくことはできるけど、無限のHTMLなんてものは実現不可能じゃないの?
詳しくは知らんが、多分ブラクラ扱いで受け取り拒否で終わるんじゃないか?
>>656
そのコードは見てるけどなにか?
http://pastebin.com/92ayEsQT
ちょっと手を加えたこれをローカルで実行しただけなんだが
http://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript?hl=ja
・JavaScript では、DOM と CSSOM のクエリと変更が可能です。
・JavaScript の実行は CSSOM をブロックします。
・JavaScript は非同期であると明示的に宣言されていない場合、DOM の構築をブロックします。
HTMLのパース中にscriptタグが出てきたら、それにasync/deferが付いてない限り、JSの読み込みと実行が終わるまでパーザは止まるよ
だからscriptタグはなるべく(DOMツリーの構築がほぼ終了している)bodyのケツに書けってセオリーが生まれたんだろ
あと無限のHTMLってなんだ?
ファイルサイズが無限のHTMLファイルがサーバーからひたすら送られてつづけてくるのか?
httpヘッダのcontent-lengthにはなんて書いてあるんだ?
HTMLパーザはとりあえずメモリ上にテキストを展開しないといけないが、どのくらいメモリを確保すればいいんだ?
JSを使ってDOMツリーに無限に要素を追加していくことはできるけど、無限のHTMLなんてものは実現不可能じゃないの?
詳しくは知らんが、多分ブラクラ扱いで受け取り拒否で終わるんじゃないか?
>>656
そのコードは見てるけどなにか?
http://pastebin.com/92ayEsQT
ちょっと手を加えたこれをローカルで実行しただけなんだが
>>650
そんな勘違いをするわけないだろ
そんな勘違いをするわけないだろ
おマヌケな解答者が多すぎて笑える
DOMContentLoadedが発生しない状態なんて現実的なコンテンツだとありえないから
一度もイベントループを回さないって、それ操作も効かないしフリーズしてるのと同じだから
DOMContentLoadedが発生しない状態なんて現実的なコンテンツだとありえないから
一度もイベントループを回さないって、それ操作も効かないしフリーズしてるのと同じだから
> DOMContentLoadedが発生しない状態なんて現実的なコンテンツだとありえないから
HTMLが大きい または 回線が遅くて
DOMContentLoadedが発生してないが
ページは表示されてるって状態なら普通にある
時間が短いだけで、ほとんどのサイトはそういう状態が発生してる
誰もイベントループの話なんかしてない。
HTMLが大きい または 回線が遅くて
DOMContentLoadedが発生してないが
ページは表示されてるって状態なら普通にある
時間が短いだけで、ほとんどのサイトはそういう状態が発生してる
誰もイベントループの話なんかしてない。
>>657
> あと無限のHTMLってなんだ?
> ファイルサイズが無限のHTMLファイルがサーバーからひたすら送られてつづけてくるのか?
そういう話をしてるだろ。
> httpヘッダのcontent-lengthにはなんて書いてあるんだ?
必須じゃない。書く必要がない。
> あと無限のHTMLってなんだ?
> ファイルサイズが無限のHTMLファイルがサーバーからひたすら送られてつづけてくるのか?
そういう話をしてるだろ。
> httpヘッダのcontent-lengthにはなんて書いてあるんだ?
必須じゃない。書く必要がない。
> JSを使ってDOMツリーに無限に要素を追加していくことはできるけど、無限のHTMLなんてものは実現不可能じゃないの?
PHPで無限ループでechoするサイトでも書けば?
PHPで無限ループでechoするサイトでも書けば?
> 詳しくは知らんが、多分ブラクラ扱いで受け取り拒否で終わるんじゃないか?
アホかw
どうやって、無限に表示され続けるかどうかを
クライアントで判断するんだよw
1TB読み込んで終わらなくても、もしかしたら1TB+1バイトで終了するかもしれんだろ
アホかw
どうやって、無限に表示され続けるかどうかを
クライアントで判断するんだよw
1TB読み込んで終わらなくても、もしかしたら1TB+1バイトで終了するかもしれんだろ
>>657
> HTMLのパース中にscriptタグが出てきたら、それにasync/deferが付いてない限り、JSの読み込みと実行が終わるまでパーザは止まるよ
> だからscriptタグはなるべく(DOMツリーの構築がほぼ終了している)bodyのケツに書けってセオリーが生まれたんだろ
お前はこの言葉の意味がわかってないな。
今話しをしてるのは、パーサーが止まるかどうかじゃなくて、
画面は表示されるのかどうかだ。
画面はいつ表示される?
body終了タグ直前になるJavaScriptの実行が
終わらないと表示されないと思うか?
> HTMLのパース中にscriptタグが出てきたら、それにasync/deferが付いてない限り、JSの読み込みと実行が終わるまでパーザは止まるよ
> だからscriptタグはなるべく(DOMツリーの構築がほぼ終了している)bodyのケツに書けってセオリーが生まれたんだろ
お前はこの言葉の意味がわかってないな。
今話しをしてるのは、パーサーが止まるかどうかじゃなくて、
画面は表示されるのかどうかだ。
画面はいつ表示される?
body終了タグ直前になるJavaScriptの実行が
終わらないと表示されないと思うか?
「JavaScriptが実行されなくても画面は表示される」から、
bodyの終了タグの直前に書けってセオリーができたんだろ(呆)
で、bodyの終了タグの直前だと
「JavaScriptが実行されなくても画面は表示される」
ページが重くなればなるほど、コンテンツ表示からjs実行時までのタイムラグが発生する。
だから
> コンテンツ表示からjs実行までのタイムラグを減らすなら、
headに入れたほうが良いって話をしてる。
bodyの終了タグの直前にいれるのは、デメリットが一切ない完璧な解決策ではなく
コンテンツ表示からjs実行時までのタイムラグは短ければ十分許容できるだろうという
判断があって使う方法。どうせ何も考えてないんだろうけどなw
大抵の場合はタイムラグは許容できるんだろうが、タイムラグを許容したくないという理由で
headでJavaScriptを読み込むってのもありなんだよ。
その場合は重くならないように必要最小限のことだけをする。
要素がまだ表示されてないから、$('#id').on('click'・・・とかじゃなくて
$(document).on('click', '#id'・・・みたいな書き方をしてな。
要素ごとにイベントハンドラを設定しないから、この方法は軽い方法になる。
bodyの終了タグの直前に書けってセオリーができたんだろ(呆)
で、bodyの終了タグの直前だと
「JavaScriptが実行されなくても画面は表示される」
ページが重くなればなるほど、コンテンツ表示からjs実行時までのタイムラグが発生する。
だから
> コンテンツ表示からjs実行までのタイムラグを減らすなら、
headに入れたほうが良いって話をしてる。
bodyの終了タグの直前にいれるのは、デメリットが一切ない完璧な解決策ではなく
コンテンツ表示からjs実行時までのタイムラグは短ければ十分許容できるだろうという
判断があって使う方法。どうせ何も考えてないんだろうけどなw
大抵の場合はタイムラグは許容できるんだろうが、タイムラグを許容したくないという理由で
headでJavaScriptを読み込むってのもありなんだよ。
その場合は重くならないように必要最小限のことだけをする。
要素がまだ表示されてないから、$('#id').on('click'・・・とかじゃなくて
$(document).on('click', '#id'・・・みたいな書き方をしてな。
要素ごとにイベントハンドラを設定しないから、この方法は軽い方法になる。
つかなんでonload嫌いなの?
個人的にbody内scriptのほうが嫌い
個人的にbody内scriptのほうが嫌い
頭の固い俺にはチンプンカンプンなので状況を整理させて
A. <head>でDOMContentLoaded
B. <head>でload
C. </body>手前で<script>
D. コンテンツ直後に<script>
E. MutationObserver
>>635はどれとどれを比較して、優位性を主張してるの?
どういう理屈でそれがいいの?
何にそんなに怒ってるの?(枝葉かもしれないけど、主張に関係してそうだから)
特に「永遠に円周率を表示するサイトっていうのは、</body>が永遠に来ない」のところが意味わかんない
A. <head>でDOMContentLoaded
B. <head>でload
C. </body>手前で<script>
D. コンテンツ直後に<script>
E. MutationObserver
>>635はどれとどれを比較して、優位性を主張してるの?
どういう理屈でそれがいいの?
何にそんなに怒ってるの?(枝葉かもしれないけど、主張に関係してそうだから)
特に「永遠に円周率を表示するサイトっていうのは、</body>が永遠に来ない」のところが意味わかんない
setTimeout(callback,0)やっとるだけ
</body>来とるがな
</body>来とるがな
content-type: text/plainなら</body>は永遠に来ないでしょうね
<head>もありませんけど
<head>もありませんけど
>>669
> コンテンツ表示からjs実行までのタイムラグを減らす
という話をしてる。
コンテンツ表示までの時間を減らすという話じゃない
コンテンツ表示からjs実行までのタイムラグを減らす話だ
表示されてるけどJavaScriptは動かないから
この間に画面に触ったらJavaScriptは反応しないという状態だ
> コンテンツ表示からjs実行までのタイムラグを減らす
という話をしてる。
コンテンツ表示までの時間を減らすという話じゃない
コンテンツ表示からjs実行までのタイムラグを減らす話だ
表示されてるけどJavaScriptは動かないから
この間に画面に触ったらJavaScriptは反応しないという状態だ
勘で書くけど、
setTimeout(g,0) に、0 を渡しても、最小単位の数ミリ秒、空くからだろ。
その間に、レンダリングするのだろう
setTimeout は非同期だから、キューに、callback 関数を入れるだけで、即リターンする。
その後に、キューから関数を取り出して実行するので、
その間、最小単位の時間が空くのだろう
setTimeout(g,0) に、0 を渡しても、最小単位の数ミリ秒、空くからだろ。
その間に、レンダリングするのだろう
setTimeout は非同期だから、キューに、callback 関数を入れるだけで、即リターンする。
その後に、キューから関数を取り出して実行するので、
その間、最小単位の時間が空くのだろう
jQuery なら、同じ要素で、メソッドチェーンで、2つのイベントも設定できる。
例えば、mouseover, mouseout で画像を切り替える
$( '#foo' ).mouseover( function( ) {
$(this).attr('src', 'a.gif');
}).mouseout( function( ) {
$(this).attr('src', 'b.gif');
});
例えば、mouseover, mouseout で画像を切り替える
$( '#foo' ).mouseover( function( ) {
$(this).attr('src', 'a.gif');
}).mouseout( function( ) {
$(this).attr('src', 'b.gif');
});
>>680
なるほどね
理解できたけど、「やっぱりheadに入れるのがいいんじゃないの?」で$(document).on('click', selectorをエスパー出来る人はいないと思った
文脈的にはあなたの主張はBだと思ってたし、あなたに反論していた人もおそらくBの体で反論してたと思うよ
余計な争いを防ぐ為にも、投稿前に重要な情報が抜け落ちていないかを注意した方が良いように思う
なるほどね
理解できたけど、「やっぱりheadに入れるのがいいんじゃないの?」で$(document).on('click', selectorをエスパー出来る人はいないと思った
文脈的にはあなたの主張はBだと思ってたし、あなたに反論していた人もおそらくBの体で反論してたと思うよ
余計な争いを防ぐ為にも、投稿前に重要な情報が抜け落ちていないかを注意した方が良いように思う
AとBのはどちらもDOMContentLoadedはコンテンツ表示から64秒後に発生する
正確にはJavaScriptファイル + HTML の両方のダウンロードが終わってから発生するが
AはJavaScriptファイルのダウンロードが終わってから、HTMLをダウンロードするのでコンテンツ表示が遅いが
BはHTMLからダウンロードしてから、あとでJavaScriptファイルをダウンロードのでコンテンツ表示が速い
ただし、どちらもJavaScriptファイルのダウンロードが終わるまでは
JavaScriptファイルが機能しないので、コンテンツ表示からJavaScript実行のタイムラグがある
> コンテンツ表示からjs実行までのタイムラグを減らす
には
JavaScriptを先にダウンロードし(この間読み込んでないコンテンツは当然表示されない)
DOMContentLoadedを待たずにJavaScriptを実行(ここがAとの違い)する。
こうすることでコンテンツが表示される時点ではすでにJavaScriptが実行されている。
正確にはJavaScriptファイル + HTML の両方のダウンロードが終わってから発生するが
AはJavaScriptファイルのダウンロードが終わってから、HTMLをダウンロードするのでコンテンツ表示が遅いが
BはHTMLからダウンロードしてから、あとでJavaScriptファイルをダウンロードのでコンテンツ表示が速い
ただし、どちらもJavaScriptファイルのダウンロードが終わるまでは
JavaScriptファイルが機能しないので、コンテンツ表示からJavaScript実行のタイムラグがある
> コンテンツ表示からjs実行までのタイムラグを減らす
には
JavaScriptを先にダウンロードし(この間読み込んでないコンテンツは当然表示されない)
DOMContentLoadedを待たずにJavaScriptを実行(ここがAとの違い)する。
こうすることでコンテンツが表示される時点ではすでにJavaScriptが実行されている。
エスパー出来てなかったし、$(document).on('click'と書かれていたなら反論しなかった
わざと欠けてる情報で相手を釣る。
おちょくり回して遊ぶ。
最後にマウントする
これが目的なのに何を言ってるんだ?w
おちょくり回して遊ぶ。
最後にマウントする
これが目的なのに何を言ってるんだ?w
お前ら盛り上がってるところすまんが
jQueryは使わない場合結局どうすればいいんだよ?教えてくれよ
jQueryは使わない場合結局どうすればいいんだよ?教えてくれよ
>>635はDOMContentLoadedの回答を得て「やっぱりheadに入れるのがいい」といってたから、Bと勘違いするのも無理ないな
>>685
それ最後にマウント取られて終わるやつ
それ最後にマウント取られて終わるやつ
無限に円周率を表示するページで
DOMContentLoadedっていつ発動するの?
→永久に発動しないんだ
→じゃあDOMContentLoadedを使うのは良くないね
→</body>もこないしね
→(DOMContentLoadedは使わず)<head>に入れよう。
DOMContentLoadedっていつ発動するの?
→永久に発動しないんだ
→じゃあDOMContentLoadedを使うのは良くないね
→</body>もこないしね
→(DOMContentLoadedは使わず)<head>に入れよう。
>>686
http://developer.mozilla.org/ja/docs/Web/API/EventTarget/addEventListener
jQueryなんかと違ってバブリングしなくても親ノードで待てるので、お勧め
http://developer.mozilla.org/ja/docs/Web/API/EventTarget/addEventListener
jQueryなんかと違ってバブリングしなくても親ノードで待てるので、お勧め
このスレは>>685みたいなのが常駐していて実に糞だな
>>622に話が戻ってきたな
window.addEventListener("click", function(evt){
if (evt.target.id == "foo")...
if (evt.target.id == "bar")...
},false);
jQueryを使わないってことは、こんな感じのコードを書かないといけない
window.addEventListener("click", function(evt){
if (evt.target.id == "foo")...
if (evt.target.id == "bar")...
},false);
jQueryを使わないってことは、こんな感じのコードを書かないといけない
>>692
イベントバブリングでぐぐれ
イベントバブリングでぐぐれ
>>696
いつからかは関係ない
いつからかは関係ない



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.109 + (1001) - [97%] - 2013/10/7 13:16
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [95%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
トップメニューへ / →のくす牧場書庫について