W3C HTML5 バリデータ メンテナはこちら。バリデーターの動作に関する現時点での簡単な答えは、バリデーターは、ドキュメントで使用するカスタム要素に対してエラーを発生させようとしているということです。現在、ユーザーがそれを回避する方法はありません。解決策が見つかるまで、もうしばらくお待ちください。
これを解決する方法について、進行中の議論を行っています。ハイフンを含む要素名を無視するようにバリデーターを変更することは、完全な解決策としては実行できません。その結果、その要素が持つ可能性のある子要素を実質的にチェックできなくなり、サブツリー全体を無視する必要があるためです。そうしないと、他のエラーが発生する可能性があるためです。したがって、それは理想的なソリューションにはほど遠いものです。
とにかく、これを解決する良い方法を見つけたいので、他の人にアイデアがあれば聞きたいです。これに関するアイデア/提案を送るのに適した 2 つの場所は、public-webapps@w3.org メーリング リスト https://lists.w3.org/Archives/Public/public-webapps/と whatwg@whatwg.org メーリング リストhttps: //whatwg.org/mailing-list#specs
私が考えたアイデアの 1 つは、バリデーターにすべてのカスタム要素を現在の<div>
要素の処理と同じ方法で処理させることです (ドキュメント内で許可されている場所と、含めることが許可されている子要素に関する限り)。これも理想的ではありませんが、少なくともカスタム要素のサブツリー内の子孫要素のエラーをチェックする方法を提供します。
2017 年 2 月 6 日の更新: W3C HTML チェッカーがカスタム要素をサポートするようになりました
そこで、 2016 年 12 月 16 日にW3C HTML チェッカー(バリデーター) にカスタム要素のサポートを追加し、数日後にそれを改良して、禁止されている名前をより詳細にチェックできるようにしました。
これをチェッカー アーキテクチャ (コアは RelaxNG 文法/スキーマ ベースのバリデーター) に実装するために私が思いついたトリックは、要素名にハイフンを含むすべての要素を取得する前処理フィルターを追加することでした。それらを個別の XML 名前空間に配置します。
次に、RelaxNG スキーマを更新して、その XML 名前空間の要素をどこでも許可できるようにしました。(皮肉なことに、私は XML 名前空間とそれが引き起こすすべての問題が大嫌いです。)
そのため、カスタム属性名について同様のことを行うことを検討しています。おそらく、それらをハイフンを含む属性名 (カスタム要素名など) として定義するだけです。
ただし、HTML 仕様が更新されて許可されるまで、カスタム属性名を許可するように HTML チェッカーを変更することはできません。そのためには、HTML-spec issue tracker で議論されている提案を参照してください。