クラスと ID にはそれぞれ長所と短所があります (使い方にも大きく依存します)。
クラス- それらはスタイリング情報を伝えるように設計されていましたが、jQuery の出現により、アクション (またはデータ) を意味することもあれば、スタイリングを意味することもある二重の目的を持つようになりました。これは、特に大規模なプロジェクトでは非常に混乱します。デザイナーが CSS を「リファクタリング」しようとして、javascript/jQuery が接続されている要素のこれらのクラス名を変更しようとしていると想像してみてください。悪いことが起こります。非スタイリング クラス名の前に「.donttouchthis-jqueryclass」のような「名前空間」を付けることを軽減できます。これにより、ロジックとプレゼンテーションが非常に原始的な方法で区別されます。クラスを使用する利点は、「スタック」できるため、たとえば ID よりも複雑な「ロジック」を伝えることができることです。
ID - 名前が示すように、要素を一意に識別するように設計されています。プログラミングの観点から見ると、ID は DOM 内の要素にアクセスする最速の方法を提供します (getElementById)。スタイルを設定することもできますが、リファクタリング時に ID を削除する可能性は低くなります (いつでも ID スタイルを削除してクラスを与えることができるため)。ID は一意であるため、複雑なデータを保存するために ID を広範囲に使用することは非常に限られています。しかし、クリック ハンドラーをバインドしたり、DOM のチャンクを一意に識別したりするのには、それらによって識別される要素の 1 つだけが必要な場合に適しています。
クラスと ID の両方に、ビジネス ロジックを伝達する手段としての有用性を制限する重要なルールが 1 つあります。数字で始めることはできません (多くの場合、要素に都合よく割り当てられたデータベース ID が必要なだけです)。
カスタム属性(データではありません) - クールなものなら何でもかまいませんが、HTML の「有効性」を気にする場合は、特定の DTD タイプに制限され、DTD で指定する必要があります。実際には、ブラウザーは (W3C 規則の下で) 不明な属性を無視することが明確に義務付けられているため、HTML に害を及ぼすことはありません。唯一の問題は、潜在的な将来の開発との衝突です。純粋なJavaScriptを使用している場合、それらも使用するのが少し面倒です(ただし、これは主観的なオプションです-上記の回答の1つで示唆されているように、これはそれらをデータストレージとして使用するための優れた補足オプションです)。CSS をリファクタリングする際の混同の可能性はわずかです。
カスタム データ属性- jQuery を使用している場合、非常に複雑なデータ (オブジェクトなど) を保存できるため、これらは優れています。正しく使用すると、DOM 要素の機能を説明するための素晴らしい語彙が得られます。「data-」名前空間は、名前空間のない属性との将来の競合から適切に保護します。
最善の解決策は、これらのいずれにもあからさまに依存するのではなく、親 DOM 要素を渡して後でマークアップに基づいて機能を適用できるようにする JavaScript パターンを実装することです (標準の jQuery プラグイン パターンのように)。このようにして、静的 HTML ソースの一部である特定の属性/クラス/ID に対する多くの依存関係を削除します。