非表示の入力とHTML5データ属性
最近私を悩ませているのは、 HTML5データ属性 の使用と、それらを使用するのに適切な時期です。
通常、サーバーに対してAJAX呼び出しを何度も実行するページでは、表示されているページを表すIDが必要です。現在これを保存しています。ページ上の非表示の_<input>_要素内にあり、jQuery docready呼び出しの上部にあるJS変数にアクセスして保存します。
Body要素の_data-id_属性に移動することを検討しており、$('body').data('id');を使用してjQueryでアクセスします。
HTML5データ属性を使用すること、またはその逆の利点はありますか？パフォーマンス？セキュリティ？ "ベストプラクティス"？
すべてのブラウザからデータ属性にアクセスできることを理解しているので、IEの処理は問題ではありません。
主な欠点の1つは、アクセシビリティです。
これらの属性はPOSTでサーバーに送信されないため、JavaScriptが無効になっているブラウザーで何が起こるかを覚えておく必要があります。ページも正常に劣化し、必要に応じて従来のフォーム送信を介して同じAJAX要求機能を実行できる必要がある場合でも、非表示フィールドが必要になります。
とは言うものの、特にJavaScriptを安全に委任できる厳密に「アプリケーション」タイプのサイトでは、データ属性が理にかなっている場合、私はデータ属性の大ファンです。たとえば、テーブルの行にdata-id属性のタグを付ける方が、セルの1つに非表示のフィールドを詰め込むよりもはるかに優れています。特に、.data()メソッドに対するjQueryのNicedata-attributeサポートと組み合わせると、非表示フィールドが少し乱雑になる可能性がある状況で、クリーンで直感的なコードが作成されます。
これが私の見解です：
- 非表示の
inputsは、ページ上でデータを表示または編集可能にすることなく、データをサーバーに戻す方法としてフォームで使用することを目的としています。 - 属性は、要素のプロパティを説明するためのものです。
data-属性は、要素に関する情報をページ上のJavaScriptに伝達することを目的としています。
これに基づくと、htmlまたはbody要素のdata-属性が最も適切であると思われます。
セマンティックではありませんが、別の解決策は、ページのメタデータをJSONとしてシリアル化し、scriptタグを使用してページのグローバル変数として設定することです。これは、たとえば GitHubリポジトリ で実際に動作していることがわかります。ここでは、グローバルGitHubオブジェクトがページの上部近くに作成され、いくつかの情報（リポジトリ名、現在のブランチ）が作成されます。 、最新のコミット）が追加され、簡単にアクセスできます。
この投稿がアクティブになってからしばらく経ちましたが、最近このトピックに出くわしたので、2つのパフォーマンスの側面についてコメントしたいと思います。
他の人が指摘しているように、データ属性はDOM自体にデータを格納するためのものであり、HTML5以前は、DOMにネストされた非表示の入力を使用するか、他の属性を使用することで、このニーズを回避するさまざまな方法がありました。
非表示の入力は、他の多くの属性を持つ（より多くのメモリを消費する）DOMオブジェクトであるため、（特にスケールアップする場合）パフォーマンスが高くなります。
他の属性を使用すると、非表示の入力に比べてメモリ効率が高くなりますが、より多くの処理が必要になる場合があります。おそらく、それらに何かを接頭辞として付け、それらの接頭辞を使用してデータを抽出する必要があります。さらに、それらを設定して取得することも難しい場合があり、一部の要素のデフォルト機能を台無しにする可能性があります。
したがって、非表示の入力とデータ属性のどちらを選択するかについて、私が自分で設定した一連のガイドラインを次に示します。
- データがフロントエンド機能のみを対象としている場合は、データ属性を選択します（再送信する必要はありません）
- 保存する必要のある大規模なデータがある場合は、データ属性を選択します（例：グラフ座標、複数のパラメーターを持つ大規模なリスト）
- データの大きなチャンクまたは特殊文字を含むデータを格納する場合は、非表示の入力を選択します
データ属性は新しいため、それらがいつ適切であるか、またはベストプラクティスが何であるかについてはまだ実際のコンセンサスはないと思います。ページのさらに下のDOM要素にデータを添付するときにそれらが論理的にそれらのDOM要素と一緒になっているので、それらが非常に理にかなっていると私は個人的に感じています。 bodyタグでそれらを使用することを検討しているとき、なぜこれらの値を通常のjavascript変数に保持しないのか疑問に思います。通常のjavascript変数を使用するとパフォーマンスが向上すると思います。これらの変数はすべてFirebugなどで簡単に表示できるため、その意味で多かれ少なかれ安全である可能性はほとんどありません。
ページの初期状態に関しては、JavaScript変数を、使用方法の非表示フィールドではなく、ページに直接配置できるようです。サーバーにフォームを投稿する場合、非表示の要素はそこで役立つ可能性があります。これは、非表示の要素が設計された目的です。
これに関するベストプラクティスは何かについての良い未解決の質問です。
一言で言えば、データ属性は、非表示の入力が別のDOM要素内にあることができず、その使用がフォームに制限されている属性によって記述される要素にアタッチできます（とにかく良い習慣です）。非表示の入力は実際のDOM要素ですが、データ属性は適切です...その属性なので、DOM要素にバインドできます。ほとんどの場合それですが、もっと情報が必要で、例を読み続ける必要がある場合は、少し長く、英語は私の母国語ではないことを警告します。
基本的に、data属性は、DOM要素に追加情報を追加するために作成されました。これは、クラスや古き良きIDなどの既存の属性で他の方法では添付できません。
これは主にWebベースのアプリ、より具体的にはSaasに影響します。この場合、データ駆動型属性の必要性は通常のWebサイトよりもはるかに広範囲です（背後にCMSがある場合でも）。
私は何年も前、2つの選択肢しかなかったときに、この属性について夢を見ていました。
- 私たちが使っていないものにはhtml属性を使用してください
最初に作成または設計された - トークンを含むhtml属性を使用して、クライアント側またはサーバー側の関数（split、splice、explode）でデコードします。
このアプローチの問題は、どのように見ても、使用するように意図および設計された方法でhtml属性を使用していないことです。
Htmlはマークアップ言語であるため、データ処理や動作を操作するために使用できないデータ駆動型の属性は自然にはありません。
そのときの基本的なシナリオは、すべてのデータ入力フォーム（クライアント、製品、サプライヤーなど）をロードする単一のjQueryダイアログが必要だったというものです。各フォームの幅と高さは異なります。そうすれば、クライアント側のスクリプトははるかに小さくなり、クライアントから要求されたアプリに追加された新しいフォームごとに新しいダイアログを追加する必要があります。
これは、データ属性が登場する前に私が行っていた方法です：
クリックして新製品を追加
Idトークン内に3つの値がありました：
- サーバーからロードされるフォーム
- ダイアログウィンドウの幅
- ダイアログウィンドウの高さ
他のアプローチはhref属性を使用することですが、これは、href属性が処理されるデータを保持するのではなくDOM要素または別のソースを指すことを意図しているという理由だけで、idを使用するよりもはるかに悪いです。
どちらのアプローチでも、splitまたは同様の機能を使用してトークンを分解する必要があります。
これは私が今素晴らしいデータ属性でそれを行う方法です：
クリックして新製品を追加
このように、トークンは必要ありません。古き良き$（this）.attr（ 'data-form'）;、$（this）.attr（ 'data-dwith'）;を使用して各属性の値を取得できます。等々。
私見私は、はるかに長いjavascriptファイルを作成して、より重く、より複雑にするよりも、html要素に少し余分なデータを追加する方が良いと思います。