私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.122 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
ブラウザで対応してないapiを使う時どっちの書き方がいいですか
if ("a" in window) {alert("未対応");}
と
if (!"a" in window) {alert("未対応"):}
もしくはこれこれ以外で良い方法を教えてください
if ("a" in window) {alert("未対応");}
と
if (!"a" in window) {alert("未対応"):}
もしくはこれこれ以外で良い方法を教えてください
<head>
</head>
<body>
</body>
<foot>
</foot>
↑これを作るべきだった
</head>
<body>
</body>
<foot>
</foot>
↑これを作るべきだった
>>502
状況に応じて typeof 演算子と Object.prototype.hasOwnProperty を使い分けてください。
> if (!"a" in window) {alert("未対応"):}
これは false in window と同義であり、期待通りに動作しません。
状況に応じて typeof 演算子と Object.prototype.hasOwnProperty を使い分けてください。
> if (!"a" in window) {alert("未対応"):}
これは false in window と同義であり、期待通りに動作しません。
追記。
それがオブジェクトであるならば、Object.prototype.toString.call で [[Class]] 判定する事も検討して下さい。
それが配列であるならば、Array.isArray を使用して下さい。
それが関数であるならば、それ自身を call する事によって関数以外で TypeError の例外を返すことを検討して下さい。
それがオブジェクトであるならば、Object.prototype.toString.call で [[Class]] 判定する事も検討して下さい。
それが配列であるならば、Array.isArray を使用して下さい。
それが関数であるならば、それ自身を call する事によって関数以外で TypeError の例外を返すことを検討して下さい。
>>500
script要素の読み込み中はDOM構築が停止する為、DOM構築速度を上げる為にscript要素をbody直前に持って行く事があります。
勿論、head要素までの読み込みで実行可能なタイミングであればhead要素内で完結すべきですが。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0006
例外として script[defer], script[async] を使用すれば、head要素内にscript要素を置いてもDOM構築を妨げません。
これらは対応ブラウザの制限がある為、対象ブラウザを踏まえて使用を検討する必要があります。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0008
http://caniuse.com/#feat=script-defer
http://caniuse.com/#feat=script-async
script要素の読み込み中はDOM構築が停止する為、DOM構築速度を上げる為にscript要素をbody直前に持って行く事があります。
勿論、head要素までの読み込みで実行可能なタイミングであればhead要素内で完結すべきですが。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0006
例外として script[defer], script[async] を使用すれば、head要素内にscript要素を置いてもDOM構築を妨げません。
これらは対応ブラウザの制限がある為、対象ブラウザを踏まえて使用を検討する必要があります。
http://gihyo.jp/dev/serial/01/crossbrowser-javascript/0008
http://caniuse.com/#feat=script-defer
http://caniuse.com/#feat=script-async
ありがとうございました
headに書いたものはbodyより前に読み込まれるので
bodyを表示してから実行したいものはbodyの後ろに書け、ということのようですね
するとheadに書けでもbodyに書けでもなく、必要に応じて分けて書けが正解でしょうか？
headに書いたものはbodyより前に読み込まれるので
bodyを表示してから実行したいものはbodyの後ろに書け、ということのようですね
するとheadに書けでもbodyに書けでもなく、必要に応じて分けて書けが正解でしょうか？
>>509
<bod>の前でも後ろでもなくて、
</body>の直前な。
<body> ～ながい本文～ <script></script></body> こうな。
</body>の後ろにはscript書けねーから
<bod>の前でも後ろでもなくて、
</body>の直前な。
<body> ～ながい本文～ <script></script></body> こうな。
</body>の後ろにはscript書けねーから
タグの話のどこがJavaScript？
関係ない話をするなら別スレに行けよ
関係ない話をするなら別スレに行けよ
ES6 の Map って便利だね
Iterator の仕様が難読だけど、どこかに日本語資料ってないのかな
Iterator の仕様が難読だけど、どこかに日本語資料ってないのかな
ECMAScript6に対応してないブラウザ向けに
Mapを提供するライブラリっていくつか有るみたいだけど
どれが一番優秀？
http://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#ecmascript-6-harmony
Mapを提供するライブラリっていくつか有るみたいだけど
どれが一番優秀？
http://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#ecmascript-6-harmony
<iframe id="fm"></iframe>
<script type="text/javascript">
var str = '<html><head><style type="text/css">*{color:red;}</style></head><body>あばば</body></html>';
var doc = DOMパーサ(str);
var fm = document.querySelector("#fm").contentDocument;
// ?
</script>
こんな感じの疑似コードがあったとして、このあとdocの内容をiframe#fmに入れるにはどうしたらいいだろうか
fm.body = doc.body; fm.head = doc.head; なんかやってみたのだがheadが入らない
パーサ使わずにfm.write(str)するというのはナシで、どなたかご教示いただきたく・・・
<script type="text/javascript">
var str = '<html><head><style type="text/css">*{color:red;}</style></head><body>あばば</body></html>';
var doc = DOMパーサ(str);
var fm = document.querySelector("#fm").contentDocument;
// ?
</script>
こんな感じの疑似コードがあったとして、このあとdocの内容をiframe#fmに入れるにはどうしたらいいだろうか
fm.body = doc.body; fm.head = doc.head; なんかやってみたのだがheadが入らない
パーサ使わずにfm.write(str)するというのはナシで、どなたかご教示いただきたく・・・
>>530
いやぁ別サイトをhttpRequestで取ってきてDOMでイジってiframeに書くようなことを考えてて
文字列やなんやらにまた書き出すなんて二度手間だなぁと思ってたんだが
readonlyならどうしようもないな、ﾄﾝｸｽ
いやぁ別サイトをhttpRequestで取ってきてDOMでイジってiframeに書くようなことを考えてて
文字列やなんやらにまた書き出すなんて二度手間だなぁと思ってたんだが
readonlyならどうしようもないな、ﾄﾝｸｽ
文字列に書き出すのはdoc.documentElement.innerHTMLで一発じゃない？
IE7 で getter-property を定義する方法はないものでしょうか
var obj = {};
Object.defineProperty(obj, 'length', {get: function () { return Object.keys(this).length; });
var obj = {};
Object.defineProperty(obj, 'length', {get: function () { return Object.keys(this).length; });
>>534
残念ながらIE7でgetterは実現できません
残念ながらIE7でgetterは実現できません
javascriptってflashみたいに
｢今見てるか、そのウィンドウが有効化されてるかどうか｣
っての判別できますか？
最小化されてたりタブにあるだけだったら停止みたいなの造りたいんですが
｢今見てるか、そのウィンドウが有効化されてるかどうか｣
っての判別できますか？
最小化されてたりタブにあるだけだったら停止みたいなの造りたいんですが
>>537
これでどうじゃろ http://hakuhin.jp/js/page_visibility.html
これでどうじゃろ http://hakuhin.jp/js/page_visibility.html
>>537
addEventListener('blur', listener, false);
addEventListener('blur', listener, false);
【JavaScript】メモリの浪費を避けるコーディング
http://utage.headwaters.co.jp/blog/?p=1116
こちらの後半に
> elemはfuga内のelem(3行目)からスコープチェーンで参照され、fugaはaddEventListener(6行目)によってelemから参照されているため、
> fuga -> elem -> fugaという循環参照が発生しています。これを回避するためには、単純にfugaをグローバルスコープにしてあげればOKです。
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。
との記述があるのですが、自分にはどちらも循環参照に見えます。
どうか一方は循環参照ではない事の解説をお願いします。
http://utage.headwaters.co.jp/blog/?p=1116
こちらの後半に
> elemはfuga内のelem(3行目)からスコープチェーンで参照され、fugaはaddEventListener(6行目)によってelemから参照されているため、
> fuga -> elem -> fugaという循環参照が発生しています。これを回避するためには、単純にfugaをグローバルスコープにしてあげればOKです。
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。
との記述があるのですが、自分にはどちらも循環参照に見えます。
どうか一方は循環参照ではない事の解説をお願いします。
>>541
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。
循環参照してる上に説明文も誤りですね
グローバルスコープにする必要があるのは elem ですし、グローバルスコープにしても循環参照はします
グローバルスコープにする理由は、DOMオブジェクトをグローバル変数にしておけば循環参照してもGCが期待通りにメモリを解放してくれるからです
var elem = document.getElementById('Sample');
elem.addEventListener('click', function (event) {
console.log(elem);
}, false);
また、この場合は event.currentTarget で対象の要素ノードを取得出来るので変数束縛する必要もありません
そもそも、このメモリリーグ問題は attachEvent を使う古い実装で発生したはずなので実証コードも良くないですね
IE8- の attachEvent なら event.currentTarget は存在しないので elem の変数束縛も納得できます
最も、event.target から該当ノードを検索すれば循環参照そのものを回避出来ますが
循環参照させないコード例とか、detachEvent で unload 時に明示的に参照を切る方法とか、その記事で触れられていない対策があるのも気になります
> グローバルスコープにすることで、スコープチェーンによる参照が無くなるため、循環参照は発生しなくなります。
循環参照してる上に説明文も誤りですね
グローバルスコープにする必要があるのは elem ですし、グローバルスコープにしても循環参照はします
グローバルスコープにする理由は、DOMオブジェクトをグローバル変数にしておけば循環参照してもGCが期待通りにメモリを解放してくれるからです
var elem = document.getElementById('Sample');
elem.addEventListener('click', function (event) {
console.log(elem);
}, false);
また、この場合は event.currentTarget で対象の要素ノードを取得出来るので変数束縛する必要もありません
そもそも、このメモリリーグ問題は attachEvent を使う古い実装で発生したはずなので実証コードも良くないですね
IE8- の attachEvent なら event.currentTarget は存在しないので elem の変数束縛も納得できます
最も、event.target から該当ノードを検索すれば循環参照そのものを回避出来ますが
循環参照させないコード例とか、detachEvent で unload 時に明示的に参照を切る方法とか、その記事で触れられていない対策があるのも気になります
>>545
循環参照とメモリリークパターンは下記を参考に
http://msdn.microsoft.com/ja-jp/library/bb250448.aspx
http://d.hatena.ne.jp/babu_babu_baboo/touch/20100417/1271465430
「この辺の知識」とは具体的には？
基本的に情報は公式サイト以外は信用しない
リークパターンでいうならMSDNを検索して検索して検索する
一次情報に勝る信頼性はないからそうしてる
リークパターンは情報が少なくて信用出来る意見を個人サイトから取り入れたのもあるけど、それでも公式サイトとの正誤比較は必須と思ってる
循環参照とメモリリークパターンは下記を参考に
http://msdn.microsoft.com/ja-jp/library/bb250448.aspx
http://d.hatena.ne.jp/babu_babu_baboo/touch/20100417/1271465430
「この辺の知識」とは具体的には？
基本的に情報は公式サイト以外は信用しない
リークパターンでいうならMSDNを検索して検索して検索する
一次情報に勝る信頼性はないからそうしてる
リークパターンは情報が少なくて信用出来る意見を個人サイトから取り入れたのもあるけど、それでも公式サイトとの正誤比較は必須と思ってる
jQueryを使うと循環参照していても
メモリリークしないのはどういう理屈でしょうか？
メモリリークしないのはどういう理屈でしょうか？
>>548
1. JavaScriptだけの世界においては循環参照していてもメモリリークは起きない
2. DOMはブラウザが持っているAPIで、JavaScriptで実装されたAPIではない。（今は多少状況が違っていたりする）
3. JavaScriptとDOM（JavaScriptの外）で循環参照しているのがメモリリークになる
4. 循環参照が起きやすいのが、DOMのイベントハンドラ
5. jQueryではDOMに直接イベントハンドラを設定せずに内部で独自に管理している
6. その為、イベントハンドラのJavaScriptとDOMが直接循環参照しない
1. JavaScriptだけの世界においては循環参照していてもメモリリークは起きない
2. DOMはブラウザが持っているAPIで、JavaScriptで実装されたAPIではない。（今は多少状況が違っていたりする）
3. JavaScriptとDOM（JavaScriptの外）で循環参照しているのがメモリリークになる
4. 循環参照が起きやすいのが、DOMのイベントハンドラ
5. jQueryではDOMに直接イベントハンドラを設定せずに内部で独自に管理している
6. その為、イベントハンドラのJavaScriptとDOMが直接循環参照しない
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (116) - [100%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.128 + (1001) - [97%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
トップメニューへ / →のくす牧場書庫について