このように使用できます。しかし、それは良い考えではないと思います。webshims lib は、Web フォームにいくつかの優れた拡張機能を追加し (エラー バブルのスタイリング/検証テキストの変更)、modernizr では機能が検出されないいくつかのバグも修正します。さらに、パフォーマンスの向上は見られないと確信しています (polyfiller.js が小さすぎます)。実際、最初にポリフィラーをロードしてからシムをロードするという事実により、多くのブラウザーでパフォーマンスに多少の「ペナルティ」が発生します。これは、これを行う方法は次のとおりです。
この警告を追加したのは、多くの人が単純にすべてを DOM-Ready コールバック内に追加することを知っているからです。
//this is not what you should do:
$(document).ready(function(){
$.webshims.polyfill('forms');
});
//instead do this:
$.webshims.polyfill('forms');
$(document).ready(function(){
//DOM and forms feature are available
});
polyfill.js を動的にロードする場合は、さらに 2 つのことを行う必要があります。
- ポリフィルへのパスを指定します (これは、最後のスクリプトのスクリプト パスを取得できるため、通常の埋め込みでは必要ありません)
これは、次の方法で行います。
$.webshims.loader.basePath = 'path-to-shims-folder/';
$.webshims.polyfill();
- DOM-Ready で HTML5 機能のスクリプトを作成したくない場合のみ (submit、invalid、input などの機能のスクリプトを作成したくない場合)
スクリプトがロードされる前に DOM-Ready がすでに発生している可能性があるため、webshims の追加の ready-method を使用する必要があります (通常、webshims はこの処理をスムーズにするために ready イベントを遅らせます)。
これは、次のコードで実行できます。
$.webshims.ready('forms DOM', function(){
//give me the validationMessage of the first input
alert($('input').attr('validationMessage');
});
標準機能のみが必要で、webshim のスクリプトを作成したくない場合は、次の方法を使用してください。
yepnope({
test: blah,
nope: '/_scripts/polyfiller.js',
complete: function () {
$.webshims.loader.basePath = '/_scripts/shims/';
$.webshims.polyfill('forms');
}
});
DOM-Ready/Feature-Loading の直後にスクリプトを作成する場合は、次の手順を実行する必要があります。
yepnope({
test: blah,
nope: '/_scripts/polyfiller.js',
complete: function () {
$.webshims.loader.basePath = '/_scripts/shims/';
$.webshims.polyfill('forms');
$.webshims.ready('forms DOM', function(){
//give me the validationMessage of the first input
alert($('input').attr('validationMessage');
});
}
});
どちらの場合も、スクリプトの警告はそのまま残りますが、関心のある開発者だけがそれらを見ることができます。
webshims lib バージョン 1.5.2 /HTML5 フォームの現在の状態に関する情報。2 つの既知の問題があります。
- $.webshims.activeLang の呼び出しは最初は機能しません (このメソッドは polyfiller から domextend に移動されました)
- インタラクティブな制約の検証と静的な制約の検証について、HTML5 仕様の一部を誤解しています (そして、私の実装を古い仕様と混ぜ合わせました) 。その結果、Opera と私のcheckValidityの実装は正しくないため、これを使用しないでください :-)。
どちらのバグもすでに修正されています。時間をかけて追加のテストを行いますので、今週末にバグリリースを期待してください :-)。これらの機能の一部が必要な場合は、現在のマスター ブランチを取得できます (これは非常に安定していますが、リリースする前に、さらに x ブラウザー テストを行う必要があります)。
いくつかのパフォーマンスルールについて:
ほとんどの yslow ルールは 2006 年に作成されました。それ以来、多くの変更が加えられました。
- JS は完全にブロックしなくなりました。(これらの問題があるのは IE6 と IE7 だけですが、80% のブラウザにはありません)
- ほとんどのブラウザは、同時に 2 つ以上 (ほとんどの場合 4 ~ 8) のファイルをロードできます。
私のテストから、6から12の間でロードします!!! (はい、12 ファイル) js ファイルは、単一の js ファイルをロードするよりもはるかに高速です (テストは、css と画像の量とサイズが異なる複数の実際の Web サイトで行われました)。
JS を一番下に配置しても、ページの読み込み時間は短縮されません。JS を一番下に置くと、いわゆるホワイトページの時間が短縮されるだけですが、これは常にスタイルのない/動作しないコンテンツの Flash につながります。FOUC が気に入らない場合は、JS を一番上に置きます。ミックスが必要な場合は、HTML ヘッドでスクリプトローダー (白いページの時間を減らし、FOUC を減らす) を使用し、そこからスクリプトをロードします。