では、カスタムHTML属性が有効なXHTMLではない場合はどうでしょうか。
一部の人々がそれらを承認しない理由はそれですが、それは本当に重要ですか？ JavaScriptとのやり取りや、サーバーとの間での情報の保存と送信において、彼らが提供する力は、検証の懸念を上回っていると思います。何か不足していますか？ 「無効な」HTMLの影響は何ですか？そして、カスタムDTDはとにかくそれらを解決しませんか？
その結果として、w3cは2、5、10年で登場し、同じ名前の属性を作成します。今あなたのページは壊れています。
HTML5は、合法的なカスタム属性（data-myattr = "foo"など）のデータ属性タイプを提供するため、今すぐ使用して、将来の名前の衝突からかなり安全になる可能性があります。
最後に、カスタムロジックがクラス属性の背後にある合理的であることを見落としている可能性があります。通常はスタイル属性と見なされますが、実際には、要素にカスタムメタプロパティを設定するための正当な方法です。残念ながら、基本的にはブールプロパティに制限されているため、HTML5がデータプレフィックスを追加しています。
ちなみに、「基本的にはブール型」というのは、原則としてです。実際には、クラス名でセパレーターを使用してカスタム値と属性を定義するのを止めるものは何もありません。
class="document docId.56 permissions.RW"
はい、「データ」を使用してカスタム属性を合法的に追加できます。
例えば：
<div id="testDiv" data-myData="just testing"></div>
その後、jqueryの最新バージョンを使用して、次のようなことを行います。
alert($('#testDiv').data('myData'))
またはデータ属性を設定するには：
$('#testDiv').data('myData', 'new custom data')
また、jQueryはほとんどすべてのブラウザーで機能するため、問題はありません;）
更新
- javaScriptエンジンに関する限り、一部のブラウザではdata-myDataがdata-mydataに変換される場合があります。小文字にしておくことをお勧めします。
検証はそれ自体が目的ではありませんが、間違いを早期に発見し、複数のブラウザタイプで使用したときにWebページが直面する可能性がある不思議なレンダリングや動作の問題の数を減らすために使用するツールです。
カスタム属性を追加しても、現在これらの問題のいずれにも影響はありませんが、将来的にはそうなる可能性は低いですが、検証されないため、ページの検証の出力を評価するときに、次のことを行う必要があります。重要な検証の問題とそうでないものの間で慎重に選択してください。ページを変更して再検証するたびに、この操作を繰り返す必要があります。ページが完全に検証されると、緑色のPASSメッセージが表示され、テストの次の段階、または必要な次の変更に進むことができます。
単純なカスタム属性を使用するよりもはるかに悪い/奇妙なことを行う検証に取りつかれている人を見てきました。
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
私の意見では、カスタム属性は本当に重要ではありません。別の言い方をすると、標準に属性が将来追加されることに注意することは良いことかもしれません。しかし、今はHTML5にdata- *属性があるので、保存されます。
本当に重要なのは、タグが適切にネストされ、属性値が適切に引用されていることです。
カスタムタグ名（ヘッダー、フッターなど、HTML5で導入されたもの）も使用していますが、IEでは問題があります。
ちなみに、皮肉なことに、iframeのアップロードなど、Googleの巧妙なトリックの前でこれらの検証の熱狂者が頭を下げていることがよくあります。
カスタム属性を使用する代わりに、JSONを使用してHTML要素を属性に関連付けることができます。
var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };
影響については、 SpliFFの回答 を参照してください。
Class属性に複数の値を格納することは、正しいコードのカプセル化ではなく、複雑なハックの方法です。たとえば、jqueryを使用するカスタムad rotatorを取り上げます。ページ上で実行する方がずっとクリーンです
<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />
そして、いくつかの単純なjqueryコードがここから作業を行うようにします。どんな開発者やWebデザイナーでも、広告ローテーターに取り組んで、あまり面倒なく尋ねられたときに値をこれに変更できます。
1年後のプロジェクトに戻るか、前の開発者が分割して太平洋のどこかの島に行った新しいプロジェクトに戻ってくると、コードが次のような明確な暗号化方法で記述されている場合、意図を理解しようとするのは一苦労です。
<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes" />
C＃および他の言語でコードを記述する場合、すべてのカスタムプロパティをスペース区切りの文字列として1つのプロパティに配置するコードは記述せず、アクセスまたは書き込みが必要になるたびにその文字列を解析する必要があります。あなたのコードに取り組む次の人について考えてください。
検証の問題は、今日は問題にならないかもしれませんが、明日問題になるかどうかはわかりません（そして、マーフィーの法則により、明日問題になるでしょう）。
将来を見据えた代替品を選ぶ方が良いです。それらが存在しない場合（ この特定のケースではあります ）、次に進む方法は、将来の証明に代わるものを発明することです。
カスタム属性の使用はおそらく無害ですが、それでも害がないと考えている（確信が持てない）だけで、なぜ潜在的に有害なソリューションを選択するのですか？将来の証拠の選択肢が高すぎるか扱いにくい場合は、これについてさらに検討する価値があるかもしれませんが、これは確かにそうではありません。
古い議論ですがそれでも;私の意見では、htmlはマークアップであり、プログラミング言語ではないため、マークアップの「エラー」については常に寛大に解釈する必要があります。ブラウザは完全にそうすることができます。これが変わることはないと思います。したがって、重要な唯一の実用的な基準は、HTMLがほとんどのブラウザーで正しく表示され、数年後もそうであるということです。その後、HTMLはおそらく再設計されます。
成分をミックスに追加するだけで、自動化ツールを使用して後処理できる/後処理できるコンテンツを作成する必要がある場合は、検証も重要です。コンテンツが有効であれば、マークアップをある形式から別の形式にはるかに簡単に変換できます。たとえば、特定のスキーマを使用して有効なXHTMLからXMLを実行することは、予測可能な形式に従っていることがわかっていて検証できるデータを解析するときにはるかに簡単です。
たとえば、コンテンツがさまざまなジョブのためにXMLに変換され、データ損失や予期しないレンダリング結果なしに変換されることが多いため、コンテンツは有効なXHTMLである必要があります。
まあそれはあなたのクライアント/ボス/等に依存します..彼らはそれがXHTMLを検証していることを必要としますか？
いくつかの回避策があると言う人もいます-そして、シーンに応じて、彼らは素晴らしい仕事をすることができます。これには、クラスの追加、rel属性の活用、および独自のパーサーを作成してHTMLコメントからJSONを抽出する人も含まれます。
HTML5はこれを行う標準的な方法を提供し、カスタム属性の前に「data-」を付けます。標準XHTMLのトラックで使用される属性を使用する可能性があるので、とにかく今これを行うことをお勧めします。
検証
検証を提供するためにカスタム属性は必要ありません。より良いアプローチは、フィールドの実際のタスクに基づいて検証を追加することです。
クラスを使用して意味を割り当てます。私は次のようなクラス名を持っています：
date（日付）Zip（郵便番号）area（エリア）ssn（社会保障番号）
マークアップの例：
<input class="date" name="date" value="2011-08-09" />
JavaScriptの例（jQueryを使用）：
$('.date').validate(); // use your custom function/framework etc here.
特定のシナリオで特別なバリデーターが必要な場合は、特別なケースで新しいクラスを作成する（または selectors を使用する）だけです。
2つのパスワードが一致するかどうかを確認する例：
<input id="password" />
<input id="password-confirm" />
if($('#password').val() != $('#password-confirm').val())
{
// do something if the passwords don't match
}
（このアプローチは、jQuery検証とmvc .netフレームワークの両方で非常にシームレスに機能し、おそらく他のフレームワークでも機能します）
ボーナス：スペースで区切られた複数のクラスを割り当てることができますclass = "ssn custom-one custom-two"
「サーバーとの間の」情報の送信
データを返す必要がある場合は、<input type="hidden" />。彼らは箱から出して動作します。
（非表示の入力を含む機密データを渡さないようにしてください。ユーザーがほとんど手間をかけずに変更できるためです）
非標準のHTMLを使用すると、ブラウザがページを「奇妙なモード」でレンダリングする可能性があります。その場合、ページの他の一部のレンダリングが異なる場合や、配置などの他のものが少し異なる場合があります。ただし、カスタムDTDを使用すると、これを回避できる場合があります。
markupが無効な場合、jquery .html（markup）は機能しません。
それらは標準ではないので、あなたは現在も将来も何が起こるかわからない。他の人が言ったように、W3Cは将来同じ名前を使い始めるかもしれません。しかし、さらに危険なのは、「ブラウザーxxx」の開発者が遭遇したときに何をしたかが分からないことです。
おそらく、ページは互換モードでレンダリングされ、ページはallでレンダリングされない可能性があります。一部のあいまいなモバイルブラウザーでは、ブラウザーがメモリリークを起こし、おそらくウイルスキラーがページを詰まらせます。などなど.
基準を忠実に守ることは、ごまかしのように思えるかもしれません。しかし、それらに従わなかったために問題を経験すると、そのように考えるのをやめる傾向があります。ただし、それではほとんど手遅れで、別のフレームワークを使用してアプリケーションをゼロから開始する必要があります...
開発者は検証するためだけに検証を行うと思いますが、マークアップをクリーンに保つという事実については言いたいことがあります。ただし、すべての（誇張警告！）ブラウザーではすべてが異なって表示されるため、実際には標準はありません。少なくとも何らかの方向性があるように感じるので、基準に従うようにしています。一部の人々は、コードを標準に保つことで、将来的に問題や競合を防ぐことができると主張しています。私の意見：とにかく今日誰も標準を正しく完全に実装していないというねじは、すべてのコードが最終的に失敗することを想定しているかもしれません。動作する場合は動作しますが、乱雑な場合や、W3Cなどに準拠するために標準を無視しようとしている場合を除き、使用してください。標準の実装は非常にゆっくりであり、ウェブは5年間でそれほど大きく変化したことを覚えておくことは重要だと思います。潜在的な競合を修正する必要がある場合、誰もが何年にもわたって通知を受けることになると私は確信しています。今日の標準に頼ることさえできないときに、将来的に標準の互換性を計画する理由はありません。
ああ、私はほとんど忘れていました。コードが検証しないと、10匹の子猫が死んでしまいます。あなたは子猫キラーですか？