速さが問題になってない時に速さを聞くのは、
速さしか良い悪いの比較方法を知らないからなんだろうな。

速さが問題になってないのなら、比較するときに茎べき言葉は
どちらがメンテナンス性高い？ やどちらが短くかける？ だ
メンテナンス性が高くて短い方が、バグも減るし。

>>501
それは当事者が考えるべきことであなたが心配することじゃない

>>503
当事者に考えさせるために言ってる。
いわば教育。

いちいちあんたが反論することじゃない。

>>504
ケースバイケースなのに速度に問題がないと決めつける必要はない
あなたの視野が狭いだけ

だからどんなケースって聞くわけさ。

そしたら経験上、速度が問題にならないケースが99%

>>496だけどすまんかった。
速度に問題があってパフォチューしてた。
.eq(i)にしてたんだけど、もっと速くなるならと思って聞いてみた。
$(selector)[index]にしてみたけどouterWidth()が
jqueryみたいで残念ながらダメだった。

パフォーマンスチューニングとは
どこが遅いか？って聞くことではなく、

どこにどれだけの時間がかかっているかを
調べることだ。

>>507
jQueryをなくしてみたら？
あるいはアルゴリズムに問題があるのかもしれない

jQueryを隠すと、開発効率が大幅に下がるからなぁ。
それじゃ本末転倒だし。

>>507
outerWidth()でふと思ったんだけど、ひょっとしてブラウザに何度もレンダリングさせて
描画サイズを取得してどうこうって処理でもしてる？

JavaScriptでバナーを貼ると空間ができるのですが
バナー同士くっつけるんには、どうしたらいいのでしょうか？

そりゃcssのお話や
一応jsでもこんな感じでいけるけどな
$(".banner").css("margin","0")

ありがとうございます。

<div id="wrapper">
<div id="slider">
<p class="left">←</p>
<div class="box">あ</div>
<div class="box">い</div>
<div class="box">う</div>
<div class="box">え</div>
　　　　　　　　　　　　：
　　　　　　　　　　　　：
<p class="right">←</p>
</div>

すみません；間違えて途中送信してしまいました

#wrapper{position:relative; width:100%; overflow:hidden;}
#slider{position:absolute left:0; width:9999px;}
.box{width:200px;}


<div id="wrapper">
<p class="left">←</p>
　　<div id="slider">
　　<div class="box">あ</div>
　　<div class="box">い</div>
　　<div class="box">う</div>
　　<div class="box">え</div>
　　　　　　　　　　　　　　：
　　　　　　　　　　　　　　：
　　</div>
<p class="right">←</p>
</div>


$('#wrapper .right').click(function(){
$('#slider').stop().animate({'left':'+=800px'},400);
});


こんな感じのスライダーを作ったのですが、←や→のボタンを速めに連クリックすると
#sliderの位置が中途半端なところで止まってしまったりしてカッコ悪いのですが
こういう場合ってどう対処するのが適切なんでしょうか？

.right(.left)を一度クリックしたら、キッチリ800px分のanimateが終わるまでは
押せないようにすることとかってできますか？

あ・・・　+=800pxではなく-=800pxでした

クリックしたときの処理の最初に追加
if($("#slider").is(":animated")) return;

お早い返答ありがとうございます！解決しました！

>>515-518
何も反応しないけど、何をやりたいの？
サンプルを出すなら動く事を確認してから出して
>>1にサンプルコードを載せるサイトが載ってるでしょ
http://jsfiddle.net/j8fdg81b/

解決したのね

jQuery.ajax でhtmlを取得するときimgタグがあれば画像もロードされますが、これを抑止するオプションはありますか？
Ajax options で、
dataFilter: function (data) {
data = data.replace('img', 'noimg');
return data;
}
のようにすると抑止されるのは確認できましたが、
根本的にimgタグがそのままでもロードさせないオプションがないかと調べていますが見つけられません
よろしくお願いします

>>523
そういったオプションはないと思う
HTMLがそのままでも読み込まないようにしたいならDOMParserしかないだろう
http://developer.mozilla.org/ja/docs/Web/API/DOMParser

>>524
ありがとうございます。調べてみます。

DOMParserは大半のブラウザに対応してないみたいだから使えないだろうね。

imgタグがあってもdocumentに追加していなければ
画像はロードされないはずだから、

var $elements = $(data);

// ここでimgタグを探してsrcからdata-srcに移動
$elements.find('img').each(function() {
　　$(this).data('src') = $(this).attr('src');
　　$(this).removeAttr('src');
});

$(document.body).append(elements);

とかでもいいかも。まあやってることは>>523とはそう変わらないけど
DOMとして解釈している所が違うかな。

>>526
> DOMParserは大半のブラウザに対応してないみたいだから
そんなことはない

