最近私を悩ませているのは、HTML5 データ属性の使用と、いつそれらを使用するのが適切かということです。
通常、サーバーに対して多数の AJAX 呼び出しを実行するページではID、表示されているページを表す が必要です。私は現在<input>、これをページの隠し要素に保存しています。その後、jQuery doc ready 呼び出しの上部にある JS 変数にアクセスして保存します。
私はそれをdata-idbody 要素の属性に移動することを検討しており、それを使用して jQuery でアクセスし$('body').data('id');ます。
HTML5 データ属性またはその逆を使用する利点はありますか? パフォーマンス？安全？"ベストプラクティス"？
データ属性はすべてのブラウザからアクセスできるので、IE を扱うことは問題ではないと私は理解しています。
主な欠点の 1 つはアクセシビリティです。
これらの属性は POST でサーバーに送信されないため、JavaScript が無効なブラウザーで何が起こるかを覚えておく必要があります。ページが正常に劣化し、必要に応じて従来のフォーム送信を介して同じ AJAX 要求機能を実行できる必要がある場合でも、非表示フィールドが必要になります。
そうは言っても、私は data- 属性が理にかなっていれば大ファンです。特に、JavaScript を安全に強制できる厳密な「アプリケーション」タイプのサイトでは特にそうです。たとえば、セルの 1 つに非表示のフィールドを詰め込むよりも、テーブルの行に data-id 属性をタグ付けする方がはるかに優れています。特に、メソッドに対する jQuery の優れた data- 属性のサポートと相まって.data()、隠しフィールドが少し乱雑になる可能性がある状況で、クリーンで直感的なコードが作成されます。
これが私の見解です：
inputは、ページ上でデータを表示または編集可能にすることなく、データをサーバーに戻す方法としてフォームで使用することを意図しています。data-属性は、要素に関する情報をページ上の JavaScript に伝えるためのものです。それに基づいて、 or要素のdata-属性が最も適切と思われます。htmlbody
セマンティックではありませんが、別の解決策は、ページのメタデータを JSON としてシリアル化し、scriptタグを使用してページのグローバル変数として設定することです。たとえば、GitHub リポジトリでこれを確認できます。グローバルGitHubオブジェクトがページの上部近くに作成され、いくつかの情報 (リポジトリ名、現在のブランチ、最新のコミット) が簡単にアクセスできるように追加されます。
データ属性は新しいため、それらがいつ適切であるか、またはベストプラクティスが何であるかについては、まだ実際のコンセンサスはないと思います。ページのさらに下のDOM要素にデータを添付するときにそれらが論理的にそれらのDOM要素と一緒になっているので、それらが非常に理にかなっていると私は個人的に感じています。bodyタグでそれらを使用することを検討しているとき、なぜこれらの値を通常のjavascript変数に保持しないのか疑問に思います。通常のjavascript変数を使用するとパフォーマンスが向上すると思います。これらの変数はすべてFirebugなどで簡単に表示できるため、その意味で多かれ少なかれ安全であるとは考えられません。
ページの初期状態に関しては、JavaScript変数を、使用方法の非表示フィールドではなく、ページに直接配置できるようです。サーバーにフォームを投稿する場合、非表示の要素はそこで役立つ可能性があります。これは、非表示の要素が設計された目的です。
これに関するベストプラクティスは何かについての良い未解決の質問です。
一言で言えば、データ属性は、非表示の入力が別の DOM 要素内にあることができない領域である属性によって記述された要素に添付でき、その使用はフォームに限定されます (とにかく良い方法で)。非表示の入力は実際の DOM 要素ですが、data 属性はまあ...その属性なので、DOM 要素にバインドできます。大部分はそれで十分ですが、さらに情報が必要で、例を読み続けたい場合は、ちょっと長いので注意してください。英語は私の母国語ではありません。
基本的に、 data 属性は DOM 要素に追加情報を追加するために作成されました。それ以外の場合は、class や古き良き id などの既存の属性では関連付けることができません。
これは、主に Web ベースのアプリ、またはより具体的には、データ駆動型の属性の必要性が通常の Web サイトよりもはるかに広範囲にわたる (背後に CMS がある場合でも) SaaS に影響します。
選択肢が 2 つしかなかった何年も前に、私はこの属性について空想にふけっていました。
このアプローチの問題点は、どのように見ても、使用するように設計された方法で html 属性を使用していないことです。
Html はマークアップ言語であるため、データの処理や動作を操作するために使用できないデータ ドリブンの属性を自然に持つことはありません。
当時の基本的なシナリオは、幅と高さが異なるすべてのデータ入力フォーム (クライアント、製品、サプライヤーなど) を単一の jQuery ダイアログにロードすることでした。そうすれば、クライアント側のスクリプトははるかに小さくなり、クライアントから要求されたアプリに新しいフォームが追加されるたびに、新しいダイアログを追加する必要があります。
これは、データ属性が登場する前に私が行っていた方法です。
クリックして新しい製品を追加
id トークン内には、次の 3 つの値がありました。
別のアプローチとして href 属性を使用することもできますが、これは単に id を使用するよりもはるかに悪い方法です。なぜなら、href 属性は、処理するデータを保持するためではなく、DOM 要素または別のソースを指すことを意図しているからです。
どちらのアプローチでも、分割または同様の関数を使用してトークンを分解する必要があります。
これは、素晴らしいデータ属性を使用して今行う方法です。
クリックして新しい製品を追加
この方法ではトークンは必要ありません。古き良き $(this).attr('data-form');, $(this).attr('data-dwith'); で各属性の値を取得できます。等々。
IMHO私は、HTML要素に少し余分なデータを追加する方が、はるかに長いjavascriptファイルを作成して、より重くて複雑にする方が良いと思います。