> imgタグがあってもdocumentに追加していなければ画像はロードされないはずだから、
new Image でもロードされる

>>527
デスクトップ モバイル
機能 Chrome Firefox (Gecko) Internet Explorer Opera Safari (WebKit)
XML のサポート (有) (有) (有) (有) (有)
SVG のサポート ? 10.0 (10.0) ? ? ?
HTML のサポート ? 12.0 (12.0) ? ? ?

>>528
出典ぐらい示せ
古いMDNを見てるんじゃあないのか？
実際に使ったことがある人なら情報が古い事にすぐ気がつくはずだが
http://developer.mozilla.org/en-US/docs/Web/API/DOMParser

>>523 ですが、画像がロードされるタイミングを理解していなかったことに気がつきました
自分のコードでは$.parsHTML(data)や$(data)を実行したときにロードされていました
一方、DOMPaserを使うとロードされないのですね

そうそう。普通にimg要素を作っちゃうと、documentに追加しなくても勝手にロードしちゃう
逆にこれを利用すると画像のプリロードをすることができる

>>529
Safariはnot supportじゃねーかｗ

>>532
それのどこが「大半のブラウザに対応してない」なんだ？
>>528のような古い情報を持ち出しておいて今更体裁を取り繕っても無駄

じゃあ、言い換えるよ？

DOMParserはSafariに対応していないからだめだろう。

SafariとかIE8とか切り捨てればいいじゃん。
最新のブラウザを使ってるユーザーしかサポートしません。
古い端末を買い換えない奴なんて見捨てればいいんだよ。

>>534
Safari には createHTMLDocument ガあるから問題ない
クロスブラウザを指摘するなら駄目出しだけせずに代替機能を把握しておけ
http://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation.createHTMLDocument

一番いいのは、各ブラウザごとの仕様の差を吸収する
ライブラリを使うことなんだよな。

http://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
> DOM Parsing and Serialization
>
> insertAdjacentHTML.js by Eli Grey, implements insertAdjacentHTML
> outerHTML.js by Eli Grey, implements outerHTML
> DOMParser HTML extension by Eli Grey, implements DOMParser text/html support

ここに書いてある、DOMParser HTML extension
http://gist.github.com/eligrey/1129031
ってのを使えばいいのでは？

クロスブラウザ対応のためにはブラウザの機能を直接使うのではなく、
こういうライブラリを使うのが一般的だよ。

この程度の Polyfill なら自前で書けるし、ライブラリを使うまでもないと思うがな
自分のコードに自信を持てない人はライブラリを使う
それだけの話

>>537
>http://gist.github.com/eligrey/1129031
これは酷いな
- DOMParser を使えない実装で ReferenceError
- text/html の決め打ち
- DOCTYPE宣言、head要素を無視

とてもじゃないが、DOMParser の Polyfill とは思えない
まともにコードを読めない人が質の悪いライブラリを使うのなら迷惑この上ない
http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#the-domparser-interface

DOMParserにHTMLも対応させるやつだからDOMParserが無いことは想定してないんでしょ

DOMParser がない実装向けのクロスブラウザが問題だったはずなのになぜこんなコードを紹介したんだろうな

Mozillaが紹介しているからだけど？
http://developer.mozilla.org/en-US/docs/Web/API/DOMParser
> DOMParser HTML extension for other browsers
> /* inspired byhttp://gist.github.com/1129031 */

このスレで名前の上がってたSafariでさえもXMLはサポートしてるんだからDOMParser自体はあるでしょうよ
確かめてないけど

・DOCTYPE宣言がなくてhead要素があるとおかしくなる
・html要素があるとおかしくなる
・IE8以下でReferenceError

クロスブラウザを問うならこのぐらいは見ないと

「MDNにあったら無条件に信じる」は技術者として駄目だろ
DOMParser と createHTMLDocument はそれなりに仕様が異なるのでライブラリで吸収するならもっとコードが長くなる
実際にはその時々で分岐コードを書いてもたいして手間にならないし、間違いがない

いや、手間になるからコード長くなってるんだろｗ

この程度で長いと感じる人もいるんだな

いつも関数一つで数百行を相手にしている人にはそう感じるんですね。

俺なら一行が二行になったら、倍。と感じるわｗ

>>548
> いつも関数一つで数百行を相手にしている人にはそう感じるんですね。
それはおまえの思い込みによる決め付けだ

> 俺なら一行が二行になったら、倍。と感じるわw
必要以上のコード量があるのは無駄だが、「必要な処理が抜けている」との指摘にその反論は的外れだろう
反論したいならMDNのコードが必要十分だという具体的な根拠を出せ
おまえの勝手な思い込みや抽象論はどうでもいい

MDNのコードは足りない。
実際にはもっと多くのコードが必要。

それを自分で作るのが面倒だから
既存のライブラリを使うって話になる。